Re: [boost] [compute] review

On Sun, Dec 28, 2014 at 8:58 PM, Kyle Lutz wrote:

On Sun, Dec 28, 2014 at 3:55 PM, Gruenke,Matt wrote:

...

I didn't mean to imply that it *needed* to have a backend for XYZ. I am merely *suggesting* backends such as a threadpool or possibly OpenMP. My point was about the design - that it should facilitate the addition of backends, in order to address both existing and future systems where OpenCL support is absent or inefficient.

Again, the key point is that the design should accommodate different backends. Whether a given backend is developed depends on whether there's enough interest for someone to write and maintain it. And perhaps some backends will exist only as proprietary patches maintained in private repositories of users. The main contribution of Boost.Compute would then be the framework, interface, and high-level algorithms.

While I agree that this would be useful, and API like this isn't the goal of Boost.Compute. I think there is room for a higher-level library to provide a more abstract parallel interface which could potentially use Boost.Compute in addition to other available parallel APIs (e.g. OpenMP, TBB, CUDA, MPI, etc.). In fact this is very much what the C++ parallelism TS is attempting to provide.

I generally agree with Matt. If we intend Boost.Compute to be widely available and useful on many platforms (Windows, Mac, and Linux is far from being the entire world today; just think of iOS, where there is no OpenCL), absolutely sticking to OpenCL seems to me as not being a good solution. Thus, if adding the possibility of other backends is not part of Boost.Compute's goal, then why not name it Boost.OpenCL? -- François Duranleau