3 ms·

What is the state of compiler support for these very advanced instruction sets ? Can the average developer benefit by basically adding a few compiler flags ? A

What is the state of compiler support for these very advanced instruction sets ? Can the average developer benefit by basically adding a few compiler flags ? Also, each new Intel platform seems to bring additional instructions but most software isn't made available in a wide range of microarchitecture-specific builds. Is there typically capability detection going on behind the scenes ? Some of the operations described here seem so specific, that I have a hard time imagining compilers being able to spot the relevant patterns in source code that can make use of them (then again, I'm not a specialist). I guess these are explicitly coded for in Assembly ?

glangdale 7y ago
Toolchain support, at the minimum, often consists of having a compiler flag to allow the use of intrinsics for the new architecture - pretty much the opposite of what you're hoping (automagical support). There's a fair bit of work where people try to autovectorize code. I'm happy that folks are pushing this work, but, well, I drive a manual (in this regard). It does happen that code does auto-detection and skips to a particularly compelling platform-specific optimization path, but it's a huge pain. It's unlikely that someone will optimize for each and every variant, but they might draw a line here and there through the myriad of architecture choices and offer something. Sorry that the story isn't better. I generally hand-code stuff - not in asm but with intrinsics (which is getting a lot of the benefit of asm, but without doing all your own codegen for the boring bits, scheduling and register allocation).
jandrewrogers 7y ago
Using these instruction sets usually requires explicitly writing code using C language intrinsic functions, which is a reasonable compromise between transparent automatic usage in C++ and needing to write assembly. On the positive side, most compilers have full support for these intrinsics and the compiler can even do compile-time evaluation for a few of them e.g. some intrinsics are treated as 'constexpr' in C++ by the compiler, but the compiler won't automagically use them for much and is generally poor at identifying ordinary code that can be reduced to these intrinsics. So for designing algorithms that take advantage of the advanced instruction sets, you are mostly on your own. Writing C/C++ code with heavy use of intrinsics isn't hard to learn or particularly opaque, just arcane. These instruction sets can offer very substantial speedups for code paths when applied judiciously. You do need to check the CPU capabilities at start up time for practical software, you can't assume the environment supports it even when these instructions have been around a long time. Some had very uneven implementation timelines across CPU product lines. Even for explicitly high-performance software, I invariably would get bug reports because someone tried to run it on a 10+ year old machine that did not support the instructions I was using. There are standard open source libraries for doing this feature detection using CPUID.

glangdale 7y ago

Toolchain support, at the minimum, often consists of having a compiler flag to allow the use of intrinsics for the new architecture - pretty much the opposite of what you're hoping (automagical support). There's a fair bit of work where people try to autovectorize code. I'm happy that folks are pushing this work, but, well, I drive a manual (in this regard). It does happen that code does auto-detection and skips to a particularly compelling platform-specific optimization path, but it's a huge pain. It's unlikely that someone will optimize for each and every variant, but they might draw a line here and there through the myriad of architecture choices and offer something. Sorry that the story isn't better. I generally hand-code stuff - not in asm but with intrinsics (which is getting a lot of the benefit of asm, but without doing all your own codegen for the boring bits, scheduling and register allocation).

jandrewrogers 7y ago

Using these instruction sets usually requires explicitly writing code using C language intrinsic functions, which is a reasonable compromise between transparent automatic usage in C++ and needing to write assembly. On the positive side, most compilers have full support for these intrinsics and the compiler can even do compile-time evaluation for a few of them e.g. some intrinsics are treated as 'constexpr' in C++ by the compiler, but the compiler won't automagically use them for much and is generally poor at identifying ordinary code that can be reduced to these intrinsics. So for designing algorithms that take advantage of the advanced instruction sets, you are mostly on your own. Writing C/C++ code with heavy use of intrinsics isn't hard to learn or particularly opaque, just arcane. These instruction sets can offer very substantial speedups for code paths when applied judiciously. You do need to check the CPU capabilities at start up time for practical software, you can't assume the environment supports it even when these instructions have been around a long time. Some had very uneven implementation timelines across CPU product lines. Even for explicitly high-performance software, I invariably would get bug reports because someone tried to run it on a 10+ year old machine that did not support the instructions I was using. There are standard open source libraries for doing this feature detection using CPUID.