[Boost-announce] [boost] [compute] Review period extended till December 30 + sum up

Subject: [Boost-announce] [boost] [compute] Review period extended till December 30 + sum up
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2014-12-23 05:20:57

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