- Boost - lists.preview.boost.org

[compute] review
by Vicente J. Botet Escriba 01 Jan '15

01 Jan '15

Hi, I have no time to do a complete review. Anyway here it is my minimal review *1. What is your evaluation of the design?** *** I would prefer that the algorithms take as first parameter the queue (which could be abstracted to an asynchronous executor). The performances let think that there is no interest in using the library for containers having less than 10^4/10^5 elements. Even if this is considered a low level library, the documentation should show how a library writer could make use of the provided interface to provide a higher one. I would prefer that the library make use of std::future or boost::future class instead of adding an additional one. Do the author tried to make use of the existing futures? if yes, which problems were found? I'm missing a range interface to most of the algorithms. I suspect that as this is a C++03 library it doesn't take advantages of some interesting C++11+/C++14 features. It is not clear which operations are synchronous, which ones could block, ... In order to get the native OpenCl handle I suggest to name the function get_native_handle instead of get. *2. What is your evaluation of the implementation?* I've not see at the implementation. *3. What is your evaluation of the documentation?* The documentation lacks of some core tutorials. I was unable to have an idea of what a context is, what can be done with a command_queue, what is a Kernel, a pipe, ...? Does it mean that the user must know OpenCL? The reference documentation should follow he C++ standard way, including pre-conditions, effects, synchronization, throws clauses. I would appreciate a description of the algorithms used, how the parallelism is used? is this completely managed by OpenCL or do the library something else? *4. What is your evaluation of the potential usefulness of the library?** *** This is essentially an optimization library. It should be quite useful, but the performances results don't probe it. *5. Did you try to use the library? With what compiler? Did you have any problems?** * No.* *** *6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?** *** A glance. *7. Are you knowledgeable about the problem domain?* Yes and not. I don't know about OpenCL, but I'm aware of the current parallel proposals. *8. Do you think the library should be accepted as a Boost library? ** * As I have not taken too much time I'm unable to say that this library should not be included in Boost. So I vote to include it conditionally, subject to: * I would need some performances that probe the library is better than using standard STL containers in most of the cases. * The documentation should be completed with more tutorials and a better reference documentation. Best, Vicente

4 4

[compute] review
by Gruenke,Matt 31 Dec '14

31 Dec '14

