Re: Wrapper for vectorized math libraries

[Christopher Hulbert]

On Fri, Sep 30, 2011 at 4:07 PM, Dan Davis <address@hidden> wrote:
> On Fri, Sep 30, 2011 at 2:05 PM, Christopher Hulbert
> <address@hidden> wrote:
> \>
>> Have you looked at the vector, signal, and image processing library
>> (VSIPL) [1]? There is also VSIPL++ which is a specification (serial
>> and parallel specifications) [1]. This was created initially under
>> DARPA funding to define a portable high-performance API for a number
>> of computational functions. I have at times used ACML, MKL, vanilla
>> BLAS and LAPACK, FFTW, etc. as backends for that specification. You
>> will also find presentations from Miriam Leeser from Northwestern I
>> think who did work in using FPGA and GPU backends in VSIPL. GTRI also
>> has a GPU release of VSIPL. The reference implementation provides the
>> unoptomized versions you were looking at implementing when not
>> compiled with a backend. Unless you want to design your own, you may
>> find it nice starting from something established, and I do not some
>> commercial companies using VSIPL++ in production environments.
>
> Thanks for the info.  I may have seen VSIPL before, but it wasn't on
> my mind when I started working on this.  As nice as it is in terms of
> a middleware, it misses the point.  What I am working towards is lower
> level than that with far fewer functions.  The even bigger point is
> that I would like run-time selection (not compile time) of the best
> available library.  That way something like Octave, which is packaged
> via .deb, .rpm, etc. type packages, could link in to the vectorized
> math functionality that is available on the machine.  So if someone
> has ACML or IMKL, software like Octave could take advantage of that
> without recompiling.
>
> For things like blas, fftw, etc., which have standardized function
> calls, I can force that run-time selection if I want using LD_PRELOAD
> and listing whichever libraries I want to use.  However, for the
> common math functions, no standard calls exists, and, thus as far as
> I'm aware, no run-time selection ability exists.

I don't understand how it misses the bigger picture, but you did look
at these and decide it wouldn't fit so I will not question you there.
I only mentioned in case you hadn't heard of it. Also, I am not sure
what "lower level than that" means.

In the VSIPL implementation I modified, setting the environment
variable VSIP_FFT_D would tell the library at run time which one I
wanted if available, otherwise a default order of libraries available
at compile time was used. Or compile using generic BLAS/LAPACK
interface and use LD_PRELOAD which would also work.

For the common math functions, you could take the opportunity at an
initialization point to call a function indicating if a particular
library is available and check its return value for validity. For
example, VSIPL defines a function vsip_init. Then you just need a stub
MKL, ACML, etc compiled in if the real library is not available.
However, I have had significant problems building with one version of
(say MKL) and using a different, so run time forcing with LD_PRELOAD
should be cautioned.

Just a few thoughts!

Chris

>
> Regards,
>
> Dan Davis
>