- Boost - lists.preview.boost.org

Re: [boost] [compute] Review period starts today December 15, 2014, ends on December 24, 2014
by Kyle Lutz 28 Dec '14

28 Dec '14

On Fri, Dec 19, 2014 at 1:07 PM, Thomas M <firespot71(a)gmail.com> wrote: > Dear all, > >> Review of the Compute library starts today > > Having spent the last 3 years on a larger-scale C++ project utilizing OpenCL > as main computing engine, without doubt a C++ GPGPU library is worthwhile. > My evaluation was based on studying the full docs, tutorial examples, > creating own (simple) applications, and inspecting selected implementation > details. Thanks for the review! I've addressed your comments in-line below: > I liked most the portable STL-like algorithms; combined with fairly > straightforward on-the-fly specifications of kernel functions (including > lambda expression support) GPGPU utilization becomes much more accessible > for every-day C++ programs. The design of this library part is rather clean > and aligns well with the C++ standard customs. I have checked a handful of > function interfaces and they correspond to the C++ STL variants. > > However I have also encountered a number of issues, of which I consider most > severe the overall library's design/aim: > > Khronos Group already provides (since years) a C++ bindings API itself > (https://www.khronos.org/registry/cl/specs/opencl-cplusplus-1.2.pdf) > Frankly the Khronos API is not an example of a clean, modern C++, but it > provides very fine-grained operations control (which can be crucial for > effective GPGPU performance), is developed (althouth a bit lagged) with > OpenCL itself, and covered in every elaborate OpenCL textbook. It is thus > IMHO the current de-facto C++ OpenCL wrapper standard. The proposed boost > library's parts core & utility (heavy in total!) seem to do just the same > interface-wise, yet lack some important features e.g. detailed control flow > (blocking / event setting), image classes, or deviate in subtle signature > details making it really difficult to grasp which does exactly what / > behaves differently. A boost library should not start from scratch but > integrate with and extend the Khronos API, both at C and C++ bindings level > (e.g. providing the STL-like algorithms to them in straightforward to use > manners). Programmers can thus rely on established practices (personally I > wouldn't switch away from the Khronos C++ API as main underlying workhorse!) > yet benefit from the extended functionality provided by the boost library. Can you give examples of where the OpenCL wrapper types in Boost.Compute are lacking? I am aware of the issue with image classes. While they do exist in Boost.Compute, their APIs are just not documented yet (though there are quite a few examples/tests which demonstrate their usage). I'll work on this. One particular issue that makes me hesitant is the lack of OpenCL 2.0 support in the "official" C++ bindings. The OpenCL 2.0 specification was released over a year ago (November 2013). The first public OpenCL 2.0 implementation was released by Intel three months ago (September 2014, followed closely by an AMD implementation). Boost.Compute had OpenCL 2.0 support implemented a week later. As of today (over a year since the specification was released), there is still no support for OpenCL 2.0 in the Khronos C++ OpenCL wrapper. I don't think it would be prudent to restrict Boost.Compute to a subset of the OpenCL API merely because of shortcomings in the "official" C++ wrapper. Other issues include lack of support for move-semantics (as well as various other C++11 features) and differing object sizes for wrapped types versus the OpenCL C API types (e.g. "sizeof(cl::Device) != sizeof(cl_device_id)" which prevents the ability to pass arrays of wrapped object types directly to C APIs). Overall I think implementing our own wrapper directly based on the C API reduces overall complexity (no workarounds for bugs/shortcomings in the C++ wrapper layer), allows us to fix bugs and issue updates quickly, and provides a more consistent and, IMHO, better API for OpenCL. Also, as they both just wrap the underlying OpenCL C API, interoperating between Boost.Compute wrapper types and the Khronos C++ wrapper types is trivial. If there are specific issues with the wrappers in Boost.Compute please submit a bug report [1]. > On the other hand to those rather new to OpenCL a simplified, less > error-prone design would be beneficial; equally this can raise the > productivity of everyone. The current design/implementation follows the > typical OpenCL execution model incl. some of its caveats (see tutorial > "Transforming Data"): explicitly copying input data to the device, executing > kernel(s), and then copying the output back to the host. Frequently however > the whole emphasis is on the kernel invocation (run an algorithm on the > data), rendering the copying an implementation detail that's "done because > it must be done" but otherwise makes code longer and comprises an error > source if forgotten. I have put much consideration into this and ultimately I don't feel it is right for the data-copying to be made implicit and hidden away from the user. I prefer the API which makes the memory copying operations and the host-device synchronization points explicit. These "under-the-hood" copy operations can be major sources of under-performing GPU-based applications and I don't think insulating the programmer from them makes the situation better. In any case, there is a simplified, high-level API available in Boost.Compute which allows kernels to directly operate on host memory. See the mapped_view class [2]. > I hence wonder if the following overall design would be more appropriate > (this is by no means a request to doing it this way, I just try to bring in > alternative perspectives): > > 1) build on top the Khronos C / C++ bindings API, i.e. use that as base > instead of the own core + utilities parts > 2) offering a high-level interface for algorithm execution that exposes > users to as little OpenCL internals as possible while giving the algorithms > lots of flexibility > 3) offering a high-level interface that auto-connects STL-containers with > OpenCL memory objects, implemented based on standard C++ / Khronos API > classes. > 4) offering a high-level interface that applies the algorithms directly to > objects of the Khronos C / C++ API. > > > The first point is rather obvious. To me the proposed library parts core + > utility appear as just another C++ wrapper, and unless this is done in > extremely (!!!) well manner (i.e. offering every functionality the Khronos > API does, yet making it clean from scratch, aligning it with Standard C++, > extending it by essential features etc., ensuring a rock-solid quality > control for reliability etc.; I'd set the bar really high here) I see no > reason to do it. If people are forced to use the proposed library core > wrapper just to gain access to the other functionality (and there is good > other functionality in there !) then I think there is a serious risk that a > considerable number of people simply turn away altogether. Well I would question the premise that the Khronos C++ wrapper is done in an "extremely well manner" and has "rock-solid quality" ;-). Could you let me know what parts of the core wrapper API fail to meet your bar for quality? > With respect to the second point I suppose something like that is doable: > > // BEGIN > > compute::gpgpu_engine gpgpuEngine; // default initialization links it to a > default device etc. > > // create vector, fill with data - ordinary C++ > std::vector<float> vec(10000); > std::generate(vec.begin(), vec.end(), rand); > > compute::transform(vec.begin(), > vec.end(), > vec.begin(), > compute::sqrt<float>(), > gpgpuEngine); > > std::cout << vec[0]; // results are already on the host > > // END > > So an instance of gpgpu_engine (or whatever name) gets setup once and can, > if needed, become customized for its behaviour (devices used, execution > policies etc.). This engine can then internally (hidden to the user, like a > std::vector manages it's memory) manage buffers, and when transform now gets > invoked it: > -) copies the data to one of its buffers (create one if none available) > -) run the kernel > -) copies the data to the host side container (keep buffer for reuse later) > > This would bring several advantages: > -) the code becomes very similar to ordinary C++ code -> short-handed, less > error-prone > -) buffers can be recycled among multiple algorithm calls (e.g. the engine > can cache a small number of buffers immediately available for future calls) > -) more efficient OpenCL runtime utilization (performance) because the whole > operation sequence has been abstracted: e.g. the input copy operation can be > enqueued in a non-blocking fashion, so the data transfer to the device and > the boost.compute kernel preparation can occur concurrently; equally while > the kernel runs the copy-back-to-host command can already become enqueued. > -) gpgpu_engine can encapsulate a number of policies that control its > behaviour (providing sensible default-configurations but allowing > fine-grained control if desired), e.g.: error handling (e.g. throwing > exception vs. setting some plain-odd OpenCL error codes); device to execute > on (if multiple available); copying back to the host in non-blocking manner > (like copy_async); to allow the selection of a 'smart' execution path (for > example if the input data do not warrant the overhead of a GPU call [e.g. if > they are too small or do not well fit GPU computation problems] defer the > call a plain STL-algorithm call or use OpenCL's built-in native C++ calling > threading functionality); etc. It would be beneficial if those options can > become temporarily overwritten (something like the boost::ios_..._saver > classes come to mind). > > > With respect to the third point I am thinking of something along the lines > of: > > template <class T, ... policies etc for both std::vector and cl::Buffer> > class vector_buffer > { > > private: > std::vector<T,...> vec; > cl::Buffer buf; > }; > > the class ensures that the std::vector and the buffer are automatically > synchronized whenever changes must become transparent (i.e. access). > Obviously this requires some thought if get functions grant access to the > plain std::vector / cl_mem/cl::Buffer; however for the present > implementation I also don't see what would stop me from hijacking a cl_mem > from a compute::vector and modify the buffer arbitrarily outside the > compute::vector class. These are definitely ideas I've thought about and these kinds of tools could all be built upon the current API. I've played around with basically a "kernel functor" abstraction which provides a class with the regular C++ "operator()(Args...)" function which stores internally an OpenCL kernel along with a command queue and any buffers it needs. This would then provide a simple, pure C++ interface for executing functions on the GPU that looks just like a normal C++ function call. I'd be very interested in pursing this more. > For 4) I am thinking of overloads for the algorithm to +- directly accept > Khronos C / C++ objects. Some really light-weight adapters adding e.g. > required type + size data could do the trick. This is fairly trivial. I have a patch in the works which would allow the Khronos C++ types to be passed anywhere that Boost.Compute wrapper types are used to make this all virtually transparent to the user. > In general I'd find it useful that all of a host object, a device object and > something linking a host with a device object can be an input / output of an > algorithm, and the implementation takes care of automatic data transfer. So > if the input refers to a host object the implementation automatically copies > the data to the device, if the output is a host object it also automatically > copies the result to it etc. See my response above, I'm not a huge fan of these automatic data transfer abstractions. However, I could be in favor of offering this functionality in a higher-level API. > A final but probably very important design consideration: > I wonder if boost needs a OpenCL-computing library, or a general > parallelization library. Presently the GPGPU world is already split too much > between CUDA and OpenCL as main players (hardware vendors doing their parts > ...), and technology is really rapidly moving (APUs etc.). > As Hartmut has already pointed out one approach could be to use the current > proposal as foundation for a parallelization implementation: cut it down to > the essentials of that and hide as much OpenCL implementation details as > possible. > A completely different approach could be to try coming up with a unifying > parallelization framework that supports multiple backends (OpenCL, CUDA, > others). Obviously this would be a tremendous amount of work (and getting > that API right is probably extremely difficult - the last thing we'd need is > just another restricted API causing more splitting) but in the long run > could be the more rewarding solution. I think developing a unifying parallel framework which can intelligently dispatch algorithms to multiple back-ends is outside the scope of Boost.Compute (and seemingly much more in the remit of the proposed C++ Parallelism TS). I think OpenCL is more than sufficient for running code efficiently across a variety of parallel hardware including GPUs, multi-core CPUs, FPGAs and various other accelerators which is why I chose it to build Boost.Compute on top of (along with it being cross-platform and an open-standard). > Implementation details: > > I have checked the implementation only briefly, mostly only when questions > arose for a few functions. Overall it looks ok and organized, yet I have > encountered some issues. > > 1) type safety [major issue - must be fixed before acceptance]: > Type safety is not a strength of OpenCL, and this is reflected at parts in > the implementation when it fails to add a proper conversion/protection > layer. Using compute::reduce it was embarrassingly easy to produce rubbish > results through the following code (modifying the provided tutorial code) : > > // BEGIN > > compute::device device = compute::system::default_device(); > compute::context context(device); > compute::command_queue queue(context, device); > > // generate random data on the host - type is float > std::vector<float> host_vector(10000); > std::generate(host_vector.begin(), host_vector.end(), rand); > > // create a vector on the device > compute::vector<float> device_vector(host_vector.size(), context); > > // transfer data from the host to the device > compute::copy(host_vector.begin(), host_vector.end(), device_vector.begin(), > queue); > > double reduction_result = 0.0; // result is of type double > compute::reduce(device_vector.begin(), device_vector.end(), > &reduction_result, queue); > std::cout << "result: " << reduction_result<< std::endl; > > // END > > The input data is of type float while the result shall be stored in a > double. This fails miserably under the current implementation because after > the reduction has completed the final value stored in device memory gets > copied merely byte-wise to the target variable (using a plain type-ignorant > clEnqueueReadBuffer), reading simply the 4 bytes from a float into an 8 byte > double (4/8 on my PC machine). I suppose reversing types (double as input, > float as output) will be even more spectacular because 4 superfluous bytes > simply overwrite the stack. > > The same affects a plain compute::copy, for example if above the > device_vector is of type double: > > // BEGIN > > // generate random data on the host - type is float > std::vector<float> host_vector(10000); > std::generate(host_vector.begin(), host_vector.end(), rand); > > // create a vector on the device - type is double > compute::vector<double> device_vector(host_vector.size(), context); > > // transfer data from the host to the device > compute::copy(host_vector.begin(), host_vector.end(), device_vector.begin(), > queue); > > // END > > it equally makes pang because the data are just copied byte-wise. > > The library must provide a strict type-safety for all algorithms / data > structures, where (in order of preference that comes to mind): > a) convert properly to target type if possible (above surely applicable) > b) issue compile-time error if conversions not possible > c) last fallback: throw a proper exception at runtime Thanks for providing these tests cases. I'll work on improving type-checking and error-reporting. If possible, could you submit these as bug reports to the issue tracker [1]? > 2) when inspecting the code flow in above copy operation I missed a debug > mode check that for a copy operation the output range can hold that many > elements; something like a safe iterator returned by device_vector.begin() > -> a good implementation should throw an organized error instead of just > overwriting memory. This is a very good idea. I'll work on adding more assertions to verify these sorts of pre-conditions for the algorithms. > 3) for float/double input containers compute::accumulate falls back to a > plain serial reduction, making element-wise additions (which is really slow > on a GPU). This is because can_accumulate_with_reduce returns false as it is > not defined for integral types. Is there a technical reason why it cannot > work for floating types? How many algorithms are affected by a possible > fallback to a plain serial execution order? Because floating-point addition is not associative. Doing this would lead to accumulate() producing different results on the device versus the host. If the user is willing to trade performance for accuracy, they can call the reduce() algorithm directly. However, I don't think Boost.Compute should make this call universally and thus it is left up to the user to decide. I think this is documented in the accumulate() function, I'll look into making it more clear. > 4) for types not supported under both OpenCL and C++ (e.g. long double, > bool, half) more specific error messages would be useful. Noted, I'll work on producing better error messages for unsupported types/operations. > Note: above are listed only issues which I have encountered during my few > trials; there's no claim whatsoever for complete coverage > > > Performance: > > I have not really tested performance so I cannot say much on it. > At times I spotted what appears as unnecessary OpenCL runtime overhead (e.g. > blocking commands, resetting kernel arguments upon each invocation) but I am > not familiar enough with the implementation to judge if this really just > redundant. If you find any unnecessary blocking/synchronization please report it to the bug tracker [1] and we'll get it fixed. > Invoking the OpenCL compiler always takes considerable time for any OpenCL > program. The library compiles kernels on demand when encountered to execute; > while this is technically reasonable I am not sure in how far it is clear to > everyone (foremost end-users of programs) that e.g. a simply accumulate of > 100 ints may take several seconds to execute in total on first invocation > simply because the kernel compilation takes that time. I guess this > considerable penalty also somewhat discourages from using the library to > create a number of kernels on the fly. True, the run-time compilation model provided by OpenCL does have some associated overhead. There a few techniques in Boost.Compute which help mitigate this. The first is a run-time program cache which keeps built versions of commonly used kernels ready so that the compilation cost is only payed once per application run (see the program_cache class [3]). The other is support for offline-caching of program binaries. This is enabled by defining "BOOST_COMPUTE_USE_OFFLINE_CACHE" and causes Boost.Compute to cache binaries for programs so that they are only compiled once the very first time they are run on the system. I'll work on documenting the compilation-overhead issues as well as the caching functionality better. > I would find it very useful if smart algorithms dispatch the algorithm to a > plain C++ algorithm if it's really predictable that a GPU execution will > just waste time (I have elaborated on this above). It's fairly trivial to > have data/algorithm combinations that are better not executed on the GPU, > being able to rely on some auto-mechanism would relief programmers. I disagree, I think the call on whether to execute the algorithm on the host or on an accelerator (with its associated overhead) should be left up to the user (or potentially a higher-level API built on top of Boost.Compute). While I agree that this would a useful feature, I just don't think Boost.Compute is the right place for that logic to live. > Answers to reviewer questions: > > 1. What is your evaluation of the design? > > See comments above > > > 2. What is your evaluation of the implementation? > > See comments above > > > 3. Documentation: > > Overall I find the documentation well written and structured. As minor > issues at times it could be more explicit / elaborate (e.g. for > compute::vector a short description is provided, but for several other > containers there is none; what are the accepted types for predicates in the > algorithms etc.). Will do. > The installation page misses that (on Windows) the OpenCL headers must be > explicitly included (it leaves the impression that the library would do it > on it's own). Hmm, the Boost.Compute headers do "#include <CL/cl.h>" where it is required. Does this not work correctly for you? If possible, could you report a bug for this with a bit more information? > The performance page should include more details with respect to overhead > and specifically "unintuitive" ones such as kernel compilation time. > Recommendations can be given when a problem is / is not suitable for GPU > execution. It is unclear if the provided measurements refer to float or > double; measurements for both should be provided. Will do. > 4. Overall usefulness of the library > > I find the portable STL-ish algorithms (+ their supplements) useful. With > respect to the core + utilities parts I think unnecessary competition with > existent wrappers is introduced. > > > 5. Did you try to use the library? > > I used MSVC 12 and had no problems installing it and running a few little > programs. > > > 6. How much effort did you put into your evaluation? > > I read the documentation, ran tutorial code and created a few example > programs on my own (I did not run any of the pre-packaged examples). When > questions arose I took close looks at the implementation (thus I focused > more on in-depth analyses of selected components instead of testing overall > into breadth). > > > 7. Are you knowledgeable about the problem domain? > > I consider myself knowledgeable of the problem domain. > > > 8. The core question: Do you think the library should be accepted as a Boost > library? > > Generally speaking yes but I recommend a major revision before acceptance is > reconsidered. My greatest concern revolves around the overall design aim. I > don't like the idea of competing with the Khronos API for general wrapping; > I'd prefer a more light-weight library with the STL-ish algorithms (or other > things) at the core, adding to what is already out there. The library needs > to find its own niche, minimizing overlap and elaborating on it's > novelty/strengths. The implementation must become more robust, presently it > is ways too trivial to break things. Thanks again for the review! There are lots of good ideas raised here. Let me know if you have any other feedback or if I can explain anything further/more clearly. -kyle [1] https://github.com/kylelutz/compute/issues [2] http://kylelutz.github.io/compute/boost/compute/mapped_view.html [3] http://kylelutz.github.io/compute/boost/compute/program_cache.html

7 16

[block_ptr] Region Based Memory Managment
by Phil Bouchard 27 Dec '14

27 Dec '14

Greetings Boost, I was talking to Filip Pizlo from the Webkit community and he pointed out that block_ptr is what we call a Region Based Memory Manager: http://en.wikipedia.org/wiki/Region-based_memory_management If we consider the worse case scenario, the sets (regions) can be unified to create a really big set. So to make block_ptr hybrid we could add a "garbage collection layer" to detect cycles inside a set that is not yet destructed. This function could be called explicitly whenever some memory usage quota is reached. It's very easy to implement. There is no other way to efficiently manage memory. Regards, -Phil

1 2

[test] Applying outstanding pull requests to develop and schedule merge of develop to master
by Jamie Allsop 26 Dec '14

26 Dec '14

Some time ago (more than 2 years) I submitted a set of four complimentary patches for Boost.Test of which one was partially applied. The tickets are: * Test Units (Cases and Suites) in Boost.Test do not capture __FILE__ and __LINE__ at declaration point making it impossible to provide source file linking using external test management tools https://svn.boost.org/trac/boost/ticket/7410 (modified patch applied) * Boost.Test, since boost 1.48 is using the deprecated Boost.Timer class - it should be updated to use the new class https://svn.boost.org/trac/boost/ticket/7397 https://github.com/boostorg/test/pull/15 * Detailed test status is not available in the Boost.Test log (status, assertions, passed) and so live test case status cannot be tracked https://svn.boost.org/trac/boost/ticket/7417 https://github.com/boostorg/test/pull/16 * Support multiple calls to framework::init() allowing wrappers to support running tests using test tools in full systems https://svn.boost.org/trac/boost/ticket/7419 https://github.com/boostorg/test/pull/17 I've updated and resubmitted patches on more than one occasion and also variously created patches against (the now) develop and master so I can actually apply them for myself for each new boost version. Now, the reason for my post is two-fold. First - I'd like to see these patches applied. They cause no user impacts and simply (a) fix broken functionality and (b) *significantly* improve the usefulness of Boost.Test. I am more than happy to help with maintaining Boost.Test since we rely on it heavily and I believe, on the whole it is a good library. Second - it is about time we formulated a schedule for merging develop into master for Boost.Test. Otherwise all the patches in the world are simply pointless. The patches I've submitted, like others will never see the light of day even if they are applied because develop is very different than master and it looks like a merge may never happen. It should be noted that for my patches I have a completely different set that I apply to an actual Boost release because of the large differences between the two branches. To recap - it is time to start actively shepherding patches into Boost.Test develop, but more importantly, it is time we started looking at a schedule for merging Boost.Test develop to master. The longer it is left the worse the impact will be. A lot of good work has been done on develop - the longer it stays there the more people will move away from Boost.Test in their own code and it will only have relevance to Boost libraries themselves. Jamie

3 6

[Test] Command line option --list_content
by Andreas Noll 26 Dec '14

26 Dec '14

Hi everyone, Within our company we heavily use Boost.Test. We use Visual Studio and have written an Visual Studio extension to show all test suites and test cases of a given test executable. This allows our developers to run all tests or only parts of them. This is necessary because we have some lengthy running tests - one could say they are more integration tests than unit tests. What we have to do currently is patching the Boost.Test code to add a command line switch to output a test executable's contents to stdout. The output shows the hierarchy of test suites and test cases and is consumed by our Visual Studio extension. As I have recognized, our patch seems to cover the same functionality as the --list_content switch that already exists in the trunk version of Boost.Test. We would really appreciate that --list_content becomes part of the official boost releases to make our patch obsolete. My questions: 1. What are the reason(s) why-list_content is not (yet) added to the release? Is there any schedule for its release? 2. Is there any way how we can help with that issue? I'm new to the community but maybe there is something our team or me can do to get the feature released. Best regards, Andreas Noll

2 1

[compute] kernels as strings impairs readability and maintainability
by Mathias Gaunard 25 Dec '14

25 Dec '14

Hi, While reading through the code of Boost.Compute to see what it does and how it does it, I often found that the approach used by the library of putting all OpenCL kernels inside of strings was an annoying limitation and made it quite difficult to reason with them, much less debug or maintain them. This has a negative effect on the effort needed to contribute to the library. Has separate compilation been considered? Put the OpenCL code into .cl files, and let the build system do whatever is needed to transform them into a form that can be executed. This would also make it easier to eventually provide a CUDA backend.

7 12

[core] [addressof.hpp] [addressof_test2.cpp] ISO C++ says that these are ambiguous
by Sergey Sprogis 25 Dec '14

25 Dec '14

It looks like he following code fragment from boost/core/addressof.hpp (latest trunk version) violates ISO C++ overloading rules: template<class T> struct addressof_impl { static BOOST_FORCEINLINE T * f( T & v, long ) { return reinterpret_cast<T*>( &const_cast<char&>(reinterpret_cast<const volatile char &>(v))); } static BOOST_FORCEINLINE T * f( T * v, int ) { return v; } }; As a result, libs/core/test/addressof_test2.cpp fails to compile with Oracle Studio 12.4 C++ compiler while gcc-4.8.2 produces just warning here. It's easy to reproduce that behavior of both compilers with 26 lines test case listed below: gcc -c t.cc t.cc:7:33: warning: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: [enabled by default] return addressof_impl<T>::f(v,0); ^ CC -c t.cc "t.cc", line 7: Error: Overloading ambiguity between "static addressof_impl<convertible2>::f(convertible2&, long)" and "static addressof_impl<convertible2>::f(convertible2*, int)". t.cc ==================================== template<class T> struct addressof_impl{ static T *f(T &v,long){} static T *f(T *v,int){} }; template<class T> T *addressof(T &v){ return addressof_impl<T>::f(v,0); } template<class T> void scalar_test(T* =0){ T *px=new T(); T &x =*px; (addressof(x)==px)? 1 : 0; } class convertible{ public: convertible(int=0){} }; class convertible2{ public: convertible2(int=0){} operator convertible2 *()const{ return 0; } }; void foo(){ scalar_test<convertible>(); scalar_test<convertible2>(); } ============================== It would be nice if boost/core/addressof.hpp file will be changed somehow to fit the proper ISO C++ requirements. Sergey

3 2

[compute] Some questions
by Andrey Semashev 23 Dec '14

23 Dec '14

Hi, I have no experience with OpenCL or GPU computing in general, so bear with me if my questions sound silly. I have a few questions regarding Boost.Compute: 1. When you define a kernel (e.g. with the BOOST_COMPUTE_FUNCTION macro), is this kernel supposed to be in C? Can it reference global (namespace scope) objects and other functions? Other kernels? 2. When is the kernel compiled and uploaded to the device? Is it possible to cache and reuse the compiled kernel? 3. Why is the library not thread-safe by default? I'd say, we're long past single-threaded systems now, and having to always define the config macro is a nuisance. 4. Is it possible to upload the data to process to the device's local memroy from a user-provided buffer, without copying it to boost::compute::vector? Same for downloading. What I'd like to do is move some of data processing to the GPU while the rest is performed on the CPU (possibly with other libraries), and avoid excessive copying. 5. Is it possible to pass buffers in the device-local memory between different processes (on the CPU) without downloading/uploading data to/from the CPU memory? 6. Is it possible to discover device capabilities? E.g. the amount of local memory (total/used/free), execution units, vendor and device name? Thanks.

3 4

[compute] Review period extended till December 30 + sum up
by Antony Polukhin 23 Dec '14

23 Dec '14

Hi, Review period of Compute library extended till December 30. Some notes and answers to them that were pointed out during review so far: * Some of the algorithms could be tuned for a specific hardware - Library author is working on a auto-tuning solution and improves existing algos * Why OpenCL C API used instead of C++ API? - C++ API had issues, C API allows a bit more control. No C++ API for OpenCL 2.0 * API is not N4105 compatible, library is not N*** compatible - This could be easily fixed by a library that will use Compute as a backend * Some of the algorithms return futures while other work with command queues - This is because of the OpenCL design + async chains/futures would be probably added later * Not all the types of the Khronos API are supported - A few types are not documented yet, there's a patch in the works which would allow the Khronos C++ types to be passed into Compute algorithms * A few type related errors could be detected at compile time - This will be fixed, more asserts would be added to runtime only checkable places. Report issues to the tracker https://github.com/kylelutz/compute/issues * On small data sets CPU algorithm would work faster than a GPGPU. How about implicitly dispatching algo on CPU in those cases? - The call on whether to execute the algorithm should be left up to the user. While library author agrees that this would be a useful feature, he just don't think Compute is the right place for that logic. * How about providing way to do chains of async operations - This is a big task that will be solved some day. * How about providing Boost.ASIO like error handling via throw and error_code - Implementing an approach like ASIO's wouldn't be that difficult. Thanks to all the reviewers for spending their time and providing useful comments so far! -- Best regards, Antony Polukhin

1 0

[compute] Define user functions using lambda expressions
by Asbjørn 22 Dec '14

22 Dec '14

Hi, I'm probably missing something obvious, but how would I go about making a custom function using a lambda expression? Say I want to declare some function "sqr" which returns "_1 * _1", and then use this in a transform() lambda expression, ie transform(..., 2.0 * sqr(_1) - 3.0 * _1 + 5.0, ...); to evaluate 2x^2 - 3x + 5. If I try to use BOOST_COMPUTE_FUNCTION() I can't use the resulting function in a lambda expression it seems. Cheers - Asbjørn

2 2

[compute] some comments
by Mathias Gaunard 22 Dec '14

22 Dec '14

Hi, I do not know if I'll be doing a full review, but I have some comments from having skimmed through the code and documentation. From a quick glance, from all the algorithms that are supported, quite a few are not easy to implement with the OpenCL programming model efficiently. I think the documentation should say more about the implementation strategies of each algorithm, its complexity and how much it is parallelized.

2 1

[icl] insert_iterator and elements
by Jeff Flinn 22 Dec '14

22 Dec '14

interval_set has overloaded insert methods for both intervals and elements. Is there a reason there insert iterator lacks this ability. The line in the code below *itr = 4; fails to compile. This could be made to compile by: - adding an implicit constructor 'interval( const element& )' for the underlying (discrete) intervals, initializing to [element, element+1), or [element, element]. - adding an overloaded operator=( const element& ) - adding an element_insert_iterator class I've encountered 2 domains now where I need to construct an interval_set<int> from a range of ints. The most natural ways to accomplish this (for me) are: boost::copy( ints, inserter(int_interval_set) ); or boost::copy_range<int_interval_set>( ints ); Of course I can transform the incoming ints, but this seems a common enough usage pattern for the library to provide. Especially since the lack of this facility is asymmetric to the insert overloads of interval_set. #include <iostream> #define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS #include <boost/icl/interval_set.hpp> #include <boost/range/algorithm/copy.hpp> int main() { typedef boost::icl::interval_set<int> IdSet; typedef IdSet::interval_type IdInterval; IdSet ids; ids.insert(3); boost::icl::insert_iterator<IdSet> itr(ids, ids.end()); *itr = IdInterval(1,2); //*itr = 4; //compile error no viable operator = boost::copy(ids, std::ostream_iterator<IdInterval>(std::cout)); std::cout << "\n"; return 0; }

1 0

[compute] review
by Pavan Yalamanchili 22 Dec '14

22 Dec '14

*Design and Implementation* The library provides an STL-like library for OpenCL devices. Although there are other libraries offering similar behavior, Boost.Compute is the most complete and the most generalized. The directory structure is well organized and easy to dig through to understand the implementation or debug an issue. Others have pointed out the existence of the OpenCL C++ wrapper and the fact that Compute library does not use it. Here are a few reasons why I think the author was *right* in his design decisions. - The C++ wrapper begins to look similar to the original OpenCL C interface once you start using it in a generalized fashion. - cl.hpp is monolithic (single file 12k+ LOC) and is not modular enough to only include the parts that you need. - Compute and cl.hpp have two different goals. The biggest selling point of Compute is the set of algorithms it supports not its C++ wrapper around OpenCL. Having said that, I think the Compute library might be better off with an additional interface that accepts the OpenCL-C++ wrapped objects. *Documentation* The documentation is comprehensive and the API is documented well. There are a few improvements that can be done. For example, the reference is at the bottom of the TOC and is hard to see immediately. The API reference in the TOC can also be expanded out a bit more to show the general categories of algorithms that are supported. *Potential Usefulness* It is fairly easy to transition from applications using vector algorithms in STL to Compute. The wide availability of OpenCL devices makes the library useful to a large user base. *Domain Knowledge* I am a developer of the ArrayFire library[1]. I am the lead engineer of a company that specializes in this domain. I consider myself to be fairly knowledgeable in this domain. *Experience with the library* ArrayFire depends on Boost.Compute for a few algorithms in our OpenCL backend. We explicitly and implicitly (via ArrayFire) test Boost.Compute on a variety of hardware / compilers / operating systems. Compilers and Operating systems we use: - gcc 4.8, 4.9 on various Linux distributions - clang 3.4 on OSX - Visual Studio 2013 on Windows. We have found some bugs through our usage that have been mostly resolved by the author or by patches sent by us. *Conclusion* The experience overall has been fairly positive. But there are certainly *some* rough edges that need resolving. An issue that will plague any OpenCL library is the performance portability across various devices. It would be nice if the author can talk about how he plans to eventually address this issue. Overall, Boost.Compute will be a great addition to Boost. But before it is accepted the following issues need to be addressed. - The tests need to be a bit more comprehensive. - Due to the general nature of OpenCL, there needs to be a list of "officially supported" devices. - Make sure all the tests are passing on the supported devices. *Links* [1] https://github.com/arrayfire/arrayfire

2 1

A Google Summer of Code Proposal(Boost C++)
by Mudit Sharma 22 Dec '14

22 Dec '14

Respected Sir, I have been studying the Boost C++ libraries.I see that there isn't any library for game development in Boost C++. I propose a new library for game development for Boost C++ under which I propose to use the pygame library of python.Make a Boost C++ analogue for pygame library of python.. *I would like to know if this can be taken as a GSoC'15 project?* Thanking You Mudit Sharma (Student,Pursuing Electronics And Communication Engg. At Delhi Technological University,Delhi,INDIA)

5 5

IDE for developing Boost
by Jens Müller 20 Dec '14

20 Dec '14

Hi, I am looking for recommendations for developing Boost, especially code in the graph library. At work, most developers (not for Boost, for some commercial software), most developers are using Eclipse. This works quite fine as soon as it has properly auto-discovered include paths etc. But before fiddling around with Eclipse to get all the settings right, I'd wanted to to ask for your recommendations. And maybe there are already settings available to make it "just work", at least initially. Cheers, Jens

16 22

[Phoenix] [Bug Fix] A fix for boost::bind compatiblity now on test.
by Fletcher, John P 20 Dec '14

20 Dec '14

For a long time there have been problems with some of the tests for Boost Phoenix compatibility with Boost Bind. These have shown up with recent compilers, gcc 4.9.0 and Clang 3.5 and 3.6. I have discovered that the problems were caused by incorrect overload resolution where some cases were being wrongly allocated. I have just uploaded a patch to develop which passes all tests with gcc 4.9.0 and I hope fixes this problem. The solution involves the use of boost::lazy_disable_if to reject the wrong functions from the overload set and allow them when they are needed. Tests affected are: bind_member_function_tests, bind_mf2_test, bind_test I have not traced a bug report which directly relates to this. I hope this helps. Please reply if there are any problems. Best wishes for the season. John Fletcher

1 0

pygame in boost C++
by Mudit Sharma 20 Dec '14

20 Dec '14

I have been studying the Boost C++ libraries.I see that there isn't any library for game development in Boost C++. I propose a new library for game development for Boost C++ under which I propose to use the pygame library of python.Make a Boost C++ analogue for pygame library of python.. *I would like to know if this can be taken as a GSoC'15 project?* Thanking You Mudit Sharma

1 0

Questions to help me determine export classification of Boost libraries
by Ben Fritz 20 Dec '14

20 Dec '14

Hello, list! One of the contractors I'm working with has delivered code to us that pulls in a few boost libraries. In order to release this code to our customer, I need to determine the Export Control Classification Number (ECCN) of the boost libraries. I see in the archives that someone has asked for the ECCN directly without success ( http://lists.boost.org/boost-users/2008/01/33241.php) so I'm currently trying to use a questionnaire put together by some of the export experts within my company to figure this out. If there is an ECCN already listed somewhere, please point me to it, otherwise I'll continue. I'm interested specifically in version 1.56.0 of the boost libraries. However, since I don't see any major additions or deletions in the 1.57.0 release notes, I assume the answers will apply to both versions. Apparently the export classification is primarily based on two things: 1. Does the library have anything specifically designed for military use? I'm assuming the answer to this is "no". Please correct me if I'm wrong. 2. Does the library include any strong encryption? This includes symmetric or asymmetric encryption with certain key lengths, cryptanalytic functions, intrusion detection, quantum cryptography, "reduce information-bearing signals" (not sure what that is), and other cryptographic technology. I looked through the list of libraries documented here: html/index.html <http://www.boost.org/doc/libs/1_57_0/libs/algorithm/doc/html/index.html> http://www.boost.org/doc/libs/?view=categorized >From the description of each library, I was mainly concerned with Boost.Algorithm, Boost.Asio, and Boost.Uuid. >From the documentation of Boost.Algorithm at http://www.boost.org/doc/libs/1_57_0/libs/algorithm/doc/ <http://www.boost.org/doc/libs/1_57_0/libs/algorithm/doc/html/index.html>, it looks like there is no encryption technology in the library. Can someone confirm? Boost.Asio contains some SSL interfaces, which undoubtedly contains encryption technology. However, according to http://www.boost.org/doc/libs/1_57_0/doc/html/boost_asio/overview/ssl.html these interfaces require OpenSSL to be used. Does this mean that the Boost.Asio library itself does not contain encryption, it only provides an interface to another library which does the encryption? I.e., is it a true statement, that Boost.Asio contains no encryption technology in either its source code or in the compiled binary, and that in order to use encryption I would need to link in a separate library? Boost.Uuid contains some cryptographic hash features. However, I understand that a cryptographic hash cannot by itself provide any message encryption, so I do not believe this should qualify. Is there anything I'm missing here? Does Boost.Uuid contain other technology that might qualify? Please also let me know if I missed any encryption in other Boost libraries, as I only looked at the library descriptions, and am not familiar with any of the library functionality. -- Ben Fritz

6 8

[RPC] Compile-time reflection for RPC and mocking
by Peter Bindels 19 Dec '14

19 Dec '14

Hi all, I've searched through the Boost mailing list history to find related emails and the last I found was from January where Oleg Labutin and Hartmut Kaiser discussed compile-time reflection in the context of RPC mechanisms. Based on Hartmut's speech last Saturday introducing HPX and explaining a bit about async/future/promise I tried to implement a simple RPC mechanism that uses then to decouple work and the result I have so far is very promising. I have a simple interface with a call that returns a future, and the caller does not distinguish between calling the actual object and calling on a proxy, as both return a future<T>. It does what the discussion mentions - serialize the name of the interface and function, as well as the arguments (basically the mangled name of the interface function) to ensure there are no mismatches. I would like to take this oppurtunity to propose two things: - I can work on this idea to work it out into a full RPC mechanism, to be proposed for Boost.RPC, if there is enough interest. Currently it uses macros to generate and wrap functions, and a simple serializer that serializes in the same way that Protobuf and Thrift also serialize. - Given a compile-time reflection method, the entire proxy class and dispatch class can be auto-generated from the interface class - the full code for registering an interface with the RPC mechanism would collapse to RPC::Register<T>(); To do so, it would need two language additions. It needs access to a compile-time iterator over functions and traits about the argument types, return type, name and whether it is a virtual function. For the prototype this can be manually generated for an interface to show it works. Additionally, it would need to be able to use such a definition to instantiate a virtual function from a base class - basically, hooking up an std::function<X> to a virtual function X directly. I think this is well-implementable (probably reusing most code from lambdas for the link code), but I don't know whether that's true. On the second note, I also proposed a Mock library a few years ago. This basically fell flat on the code that I suggested being very unsafe and using many hackish methods to mock functions. Using the compile-time reflection proposed for the second bullet I would be able to replace the entire hackishness from that with 100% compliant code, with only one minor regression in functionality. That should make it Boost-OK at least from a language standards perspective. Any ideas? Reactions on RPC or Mocking? Best regards, Peter Bindels

8 15

file_descriptor::read() docs?
by Olaf van der Spek 19 Dec '14

19 Dec '14

Hi, Where is file_descriptor::read() documented? Shouldn't it be at http://www.boost.org/doc/libs/1_57_0/libs/iostreams/doc/classes/file_descri… ? -- Olaf

2 3

[compute] Request to extend the review period till 30 December
by Antony Polukhin 19 Dec '14

19 Dec '14

Hi, Now, when the review of Compute library is going on, it seems that 10 days is not enough. Some of the Boost developers are on a vacations or do not have much free time right now. I've got a few personal requests to extend the review period. Library author agrees to extended review. 30 of December seems like a reasonable date for the last review day to both of us. Do the review wizards agree for extended review? -- Best regards, Antony Polukhin

2 1

[inteprocess] static analyzer results
by Gaetano Mendola 19 Dec '14

19 Dec '14

We have upgraded to use boost 1.55 and our static analyzer is telling us: interprocess/detail/win32_api.hpp: ~1145 if if(!SetSecurityDescriptorDacl(&sd, true, 0, false)) takes the true branch then sa.nLenght, sa.lpSecurityDescriptor, sa.bInheritHandle result in not initialized members. interprocess/sync/spin/recursive_mutex.hpp: CTOR at 71 leaves the m_s not initialized interprocess/mapped_region.hpp: ~341 boost::uintmax_t(mapping_size - (offset - page_offset)) > boost::uintmax_t( std::size_t(-1))) is always false

1 0

[compute] review
by Sebastian Schaetz 17 Dec '14

17 Dec '14

Hi, Here is my review of Boost.Compute: 1. What is your evaluation of the design? The library is based upon OpenCL, a cross-platform cross-device open standard that abstracts access to and provides a programming model for many-core vector co-processors such as GPUs. These co-processors are usually referred to as "devices". The library provides a wrapper layer around the OpenCL C interface. It skips the standard OpenCL C++ wrapper which I don't consider a problem because except for destructors there is no added value in using this wrapper. In my opinion Khronos should adopt Boost.Compute as their C++ layer for OpenCL. Boost.Compute provides compatibility with the OpenCL C interface through conversion operators that decay Boost.Compute types to their OpenCL C equivalents. This can be quite useful. On top of this wrapper Boost.Compute exhibits 3 core components: * types to interact with and issue commands to devices: these follow OpenCL concepts but are not necessary if defaults are used * means of managing memory (allocate, copy) on devices: this component contains also asynchronous operations which I consider essential in a library that deals with co-processors * a collection of parallel primitives and meta-functions with an STL interface: this components contains powerful iterators to combine containers and algorithms to implement more complex algorithms in an efficient manner One thing I'm not clear about is how asynchrony is handled. Command queues are exposed, issuing commands to different queues is a way to express concurrency. At the same time copy_async returns a future which is another way of exposing concurrency. It is out of the scope of Boost.Compute to solve the challenges of asynchronous/concurrent operations because it is a different and difficult topic not yet solved for C++ in general either, but at least the documentation should be more explicit about which commands are executed when, which commands are synchronous, which are asynchronous and what is the role of the command_queue in this regard. 2. What is your evaluation of the implementation? I did not evaluate the implementation in detail but looked at a few of the tricks Boost.Compute uses to generate kernels. The implementation of this part of the library is good and instructive. 3. What is your evaluation of the documentation? Boost.Compute documentation is of excellent quality. The recent addition of performance data is helpful. I could not find any documentation about fancy iterators, this should probably be added. Also, it would be great if the my questions regarding asynchrony/concurrency could be addressed in the documentation. 4. What is your evaluation of the potential usefulness of the library? Boost.Compute is extremely useful. With this library a developer familiar with the STL can utilize the processing power of GPUs without any knowledge of vector co-processor programming. The documentation shows that for large vector sizes, some Boost.Compute algorithms outperform the STL by an order of magnitude. 5. Did you try to use the library? With what compiler? Did you have any problems? I tried the unit-tests on a 8x GeForce Titan system without any problems and on a ARM Mali GPU with some unit tests failing. I'll be working with the library author to fix tcomp.lib.boost.develhe problems in these unit tests. I used gcc 4.8.2 for the tests on both GeForce and Mali. 6. How much effort did you put into your evaluation? A glance? Aquick reading? In-depth study? I reviewed the library a few months ago in-depth and reread the documentation for this review as well as ran some unit tests. 7. Are you knowledgeable about the problem domain? My job involves working with both CUDA and OpenCL. Furthermore I am the author of the Aura library [0] a similar, albeit lower level library for accelerator programming. 8. Do you think the library should be accepted as a Boost library? I think the library should be accepted into Boost. The interface is simple and easy to understand for non-experts and the benefits of using this library can be significant. I'd like to add that Boost.Compute represents one level of abstraction for accelerator programming. I'd like the Boost community to keep an open mind when it comes to different levels of abstraction, either lower (i.e. my Aura library) or higher (i.e. VexCL). Libraries with different levels of abstraction can coexist, be compatible with one another or could even build upon one another. Best Regards, Sebastian Schaetz [0] https://github.com/sschaetz/aura

2 1

File Handle and FILE* wrappers?
by Olaf van der Spek 16 Dec '14

16 Dec '14

Hi, Would there be any interest in wrappers for file handles / descriptors and FILE*? Sometimes one needs native handles or FILE* for interoperability or special features like memory mapped IO, but standard C++ doesn't provide convenient RAII friendly wrappers for these. The idea seems trivial yet quite useful. I'm aware of <boost/iostreams/device/file_descriptor.hpp> but it seems to be too high-level. I've put a simple start for FILE* at https://code.google.com/p/xbt/source/browse/trunk/xbt/misc/xbt/cfile.h What do you think? Also posted at https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/Q4RdFSZg… -- Olaf

8 21

[utility] What happened to OptionalPointee/compare_pointees?
by Mostafa 16 Dec '14

16 Dec '14

1) OptionalPointee/compare_pointees reside here: libs/utility/OptionalPointee.html, but there's no way to navigate to it from here: libs/utility/ or here: libs/utility/utility.htm 2) IMO, compare_pointees should have stand alone documentation, and be grouped with pointee and indirect_reference. 3) pointee and indirect_reference are not iterator specific, therefore they shouldn't reside under iterator's documentation. IMO, compare_pointees, pointee and indirect_reference should all reside under a pointee utilities section. Thanks.

