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