Boost.Compute v0.1 Released
I'm proud to announce the initial release (version 0.1) of
Boost.Compute! It is available on GitHub [1] and instructions for
using the library can be found in the documentation [2].
Boost.Compute is a GPGPU and parallel-programming library based on
OpenCL. It provides an STL-like API and implements many common
containers (e.g. vector<T>, array
On Sun, Mar 16, 2014 at 05:03:57PM -0700, Kyle Lutz wrote:
I'm proud to announce the initial release (version 0.1) of Boost.Compute! It is available on GitHub [1] and instructions for using the library can be found in the documentation [2].
Looks neat.
I hope to propose Boost.Compute for review in the next few months but for I'm looking for more wide-spread testing and feedback from the Boost community (please note the FAQ [4] and design rationale [5] where I hope to have answered some common questions).
Not to be the one that's the one that has to drag out the naggy old discussion every time this happens, but pet peeve of mine... What ever happened to avoiding the use of "Boost.Something" names for proposed libraries and libraries that have not successfully reviewed yet? Just look at the constant confusion there is around things like "Boost.Process" which is regularly thought to be under the Boost umbrella and keeps getting questions as to where and how to get hold of the multitude of releases of it. In my eyes, not being very explicit about library naming results in a lot of confusion between the pre-review state of a library and its life after the review cycle, whether it's accepted or not. (yes, there's a small note at the bottom of the documentation) -- Lars Viklund | zao@acc.umu.se
Could we just adopt having something like a consistent graphic at the top
and different style or something for proposed libraries?
On Sun, Mar 16, 2014 at 5:23 PM, Lars Viklund
On Sun, Mar 16, 2014 at 05:03:57PM -0700, Kyle Lutz wrote:
I'm proud to announce the initial release (version 0.1) of Boost.Compute! It is available on GitHub [1] and instructions for using the library can be found in the documentation [2].
Looks neat.
I hope to propose Boost.Compute for review in the next few months but for I'm looking for more wide-spread testing and feedback from the Boost community (please note the FAQ [4] and design rationale [5] where I hope to have answered some common questions).
Not to be the one that's the one that has to drag out the naggy old discussion every time this happens, but pet peeve of mine...
What ever happened to avoiding the use of "Boost.Something" names for proposed libraries and libraries that have not successfully reviewed yet?
Just look at the constant confusion there is around things like "Boost.Process" which is regularly thought to be under the Boost umbrella and keeps getting questions as to where and how to get hold of the multitude of releases of it.
In my eyes, not being very explicit about library naming results in a lot of confusion between the pre-review state of a library and its life after the review cycle, whether it's accepted or not.
(yes, there's a small note at the bottom of the documentation)
-- Lars Viklund | zao@acc.umu.se
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- -Matt Calabrese
We had a long (but ultimately inconclusive discussion) about this. I propose (again) the use of these logos attached. Paul Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 01539 561830 07714330204
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Matt Calabrese Sent: 17 March 2014 00:50 To: boost@lists.boost.org Subject: Re: [boost] Boost.Compute v0.1 Released
Could we just adopt having something like a consistent graphic at the top and different style or something for proposed libraries?
Hi, I guess, part of the reason such discussions stall is that no "external" person knows who owns which rights in which logos. It might be advantageous for Boost, if - either all art work contributed to Boost could be put under an appropriate license (think: CC) - or the "steering committee" could somehow assume legal ownership of such work Unless there is a single entity that may say "yes, you can" or the work has been put under an open license, most discussions of this type will stall. On a side-note: I'd love to have a logo of the type "Proudly using Boost", which I could put on our web page and in our manual (130K LOC which uses Boost in many places). I would love to give credit where credit is due. I believe that the visibility of Boost would benefit a lot if such logos would suddenly pop up in many places. Boost IS used in a lot of software, both proprietary and Open Source, I am sure. Best Regards, beet Am 17.03.14 11:30, schrieb Paul A. Bristow:
We had a long (but ultimately inconclusive discussion) about this.
I propose (again) the use of these logos attached.
Paul
Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 01539 561830 07714330204
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Matt Calabrese Sent: 17 March 2014 00:50 To: boost@lists.boost.org Subject: Re: [boost] Boost.Compute v0.1 Released
Could we just adopt having something like a consistent graphic at the top and different style or something for proposed libraries?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of beet Sent: 17 March 2014 10:52 To: boost@lists.boost.org Subject: Re: [boost] Boost.Compute v0.1 Released
Hi,
I guess, part of the reason such discussions stall is that no "external" person knows who owns which rights in which logos. It might be advantageous for Boost, if - either all art work contributed to Boost could be put under an appropriate
license
(think: CC) - or the "steering committee" could somehow assume legal ownership of such work Unless there is a single entity that may say "yes, you can" or the work has been put under an open license, most discussions of this type will stall.
On a side-note: I'd love to have a logo of the type "Proudly using Boost", which I could put on our web page and in our manual (130K LOC which uses Boost in many places). I would love to give credit where credit is due. I believe that the visibility of Boost would benefit a lot if such logos would suddenly pop up in many places. Boost IS used in a lot of software, both proprietary and Open Source, I am sure.
Agree strongly - see attached for one proposal for a Powered-by-Boost logo. You are right that these should have a license embedded, but I doubt that we can control their use as a 'trade mark' (since Boost is a legal non-entity, by design). However that's not a reason for not encouraging this. I think we are missing a trick here. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 01539 561830 07714330204
On March 16, 2014 8:23:06 PM EDT, Lars Viklund
On Sun, Mar 16, 2014 at 05:03:57PM -0700, Kyle Lutz wrote:
I hope to propose Boost.Compute for review in the next few months
[snip]
Not to be the one that's the one that has to drag out the naggy old discussion every time this happens, but pet peeve of mine...
What ever happened to avoiding the use of "Boost.Something" names for proposed libraries and libraries that have not successfully reviewed yet?
[snip]
In my eyes, not being very explicit about library naming results in a lot of confusion between the pre-review state of a library and its life after the review cycle, whether it's accepted or not.
(yes, there's a small note at the bottom of the documentation)
+1 Libraries that have not been accepted into Boost may not be labeled Boost.Name without qualification. They are to have a prominent disclaimer at the top of the documentation stating that they have not been accepted, too. There was discussion, once, of a special logo to use for such libraries, but I don't recall if that was ever finalized. I also don't recall whether the above was captured on the web site. Perhaps someone else had time to check that. ___ Rob (Sent from my portable computation engine)
On Sun, Mar 16, 2014 at 7:03 PM, Kyle Lutz
Boost.Compute is a GPGPU and parallel-programming library based on OpenCL. It provides an STL-like API and implements many common containers (e.g. vector<T>, array
) as well as many common algorithms (e.g. sort(), accumulate(), transform()). A full list can be found in the header reference [3].
Besides the OpenGL niceness and STLishness, is there a reason to prefer Boost.Compute over alternatives targeted at OpenCL/CUDA numerics? There's already been much work in this space [1], including VexCL [2] which many of my collaborators like. While there is an answer in the FAQ [3], it seems dodgy as clearly VexCL could not presently be built on Boost.Compute since the latter does not support for CUDA while the former does. - Rhys [1] http://arxiv.org/abs/1212.6326 [2] https://github.com/ddemidov/vexcl [3] http://kylelutz.github.io/compute/boost_compute/faq.html
On Sun, Mar 16, 2014 at 6:10 PM, Rhys Ulerich
On Sun, Mar 16, 2014 at 7:03 PM, Kyle Lutz
wrote: Boost.Compute is a GPGPU and parallel-programming library based on OpenCL. It provides an STL-like API and implements many common containers (e.g. vector<T>, array
) as well as many common algorithms (e.g. sort(), accumulate(), transform()). A full list can be found in the header reference [3]. Besides the OpenGL niceness and STLishness, is there a reason to prefer Boost.Compute over alternatives targeted at OpenCL/CUDA numerics? There's already been much work in this space [1], including VexCL [2] which many of my collaborators like. While there is an answer in the FAQ [3], it seems dodgy as clearly VexCL could not presently be built on Boost.Compute since the latter does not support for CUDA while the former does.
Good point. That FAQ entry was written before VexCL added its CUDA back-end (which occurred relatively recently). Boost.Compute and VexCL have different aims and scopes. Boost.Compute is more similar to the C++ STL while VexCL is more similar to a linear algebra library like Eigen. Also see this StackOverflow question [1] entitled "Differences between VexCL, Thrust, and Boost.Compute". -kyle [1] http://stackoverflow.com/questions/20154179/differences-between-vexcl-thrust...
Is it possible to use ordinary C++ functions/functors or C++11 lambdas with Boost.Compute?http://kylelutz.github.io/compute/boost_compute/faq.html#boost_compute.faq.i... Unfortunately no. OpenCL relies on having C99 source code available at run-time in order to execute code on the GPU. Thus compiled C++ functions or C++11 lambdas cannot simply be passed to the OpenCL environment to be executed on the GPU. This is the reason why I wrote the Boost.Compute lambda library. Basically it takes C++ lambda expressions (e.g. _1 * sqrt(_1) + 4) and transforms them into C99 source code fragments (e.g. “input[i] * sqrt(input[i]) + 4)”) which are then passed to the Boost.Compute STL-style algorithms for execution. While not perfect, it allows the user to write code closer to C++ that still can be executed through OpenCL. Also check out the BOOST_COMPUTE_FUNCTION() macro which allows OpenCL functions to be defined inline with C++ code. An example can be found in the monte_carlo example code.
I find this to be a serious (killer) downside. Are there any examples/FAQ about launching kernels that call member functions or about using Boost.Compute within class hierarchies? Even a minimal example where the data is a class member e.g. vector and the kernel uses one or two member functions would be very much appreciated. The std proposal for a parallel algorithms library, TBB, C++AMP, and Thrust seem to be a better fit for a "C++ interface to multi-core CPU and GPGPU computing platforms" than any OpenCL based library I've seen (OpenCL, Bolt, VexCL, Boost.Compute). OpenCL and C++ seem to not be made for each other. OpenCL is just FUBAR without extra compiler support like C++AMP or OpenACC. On Monday, March 17, 2014 1:03:57 AM UTC+1, Kyle Lutz wrote:
I'm proud to announce the initial release (version 0.1) of Boost.Compute! It is available on GitHub [1] and instructions for using the library can be found in the documentation [2].
Boost.Compute is a GPGPU and parallel-programming library based on OpenCL. It provides an STL-like API and implements many common containers (e.g. vector<T>, array
) as well as many common algorithms (e.g. sort(), accumulate(), transform()). A full list can be found in the header reference [3]. I hope to propose Boost.Compute for review in the next few months but for I'm looking for more wide-spread testing and feedback from the Boost community (please note the FAQ [4] and design rationale [5] where I hope to have answered some common questions).
Thanks, Kyle
[1] https://github.com/kylelutz/compute [2] http://kylelutz.github.io/compute/ [3] http://kylelutz.github.io/compute/compute/reference.html [4] http://kylelutz.github.io/compute/boost_compute/faq.html [5] http://kylelutz.github.io/compute/boost_compute/design.html _______________________________________________ Boost-users mailing list Boost...@lists.boost.org javascript: http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 17.03.2014 01:03, Kyle Lutz wrote:
I'm proud to announce the initial release (version 0.1) of Boost.Compute! It is available on GitHub [1] and instructions for using the library can be found in the documentation [2].
I am really happy to see more efforts on well designed high level GPGPU libraries, especially in Boost. Boost.Odeint has already adapters for Boost.Compute. Denis Demidov (the author of VexCL) provided them.
participants (9)
-
beet
-
Gonzalo BG
-
Karsten Ahnert
-
Kyle Lutz
-
Lars Viklund
-
Matt Calabrese
-
Paul A. Bristow
-
Rhys Ulerich
-
Rob Stewart