Hey, > As far as I can tell, all you need to do is to adjust the matrix > sizes in the existing gemm tests? It covers all this already. What > am I missing? > > > Well, essentially it's about reajusting the size, yes. But the tests > should be slightly different and allow for multiple passes on multiple > size tuples.
Ok, that should be only a matter of reorganization. > The GEMM tests are quite an issue already, because they consume a > lot of time particularly on weaker systems. A substantial part of > the problem is the verification on the CPU with uBLAS, which both > adds an uBLAS dependency and is also rather slow. The current test > sizes are pretty much the minimum possible, but still they take > minutes to complete. Without a proper strategy to deal with this, > chances are high that we make our test system almost unmanageable... > Any clever approaches appreciated! > > > Well, with the current approach I've noticed that something a bit silly > is being done, in that products are computed many, many more times than > necessary. For all row/col layouts combination, A*B has to be computed > only once for full/range/stride. Then, C += A*B, C-=A*B can be tested on > the GPU without recomputing A*B on the CPU. This current redundancy is an artifact of trying to not only check the result values, but also to check all the entries outside the range or stride. For performance reasons, this has been cut down to only checking the result entries. > Right now, the CPU product is computed something like 8*27*12 = 2592 > times. We could equally test our GEMM implementation with only 27*4 = > 108 clever computations (all the full/stride/range combination for all > the transposition possibilities). Also, the test file is like 800 lines > long, which is a bit discouraging to modify :-p I'll refurbish it using > macros and such. As a side note, most tests could be really benefit from > using macros. I've lost a couple of hours a few days ago because the > vector tests report a failure on dot product when plane rotation is > faulty. There are a couple of similar glitches here and there. Perhaps > we should do this during the large code refactoring session we've planed > for a couple of weeks already :-p Feel free to do so. All modifications improving the test coverage by reducing the test size are appreciated. On the other hand, I will certainly complain if the test coverage is reduced ;-) (And yes, my overly cautious avoidance of macros for the test has bloated the code more than necessary. A controlled use of macros certainly makes sense here.) Best regards, Karli ------------------------------------------------------------------------------ _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
