Boost logo

Boost :

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
instruction sets.
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
matrix multiplication".

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, gregod at, cpdaniel at, john at