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.