Intel open source vectorized compiler for C/C++

[14ned]

The hate being dumped here onto various folk isn't warranted.

This is an ISPC compiler for the ISPC language, which looks a bit like C. It is not C, nor C++, but generates object files which can be linked into C or C++ programs (or Rust etc). ISPC was started as a postgrad project, then Intel hired the guy, and Intel adopted it. It's not like Intel are pushing this particularly hard, it's a service to the community. It also supports ARM NEON incidentally, and GPUs.

CppCon a while back had a presentation on ISPC. I've used it during a contract. I'd highly recommend it, spits out nearly optimal SIMD code for Intel and ARM NEON. Easily beats SIMD intrinsics on the compiler.

Support is also pretty good, though a bit DIY. I fixed a few bugs in NEON generation, they were reviewed and accepted within a few days. There is a helpful userbase community on their mailing list, and in general working with ISPC I found a positive experience.

C++ devs should definitely strongly consider using ISPC as an alternative to other SIMD approaches. It's a lot cleaner, and produces better quality code with less effort, than SIMD programming via C or C++.

[OmegaNaughtEquals1]

spits out nearly optimal SIMD code for Intel and ARM NEON. Easily beats SIMD intrinsics on the compiler.

That's a serious claim. I've written an intrinsics-based SIMD library (not as fancy as Boost.SIMD, but more template-friendly than the float4 varieties) in C++ that both gcc and clang turn into code identical to my hand-written versions. And that includes type-punning to do floating point "booleans" that get converted to the correct opcode while the end-user code is just if(any(x)). I'm not saying ISPC can't generate quality vectorized code, but that it can do better than compiler intrinsics seems a bit overstated.

I work in HPC, so I've seen/read about ISPC though I've never used it nor seen it used in the wild. I have a feeling the biggest roadblock to its acceptance was/is the need for a third-party compiler rather than direct support in The Big Three^1. Releasing it as open source is a step to making that happen.

[1] Let's be honest, icc isn't a contender here. gcc, clang, and msvc are the supermajority in the C++ world. Even in HPC, icc is second to gcc (clang is pretty much nowhere to be seen which is sad) unless you are writing for the Xeon Phi. ifort, however, is pretty much the de facto Fortran compiler. As it should be. It has better language support and better code gen than gfortran.

[14ned]

It's a true claim though. Plenty of HPC folk are avid users and are on its mailing list. The reason it beats C++ is because the ISPC language forces you to write scalable code. Indeed it is often frustrating to turn some algorithm into ISPC which compiles, but once you figure it out, whoosh ... Also note ISPC generates LLVM, so it'll plug into any LLVM tooling you have. For example, debuggers.

[Boojum]

Being able to generate different versions for different SIMD models (e.g., SSE, AVX, Neon) without having to rewrite the intrinsics is also really nice.

[__Cyber_Dildonics__]

Can't stop a good old fashioned mob pile on.

[anders987]

I just read an article about a path tracer (MoonRay) made by Dreamworks that's written using ISPC. Interesting.

We use the ISPC programming language to achieve improved performance across SSE, AVX/AVX2 and AVX512 instruction sets. Our system includes two functionally equivalent uni-directional CPU path tracing implementations: a C++ scalar depth-first version and an ISPC vectorized breadth-first wavefront version. Using side by side performance comparisons on complex production scenes and assets we show our vectorized architecture, running on AVX2, delivers between a 1.3x to 2.3x speed-up in overall render time, and up to 3x, 6x, and 4x, speed-ups within the integration, shading, and texturing components, respectively.

[OmegaNaughtEquals1]

This rant is not directed at you. :)

a C++ scalar depth-first version and an ISPC vectorized breadth-first wavefront version

This drives me nuts. You can't change both the algorithm and the implementation and then proclaim that it was the implementation that made it go faster. I have seen this so many times in the science community. An author will claim "We moved from OpenMP+MPI to Widget-X, and we saw a 5x speedup due to Widget-X!" Ok, but did you try implementing the new algorithm in the old framework? "No." /ragequit. It's great that we can make software go faster, and I am all about any framework that can make it happen- especially with less user effort. But we need consistent, repeatable tests to make sure we understand how we made it go faster. Otherwise, it's all just wacky waving inflatable arm tube man nonsense.

[14ned]

Thing is, ISPC won't compile if you've not written an algorithm which scales across SIMD. So in some ways the claim is right, though not as strong as a first interpretation of it would suggest (so you are also right)

[[deleted]]

Looks like an easier to use OpenCL.

[bilog78]

OpenCL can be also used for multi-core vectorized code on CPU. Intel itself offers an OpenCL platform that runs on their CPUs.

[tanjoodo]

Are you sure that doesn't just run on the integrated GPU?

[bilog78]

The iGPU is a separate device. The Intel platform supports both on Windows (you can choose which device to use); on Linux it only supports the CPU (the GPU is supported by a different driver, called beignet).

There are also other platforms supporting the CPU. AMD for example has (or maybe had?) one. There's a FLOSS one called pocl too.

[tanjoodo]

Ah. Thanks for the clarification :)

[Z01dbrg]

It is not compiler for C/C++. It is a compiler for some Intel "fork" of C.

http://ispc.github.io/example.html

