Re: [boost] [simd] Hardware support

Subject: Re: [boost] [simd] Hardware support
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-04-08 13:32:55

On 04/08/17 16:01, Niall Douglas via Boost wrote:
>>>> Boost.SIMD only supports x86.
>>>>
>>>> Are there plans for ARM NEON and/or MIPS SIMD?
>>>
>>> Other platforms are supported in the proprietary version of the library.
>>> https://developer.numscale.com/bsimd/documentation/v1.17.3.0/
>>
>> Will those be eventually included in Boost.SIMD, if it's accepted into
>> Boost?
>>
>> This is an important point, IMO, and it should be clarified before
>> review. If there are no plans to improve Boost.SIMD in order not to harm
>> the commercial version then that makes Boost.SIMD significantly less
>> attractive. Personally, I would vote for rejection in this case.
>
> I am sympathetic to this opinion.
>
> But strictly speaking Boost libraries if they work without error on some
> architecture, rather than being optimal on some architecture, then that
> is good enough for the portability requirement.

Well, the point of a SIMD library is to employ SIMD supported by the 
hardware. If I'm content with non-SIMD execution, I would probably not 
bother with a SIMD library. So, yes, performance is crucial for a SIMD 
library, and serial execution is only acceptable if a given operation is 
not available as SIMD in hardware, or is not *yet* supported (meaning 
that the support is at least planned).

> Now, as to whether the Boost edition of the library is a loss leader for
> the commercial edition ... again, I am sympathetic, but if the library
> as presented is useful to a majority of people (and indeed a majority
> are on Intel), then I think it must be allowable.
>
> I certainly don't think a rejection just because of either of these two
> features is right. The library as presented should be judged as
> presented. Whether stuff is being held back or not shouldn't matter.
>
> Down the line, I hope to have some of my Boost libraries come with an
> open source edition with acceptable performance and guarantees, and
> commercial editions with much superior performance and guarantees. I
> think this would be a healthy development for Boost, if not pushed into
> silliness.

While I respect the will to commercialize people's work, I wouldn't want 
Boost to become an advertisement platform. Authors coming with their 
libraries to Boost should be committed to provide a fair and proper 
support of their libraries (i.e. those versions of their libraries that 
entered Boost). That includes adding features to their libraries that 
have demand in the community and are also present in commercial versions 
of their libraries.

When that is not the case, I would rather prefer such libraries not be 
accepted into Boost. They can still be opensource and offered as a trial 
to the full product, but they should not be associated with Boost, IMO.