5 ms·

The story of ispc: all the links (2018)

42 points by lelf 7y ago

dang 7y ago
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
zwegner 7y ago
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.
chrispsn 7y ago
Does ispc still offer compelling advantages versus icc or other compilers?
- jcranmer 7y ago
  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.

42 points by lelf 7y ago

dang 7y ago

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

zwegner 7y ago

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.

chrispsn 7y ago

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

jcranmer 7y ago
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.