1 1

Spam ticket
by Barend Gehrels 15 Dec '14

15 Dec '14

Hi, This is not a spam-ticket but an annoying spam-comment in a long closed ticket. How can we handle this? Can the user of this comment (Smithg358) be blocked? Thanks, Barend -------- Original message -------- Onderwerp: Re: [Boost C++ Libraries] #6019: Convex hull and Area, combined, sometimes give wrong result Datum: Sat, 13 Dec 2014 23:23:53 -0000 Van: Boost C++ Libraries <noreply(a)lists.boost.org> CC: boost-bugs(a)lists.boost.org #6019: Convex hull and Area, combined, sometimes give wrong result ------------------------------------------+------------------------------ Reporter: Crispin Cooper <cooperch@…> | Owner: barendgehrels Type: Library Submissions | Status: reopened Milestone: Website 1.X | Component: xpressive Version: Boost.Build-M3 | Severity: Not Applicable Resolution: | Keywords: convex hull area ------------------------------------------+------------------------------ Changes (by Smithg358): * status: closed => reopened * severity: Problem => Not Applicable * type: Bugs => Library Submissions * component: geometry => xpressive * version: Boost 1.47.0 => Boost.Build-M3 * milestone: To Be Determined => Website 1.X * resolution: fixed => Comment: Your goal is to breed all the different dragons available to you ddgkbecefcfgddbk -- Ticket URL: <https://svn.boost.org/trac/boost/ticket/6019#comment:7> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.

2 2