> 1. What is your evaluation of the design? I agree with other comments made about synchronization. The design should be more explicit about what's asynchronous, and ideally utilize only one mechanism for synchronization. One approach that would have made this clearer is if high-level operations were actually objects that got posted to the command_queue. Regarding synchronization, I'm a also bit concerned about the performance impact of synchronizing on all copies to host memory. Overuse of synchronization can easily result in performance deterioration. On this point, I think it might be worth limiting host memory usable with algorithms, to containers that perform implicit synchronization to actual use (or destruction) of results. Give users the choice between that or performing explicit copies to raw types. Also, I agree with Thomas M that it'd be useful for operations to return events. That said, if you told me it doubled the overhead involved in dispatching operations, I'd suggest to make it optional through overloads or via a mechanism in the command_queue itself. > 2. What is your evaluation of the implementation? It seems a bit heavy to be header-only. I'd agree with Andrey Semashev, regarding thread safety, except I think it shouldn't be an option at all. That said, not all operations on all objects need be thread safe. I think the Boost.ASIO documentation provides a good example of how to express different thread safety limitations. Now, I haven't examined the use of thread-local storage, but do you feel there's a strong case to be made for the thread safety it's providing (especially, given that you seem to feel it's non-essential)? I'm a bit concerned about the use of type names ending in '_', such as float4_. Is this consistent with Boost conventions? I've only seen that used in other Boost libraries to denote class member variables. I didn't notice any unit tests specifically intended to verify exception-safety. I'd want to know that had been thoroughly vetted, before I'd consider using Boost.Compute in production code. Finally, based on the docs, it seems there's a bug in boost::compute::command_queue::enqueue_copy_image_to_buffer() and boost::compute::command_queue::enqueue_copy_buffer_to_image(). The region and origin parameters should be arrays, in the 2D and 3D cases. If this discrepancy is intentional, it should be noted. I haven't exhaustively reviewed the reference docs, so there might be other issues of this sort. > 3. What is your evaluation of the documentation? It needs more and better-documented tutorials (and I'm including the "Advanced Topics", here). Some of the reference pages could use more details, as well, especially concerning synchronization and exception usage. Regarding exceptions, there should be discussion of specifically what is invalidated by which kinds of errors. If any errors are non-recoverable, this should also be called out and perhaps derived from a different or additional baseclass (not a bad use case for multiple inheritance, actually). I agree with Mathias Gaunard that it would be helpful to discuss computational complexity, device memory requirements, and the various methods used to implement some of the algorithms. You could continue to omit these details on the simple algorithms, though. > 4. What is your evaluation of the potential usefulness of the library? This is my biggest misgiving, by far. In the very near future, I expect developers will opt for either SYCL (https://www.khronos.org/opencl/sycl) or Bolt (https://github.com/HSA-Libraries/Bolt) SYCL provides a modern, standard C++11 wrapper around OpenCL, with better concurrency control and support for integrating kernels inline. Bolt provides many of the same higher-level abstractions found in Boost.Compute, but with forthcoming support for HSA. To have the kind of lasting relevance and broad applicability to which all Boost libraries should aspire, I think Boost.Compute should be architected to support multiple backends. Though OpenCL support is currently ascendant, it's far from universal and is already flagging on some platforms (Nvidia, not the least). And HSA provides a foundation on which alternatives are actively being built. Most importantly, there exist multitudes of multi-core and multiprocessor systems which lack OpenCL support. It would be eminently useful to support these with such backends as thread pool, OpenMP, etc. And backends could be added to support new technologies, as they mature. > 5. Did you try to use the library? With what compiler? Did you have any problems? I downloaded and inspected the sources and some examples. I didn't have any questions or concerns that would be addressed by experimentation. > 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Review of the documentation, some sources, some examples, and a refresher on SYCL & Bolt. I also read all of the reviews and replies sent thus far. > 7. Are you knowledgeable about the problem domain? I've been developing production code for parallel and heterogeneous computing platforms for the majority of the last 16 years. I've followed OpenCL since version 1.0 was finalized. I've also submitted bug reports and minor patches for Khronos' official C++ OpenCL interface. > 8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Not in its current state. The primary issue is that it's too OpenCL-centric. It should support more backends, even if these are just compile-time options. This is crucial for both current and lasting relevance. Beyond that, better concurrency control is crucial for optimum performance. If done well, it could even help further reduce usage errors. Matt ________________________________ This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.

13 63

Boost.Build files at superproject root
by Peter Dimov 31 Dec '14

31 Dec '14

Currently, the Boost root contains the following files: boost-build.jam boostcpp.jam boostcpp.py bootstrap.bat bootstrap.sh Jamroot which are part of Boost.Build and so their rightful place is in the submodule. Would it be possible to move them there, and leave only minimal forwarding shims (that would never need to change) in the superproject?

3 5

[compute] Review
by John Bytheway 31 Dec '14

31 Dec '14

Here's my review. 1. What is your evaluation of the design? The design of building on OpenCL seems sound, for the reasons Kyle has explained. The fact that it has real users is very encouraging. I don't really like the name (I was unable to guess what the library was about from the name), but it's not worth changing at this point. I am worried about the compile-time configuration with macros. I would hope that BOOST_COMPUTE_HAVE_THREAD_LOCAL could be read from Boost.Config. For the two features which require linking against other Boost libraries, my instinct would be to have them on by default, rather than off by default (that should be easier if and when Boost.Compute is part of the Boost distribution). It would be very nice to have range versions of all the algorithms. I find myself using the boost::range algorithms much more than the std:: ones these days. Similarly, it would be good to provide the safer 4-iterator versions of equal, is_permutation, mismatch (and any I've forgotten) as were added to C++14. Some minor things: - Consider renaming boost::compute::lambda to be consistent with one of the other placeholder-containing namespaces from std or Boost. (You can keep the old name as an alias for backwards-compatibility). - Why the default of .25 as the bernoulli_distribution parameter? - Did you consider using Boost.Predef for your version macro? 2. What is your evaluation of the implementation? Only looked at a couple of things while trying to understand the docs. 3. What is your evaluation of the documentation? Overall, not too bad. More tutorial would be good. In particular, something using some of the standard algorithms. Some concerns: - All the header links off <http://kylelutz.github.io/compute/boost_compute/reference.html> are broken. - All or most of the things in "See also" sections look like they ought to be links but aren't. - For all your function parameter documentation, the list of parameters seems to be sorted alphabetically by parameter name rather than in the order they are passed to the function. This is really weird... - As others have mentioned, some kind of complexity estimate or promise for the algorithms is very important. In particular it would be good to understand how much parallelism they take advantage of and how they ought to scale with device compute capability. - The warning about accumulate being slow for floats should be much more prominent. - <http://kylelutz.github.io/compute/boost/compute/copy.html> mentions copying from e.g. a std::list to a compute::vector. It would be nice if it gave some kind of indication as to how efficient we can expect such an operation to be. In particular, I guess it ought to do some kind of buffering on the host? - The way I normally copy into vectors is call v.reserve(...) and then copy to std::back_inserter(v). I tried that with a compute::vector and unsurprisingly it was very inefficient. I see you already warned about this in the push_back docs, but perhaps it should also be highlighted in the documentation of compute::copy. - Is there no version of inclusive/exclusive_scan or iota using an arbitrary associative operator? - <http://kylelutz.github.io/compute/boost/compute/includes.html> it's unclear whether the subrange has to be contiguous. - min_element and max_element should cross-reference minmax_element. - What source of randomness does random_shuffle use? - Why does reduce return its result through an OutputIterator? - <http://kylelutz.github.io/compute/boost/compute/remove.html> Does this really remove things or use std::remove semantics? You should clarify and document the return value. (Same with remove_if, unique) - I can see how sort_by_key might be useful, and I'm slightly surprised that there's no stable_sort_by_key (which seems like it would be more useful than stable_sort). Any particular reason? - The boost/compute/types headers docs seem to be broken or missing. In particular I couldn't find reference documentation for float4_ et al. - I was interested to see allocators, but the docs seem uninformative: <http://kylelutz.github.io/compute/boost/compute/pinned_allocator.html> - Given the confusion with std::future, you might want to clarify whether compute::future's destructor blocks. - Also, <http://kylelutz.github.io/compute/BOOST_COMPUTE_CLOSURE.html> doesn't explain what format the lists (arguments and capture) should be in. Preprocessor functions often take lists in other formats, such as a Boost.PP Sequence <http://www.boost.org/doc/libs/1_57_0/libs/preprocessor/doc/data/sequences.h…>, and your example only has one-element lists, so it's not enough to clarify this point. (To be clear: I'm not suggesting you should use Boost.PP sequences, merely that you should make it clear in the docs whether you are). - <http://kylelutz.github.io/compute/BOOST_COMPUTE_CL_CALLBACK.html> is empty, as is <http://kylelutz.github.io/compute/BOOST_COMPUTE_MAX_ARITY.html> - <http://kylelutz.github.io/compute/boost/compute/valarray.html> - presumably compute::valarray has overloaded arithmetic operators? Are they mentioned anywhere? - <http://kylelutz.github.io/compute/boost/compute/vector.html> the unusual behaviour of vector's size_t constructor (not initializing the elements) should be warned more prominently. - <http://kylelutz.github.io/compute/boost/compute/device.html> the documentation of the enum type in the synopsis seems to be messed up. Similarly memory_object. - <http://kylelutz.github.io/compute/boost/compute/function.html> I'm puzzled by this interface. What's the name for? Would one ever use this constructor rather than e.g. make_function_from_source? - <http://kylelutz.github.io/compute/boost/compute/field.html> My reading of this is that when you get the type wrong you are guaranteed some kind of meaningful error report, and not just undefined behaviour; is that right? Perhaps you should clarify. - I can't guess what atomic_min and atomic_max do. - The right arrow ('next') link from <http://kylelutz.github.io/compute/boost/compute/atomic_xor.html> is broken (looks like the docs for the placeholders don't work). - The iterators should state what iterator category they have. - I can't guess what svm_ptr is for. Later I discovered svm_alloc and svm_free. Is there an RAII way to manage these things? - What does default_device do if there are no devices? Do the various environment variables mentioned have any kind of precedence? (Probably linking to the corresponding OpenCL docs is sufficient for such questions). Do they have to be exact matches? Are they case-sensitive? - What does find_device do if the requested device does not exist? - Can you give examples for type_definition? My guess was that it did the thing which type_name later turned out to do... - BOOST_COMPUTE_ADAPT_STRUCT should state that it must be used at global scope (i.e. not within a function or other namespace). - Congratulations for getting compile-time detection of internal padding into BOOST_COMPUTE_ADAPT_STRUCT :). You might want to mention in the docs that this will be detected, so people don't worry too much. - It looks like the performance tests don't include the time for copying data to (and, where applicable, from) the device. You should mention this on the Performance page. - You should probably add C++AMP to your things compared with in the FAQ. 4. What is your evaluation of the potential usefulness of the library? High. I've wanted something like this in the past and not found this. 5. Did you try to use the library? With what compiler? Did you have any problems? I used it with g++ 4.8.2 in C++1y mode. Some quick tests seemed to work OK, and indeed I was able to sort some large vectors of scalars faster using boost::compute::sort than std::sort, which is nice. I was pleased to see that 64-bit integers were handled fine. 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Couple of hours reading and trying simple examples. 7. Are you knowledgeable about the problem domain? I have done a couple of small projects with CUDA, and am generally knowledgeable, but with no previous OpenCL experience. 8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes. OpenCL seems to have fairly broad acceptance, but is rather difficult to use safely and with C++-isms. This library fills a useful niche. In an ideal world it will eventually be rendered obsolete by things like parallelism entering the standard library, but I doubt that will happen soon if at all. This provides a good solution now, and we shouldn't dismiss it simply because something sparkly is approaching, which may or may not turn out to be awesome and widely adopted. This library has clearly been a lot of work. Congratulations on making it this far, I hope the review is not too stressful :). John Bytheway

