Autovectorization alone is difficult in C and C++ because the languages provide almost no useful information about aliasing. Precise aliasing info is just the tip of the iceberg regarding what you would need for GPU-based autovectorization.
a[] = c * b[];
Another aspect of D that enables parallization is the use of ranges + algorithms. Although currently unexploited, it has the potential to be able to express parallel algorithms, and then take advantage of that.
It also does not help with problems that are not as embarrassingly parallel, but could still benefit from vectorisation, such as summations (or reductions in general), or things that contain their own inner control flow (think a Mandelbrot set, where you have a larger outer parallel loop with an inner serial while-loop).
It'll be interesting to see what sort of context-switch performance comes out of the Zen APU devices when they are released (next year I believe).
I'd be somewhat surprised if Intel and NVidia aren't working on similar things.
Shared memory by itself will not have a significant performance impact here (although it simplifies the data movement substantially). For a scalar-vector multiplication, you are strongly memory bound, and so you still have to wait for all the memory to be retrieved over the bus. You are correct if both CPU and GPU are behind the same bus (such as if the GPU is on the same die), but modern GPUs support shared virtual memory even for non-integrated GPUs.
Is that similar to the C++ std::algorithm execution policy features introduced in C++17?
Foo[] foo = ...;
foreach(f; foo) { f.bar.baz.quux; }
and the computation is parallelisable then you can write
import std.parallelism; foreach(f; parallel(foo)) { f.bar.baz.quux; }
and it will parallelised across threads.
I guess std.parallelism's parallel might be more analogous to an "instance" of an executor.
std::sort(par,a.begin(),a.end());
to call a parallel implementation of sort on `a`.
probably won't get on the front page of HN :|