Subject: Re: [boost] Going forward with Boost.SIMD
From: Evgeny Panasyuk (evgeny.panasyuk_at_[hidden])
Date: 2013-04-18 09:29:53
18.04.2013 14:46, Mathias Gaunard:
> Unfortunately the concurrency/parallelism group has decided that they do
> not want C++ to provide types representing SIMD registers.
I would also like to know details of rejection.
> I'm afraid I don't quite understand the rationale for such a refusal;
> proposing more high-level constructs similar to valarray (or to our own
> library NT2) was suggested, but that's obviously a more complex and
> limited API, not a basic building block to program portably a specific
> processor unit.
I am using Eigen library in my projects, internally it has it's own
abstraction around SIMD instructions and several backends for different
Such kind of high-level libraries would clearly benefit from some
standard-way to do SIMD operations.
However, I see one major drawback of low-level SIMD interface in ISO: it
is not as future-proof as higher-level API.
SIMD instruction sets are expanding and becoming more complex, I am not
sure how low-level library is supposed to catch future trends.
For instance, there is FMA instruction "d=a+b*c" - yes, your proposal
have appropriate fma function in <cmath>.
But imagine that some new architecture would have "double FMA"
instruction like: "f=a+b*c+d*e", or even more complex instruction: "2x2
In order to support such kind of new instructions, low-level library
should add new functions - i.e. wait for new version of ISO.
And until new version of ISO would not adapt these new functions, that
low-level interface would not be competitive - users (higher-level
libraries developers) would again use compiler-specific intrinsics.
While in case of higher level interface (like Eigen), only internal
implementation should be adjusted in order to get benefits.
-- Evgeny Panasyuk
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk