On Thu, Apr 18, 2013 at 2:46 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
Hi,
This week I presented a proposal to the C++ standards committee to provide a standard library component for SIMD computation based on the library in development Boost.SIMD (not yet a Boost library).
I was hoping to get feedback on the interface and establish an API that would satisfy hardware and compiler vendors.
Unfortunately the concurrency/parallelism group has decided that they do not want C++ to provide types representing SIMD registers. 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.
This is a shame. Is the rationale or the official response from the working group available somewhere? Development of Boost.SIMD will still proceed, aiming for integration in
Boost, but standardization appears to be definitely out of the question. Any feedback of the API presented in the proposal is welcome. http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3571.pdf
I have a few questions: 1. When a particular algorithm or pack configuration is not supported by the hardware, is the implementation required to emulate it with scalar or partially vectorized operations? And what is the behavior of Boost.SIMD in this regard? 2. It looks like the proposal does not define any means to discover the availability of certain operations and pack configurations in hardware. How would algorithm versioning work with this proposal? I'm not assuming each algorithm and operation would dispatch its implementation based on the hardware check as this would be too slow. 3. It supports division and modulus for integers? Is it supported by any hardware? This is out of curiosity, I'm not familiar with implementations other than SSE/AVX. 4. How would advanced operations be implemented, such as FMA and integer madd? Is it through additional library provided functions? IMHO, the availability of these operations is often crucial for performance of the user's algorithm, if it is more complicated than just accumulating integers. 5. Do you have any plans or time frames on Boost.SIMD inclusion? What is the state of the library? I also want to encourage you on continuing this work. This is a very interesting area and there is certainly demand for a higher level abstraction of SIMD operations. Keep up the good work and perhaps one day we'll see SIMD in the Standard after all.