5 ms·

I've always wondered, if I compile an application and don't specify the architecture as explicitly having AVX, just say x86 64bit, will alternate code paths be

I've always wondered, if I compile an application and don't specify the architecture as explicitly having AVX, just say x86 64bit, will alternate code paths be in the binary for processors with AVX? Or alternatively, if I do specify AVX support on the command line, then what happens if the binary runs on a CPU without AVX? The reason I ask is I use commercial tools for circuit simulation, and they run on a wide range of CPU architectures, but it would be a shame if thst CPU compatability comes at a performance hit when run on a more capable CPU architecture

mojuba 6y ago
Wondered the same. I'm also curious if Apple's Accelerate framework uses AVX underneath when available. Sounds like an OK compromise if it's the case: maybe the compiler will miss a few opportunities to optimize some of your loops, but if you are aware of Accelerate you will use it in your audio/video processing anyway, which should be a win.
- saagarjha 6y ago
  It does indeed. And NEON on ARM, of course.
pabs3 6y ago
I depends on the compiler you use and the approaches it has to optional CPU features and the options you pass to the compiler. For example, with GCC you can set the baseline CPU features. You can also use function multi-versioning to provide faster functions for CPUs with newer features. https://lwn.net/Articles/691932/ https://lwn.net/Articles/691932/
glangdale 6y ago
Answer is generally no; you have to compile something with specific flags for a given architecture, and you will normally only get one path. There may be exceptions for some libraries which may do clever stuff, but generally you pick your level of machine support (usually low) and live with it. Note that there are many new machines (Atoms and low-brand stuff like "Pentium" branded CPUs - even recent ones based on Comet Lake) which don't have anything beyond SSE4.x). IIRC they don't even have BMI/BMI2 which is a huge pain.
- tails4e 6y ago
  This is interesting, the use case I was thinking about is EDA SW, which is very expensive and performance (runtime) can be days in some cases. In the tool installs I only ever see i386 and x86_64. In curious if the EDA vendors have compiled for the lowest common denomnator for these two basic architectures. If so it would seem like they are leaving a lot of performance potential on the table. Is there any tool that explores and executable and reports if vector instructions are present and follows dependencies (like ldd)?
  - glangdale 6y ago
    On Linux, you can turn on the performance counters systemwide and watch instruction counts of various types of instructions tick up, if you want. I don't know how to do this on Windows. I imagine you could also use any number of disassembly tools to peer at the instructions - looking for xmm/ymm/zmm in the textual output would be the giveaway.
lozenge 6y ago
Depends on the compiler. Gcc compiles to the lowest common denominator while icc offers "Processor dispatch technology performs a check at execution time to determine which processor the application is running on and use the most suitable code path for that processor. Compatible, non-Intel processors will take the default optimized code path." For HPC they will always compile to use the full set of instructions and see how it performs. For some software there will be explicit checks and loading the right compiled code(compression, video effects etc). On a desktop most things are compiled for the minimum processor though. The CPU might still be able to use its new features like wide registers of the instructions are in just the right order. If you run something with instructions your processor doesn't have it will crash.
- majewsky 6y ago
  > If you run something with instructions your processor doesn't have it will crash. I would be very surprised if the processor itself crashed. I haven't encountered it in actuality so far, but as far as I'm aware, illegal instructions raise an interrupt that the OS can catch. On Unix, this should result in the corresponding user space process receiving SIGILL. It appears that SIGILL is actually preemptible. Could this be used as a poor man's CPU feature detection mechanism?
  - lozenge 6y ago
    I meant the process crash not the CPU, you are correct. Also, my gcc knowledge is outdated. People have mapped out the millions of "undocumented instructions" by trapping SIGILL.
saagarjha 6y ago
By default, most compilers will target some old processor with basic features, like perhaps SSE2. If you up the processor to something with AVX2, for example, you’ll get those instructions but without anything else you will SIGILL on older computers. Now, if you want to be smarter there’s a number of things you can do, some of which have compiler or OS support. You could, in your program, manually detect these features (cpuid) and then use them if available. You could have entire functions that are specialized for one architecture and pick the right one at runtime; some compilers can do this for you “transparently” with custom attributes. If the dynamic linker supports it, you could have it pick the right version of the symbol for your processor and your program is otherwise none the wiser which one gets selected; it just has to have the appropriate versions of functions. And at the extreme end you can compile entirely separate versions of your program for different base processors; on Darwin you can have a universal binary recognized by the kernel itself as supposing x86_64 (basic 64-bit features) and x86_64h (assume Haswell and above) and the right one will get loaded based on your hardware.
fmajid 6y ago
Your libraries, e.g. BLAS may use it even if your own code doesn't.

mojuba 6y ago

Wondered the same. I'm also curious if Apple's Accelerate framework uses AVX underneath when available. Sounds like an OK compromise if it's the case: maybe the compiler will miss a few opportunities to optimize some of your loops, but if you are aware of Accelerate you will use it in your audio/video processing anyway, which should be a win.

saagarjha 6y ago
It does indeed. And NEON on ARM, of course.

pabs3 6y ago

I depends on the compiler you use and the approaches it has to optional CPU features and the options you pass to the compiler. For example, with GCC you can set the baseline CPU features. You can also use function multi-versioning to provide faster functions for CPUs with newer features. https://lwn.net/Articles/691932/ https://lwn.net/Articles/691932/

glangdale 6y ago

Answer is generally no; you have to compile something with specific flags for a given architecture, and you will normally only get one path. There may be exceptions for some libraries which may do clever stuff, but generally you pick your level of machine support (usually low) and live with it. Note that there are many new machines (Atoms and low-brand stuff like "Pentium" branded CPUs - even recent ones based on Comet Lake) which don't have anything beyond SSE4.x). IIRC they don't even have BMI/BMI2 which is a huge pain.

tails4e 6y ago
This is interesting, the use case I was thinking about is EDA SW, which is very expensive and performance (runtime) can be days in some cases. In the tool installs I only ever see i386 and x86_64. In curious if the EDA vendors have compiled for the lowest common denomnator for these two basic architectures. If so it would seem like they are leaving a lot of performance potential on the table. Is there any tool that explores and executable and reports if vector instructions are present and follows dependencies (like ldd)?
- glangdale 6y ago
  On Linux, you can turn on the performance counters systemwide and watch instruction counts of various types of instructions tick up, if you want. I don't know how to do this on Windows. I imagine you could also use any number of disassembly tools to peer at the instructions - looking for xmm/ymm/zmm in the textual output would be the giveaway.

lozenge 6y ago

Depends on the compiler. Gcc compiles to the lowest common denominator while icc offers "Processor dispatch technology performs a check at execution time to determine which processor the application is running on and use the most suitable code path for that processor. Compatible, non-Intel processors will take the default optimized code path." For HPC they will always compile to use the full set of instructions and see how it performs. For some software there will be explicit checks and loading the right compiled code(compression, video effects etc). On a desktop most things are compiled for the minimum processor though. The CPU might still be able to use its new features like wide registers of the instructions are in just the right order. If you run something with instructions your processor doesn't have it will crash.

majewsky 6y ago
> If you run something with instructions your processor doesn't have it will crash. I would be very surprised if the processor itself crashed. I haven't encountered it in actuality so far, but as far as I'm aware, illegal instructions raise an interrupt that the OS can catch. On Unix, this should result in the corresponding user space process receiving SIGILL. It appears that SIGILL is actually preemptible. Could this be used as a poor man's CPU feature detection mechanism?
- lozenge 6y ago
  I meant the process crash not the CPU, you are correct. Also, my gcc knowledge is outdated. People have mapped out the millions of "undocumented instructions" by trapping SIGILL.

saagarjha 6y ago

By default, most compilers will target some old processor with basic features, like perhaps SSE2. If you up the processor to something with AVX2, for example, you’ll get those instructions but without anything else you will SIGILL on older computers. Now, if you want to be smarter there’s a number of things you can do, some of which have compiler or OS support. You could, in your program, manually detect these features (cpuid) and then use them if available. You could have entire functions that are specialized for one architecture and pick the right one at runtime; some compilers can do this for you “transparently” with custom attributes. If the dynamic linker supports it, you could have it pick the right version of the symbol for your processor and your program is otherwise none the wiser which one gets selected; it just has to have the appropriate versions of functions. And at the extreme end you can compile entirely separate versions of your program for different base processors; on Darwin you can have a universal binary recognized by the kernel itself as supposing x86_64 (basic 64-bit features) and x86_64h (assume Haswell and above) and the right one will get loaded based on your hardware.

fmajid 6y ago

Your libraries, e.g. BLAS may use it even if your own code doesn't.