Wild guess: libs (intel cilk?), compiler intrisics through reified assembly.

I've used a lot of SSE2 and prefetch instincs in Visual C++ for math / data heavy high performance computing applications. It can make a fairly big different -- like more than 50% performance improvements for key parts of the code.

Games on consoles, where the hardware architecture is frozen and you can optimize to the metal all you want.

Not all titles do this, since most titles are cross-platform and you're not going to do tons of optimization for a specific one unless there is a huge payoff.

Specialized HPC workloads

Many of the capabilities described in the article are just hardware features which don't need any control from application developers, but their effectiveness can be improved if the developers are aware of them (e.g. caches, TLBs). Others properties are exploited automatically by compilers (e.g. instruction scheduling for improving throughput in a superscalar processor)

Instruction set extensions (which I believe might be what you were thinking of) are used via intrinsics and assembly programming by pretty much any performance-oriented code. For example look at the dozens of architecture-specific implementations of glibc functions: x86-64[0], arm[1].

[0] https://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/x86... [1] https://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/arm...

> it just sucks when you have to do CPU feature detection and have different code paths for different CPUs.

In the Linux kernel they went so far as to actually replacing instructions at boot-time at known locations, based on the capabilities of the CPU the code is executing on. This prevents them from maintaining many paths in the compiled code.

Yes, but as I answered they are compiler specific and cover only part of the CPU.