Hi, (CC-ing viennacl-devel, as this is developer-talk ;-) )
> Either way, I want to let you know that the generator/auto-tuner is > undergoing significant changes, and that you will, actually, not have to > worry about it for your GSoC project. The generator will be used > transparently via the viennacl::linalg:: functions, and the auto-tuner > will be entirely moved to pyviennacl. Well, I think this is not entirely unrelated. The purpose of the GUI is still to allow a broader community to feed us with benchmark data, so somehow the loop over all possible configurations is still essential. With an interface to Python I assume that an API to do exactly that will still be available ;-) > There is, however, one additional point I'd like to discuss. The > performance of all the algorithms you'll have to benchmark are highly > dependent on the characteristics of the input data. For example, matrix > products will behave very differently according to the size/shape of the > input matrices. This is very important : this means that a good > benchmarking GUI could help the users to design their system. > Here's an example. Suppose that someone wants to solve the linear system: > A*x* = *y* > If, for his particular application, A is a 50,000x50,000 sparse matrix, > then he could be greatly interested in knowing how he could pad A to > achieve better performance. In that case, the benchmarking-gui could > explore randomly R^2 beyond (50,000 ; 50,000), and potentially tell the > user that, if he makes A a (50,500; 50,500) matrix, then he could > improve his performance by say 10 or 20%. For sparse matrices I don't believe in random patterns. The user usually has a particular application in mind, so I consider it more important to a) Allow users to feed the tuner with their own sparse matrix b) Allow users to select sparse matrices from the Florida matrix market The second option is important for benchmark purposes and for comparison with data in the literature. We can also add a third option for random matrices, but it's certainly far less important. > In the case of dense matrix > products, one may even be able to double his performance by slightly > altering the size of the input matrices. Okay, this is only about adjusting the padding parameter and should transparently included in the tuning process anyway, shouldn't it? Best regards, Karli ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ ViennaCL-devel mailing list ViennaCL-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viennacl-devel
