2014-12-28 15:26 GMT+03:00 Sebastian Schaetz
Gruenke,Matt
writes: 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.
OpenCL is supposed to be the abstraction layer that does all that, remember? 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.
Totally agree. 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 choice. * 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 http://en.wikipedia.org/wiki/Microsoft_Open_Specification_Promise#Scope_limi... . 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