...

...

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/

...

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/

...

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/

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.

Thijs (M.A.) van den Berg wrote:

I would be worried about you (in this hypothetical case) being able to reject improvements to the boost version. ... 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 ?

As Joel has stated later in this thread, it's not their intention to do so, and (IIUC) they already take patches to the OS version that adds support for things from the closed source version. He also mentioned that bSIMD licensing is not their only way of making money on their work. Is the concern here that Joel/NumScale might not be able to stick to this policy in the future? Would people be less concerned if the library had other maintainers with no commercial interest in bSIMD? -- View this message in context: http://boost.2283326.n4.nabble.com/simd-Hardware-support-tp4693499p4693544.h... Sent from the Boost - Dev mailing list archive at Nabble.com.

On 08/04/2017 23:57, Andrey Semashev via Boost wrote:

2. Whether Boost.SIMD will be properly maintained after acceptance given the commercial version. Things are less optimistic on this front - no concrete plans on supporting other architectures, but at least Joel promises to give fair consideration to pull requests. Whether that is acceptable or not the review will show.

Another point that occur to me is that: how much different is this situation than with other existing library that has a different pace of updates (like ASIO for ex.) than regular Boost and for which the asymmetry between the current version in boost and the current free standing version may be large but get fixed at some later point ? In both case we have a software that lives following its own agenda then get merged back into boost at some (ir)regular intervals.

On 9 April 2017 at 09:30, Niall Douglas via Boost wrote:

If copyright weren't a problem, I'd suggest the Apache 2.0 licence which gives stronger guarantees to the end user (a Boost library doesn't actually have to have the Boost licence, it's just strongly recommended). But you don't own the copyright to the entire library.

The library only has NumScale copyright notices, so they claim ownership of the library, and could re-license it. AFAIK the Boost Software License requires keeping the copyright notices of any work it is derived from, so this is a violation of the BSL. Boost.SIMD is derived from the NT2 library which was a BSL-licensed collaboration between various parties. I warned NumScale about this a few years ago, but they dismissed it.

On 9 April 2017 at 17:21, Robert Ramey via Boost wrote:

On 4/9/17 5:29 AM, Mathias Gaunard via Boost wrote:

...

On 9 April 2017 at 09:30, Niall Douglas via Boost wrote:

...

If copyright weren't a problem, I'd suggest the Apache 2.0 licence which gives stronger guarantees to the end user (a Boost library doesn't actually have to have the Boost licence, it's just strongly recommended). But you don't own the copyright to the entire library.

The library only has NumScale copyright notices, so they claim ownership of the library, and could re-license it.

I'm not a lawyer. The Boost license was vetted very carefully by specialized legal counsel. No one has yet raised the possibility that a license, once granted, could be revoked. So whatever NumScale were to do in the future, would not affect Boost.

They cannot be revoked. My understanding was that we were discussing the possibility that Boost.SIMD could also be licensed under a license providing stronger guarantees than the Boost Software License so as to better protect the end user.

AFAIK the Boost Software License requires keeping the copyright notices of

...

any work it is derived from, so this is a violation of the BSL.

This is not clear to me from reading the actual license.

http://www.boost.org/users/license.htmlhttp://www.boost.org/ users/license.html

That's pretty clear to me. Attribution of ownership (aka copyright notices) must be preserved in source form, but not compiled form. The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software, in whole or in part, and all derivative works of the Software, unless such copies or derivative works are solely in the form of machine-executable object code generated by a source language processor.

I have not idea what a "BSL-licensed collaboration" is

I'm not sure what's confusing here, but let me rephrase if that helps. "A work developed by various parties working together and licensed under the Boost Software License." The NT2 library had copyright notices attributing ownership to LRI and LASMEA -- two French public research laboraties -- in addition to NumScale; those copyright notices should have been preserved. The latest version of Boost.SIMD attributes ownership to NumScale exclusively.

Niall Douglas wrote:

They had bought a full owning copy from the IP originators, which is also possible BTW, ...

Not necessarily. It's possible under American copyright law, not possible under at least some European copyright laws. You can only get a full owning copy if it's work for hire (in which case you become the owner of the work). You can never get a full owning copy by buying it from the owner. Ownership is fixed at the moment of creation and is not for sale. All this does not appear to be of consequence with respect to the Boost-licensed portions though.

On 09/04/2017 23:20, Mathias Gaunard via Boost wrote:

That is correct, IANAL, but my understanding is that French law does not allow transfer of ownership of intellectual property, and that it stays with the author until death.

Moral rights cannot be transferred in many European countries, but economic rights can be. One can also sign a contract binding you to never assert your moral rights. The end result looks very similar to outright sale or transfer of IP as under English law.

In any case, I am listed as one of the main authors in legally-binding registrations of various pieces of software managed by the University of Paris-Sud, including NT2 on which this library is based on, and would have to give my agreement for any special licensing deal. This is mostly a technicality, as all of this is licensed under the Boost Software License and there are little damages to speak of, but still something that needs fixing.

