Hi hi,
2014-05-05 21:49 GMT+02:00 Karl Rupp <r...@iue.tuwien.ac.at>:
> 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.
>
I mean, the data is pretty useful because it tells us about the best
default kernel for large square matrices, but it is not very useful if we
want to build a general input-dependent model, as it requires in my
experience more than 1000 data points.
>
>
> 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.
>
Are you sure? It would not take a lot of efforts to have an optional way to
call the python script with the proper arguments from the auto-tuner, as
long as the user provides the path and that he has all the necessary
dependencies.
>
> 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
> foc
us on serving the main audience first and then watch out for fruitful
> directions on how to extend it further.
>
Of course ! I've been referring to the "expert settings" tab from the
beginning :)
Philippe
> 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
