Re: [boost] [compute] review

Subject: Re: [boost] [compute] review
From: Francois Duranleau (xiao.bai.xiong_at_[hidden])
Date: 2014-12-29 10:58:07

On Sun, Dec 28, 2014 at 8:58 PM, Kyle Lutz <kyle.r.lutz_at_[hidden]> wrote:
>
> On Sun, Dec 28, 2014 at 3:55 PM, Gruenke,Matt <mgruenke_at_[hidden]> 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