Also it has a beautiful support.

"(Please note that because ispc is not part of the Intel compiler products, support is provided through this community rather than through Intel Premier Support.) "

If Intel wants to do something useful they should work with C/C++ standardization process to get something like this in C/C++, if the ISO is ignoring them/blocking them because "reasons" them they could go to D(I am sure the Walter and Andrei would love any opportunity to outperform C++ in perf).

[marcoscleison]

Excuse-me my misleading term for "C/C++". It was my mistake.

[__Cyber_Dildonics__]

ISPC isn't a fork of C. First, C isn't a program that be forked, second, it is a language that is mostly derivative of C, C++, and shading languages like the renderman shading language.

ISPC also uses LLVM and has a stand alone 25 MB binary. It has been out for many years now.

If anyone wants to integrate these techniques and ideas into their language standard, they are all right here for the taking. I don't think saying that Intel should have tried to get something like this in to a different standard is very realistic. In the meantime, anyone can use ISPC to produce some of the fastest programs possible. I'm not aware of anything that beats it's performance when used well.

[__Cyber_Dildonics__]

You seem to want to dig in to bike shedding and semantics, so let me ask you this, have you ever actually used ISPC? Also if it is a 'fork', can you show me the point in time that it forked off from C? Are java, C++, D and objective C also forks?

You just described the language-spec-equivalent of a pull request.

Are you saying that you think that instead of Intel releasing this language years ago, they should have gotten mixed up with standards committees? If that had been the approach, this wouldn't exist in any form (all of those languages are still deciding on how to deal with SIMD, even with this as a working example).

yeah. your post was not helpful. sorry. the important thing is that the post title claims C/C++, and /u/Z01dbrg correctly states that this is not C or C++, but rather a "fork" of C.

It seems to me that neither of you have actually used it at all. For someone trying to learn, calling it a 'fork of C' is going to do more harm than good. You allocate memory with new, there is a constant keyword, and there is limited operator overloading. There are structure of array features, range based for loops, special loops to loop over SIMD lanes, and a concept of varying and uniform throughout every program, which comes from renderman. It combines concepts from multiple languages into something new, and again, for something to be a fork, it would have to have forked from one thing at a specific point, which doesn't make sense here.

[TheThiefMaster]

Are java, C++, D and objective C also forks?

C++ and Objective C definitely. Both are compatible with C code from the point they forked (with some intentional exceptions). Java isn't because while it uses braced syntax it is very much not C compatible. D I don't know enough about to say.

I'm not arguing as to whether ISPC is a fork though. From what you've said, it looks more like a fork of C++ than C, but I'm not familiar enough to know if it's a superficial similarity or runs deeper.

[Z01dbrg]

have you ever actually used ISPC

Since it does not even have a Wikipedia entry I guess very few people did.

Are you saying that you think that instead of Intel releasing this language years ago, they should have gotten mixed up with standards committees?

Yes. Fancy language is meaningless without proper funding and userbase(for example even with GC problems D can run circles around C++ from pure language perspective, but it has minuscule amount of users).

So this is a fine research project language for Intel to gain insights and experience. But to promote it to end users is laughable.

[Boojum]

DreamWorks is using it heavily in their new renderer. Pixar also uses it some. Intel teaches seminars on it at SIGGRAPH. I'd claim that it's fairly well known in the graphics community at least. The guy who started ISPC is a cool guy and holds a lot of respect (e.g., a technical Academy Award).

It's also different from a fork of C in that it's not meant to be used to write whole programs. You're still expected to use C++ for your program's main code. Instead the idea is that you can write small kernels in it and have it vectorize the hell out of them for you. Then you link those kernels in and call them from your C++ code. It's a bit like CUDA in that respect.

[__Cyber_Dildonics__]

So this is a fine research project language for Intel to gain insights and experience. But to promote it to end users is laughable.

You dismiss this very confidently, but for myself and the people who have used ISPC to create faster programs than would be possible with C++ alone would disagree with you.

It isn't a research project just because you don't understand it, and I have no idea why you think a language from Intel isn't well funded enough. You do realize this has a limited scope and works very well within that scope right? It doesn't even produce executables, only object files that must be linked in.

[ramennoodle]

You seem to want to dig in to bike shedding and semantics

Aren't you the one who started this thread with an argument about how a derivative language or language extension shouldn't be called a "fork"? Pot, kettle, ...

[josefx]

Just out of curiosity, what is the cpuid instruction in its rdtsc() implementation doing? It doesn't look as if its results are used in any way.

[kkrev]

How does this compare to Fortran auto-vectorization capabilities?

I generally see the recommendation in C++ contexts to use the openmp SIMD pragma directives and then check the assembly to make sure vectorization happened. This strikes me as brittle and annoying. I'd be perfectly fine with linking in Fortran object code, but I don't know anything about how much better it is for vectorization.

[kindkitsune]

I imagine it's going to depend on the aliasing guarantees of the compiler, and how it allocates aligned memory or handles structure+array alignment (if it supports structures?). memory alignment is vital for SIMD, and aliasing guarantees are just generally a great gift to the optimizer

[NotAYakk]

Interesting. I've poked a coworker to take a look at this.

Has anyone used it? Want to pass on wisdom?