Hi,
2013/8/3 Karl Rupp <r...@iue.tuwien.ac.at>
> Hi,
>
>
> A padding of 256 looks pretty expensive to me, resulting in a lot of
>> unnecessary FLOPs in worst case. Can you please assemble a list of
>> all GEMM kernel configuration parameters and their execution times
>> for the GTX 470, Tesla C2050, HD 7970 and HD 5850? mL, nL, and kL
>> are of main interest, but for future reference it's better to just
>> dump all parameters. I think I can also run on a K20X here, I need
>> to beg a colleague. I'll also open up a separate repository on
>> GitHub for collecting results there, hopefully it will grow with
>> more device results over time.
>>
>>
>> I am working on the autotuning procedure right now, it outputs a nice
>> .txt file now. I am playing a bit with it on my HD5850 and I am not
>> satisfied with the results I get, but I need clAmdBlas to compare.
>> I was thinking, I don't think we made an agreement on the database
>> format yet. While the XML format is tempting, should we dump all the
>> profiles into the same giant XML file (like at the first iteration of
>> the generator in january) or should we have finer granularity with
>> multiple XML files (say, one per device, or one per vendor/device_type
>> pair)? I personally prefer to have finer granularity at the vendor
>> level, it would be clearer from my point of view...
>>
>
> We actually need two sets of files: One for dumping the benchmark results,
> one for holding the 'best' parameter configuration. For dumping results, we
> probably want something more lightweight than XML:
> - JSON
> - Just CSV files with a metadata section, e.g.
> # NVIDIA GeForce 470 GTX
> # time mL kL nL mS kS nS ...
> 0.000319 64 32 64 4 8 4 ...
> 0.000324 32 64 32 4 4 4 ...
> etc.
>
> The last one is quite attractive, as the data is essentially filling up a
> table rather than being unstructured (and thus asking for XML or JSON).
> Also, it can be processed with standard command line tools, OpenOffice,
> etc. if necessary.
>
>
Yes, the CSV format is what I chose yesterday when rewritting some of the
autotuner, which now prints all the result to such a file. For now I only
print execution time, but I might just add some flexibility to deal with
profile-specific metrics ( BLAS1, bandwidth, BLAS2-BLAS3, GFLOP/s)
> For loading parameters for the different kernels, CSV is not an option.
> XML or JSON is equally fine for me. For XML we already have pugixml in use,
> so it would be a smoother transition. What we definitely should *not* do is
> to 'invent' a new file format...
>
Yes, and pugixml can be used in header-only mode by doing:
#define PUGIXML_HEADER_ONLY
#include "pugixml.cpp"
I also advocate XML. But if we are to use XML, it will cumbersome to change
the format over time, I think it would be cool to define the structure of
the XML we want... there are just so many options !
I would go for one .xml file per vendor, since one .xml file per device is
probably going to grow too large, and one global is too hard to maintain
and too error-prone. Plus, this way, the user would just have to get a tiny
enough xml file for his vendor. The .xml file can be named "vendor-id.xml",
which is well enough standard compliant. We could have some related PATH
variable like AMD does, and if it is not defined, look-up for it in the
current directory, and if it is not found, fall-back on a conservative
profile. I have practically no experience with XML, and hence no intuition
of when to use attributes or element. I would personally tend to go for
such a thing :
<device>
<name> ... </name>
<!--all kind of device info here, maybe we should just put them all
so we're sure not to lack any in the future--!>
<vector_saxpy>
<group_size> ... </group_size>
</vector_saxpy>
....
<matrix_product lhs_transposed="0" rhs_transposed="0">
<mL> ... </mL>
...
</matrix_product>
</device>
<device>
....
</device>
The autotuner can then spit out the correct xml file in the current
directory, just like it spits the data .csv file
Any thoughts?
Best regards,
Philippe
> Best regards,
> Karli
>
>
>
Best regards,
Philippe
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
ViennaCL-devel mailing list
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
