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.