Boost logo

Boost :

Subject: Re: [boost] [gsoc] boost.simd news from the front.
From: Robert Jones (robertgbjones_at_[hidden])
Date: 2011-06-06 06:10:52


On Mon, Jun 6, 2011 at 8:37 AM, Mathieu - <ptr.jetable_at_[hidden]> wrote:

> Hi everyone,
>
>
> Last week, we (Joel Falcou my mentor, Mathias Gaunard, and me) had a
> meeting to decide the courses of action for the future boost.simd
> library. For those who aren't aware of it, it's a subset of an
> existing library, namely nt2, which provide an abstraction for simd
> instructions in C++.
> Here is what have been decided so far : boost.simd will be composed of
> several modules mimicking what's done in nt2 (or in phoenix). That is
> there will be the main operators in a module (add / minus etc) and the
> extra modules that we provide like bitwise (bitwise_andnot etc) or
> arithmetic. Second, what will be included? We decided to keep only
> functions which might have a corresponding intrinsic to exploit.
> Finally boost.build will come into play later in the process.
>
> Final note, despite what I said in a previous mail a few weeks ago,
> the initial development will happen in the nt2 (available at
> https://github.com/MetaScale/nt2 : main repository (in a branch) for
> ease of use (to ease merge process mainly) and in the boost.simd
> repository.
>

Hi Mathieu - I hope you forgive naive questions from the almost terminally
ignorant on this
topic, but I'm just trying to understand what, in the most general terms,
you're trying
to do.

>From reading a few of the nt2 webpages, and wikipedia on SSE2, the business
of exploiting
SIMD capability seems to be in the domain of the compiler. How does this
look from
a library perspective? What are the mechanisms you'll use/consider?

You mention "in the style of phoenix", so does this mean that as users of
your
library we would construct the equivalent of phoenix lazy objects, which
would then
have enough internal intelligence to evaluate in a super-efficient, SIMD
context?

Thanks

- Rob.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk