Subject: Re: [boost] [compute] review
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2014-12-28 11:36:01
2014-12-28 15:26 GMT+03:00 Sebastian Schaetz <seb.schaetz_at_[hidden]>:
> Gruenke,Matt <mgruenke <at> Tycoint.com> writes:
> > To have the kind of lasting relevance and broad applicability to which
> 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
> 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.
> OpenCL is supposed to be the abstraction layer that does all that,
> That is, support multi-core, multi-processor and many-core vector
> co-processors. Asking Boost.Compute to support threading and OpenMP is
> asking it to do the job of OpenCL library implementers.
Here's my 0.05 rubles (it's much less than 5 cents):
* OpenCL is the non proprietary open widely used technology that is meant
to be the abstraction atop of any computing device. That's a 100% right
* CUDA is a proprietary technology nailed to the NVidia graphics. That's a
very platform dependent solution for Boost. Some CUDA code could be
possibly added to Compute only if it gives significant performance boost,
but OpenCL implementation must be provided for not NVidia based platforms.
* C++ AMP is not licensed with MIT, GPL, Boost or BSD. It's a "Microsoft
Community Promise" which makes me nervous and it does not look like a
perfect license for open standard
. C++ AMP is not as popular as OpenCL or CUDA. The only one non Windows
based implementation is the C++ AMP compiler that outputs to OpenCL. I see
no reasons to use this technology.
-- Best regards, Antony Polukhin