3 12

[system] Problem with boost::system::system_category() under QNX Momentics
by Piotr Orzechowski 31 Dec '14

31 Dec '14

At the beginning I must assure You that I've tried almost every solution from similar topics , still they didn't solve my issue. I'm building binaries from Boost 1.57 using **MinGW**. Boost libraries I'm using: *thread* and *system* build without any errors. I was trying: > toolset=gcc --target-os=qnxnto and toolset=gcc --target-os=qnx, both didn't work. I'm including correctly both libraries: > -lboost_system-mgw48-mt-d-1_57 -lboost_thread-mgw48-mt-d-1_57 after using: > `#define BOOST_SYSTEM_NO_DEPRECATED` I got rid of `boost::system::generic_category()` error, still I can't get rid of: > boost::system::system_category() I'm working in **QNX Momentics**. I'm totally out of ideas, I'm really looking forward for any help I can get.

2 2

Define to test for deprecated std::auto_ptr
by Fletcher, John P 31 Dec '14

31 Dec '14

I have some tests which are throwing up std::auto_ptr as deprecated with C++11. Is there a define that can be tested for in user code so that I can switch to std::unique_ptr when it is available? Something like this: #ifdef BOOST_NO_CXX11_UNIQUEPTR // use auto_ptr #else // use unique_ptr #endif Is there a general flag for C++11 or C++14 or is it all done on particular features? Thanks John

