Subject: Re: [boost] [simd] Hardware support
From: Joel FALCOU (joel.falcou_at_[hidden])
Date: 2017-04-08 14:14:58
On 08/04/2017 15:55, Niall Douglas via Boost wrote:
> But consider this. Imagine I make a toy key-value store and hand it over
> to Boost. It works well enough for most people. I then invest twelve
> months full time work into a serious key-value store which has been
> exhaustively tested in many major storage designs for correctness,
> costing me at least $150,000 to develop.
> I think it's highly unreasonable to expect that serious key-value store,
> even if 100% API compatible but just faster and better in every way to
> the toy store, to be released as open source until the cost of
> developing it is recouped from commercial licences.
> After all, the toy edition is good enough. It works. It just will come
> with no guarantees that it won't eat your data, and it will probably be
> quite slow.
And that's exactly our point.
The reason of why Boost.SIMD is proposed is to give back part of it to
the community we're part of. Put bluntly, NumScale has other sources of
revenues (products and services) so we're above the need of using Boost
as a cheap advertisement platform.
It has been discussed with Michael Caisse and other people from the
steering committee and has been found to not be an issue. Also note that
NumScale has volunteered to act as BLOM for Boost.SIMD, which means also
indirectly investing ressources into this open source endeavour.
As Michael put it elegantly when we started discussing this, the current
shape of Boost.SIMD submitted is what it is. It goes through a review to
know if this actual piece of software is interesting enough to be
included. If the lack of some hardware support is a point against, then
cast your vote accordingly. I it means that this software is not into
boost at the end of the review, well so be it and we'll revert to
support an open source version of bSIMD renamed and outside of boost. We
wont die or miss anything, the Boost community may.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk