Quantcast

[simd] Hardware support

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[simd] Hardware support

Boost - Dev mailing list
Boost.SIMD only supports x86.

Are there plans for ARM NEON and/or MIPS SIMD?

What does Boost.SIMD currently do on unsupported platforms? Revert
back to SISD?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [simd] Hardware support

Boost - Dev mailing list
On 8 April 2017 at 11:14, Bjorn Reese via Boost <[hidden email]>
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/

Earlier versions of the IBM POWER and PowerPC support used to be
open-source as well.


What does Boost.SIMD currently do on unsupported platforms? Revert
> back to SISD?
>

Yes, likewise if you're on x86 but requesting an operation that your
hardware does not support, it will still work using the best possible
implementation.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [simd] Hardware support

Boost - Dev mailing list
On 04/08/17 14:06, Mathias Gaunard via Boost wrote:
> On 8 April 2017 at 11:14, Bjorn Reese via Boost <[hidden email]>
> 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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [simd] Hardware support

Boost - Dev mailing list
>>> 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.

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.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [simd] Hardware support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 8 April 2017 at 13:21, Andrey Semashev <[hidden email]> wrote:

> On 04/08/17 14:06, Mathias Gaunard via Boost wrote:
>
>> On 8 April 2017 at 11:14, Bjorn Reese via Boost <[hidden email]>
>> 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?
>

Being no longer affiliated with NumScale, the company behind this library,
I cannot say.
The original plan was to keep support for unusual and/or recent
architectures proprietary, while the open-source version would get backends
once the underlying technology becomes mainstream enough.

In practice I would not expect much; Boost.SIMD was initially developed by
a French university but is now handled by a company whose leanings towards
open-source might be less open.


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 personally have severe concerns about all aspects of intellectual
property surrounding that library and the people behind it.
For example, when I did a talk about Boost.SIMD at a conference using
nothing but open-source material, my employer received a cease-and-desist
letter and was asked to destroy all material related to Boost.SIMD as
NumScale claimed it was their property. My employer complied to be on the
safe side.

I believe that during the review we should definitely take into account how
the existence of the two versions of the software can be harmful to users.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [simd] Hardware support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [simd] Hardware support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> I personally have severe concerns about all aspects of intellectual
> property surrounding that library and the people behind it.
> For example, when I did a talk about Boost.SIMD at a conference using
> nothing but open-source material, my employer received a cease-and-desist
> letter and was asked to destroy all material related to Boost.SIMD as
> NumScale claimed it was their property. My employer complied to be on the
> safe side.
>
> I believe that during the review we should definitely take into account how
> the existence of the two versions of the software can be harmful to users.

Eh, sorry, are you saying that anybody who uses Boost.SIMD may receive a
cease and desist legal order from the people behind its commercial
edition? Because if so, I think the SFF of which Boost is a part would
say that means that library cannot enter Boost due to being of uncertain
legal providence.

I mean, a while back with Hana, there was a storm in a teacup over the
fact it was named after a product by a well known multinational. That
was worrying over nothing (trademarks in different domains do not
conflict), but somebody actively suing users of a potential Boost
library is a real concern.

Also, if SIMD enters Boost and then someone adds features to it like
support for ARM, will they get sued for stealing IP from the commercial
edition? Because even if they demonstrably could not have stolen the IP,
it's the legal costs of proving you didn't do anything wrong which can
be ruinous.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [simd] Hardware support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 04/08/17 16:21, Mathias Gaunard via Boost wrote:

> On 8 April 2017 at 13:21, Andrey Semashev <[hidden email]> wrote:
>
>> On 04/08/17 14:06, Mathias Gaunard via Boost wrote:
>>
>>> On 8 April 2017 at 11:14, Bjorn Reese via Boost <[hidden email]>
>>> 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?
>>
>
> Being no longer affiliated with NumScale, the company behind this library,
> I cannot say.
> The original plan was to keep support for unusual and/or recent
> architectures proprietary, while the open-source version would get backends
> once the underlying technology becomes mainstream enough.
>
> In practice I would not expect much; Boost.SIMD was initially developed by
> a French university but is now handled by a company whose leanings towards
> open-source might be less open.

That is sad to hear.

In the case that the code is not released, are you or other authors
allowed (legally), able and willing to implement those backends in the
opensource Boost.SIMD? By "implement" I don't mean reproducing the
closed-source code but implementing the backends as your library design
requires. If not you yourself, would you be willing and able to accept
patches that implement that functionality, if someone else takes on the
task?

> 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 personally have severe concerns about all aspects of intellectual
> property surrounding that library and the people behind it.
> For example, when I did a talk about Boost.SIMD at a conference using
> nothing but open-source material, my employer received a cease-and-desist
> letter and was asked to destroy all material related to Boost.SIMD as
> NumScale claimed it was their property. My employer complied to be on the
> safe side.
>
> I believe that during the review we should definitely take into account how
> the existence of the two versions of the software can be harmful to users.

If the licensing situation is indeed unclear, it probably makes sense to
put the review on hold and clarify this matter with NumScale (or whoever
claims rights on the library). I think the last thing anyone needs is
being pulled into court.

Until the licensing issue is clear, I don't think the review, let alone
acceptance, should happen. (Sorry, if that sounds disappointing or
harsh, but I think that is ultimately for the better for you, Boost and
Boost users.)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [simd] Hardware support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
>> 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.

I know what you mean.

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.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [simd] Hardware support

Boost - Dev mailing list




On 08 Apr 2017, at 15:55, Niall Douglas via Boost <[hidden email]> wrote:

>>> 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.
>
> I know what you mean.
>
> 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.
>
> Niall
I would be worried about you (in this hypothetical case) being able to reject improvements to the boost version. Boost libraries are not aiming to be "average, good enough" type of libraries, they aim higher. So suppose that someone want to improve the boost versions, because it is all sort of slow bits, would you accept those changes as a library maintainer? Or would you block them because it would ruin your commercial business  ?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [simd] Hardware support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
We have no MIPS support mostly because lack of time and platform access,
patch welcome.

NEON support is indeed part of bSIMD, NumScale's proprietary software on
which the proposed Boost.SIMD library is extracted from. There is, for
now, no short term plan to release the ARM support as Open Source software.

And let's be clear : to release the ARM support *NumScale developed*.

If a pull request came in with some support for ARM and the quality was
good enough in term of performances and coverage of function, I guess
it'll go through a regular review process.


On 08/04/2017 12:14, Bjorn Reese via Boost wrote:

> Boost.SIMD only supports x86.
>
> Are there plans for ARM NEON and/or MIPS SIMD?
>
> What does Boost.SIMD currently do on unsupported platforms? Revert
> back to SISD?
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [simd] Hardware support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [simd] Hardware support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 04/08/17 16:55, Niall Douglas via Boost wrote:

>>> 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.
>
> I know what you mean.
>
> 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.

I can understand if you want to keep certain features in the
closed-source version to return the costs and make profit. But that
shouldn't impede the Boost version from evolving. If that feature has
high demand, I would expect it to eventually appear in the open-source
version. If soneone offers a patch implementing that feature, I would
expect you to give a fair consideration of it, even if it makes things
differently to your closed-source code. What I wouldn't expect or want
to see is the author referring the community to the commercial version
instead.

I'd like to make myself clear. I'm absolutely not against people making
money on the software they write. But at the same time, if those people
come to Boost I think they should be aware and committed to Boost and
open-source community. If there is a chance of a conflict between making
profit and commitment to opensource, I'd rather them avoid that conflict
by not coming to Boost in the first place.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [simd] Hardware support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list

>> 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.
>
> I would be worried about you (in this hypothetical case) being able
> to reject improvements to the boost version. Boost libraries are not
> aiming to be "average, good enough" type of libraries, they aim
> higher. So suppose that someone want to improve the boost versions,
> because it is all sort of slow bits, would you accept those changes
> as a library maintainer? Or would you block them because it would
> ruin your commercial business  ?

I've never been in that situation, but what I have in mind has pluggable
storage backends with a single frontend API. So if someone wants to
develop a competing backend superior to the open source one which
directly competes with my commercial one, I'd say rock on. Competition
is good!

If on the other hand they wanted to extend or modify the frontend API in
a way which severely breaks things for my commercial backend, the
chances are I'd say no unless it fixes an obvious bug or problem. I
would prefer a new breaking version of the library to that, which of
course they are free to fork.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [simd] Hardware support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list

>> 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.
>
> I can understand if you want to keep certain features in the
> closed-source version to return the costs and make profit. But that
> shouldn't impede the Boost version from evolving. If that feature has
> high demand, I would expect it to eventually appear in the open-source
> version. If soneone offers a patch implementing that feature, I would
> expect you to give a fair consideration of it, even if it makes things
> differently to your closed-source code. What I wouldn't expect or want
> to see is the author referring the community to the commercial version
> instead.

I'd hope to allow competition. But if you think developing high quality
C++ code is expensive, then developing high quality storage code is
considerably more so. I think recouping the cost of development is very
reasonable, after which it can be open sourced.

> I'd like to make myself clear. I'm absolutely not against people making
> money on the software they write. But at the same time, if those people
> come to Boost I think they should be aware and committed to Boost and
> open-source community. If there is a chance of a conflict between making
> profit and commitment to opensource, I'd rather them avoid that conflict
> by not coming to Boost in the first place.

Profit and open source are not in conflict. If anything, especially in
recent years, there is plenty of profit in open source. I, and many
others even on here, make a living from it.

I'm also mindful of Anthony Williams' Just Threads! which is effectively
a v4 complete rewrite of Boost.Thread. That's a commercial product held
totally separate to Boost, and it has been woefully underused because
people didn't know it existed. Some would argue - and I'm not sure I
include myself here - that if Just Threads! were the all new singing and
dancing Boost.Thread rewrite, and if people running into problems with
Boost.Thread could pay the fee for the new rewrite until its development
costs were paid off, that could bring new very high quality developed
for profit libraries to Boost.

As I said, I'm not sure I agree with that myself, lots of slippery
slopes in there. But equally I've seen old versions of big games engines
released to open source after they no longer make money, and that's been
a *huge* benefit to open source. So the model can work, and work very well.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [simd] Hardware support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Sorry if this has been answered already but what is the incentive to
evolve the Boost version instead of the commercial version (or both)?
Boost libraries seem like they can be quite labor intensive to
maintain, especially libraries targeting specific architectures; is
there not a clear conflict of interest with respect to development
time being split across a for-pay and a for-free version of the same
library?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [simd] Hardware support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 8 April 2017 at 14:49, Niall Douglas via Boost <[hidden email]>
wrote:

> > I personally have severe concerns about all aspects of intellectual
> > property surrounding that library and the people behind it.
> > For example, when I did a talk about Boost.SIMD at a conference using
> > nothing but open-source material, my employer received a cease-and-desist
> > letter and was asked to destroy all material related to Boost.SIMD as
> > NumScale claimed it was their property. My employer complied to be on the
> > safe side.
> >
> > I believe that during the review we should definitely take into account
> how
> > the existence of the two versions of the software can be harmful to
> users.
>
> Eh, sorry, are you saying that anybody who uses Boost.SIMD may receive a
> cease and desist legal order from the people behind its commercial
> edition?


That's certainly what happened to me, though I have special circumstances
as I used to be affiliated with them.
Your mileage may vary.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [simd] Hardware support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 08/04/2017 16:40, Vinnie Falco via Boost wrote:
> Sorry if this has been answered already but what is the incentive to
> evolve the Boost version instead of the commercial version (or both)?
> Boost libraries seem like they can be quite labor intensive to
> maintain, especially libraries targeting specific architectures; is
> there not a clear conflict of interest with respect to development
> time being split across a for-pay and a for-free version of the same
> library?

As I said, NumScale has no *short term* (first key point) intention into
releasing  *their own implementation* (second key point) of some
architecture support.

If someone want to invest time into supporting some architectures, they
are free to do it and we'll give it a fair code review if they send us a
pull request.

Also consider that we daily end up patching the OS version because of
bugs raised from the behind the pay wall. Our issues list on github is
also full of stuff we want to do and we deemed that their support could
be done in the OS version.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [simd] Hardware support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 08/04/2017 16:07, Thijs (M.A.) van den Berg via Boost wrote:
> I would be worried about you (in this hypothetical case) being able to reject improvements to the boost version.
> Boost libraries are not aiming to be "average, good enough" type of libraries, they aim higher. So suppose that
> someone want to improve the boost versions, because it is all sort of slow bits, would you accept those changes as a library maintainer?
> Or would you block them because it would ruin your commercial business  ?

Such case already happen, we have a bunch of contributors sending us
patches and we treat the PR fairly. As I said earlier, the effort into
adding the full support for a given arch can be non-trivial but if the
PR is good enough, we'll give it an actual look and see if it is indeed
worth merging.

As for our business, be assured we don't run on bSIMD licence only ;)


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [simd] Hardware support

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
A thread which deals with ... lot's of stuff ... related to a particular
library SIMD proposed for Boost.  This stuff relates to legal issue
related to to usage, provinence, and future maintainence and direction
of the library.

I think we would be better off focusing an one simple question:

Does the proposed library include the Boost License.  If it does, fine.
If it doesn't it can't be a boost library and hence there is no need for
a review.

Robert Ramey




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
123
Loading...