Re: [boost] [GSoC] SIMD proposal

Subject: Re: [boost] [GSoC] SIMD proposal
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-03-23 19:44:50

On 23/03/2011 21:45, Mathieu - wrote:
> Hello everyone,
>
>
> I'm a french student preparing a Master in Computer Science. I'm
> highly interested in participating in the 2011 GSoC with Boost. I'm
> particulary keen on working on the boost.simd subject. I think having
> SIMD abstraction in boost could be really beneficial (the first
> example which comes to mind is boost.math).
> However I have some questions about the subject in order to do my
> proposal, some of them have already been discussed with Joel Falcou
> and Mathias Gaunard on IRC, but here it is : One of the main concern I
> have is that nt2 relies heavily on cmake to detect various things like
> SSE instruction set support etc.

The library must know what instruction sets are available on the target 
machine. This is done using a configuration header file that contains 
macros that exist if the instruction sets in question are available.
That configuration header can be either written manually or be generated 
by the build system.
On x86, we use a program that calls the 'cpuid' instruction (using 
inline assembler) which directly gives the processor capabilities. Then 
we check the compiler allows their usage (MSVC Express Edition does not 
allow SSE3+).

Finally, the right options to enable those instruction sets must also be 
passed to the compiler whenever compiling code that uses the library.
I think this is quite unique, as no other boost library requires 
specific compiler flags to be used AFAIK.
Therefore it *could* make sense to also ship the bjam or cmake modules 
that allow to detect the best set of options available as part of the 
boost installation; but I understand that's quite a disruptive idea.

In NT2 we also put other things in the configuration header but all of 
this is being reworked, and won't be in Boost.SIMD.

> is bjam able to do everything we need to
> do, or will we need to do the detection in any other way?

If bjam can 1) compile temporary programs, run them and retrieve their 
output and 2) test whether the compiler supports some flags -- then 
we're fine.

> I use, and I
> kind of know bjam but I'm not an expert either, I believe Vladimir
> Prus will be able to help here.

Anyway, there are lots of interesting things to do technically, and 
which ones you want to do is up to your project to define. There are 
even possibilities I didn't outline in the project idea on the wiki: 
NEON support (ARM) is possible as well, for example, but that's somewhat 
harder than AltiVec.
I wouldn't put too much a focus on things like the build system.

> Another thing that is a bit blur for me at the moment, is what is the
> scope of boost.simd? I mean, from what I see the simd part is quite
> deep-rooted in nt2, has dependencies on several modules of it, so will
> boost.simd be a subset of nt2 simd module or will we need to rewrite
> part of it to avoid dragging huge dependencies (and well, end up doing
> boost.nt2).

NT2 is being split into independent modules.
At the moment, I'd say the simd supports spans the sdk, arithmetic, 
bitwise, predicates, reduction, swar and ieee modules (quite a big chunk 
indeed).

Those need to be split further, as not everything is necessary in those 
modules.
We'll be working on this and try to come to a solution shortly.