3 5

[compute] CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE
by Gruenke,Matt 31 Dec '14

31 Dec '14

I assumed there was some behind-the-scenes mechanism to maintain order of higher level operations, but I hadn't dug around to find them. I thought maybe there was an event object embedded in the device memory containers, used to track any pending writes to them, that could be added to the wait list of subsequent operations. But I don't see anything like this. So, will enabling out-of-order execution will break the higher level operations? Or am I missing something? Matt ________________________________ This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate, copy or take any action in respect of any information contained in it. If you have received this e-mail in error, please notify the sender immediately by e-mail and immediately destroy this e-mail and its attachments.

3 6

[compute] Review period starts today December 15, 2014, ends on December 24, 2014
by Antony Polukhin 31 Dec '14

31 Dec '14

Dear All, Review of the Compute library starts today on Mon 25st of December 2014 and will last for ten days. The Compute library provides a C++ interface to multi-core GPGPU and CPU computing platforms based on OpenCL. The project is hosted on GitHub at https://github.com/kylelutz/compute. Docs are available at http://kylelutz.github.io/compute/ Sources could be downloaded as a ZIP archive via https://github.com/kylelutz/compute/archive/master.zip Some pre-official reviews could be found in Boost Library Incubator: http://rrsd.com/blincubator.com/reviews/?library_id=669 Please, answer the following questions in your review: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? And finally, every review should answer this question: 8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. -- Best regards, Antony Polukhin