One of the big problems with the older open source licences such as the Boost licence was a lack of awareness at the time of writing of different copyright regimes outside the English law ones. Newer open source licences are much better designed in this regard, and the EU in 2009 published the EUPL licence specifically designed for maximum global compatibility. (Incidentally I really wish US-centric open source orgs would use something like the EUPL https://joinup.ec.europa.eu/sites/default/files/eupl1.1.-licence-en_0.pdf rather than their US-centric licences which are problematic outside English law jurisdictions) One might think that a lawyer in a European country could assert that due to the impermeability of moral rights, that the failure to comply with the Boost licence requirement of preservation of copyright notices is a problem, but that would only be in countries where moral rights are impermeable. The argument wouldn't fly in the US or the UK, except when applied to visual artwork. However, in Europe legal precedent holds that licences cannot impose conditions on a sale of software, where "sale" is defined to be any distribution such as a download. So as soon as a European downloads an open source library, they are free to ignore any conditions in any licence. This is probably surprising to most readers on here as it makes licences such as the GPL unenforceable in the EU, see http://www.lexology.com/library/detail.aspx?g=91b10f02-8ae0-4e2d-bd20-4bba0e.... Obviously this is a recent (2013) ruling to a specific case, but it was by the EU supreme court, so any further legal cases would likely be decided the same way. So, and stressing IANAL, I think Numscale are on solid legal ground here, at least both in the US and Europe. As a spinout from a university, I think it would be extremely unlikely that the university's legal department haven't gone through the situation with a fine tooth comb beforehand. tl;dr; I see no problem with Boost.SIMD's IP provenance. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 4/9/17 1:30 AM, Niall Douglas via Boost wrote:

...

#1 is critical. Without it being done there's nothing to review.

I'd tend to agree with Robert's view on this. If it's under the Boost licence, then it's just like any other library.

If copyright weren't a problem, I'd suggest the Apache 2.0 licence which gives stronger guarantees to the end user (a Boost library doesn't actually have to have the Boost licence, it's just strongly recommended). But you don't own the copyright to the entire library.

When I first read this I thought it was wrong. I always thought that a boost license was a requirement for inclusion in Boost. It turns out that I been wrong about this. http://www.boost.org/development/requirements.html#License So I guess it's more correct to say that a) if a library has Boost license, fine it can be reviewed. b) if a library has a Boost Compatible license, it can also be reviewed. But it's not clear to me who determines this. I guess this would be the review wizard who decides to add (or not add) a library to the review queue. c) If a library doesn't have a Boost compatible license, it can be added to boost so there is no point to subjecting it to review. The Boost Compatible license is important because it allows users to incorporate boost code with confidence that there will likely be no legal issues arising from such incorporation. I hope that we can all agree on the above. There is one issue still pending. Suppose one submits a library with a compatible license which incorporates code which from another source in such a way that the right to use the incorporated code is in question. I'm not really sure, but it seems that Mathias has (among other things) raised this as an issue. I would guess that places the onus on Joel to explain why he feels that this is not a problem in this case and finally the review wizard will have to consider the point in his decision to accept the request to place the library in the review queue. I'm aware that decisions such of this can never be resolved definitively. It's a feature of the legal system that the more time is expended, the more it serves the system rather then the rest of us. Basically they get paid to bikeshed. That's why we like to stay away from it. But, I'm hopeful that we can get legitimate concerns addressed one way or another in an expedient way so we can all move forward. Robert Ramey

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.

On 08/04/2017 16:40, Niall Douglas via Boost wrote:

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.

Anthony's Just Thread situation was part of our inspiration for submitting Boost.SIMD as we indeed saw it as something that follow a model close to ours and looks like it works. The main difference is indeed the order of inclusion.

On 8 April 2017 at 07:01, Niall Douglas via Boost wrote:

... and commercial editions with much superior performance and guarantees ...

boost as baitware... desgki

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/

On Apr 8, 2017, at 6:49 AM, Niall Douglas via Boost 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? 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 have used Boost.SIMD in some simulations, wrote a blog post about that [1] and presented it in talks at C++ conferences [2,3]. This is about as public as one can use an OS library. So I can ensure you that using Boost.SIMD is no different then any other library in this regard. Best, Mario [1] https://www.codeproject.com/Articles/841136/Boosting-ODE-simulations-with-Bo... [2] https://www.youtube.com/watch?v=KN8MFFvRl50 [3] https://www.youtube.com/watch?v=RGQ6uYjlYR0

On 04/08/17 16:21, Mathias Gaunard via Boost wrote:

On 8 April 2017 at 13:21, Andrey Semashev wrote:

...

On 04/08/17 14:06, Mathias Gaunard via Boost wrote:

...

On 8 April 2017 at 11:14, Bjorn Reese 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?

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.)

On 08/04/2017 19:08, Robert Ramey via Boost wrote:

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

Thank Robert to bring the discussion on track.

On 10/04/2017 14:44, Bjorn Reese via Boost wrote:

On 04/08/2017 01:06 PM, Mathias Gaunard via Boost wrote:

...

On 8 April 2017 at 11:14, Bjorn Reese via Boost wrote:

...

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.

Is there any run-time overhead (e.g. induced by pack, load, save, etc.) in the SISD case?

This is a case we don't benchmark much but the strategy is to statically unroll the scalar calls over the pack element which are store din an std::array. So I suspect the overhead is not worth than having called the scalar function Nth times.