The CPU you compile on will probably not be the CPU your program runs on. If you know what CPU you're running on I guess you can just make assumptions about what features that chip supports, but it's much safer to use something like this to verify at runtime that you support avx or whatever features you need.

I was getting at cross-compilation, where you do know the CPU you're running on, but I see that this breaks down because the binaries can run on CPUs that support different features.

Even for same architecture compilation, the host's feature set is rarely that of the targets. If you're distributing binaries, you generally want to target a safe, old minimum baseline to maximize user bases--for x86-64, resorting to just sse2 is safe [1] and often sufficient [2]. Most compile farms and developer machines are often newer hardware.

[1] The x86-64 ABI actually requires SSE2 extensions to work correctly.

[2] SSE2 added double-precision and vectorized integer support to the SSE registers, the former allowing you to replace x87 FPU usage for floating point (unless you need long double, which is extremely rare). The newer SSE sets generally add only specialized operations that are unlikely to show up in autovectorization anyways, and the wider instruction set of AVX is less useful for performance in the "it might be useful" autovectorization scenario. They are useful for specific known hot regions of code, and in distributing binaries, variants of these are constructed for different levels of feature sets and are dynamically selected based on the user's actual hardware.

To add on the other comments, not only the machine where you compile is not the same as the one where you run your software, but consider the case where you want a software to run on as many CPUs as possible while still making use of advanced features where supported.

You'd tell the compiler "target a machine with <basic instruction set>", so it's not allowed to use advanced features like FMA because it can't assume they're supported. With this library, you'd check at run-time if FMA is supported, and then change functions accordingly.

Yes, I realized that I didn't take that into account. A follow up though: could a executable loader find and "trim" implementations that aren't optimize for the processor it's using, if it's properly marked in the binary?

Something like this is done by gcc & clang:

https://gcc.gnu.org/wiki/FunctionMultiVersioning

https://lwn.net/Articles/691932/

https://llvm.org/devmtg/2014-10/Slides/Christopher-Function%...

Comment from the post:

> Just in case anyone is tempted, please do not write code that assumes the host on which it is compiled will always be the host on which it will be executed.

A related note: Don't assume that all AWS EC2 instances of a given type use identical CPUs.

When the processor model varies for more recent generations of EC2 instances it is documented here: https://aws.amazon.com/ec2/instance-types/

Scroll down to get to the table that includes Physical Processor, Intel AVX, Intel AVX2, etc.

T2 instances do run on a number of different processor models, therefore it is listed as "Intel Xeon Family." M4 instances run on Intel Xeon E5-2676 v3 (Haswell) or Intel Xeon E5-2686 v4 (Broadwell), though m4.10xlarge only runs on Haswell and m4.16xlarge only runs on Broadwell. Pay close attention to the * in the table for those instances that run on either Haswell or Broadwell.

Generally you will find that the recent generations of EC2 instances for C and R have identical CPUs within a generation.

very good point, this has been my experience as well, particularly for burstable instances such as the T2s

Only if you are compiling and running on the same machine, no?