[tmurray]

reasonable SIMD support (let's limit it to SSE2 and above for "reasonable") has been in every Intel processor since what, Pentium 4? it's not much of a bolt-on anymore. one of the causes of the lack of good programming models for SIMD is that autovectorization was supposed to generate SIMD code for every application, but autovectorization isn't actually that great for many (most?) applications. (plus naive developers generally write terrible code--if array of structures versus structure of arrays doesn't make sense to you, you're probably writing code that cannot be autovectorized)

the lack of a magic compiler bullet is infinitely more true as soon as you look at anything remotely like a GPU, which gets into other more complicated problems due to a distinct memory space.

if I were to add any features like that to Go, I'd probably look in the direction of generating ISPC ( http://ispc.github.com/ ) or ISPC-like output. no need to solve the distinct address space issue (which you cannot solve), you have work creation so you don't need to do crazy scheduling hoops like persistent launches on the GPU, and it performs very well on Intel processors for SIMD-friendly applications.

[pcwalton]

I don't think the issue of separate address spaces is unsolvable. As long as you have a type system powerful enough to forbid aliasing between the CPU and the GPU code, you can do it. (For example, Rust's type system can encode task-local data.)

[masklinn]

> reasonable SIMD support (let's limit it to SSE2 and above for "reasonable") has been in every Intel processor since what, Pentium 4?

Yeah, and the Athlon64 (and Opteron) for AMD.