March 2013 - Boost - lists.preview.boost.org

Re: [boost] [compute] GPGPU Library - Request For Feedback
by Jeffrey Lee Hellrung, Jr. 06 Mar '13

06 Mar '13

On Mon, Mar 4, 2013 at 6:25 PM, Kyle Lutz <kyle.r.lutz(a)gmail.com> wrote: > On Sun, Mar 3, 2013 at 6:39 PM, Hartmut Kaiser <hartmut.kaiser(a)gmail.com> > wrote: > > > > Also, do you have asynchronous versions for all algorithms? > > As of now only copy_async() is implemented (as it is the most > important for achieving good performance by overlapping memory > transfers with computation). However, I am not sure if this is the > best interface to be extended to all the other algorithms. > > I've been thinking about moving towards an asynchronous execution > function like std::async() which would be passed the algorithm > function along with its arguments. However, I've encountered problems > with overloading and having to explicitly specify the argument > template types. This is one point where I'd like to get some > feedback/ideas from the community. I would also like to have a > <algorithm>_async_after() version which would take the algorithms > parameters along with a list of futures/events to wait for before > beginning execution. My dilemma is that extending these different > versions would increase the size of the API by a factor of three. > > Any feedback/ideas/comments would be very helpful. > This sounds vaguely similar to Google's Flume framework: http://dl.acm.org/citation.cfm?id=1806638 - Jeff

1 0

Re: [boost] [compute] GPGPU Library - Request For Feedback
by Hartmut Kaiser 06 Mar '13

06 Mar '13

> > That's excellent (sorry I have not seen this in the docs before). > > However I think it's not a good idea to create your own futures. This > > does not scale well nor does it compose with std::future or > > boost::future. Is there a way to use whatever futures (or more > > specifically, threading implementation) the user decides to use? > > The boost::compute::future class wraps a cl_event object which is used to > monitor the progress of a compute kernel. I'm not sure how to achieve this > with std::future or boost.thread's future (or even which to chose for the > API). Any pointers (or example code) would be greatly appreciated. Yes, that's exactly the problem. It is nothing specific to your particular library but a general issue to solve. In the library we develop (HPX, https://github.com/STEllAR-GROUP/hpx/) we face the same issue of having to rely on our own synchronization primitives which makes it impossible to reuse std::future (or boost::future). Any suggestion on how to create specialization/customization points allowing to make boost::future universally applicable would be most appreciated. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

1 0

Re: [boost] [compute] GPGPU Library - Request For Feedback
by Ioannis Papadopoulos 06 Mar '13

06 Mar '13

On 3/4/2013 8:47 PM, Kyle Lutz wrote: > On Sun, Mar 3, 2013 at 9:15 PM, Ioannis Papadopoulos > <ipapadop(a)cse.tamu.edu> wrote: >> A comparison would be nice. Moreover, why not piggy-back on the libraries >> that are already available (and they probably have better optimizations in >> place) and simply write a nice wrapper around them (and maybe, crazy idea, >> allow a single codebase to use both AMD and nVidia GPUs at the same time)? > > Boost.Compute does allow you to use both AMD and nVidia GPUs at the > same time with the same codebase. In fact you can also throw in your > multi-core CPU, Xeon Phi accelerator card and even a Playstation 3. > Not such a crazy idea after all ;-). > > -kyle > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > Thanks for the comparison. The only issue I see with Boost.Compute is that it will have problems supporting well the well-known architectures. Basically, it takes all the optimizations that have been researched and developed for maximum efficiency and throws them out of the window. For example, there is a wealth of CUDA algorithms highly optimized for nVidia GPUs. These will have to be reimplemented in OpenCL. And tuned (ouch); possibly for each device (ouch x 2). I see it as a massive task for a single person or a small group of people that are doing that in their spare time. However, if Boost.Compute implements something similar to Boost.Multiprecision's multi-backend approach, then you can use underneath thrust, Bolt, whatever else there is and only fall-back to the OpenCL code if there is nothing else (or the user explicitly requires it). They way I'd see something with the title Boost.Compute is as an algorithm selection library - you have multiple backends, which you may choose from based on automatic configuration at compile time and at run time based on type and input size of your input data. Starting from multiple backends is a good start.

1 0

Re: [boost] License of endian and limits in Boost detail
by Philip Bennefall 06 Mar '13

06 Mar '13

----- Original Message ----- From: "Rob Stewart" <robertstewart(a)comcast.net> To: <boost(a)lists.boost.org> Sent: Wednesday, March 06, 2013 12:12 AM Subject: Re: [boost] License of endian and limits in Boost detail On Mar 5, 2013, at 2:29 AM, Philip Bennefall <philip(a)blastbay.com> wrote: > * Permission to use, copy, modify, distribute and sell this software > * and its documentation for any purpose is hereby granted without fee, > * provided that the above copyright notice appear in all copies and > * that both that copyright notice and this permission notice appear > * in supporting documentation. > > This looks to me like it enforces inclusion of the above text in object > code distributions, IANAL, but I read that as only requiring the copyright notice in copies of the source and in the documentation, not in the binaries. Do you mean the end user documentation accompanying binaries (e.g. the documentation of a derivative work)? That is the part I want to avoid. Philip Bennefall ___ Rob _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

7 8