This is a great series of posts, highly recommended.
From my perspective, as someone who was once on one of the Larrabee graphics teams (but not the same one as Matt), I'd agree that the programming model was a big issue. For us, even C++ with intrinsics wasn't fast enough for the most important code, since we didn't control the compiler (note that I'm only speaking anecdotally here, these decisions pre-date my involvement). So we had our own programming language that was more like Python with intrinsics, that hooked into the back end of the shader compiler (which handled register allocation and scheduling).
This probably wasn't the best call for a Larrabee programming model "for the masses" (even lots of people on the team were skeptical of it)... But damn, that was a fun project. We needed the ability to try any crazy idea we could think of, because that's the only thing that could work.
Probably. To vectorize effectively for wide SIMD architectures, you need to start with the right data-layout properties (struct of arrays, instead of array of structs), as well as vectorizing at the right level. The standard way people write code in C/C++ is simply not that great for doing this stuff automatically.
The difference is going to be a lot more minor if you use C/C++ code written with #pragma vectorize manually, and do these data transforms yourself in code. I know Intel has been pushing harder on "outer-loop vectorization," judging from the papers they've been putting out at PLDI and the like. But I still imagine that a dedicated SPMD programming language is going to have an edge over twisting C/C++ to that end, especially in terms of ergonomics, if nothing else.
From my perspective, as someone who was once on one of the Larrabee graphics teams (but not the same one as Matt), I'd agree that the programming model was a big issue. For us, even C++ with intrinsics wasn't fast enough for the most important code, since we didn't control the compiler (note that I'm only speaking anecdotally here, these decisions pre-date my involvement). So we had our own programming language that was more like Python with intrinsics, that hooked into the back end of the shader compiler (which handled register allocation and scheduling).
This probably wasn't the best call for a Larrabee programming model "for the masses" (even lots of people on the team were skeptical of it)... But damn, that was a fun project. We needed the ability to try any crazy idea we could think of, because that's the only thing that could work.