Hey again,
While we're at it, let's discuss the dynamic dispatching mechanism we'd
ideally want. I see two options:
(1) A global function pointer table. So, one could for example set:
viennacl::internal_blas::sgemv_ptr = &viennacl::cblas_wrapper;
where cblas_wrapper essentially checks for the stride in the non-leading
dimension and forwards to cblas if this stride is one. Of course, if the
current backend is different, cblas_wrapper is not defined, and
cublas_wrapper can be defined instead.
I like this solution a lot, since this allows one to mix multiple blas
implementation in the same program. This can be useful in some case
(OpenBlas is faster than MKL for BLAS3, but MKL is supposedly faster for
all the rest). HOWEVER, this requires linkage if we want to avoid multiple
definitions of that global pointer table. Since we now provide a
libviennacl.so, though, we could include the global table therein, and one
would link with it if he wants to use the additional functionnalities.
Plus, if one has his own blas function he wants to benchmark against ours,
for example, then this solution is very convenient.
(2) A template parameter. So that one would write:
viennacl::prod<CBlasBackend>(), similarly to how I did with UMinTL.
However, I am not very fond of this solution for ViennaCL, because it will
create a huge bloat in the code, since templates essentially need to
propagate, and it might screw up a bit the template deduction mechanism of
some compiler (since prod<> is already templated with the underlying
ScalarType...)
I would prefer (1). But maybe I'm missing an ideal (3) :D
Best regards,
Philippe
2013/12/15 Philippe Tillet <phil.til...@gmail.com>
> Hello,
>
> I've just realized that most BLAS implementation don't provide anyway to
> do strided matrix accesses in the non-leading dimension ... ! Is this
> correct?
> I was hoping that we could have avoided such special cases, but it seems
> like a couple of tests will need to be made.
>
> Philippe
>
>
> 2013/12/14 Karl Rupp <r...@iue.tuwien.ac.at>
>
>> Hey,
>>
>> > Okay. I'll probably do it statically at first, and I'll keep in mind
>>
>>> that we want it dynamic at the end of the day (well, not at the end of
>>> today :D). Once everything works statically, I think we can discuss the
>>> details of the API we want.
>>>
>>
>> Fine with me. This way we can first collect a bit of experience on some
>> details which might be important for the runtime layer later.
>>
>> Best regards,
>> Karli
>>
>>
>
------------------------------------------------------------------------------
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
ViennaCL-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/viennacl-devel