7 8

[compute] Review comments
by Asbjørn 30 Dec '14

30 Dec '14

Hi, not a proper review, just some comments from a library user based on studying documentation and writing a couple of simple programs using Boost.Compute on Intel's and NVIDIA's OpenCL implementations (i7 CPU and GTX970 GPU respectively). I used MSVC2013 for the tests. Some of these comments I've shared previously on this list, but I'm repeating them here for completeness. I have some background in heterogeneous development and OpenCL in particular, but I'm no expert. I found Boost.Compute easy to pick up and providing a nice C++ layer, with a nice mix of low and high level. Comments in no particular order: 1) As a library user and one who's not a C++ guru by any means, the error messages thrown up when passing incorrect parameters can be quite confusing. For example, first time I tried to use Boost.Compute I managed to not pass the ouput iterator parameter to transform(), so that the lambda expression ended up in that position instead. This resulted in several very confusing errors inside result_of.hpp, with no errors anywhere near my or Boost.Compute source code. It would be nice if the compilation could fail in more informative manners. 2) I did miss async versions of the algorithms, so it's possible to chain together multiple calls. Even though all the data sits on the compute device, the overhead of waiting for each operation to finish before queuing the next can make the compute gains completely irrelevant. 3) I think relevant calls should have a non-throwing form returning an error code, ala Boost.ASIO. 4) Threading has been mentioned in this list. At the very least the documentation should be updated to clearly state the thread safety of each call/class, ala Boost.ASIO. Beyond that I would like to be able to share a context between several threads, each which could contain their own queue and device. 5) If thread safety or similar important features requires a compiled part, I wouldn't mind Boost.Compute being non-header-only. Though if possible making it optional like other Boost libraries do would be great. 6) The tests, and preferably the performance tests as well, should have some way of testing all devices across all platforms. Currently they only test the default device on the default platform it seems. This is insufficient IMHO. 7) I'd like some way of defining user functions either as lambda expressions, raw OpenCL-C code via make_function_from_source or both, which can be used in lambda expressions for say transform(). Something like function<int (int)> sqr = _1 * _1; transform(inp.begin(), inp.end(), out.begin(), sqr(2 * _1 + 1)), queue); Overall I think Boost.Compute can be useful right now for some use-cases, and it has good potential to be significantly more useful with a bit more work. Just my 2 øre. Cheers - Asbjørn

4 5

[filesystem] imbue_utf8
by Peter Dimov 30 Dec '14

30 Dec '14

Since nowadays it's very common for programs to use UTF-8 for path encoding everywhere, I suggest that in addition to path::imbue( loc ), there should be path::imbue_utf8(), which imbues a UTF-8 codecvt facet. Since this is the default on Mac OS X, the implementation is already present, but the user has no way to get to it.

1 0