Re: [boost] Going forward with Boost.SIMD

Subject: Re: [boost] Going forward with Boost.SIMD
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-04-18 08:41:11

On Thu, Apr 18, 2013 at 2:46 PM, Mathias Gaunard <
mathias.gaunard_at_[hidden]> 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.