Hi,
2013/12/15 Karl Rupp <[email protected]>
> Hi,
>
>
> > Yeah, it certainly is a bit tedious. Feel free to only do this for
>
>> matrix-matrix multiplications for now, a full operation table is
>> presumably too much of a refactoring for ViennaCL 1.x.y, but much
>> better suited for 2.0.0.
>>
>>
>> Yes. It's actually a pretty complicated problem, because of the
>> different signatures of the different BLAS functions... It seems like
>> the cleanest way to do it would be using std::function<>, and
>> std::bind<>, which may indeed be widely available at the time ViennaCL
>> 2.0.0 comes out. I hadn't seen this coming.
>>
>
> The interfacing problem is just a matter of wrapping everything behind a
> common function interface and then use function pointers appropriately.
> C++11 is not an option for me for a few more years to come, mostly because
> this is the usual timeframe on large-scale clusters. (Our test system now
> includes a CentOS 5.10 machine with GCC 4.1.2...)
Yap, sometimes reinventing the wheel makes sense because the car is too old
:D
>
> Wouldn't a classic preprocessor directive but with better BLAS support
>> (as I have it implemented now : cpy, swap, asum, norm2, gemv, gemm) be
>> more interesting feature-wise than a dynamic gemm only dispatch, in the
>> end?
>>
>
> How would that look like? Do you mean a classic #ifdef? If right now we
> are only interested in GEMM, then yes, a simple static dispatch is enough.
> It just shouldn't start growing if we don't see this as the right way to go
> in the future.
Oh, something like :
#define VIENNACL_WITH_CBLAS
or
#define VIENNACL_WITH_CUDA
#define VIENNACL_WITH_CUBLAS
which would dispatch cpy, swap, asum, norm2, gemv, gemm (for the other one,
I think that the temporary saving of ViennaCL is beneficial) for float and
double, and when the non-leading dimension of a matrix is strided. I can
add a set of more specific switches if necessary:
#define VIENNACL_WITH_CUBLAS_GEMV
#define VIENNACL_WITH_CUBLAS_GEMM
etc...
>
>
> Plus, it seems like the dynamic dispatch will be much more
>> interesting in the context of ViennaCL 2.0.0 where more things will be
>> dynamic, with possibly already kernel-dispatch for the generator based
>> on the input sizes (I'm thinking about it)...
>>
>
> Absolutely. I think it's important to have directions for the future
> (being more dynamic is apparently one of them), but from the 1.5.0 delay I
> have learned the hard way that one should not start too many changes at the
> same time... ;-)
>
>
Well, yes, I had the same problems on a couple of projects... However
kernel generation should be the main topic of my internship and my
(hopefully) Ph.D, so I hope I'll have time for these things!
Best regards,
> Karli
>
>
Best regards,
Philippe
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
ViennaCL-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
