Hi,
> 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 ;-)
>
>
> Well, looping over all the possible configurations for one particular
> problem size is good for benchmarking purpose only; the data generated
> this way will not be re-usable unless we can make some assumption on the
> input-data size.
The data is reusable, of course assuming that one knows the matrix sizes
it has been obtained for.
> That is, if the GUI only auto-tunes GEMV/GEMM for large
> square matrices, then we will collect a lot of pointless data.
Why is data pointless? I'd rather have only a few datapoints on new
hardware out there rather than having absolutely no data at all.
> Instead,
> the GUI should export a model which, given some input data sizes and a
> hardware configuration, is able to predict the optimal kernel. This is
> why the auto-tuner is being moved to pyviennacl.
> However, the GUI could/should indeed still be able to execute the
> corresponding python scripts.
I'd rather refrain from running Python scripts from the benchmark GUI.
This is intended to be an end-user tool. Those interested in running
from Python should take the Python code (i.e. PyViennaCL) directly.
> 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.
>
>
>
> We could also try to describe a sparse matrix by a few parameters
> (number of rows/cols, format, sparsity pattern, etc...) and use machine
> learning to predict the optimal kernel given an arbitrary sparse matrix.
> For the training data, we could use the Florida matrix market, indeed.
I agree with this approach. Everything is better than using a fixed work
group size as we do now (even though this is how other libraries deal
with the problem as well)
> 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?
>
>
> This is not exactly what I meant. Suppose that someone wants to compute
> the dense matrix product:
> A*B
> where A is in R^{238, 2031}, and B is in R^{2031, 1240}.
> Then, the auto-tuner should indeed find the optimal padding size, and A
> and B would be transparently padded to multiples of 128: {256,2048} and
> {2048, 1280}.
> However, for some reason, using matrices of size {256, 2176} and
> {2176, 1280} may be worth it on SGEMM (but not on DGEMM), because 2048
> could trigger a lot of bank conflicts. Similarly, one might fall on a
> sweet spot of his GPU for {256,2560}x{2560,1408}. I don't think that
> ViennaCL should handle this. I can think of some applications in the
> field of Artificial Neural Networks, where one may want to resize the
> layers of his neural network so as to fall on some sweet spots of his GPU.
Such cases are probably only interesting for the 'expert settings' tab
in the GUI, as these parameters only make sense to people who *really*
know what they are doing (and willing to invest the time). For bloggers,
journalists, etc., who just want to quickly get some performance
datapoints for the very latest hardware, this is usually not of
interest. We need to focus on serving the main audience first and then
watch out for fruitful directions on how to extend it further.
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
