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
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
> 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
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
Those need to be split further, as not everything is necessary in those
We'll be working on this and try to come to a solution shortly.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk