[vsipl++] [patch] SAL dispatch for matrix and vector products

[Don McCoy]

Here is an updated patch for SAL.  In addition to the matrix-vector 
products, it includes outer and gemp.  Some comments are included below...

Jules Bergmann wrote:

> Don McCoy wrote:
>
>> I am working on BLAS dispatch as well.  Patch to follow.  This one 
>> just includes SAL.  Hopefully I've separated them well.
>>
>> Two issues worth pointing out:
>>
>>    1) The exec() function checks for row-major ordering because it 
>> calls the newer SAL functions (mat_mul) that allow the column-stride 
>> to be specified.   I believe the rows must be unit stride.  This is a 
>> little less general than the older ones (mulx) which allow non-unit 
>> strides.  Recently, we heard back from Mercury that the older ones 
>> perform better (at this time).  Given that the older ones handle 
>> non-unit strides and are faster, should we revert to using those?  If 
>> Mercury changes in the future, then we can follow.
>
> Yes, we should revert to the old ones for now.
>
> Because the old and new functions have different dispatch requirements 
> (for supported strides and mixing of dimension orderings), we should 
> have separate evaluators for each (as opposed to trying to hide the 
> different in sal::mmul).

I added SAL_USE_MAT_MUL for use in selecting the newer functions.  The 
default (0) selects the old ones.  It is tempting to make this a 
configuration option, but i really don't anticipate changing this switch 
back and forth.  I'm sure we'll just change it to a 1 when Mercury 
indicates it is a good time to do so.

>>    2) Split-complex products (other than vector-vector) are not 
>> handled at this time.  Just a reminder that we were going to discuss 
>> how to address this issue sometime.
>
>
> We should be able to handle this by:
>
>  - providing overloads of sal::mmul for std::pair<T*, T*>, and
>  - checking that all the matrices have the same complex format in 
> ct_valid.
>
> Granted, we wont be able to fully exercise this until we get prod 
> integrated into the expression templates.
>

I added a function in tests/matvec-prod.cpp that calls 'generic_prod()' 
directly with split-complex data.  This lets us see that it is working 
now.  Until we change prod() itself, it will select the generic 
evaluator that returns the data in interleaved form, regardless of the 
layout of the inputs.


A note on testing:  The easiest way to test the dispatch mechanism was 
to insert debugging statements into the code in order to observe the SAL 
functions being called.  The code in tests/matvec-prod.cpp walks through 
a very large assortment of types, ordering and matrix sizes.  Checking 
that SAL is used everywhere it could be is a manual process that is 
likely to be error prone.  The hope is that I did not miss any cases 
where SAL could be used (e.g. an error in the rt_valid() function caused 
the generic evaluator to be selected instead).  Of course, cases where 
SAL is used where it *shouldn't* be are already taken care of. :)

Coming at this from another angle, we could test each library for 
certain capabilities and make sure it was used where/when it should be.  
The only way i can think to do this would involve inserting code that 
would allow us to detect (after a call to the dispatch mechanism) 
/which/ evaluator succeeded.  It may be too much work for not enough 
benefit, but I thought I'd throw the idea out there just in case.

Regards,

-- 
Don McCoy
CodeSourcery, LLC

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sd2.changes
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20051114/9dee1876/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sd2.diff
Type: text/x-patch
Size: 47497 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/vsipl++/attachments/20051114/9dee1876/attachment.bin>