Hacker News Reader

Comment by TekMol | Hacker News Reader

How does software these days target all the different CPUs with different instructions?

If I download, say, debian-11.7.0-amd64-netinst.iso - does it somehow dynamically adapt to all the different AMD and Intel CPUs and uses the instructions available on the users machine?

View on HN

Software compiled to be "portable" uses a reduced subset. You actually have to bully GCC into using the full CPU instruction set with -march=native (you can also put another target CPU arch there).

In short, distributed binaries tend to use "least common denominator" instructions.

I believe one of the pros touted of Gentoo, where everything is compiled locally, is that all the software uses the CPU to it's fullest potential.

Afaik, Debian runs on the 386? And I think that came out in the 80s?

So all new CPU instructions of the last 40 years are pretty much used by nobody?

No, according to this [1], Debian's i386 architecture dropped support for the 386 and 486 in versions Sarge and Squeeze respectively. Pretty amazing that it did work on the first Pentium (released 1993!) up to 2018. In Debian version after Jessie the Pentium (i586) has been dropped too [2].

Of course, I don't think many people are using i386 builds anymore - most people would have switched to the more modern x86_64 long ago.

1. https://www.debian.org/releases/jessie/i386/ch02s01.html.en

2. https://www.debian.org/releases/stretch/i386/ch02s01.html.en

The new instructions are used often or seldom depending on whether you count invocations or occurences.

There are new instructions that can be used to write a constant-time SHA-256 hash function. A program that contains megabytes of code, more than a million instructions, may reasonably contain only a few of those instructions, because it contains only one or two small hash functions. The instructions are important and effective, but occur only a handful of times among a million instructions.

The dirty secret is: yes, many of the new instructions aren't used very often. They only come into play in certain cases: encryption, signal processing, CPU graphics (e.g. paint packages), video/jpeg decoding (when not done on GPU) and so on, most of which are packaged inside libraries which may or may not have multi-CPU implementations.

I think the default configuration for GCC x64 is SSE 4.0 instructions enabled, AVX2 instructions enabled, AVX512 and SSE 4.2 disabled. And I think MSVC defaults to processors of a roughly similar age (10 to 15 years old). So instructions in the 40-to-15 year old range get used a lot.

If you're running software that's heavily math intensive, or ever gets benchmarked, it's a fairly good bet that they will have either conditionally-installed or conditional-executed code that targets more modern processors.

The baseline amd64 System V ABI, which is what Debian targets, only includes SSE and SSE2; not SSE3, SSE4 or AVX2.

The Linux kernel dropped support for the original 80386 in December 2012, with kernel 3.8

Debian dropped support with sarge in 2005

https://en.wikipedia.org/wiki/I386

You can also dispatch at runtime based on CPUID (x86) or getauxval(AT_HWCAP) for ARM. Also Clang and GCC seem to be moving in the direction of removing -march=native which is sad since grokking all the different microarchitectures isn't easy.

Lots of speed sensitive programs also ship multiple implementations they can choose at run time so they can more fully utilize a CPU without recompiling.

Probably one of the biggest Bang for your Buck (on Linux) would be to recompile your libc and OpenSSL with -march=native. Then at least all software that depends on those libs (probably the majority) would get some benefit from your local processors extensions.

Or you can use Gentoo.

glibc and OpenSSL both have runtime detection of CPU features to switch between hand-coded versions of hot functions, so those two are probably the packages that will get the _least_ benefit from a recompilation.

IFunc relocations are how glibc dynamically chooses the best memcpy routine to use at runtime based on the CPU.

see https://github.com/bminor/glibc/blob/glibc-2.31/sysdeps/x86_...

Here's a article that describes how to use function multi-versioning and indirect functions (ifunc) with GCC and GNU tools:

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

In many cases, multiple implementations are included and one is chosen to utilize the best instruction supported by the CPU. Example code: https://source.chromium.org/chromium/chromium/src/+/main:thi...

There are several uarch levels defined for x86_64 which include newer instructions than the baseline. Some distros are starting to move to use those higher levels, notably RHEL9 is x86_64-v2.

You'll find lots of discussions happening around this topic, for example: https://www.phoronix.com/news/Arch-Linux-x86-64-v3-Port-RFC

Runtime CPU dispatching: https://maksimkita.com/blog/cpu-dispatch-in-clickhouse.html

For a while, submissions to the iOS app store could include bitcode, which was LLVM's intermediate byte code. I don't know if they ever did, but Apple could generate architecture-optimized binaries for their various CPU models. They deprecated that last year, though.

.Net ahead-of-time compilation (that is, compiling the .net / clr VM byte code into something your CPU can run directly) could (but apparently doesn't?) do CPU-specific optimizations. The JIT compiler, however does do some CPU-specific optimizations.

Compiler flags. You turn on/off compiler optimisations for target architectures that are aware of all the instruction-set specific hardware level optimisations.

But I'm not compiling. And neither are 99.9% of other software users.

Hence why JITs have some advantages when shipping software, at the cost of a few extra MBs.

Only if the JIT uses the fancy instructions :)

Most JVM implementations and the CLR do keep up with fancy instructions.

Not all, but surely a few.

Reply on news.ycombinator.com