
The story of ispc: all the links (2018) - lelf
https://pharr.org/matt/blog/2018/04/30/ispc-all.html
======
zwegner
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.

------
dang
Three small thread from the time:

[https://news.ycombinator.com/item?id=16966009](https://news.ycombinator.com/item?id=16966009)

[https://news.ycombinator.com/item?id=16891980](https://news.ycombinator.com/item?id=16891980)

[https://news.ycombinator.com/item?id=18253742](https://news.ycombinator.com/item?id=18253742)

------
chrispsn
Does ispc still offer compelling advantages versus icc or other compilers?

~~~
jcranmer
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.

