On Tue, Apr 23, 2013 at 5:43 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
On 18/04/13 16:08, Niall Douglas wrote:
1. GPU and CPU stream computation technologies are still merging. In other
words, it's too soon to standardize this technology lest we accidentally break some novel form of new convergence. Happy to reconsider post-C++14.
I think CPUs and GPUs are different things, and that it is a mistake to consider an unified programming model.
A GPU is an accelerator for large regular computations, and requiring sending memory and receiving it back. It's also programmed with a very constrained programming model that cannot express efficiently all kinds of operations.
A CPU, on the other hand, is a very flexible processor and all memory is already there. You can make it do a lot of complex computations, irregular, sparse or iterative, can do dynamic scheduling and work stealing, and have fine-grained control on all components and how they work together.
IMHO, there is a clear trend of convergence. GPUs are slowly getting close to CPUs, both in terms of capabilities and physical distance. For example, AMD's APU share execution units between CPU and GPU and I expect Intel to eventually follow that lead. GPU and CPU already share memory. The only thing left is to extend x86 instruction set to employ additional units in the GPU. On the other hand, Nvidia is planning Maxwell (to be released next year) to include an ARM core within the GPU, so the graphics card becomes more independent from CPU and the main memory. Also take a note of Intel Xeon Phi, which is basically a CPU coming close to GPU in terms of number crunching. But I have to say I don't support the point of delaying standardization to wait and see what comes out of this diverse field of technologies. Things are evolving constantly, so we can end up waiting forever that way. I don't advocate for rushing the standardization but SIMD technologies, although different in different architectures, are quite established and have proved to be useful. If there is a common extensible layer that can simplify programming SIMD, why not standardize it? Anyway, I will be a happy user of Boost.SIMD even if it doesn't go to the standard, provided that it fits my needs.