Re: [boost] Going forward with Boost.SIMD

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