Re: Wrapper for vectorized math libraries

[Dan Davis]

On Mon, Oct 3, 2011 at 11:30 PM, John W. Eaton <address@hidden> wrote:
>
> I don't know the rationale for including the -mveclibabi=X option in
> GCC, but I'd be interested in knowing more if you know where that
> decision was discussed.

Sorry, I have no idea why those closed source libraries get special
treatment, other than their significant potential for optimizing
scientific codes by allowing much more vectorization.


My actual solution was going to avoid that flag and be along the lines
of a new mapping function for the vectorized routines.
It would have looked something like below.


 template <class U, class F>
 Array<U>
 map_vectorized (F fcn) const
 {
    octave_idx_type len = length ();

    const T *m = data ();

    Array<U> result (dims ());
    U *p = result.fortran_vec ();

    octave_idx_type i;
    const int block_size = 128;
    for (i = 0; i < len; i += block_size)
      {
        octave_quit ();
        int local_len = min(block_size, len-i);
        fcn(local_len,m+i,p+i);
      }

    octave_quit ();
    return result;
 }

Then the function passed in would have been a function pointer to
either the simple

void local_vect_sin(int N, const double *x, double *ans) {
   while(N--) *ans++ = sin(*x++);
}

or the AMD library call

void vrda_sin(int N, const double *x, double *y)

or the equivalent IMKL call.

The point being that something like dlopen can be used to check for
the AMD library and associate the function pointer with it if it is
installed in the load path, and if it isn't installed utilize the
simple case.  This way, Octave isn't linked to the AMD or Intel
library any more than Flash player is linked in to Firefox.  But I'm
not trying to push the issue.  I just had the idea and wanted to get
an opinion on propriety before trying to implement it.  I actually
have no interest in going further if it won't be distributed with
Octave, because the whole point is to avoid needing to compile locally
to use the libraries.

Dan Davis