5 ms·
Intel SPMD Program Compiler: A Compiler for High-Performance SIMD Programming
- corysama 7y agoI only played with ISPC a little bit. What I found is that it is really great if you need to write a large volume of SIMD code and that code sticks to one lane size. Like, 4 32-bit floats or ints. But, if you want switch mid-stream to 8 shorts or 16 bytes, you’re gonna have a hard time. Or, if you just need a few instructions, it’s easier to just use intrinsics.
- a1369209993 7y agoI think that's somewhat intentional? The name stands for [Intel [Single Program Multiple Data] Program Compiler], not "SIMD"/"Instruction". I'd expect switching lane depth (4 shorts or 4 bytes) to work fine, but switching SIMD width (8 or 16 lanes) seems out of scope for "run 4 instances of this program in lockstep".
- BubRoss 7y agoI would have to see an example of what you mean, but it should be completely possible though might require converting without using vectorization. Switching lane size doesn't make much sense to me because ideally you would want lanes that are as wide as possible and mostly be agnostic to their size.
- corysama 7y agoI had some code that tried to stay 16x8bit, but would occasionally _mm_unpacklo_epi8, _mm_unpackhi_epi8 to 2 8x16bit vectors to keep precise intermediate results during some fixed-point math. Writing it out like that, it sounds like it should have been easy. Don't remember what I ran into. Maybe didn't bang on it long enough.
- BubRoss 7y agoThe original AVX instructions didn't have all the integer operations that the most modern chips have. It might have been haswell that added small integers over the 256 bit lane width.
- stephencanon 7y agoRight. AVX (the original extension) only added 256b floating-point and non-destructive 128b integer. The 256b integer SIMD ops are all in AVX2 or later.
- rrss 7y agoMatt Pharr wrote a series of posts telling the story of ispc: https://pharr.org/matt/blog/2018/04/18/ispc-origins.html https://pharr.org/matt/blog/2018/04/18/ispc-origins.html I found them extremely interesting - highly recommended.
- joe_the_user 7y agoThat is an interesting read - compiler writers got hung up on creating auto-vectorization where Cuda is essentially manual vectorization. And that's the thing. Once you find ways that writing a massively vectorized program on a GPU makes sense, why would you write a program where you had to hope your program gets vectorized? That said, as I understand things, vectorization can fail with Cuda if you allocate more kernels than exist on the chip, in which case the chip may run the kernels in serial, producing surprising results.
- rrss 7y agoThat isn't really a failure case in cuda (or opencl). It's very common to launch more blocks/workgroups than can be resident simultaneously on the GPU.
- joe_the_user 7y agoNeither autovectorization-fail nor Cuda executing kernels in serial is a "fail-fail", both are fall-back actions that accomplish a given task in a bit longer than the explicit instructions imply. That said, executing kernels in serial can supposedly create problems if a programmer creates logic that assumes kernels are always moving in lock-step.
- Fronzie 7y agoAfter reading, I do wonder, though: If one would work out the 'packet' datatype of the Eigen (http://eigen.tuxfamily.org/index.php?title=Main_Page http://eigen.tuxfamily.org/index.php?title=Main_Page) library, wouldn't that give the same kind of parallelism? Together with a parallel-for from, for example, Intel's TBB library would make it parallel. Making a new language imposes a huge development cost. Code will have to be adjusted. Although the story is interesting, especially with notes on company politics, it is a bit one-sided on the technical side. The compiler-chiefs might have had a point that went beyond 'politics'.
- yarg 7y agoIt's open source, so it should be fine? But Intel's history when it comes to compilers and applied optimisations leaves this making me immediately uncomfortable. The sort of PR work that these guys would need to do in order for me to consider them even remotely trustworthy is beyond even their budget.
- insulanus 7y agoI assume you're referring to Intel's robust history of "Intellectual Property" lawsuits? Agreed. ISPC is under a BSD license, but I wonder if there's a lawsuit to be made from the use of the techniques.
- frostburg 7y agoHe's probably referring to Intel compilers outputting code designed to slow down CPUs from other makers.
- amiga-workbench 7y agoAnd this is an even bigger issue because several popular benchmarking tools were compiled with ICC, skewing CPU reviews in Intel's favour.
- wolfgke 7y ago> And this is an even bigger issue because several popular benchmarking tools were compiled with ICC, skewing CPU reviews in Intel's favour. A benchmark whose speed also depends on a compiler is not a benchmark of the CPU, but of a combination compiler/CPU. If this is not written down (and, of course, also written down which compiler was used), it is a deception of the reader.
- rbanffy 7y agoDuring the UNIX wars, it was suspected many companies tuned their compilers to generate unrealistically fast code for common benchmarks.
- gnufx 7y agoThis would benefit from a comparison with current OpenMP/OpenACC (which supports offloading to attached processors in a standard way for C and Fortran, at least). Also, comparing with gcc 4.2 in the performance examples doesn't seem very useful; it didn't support AVX, regardless of auto-vectorization. (That's not meant to dismiss ISPC.)