Re: [boost] Back to Boost.SIMD - Some performances ...

Subject: Re: [boost] Back to Boost.SIMD - Some performances ...
From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2009-03-26 15:03:39

On Thu, Mar 26, 2009 at 2:56 PM, Joel Falcou <joel.falcou_at_[hidden]> wrote:
> Felipe Magno de Almeida a écrit :
>>
>> Could the library's interface match a GPGPU implementation?
>> Creating operations result in shader compilations, so there would
>> have to be a way to save these operations. Like boost::function<vec(vec,
>> vec)>for the performance to be worth. Do you see a way to do this with your
>> library? (This is using a OpenGL implementation).
>
> Well, i have a similar system planned in the matrix library that Boost.SIMD
> is extarcted from (http://nt2.sourceforge.net).
> I think it's slightly out of scope for a strictly SIMD library.
>
> Implementationwise, it is doable I think as the core library is already
> split up upon extension detection. Adding another level is easy. But I fear
> the performance won't be that great as we'll run lots of small scale
> operation when GPGPU prefer large amounts of data (hence this being more a
> model for a matrix library).

FWIW, ACML also offers a GPU library that offloads operations to the
GPU when "it makes sense".

I do agree with Joel - a GPGPU implementation can be added later.  It
would probably be better to let OpenCL mature as well, before heading
into this area.

Joel, how does the extension detection mechanism work?  Is there a
small runtime penalty for each function as it detects which path would
be optimal, or can you define at compile-time what extensions are
available (e.g. if you are compiling for a fixed hardware platform,
like a console).

--Michael Fawcett