Re: [boost] Going forward with Boost.SIMD

Subject: Re: [boost] Going forward with Boost.SIMD
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-04-23 10:44:31

On Tue, Apr 23, 2013 at 5:43 PM, Mathias Gaunard <
mathias.gaunard_at_[hidden]> 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.