segfault with illegal opcode

So when I am downloading binary - i.e. Krita/GIMP or any open source project - how do the dev ensure that the common binary will utilize these newer instructions without hitting 'illegal opcode' error?

Depends on the binary. Compiling to the lowest common denominator is one strategy. The other is to to have the code detect what's available and only use that subset.

Interesting. How do the devs decide on the lowest common denominator? Do you happen to know any blog or resources that explains the process?

I touched that question in "Hardware Support" section, on page 6 of that article http://const.me/articles/simd/simd.pdf

TLDR: SSE1 and SSE2 are parts of the base AMD64 ISA, they are always available while compiling for 64 bits. SSE3, SSE4.1 are old, market penetration is very close to 100%, always available in practice. For the newer extensions like AVX and FMA, the optimal tradeoff depends on the product and the market.

Do I need to download the source and compile it using correct flags on the target system for optimal performance? In my previous institution they would download the commonly distributed R language binary and run as is on a brand new system, and I was wondering if recompiling from source would have made a difference.

I don’t know, it depends on the specific library.

If they were compiling for least-common denominator like SSE2, recompiling with -march=native might make a difference. The exact amount of that difference depends heavily on the code.

Automatic vectorizers are limited, they only generating good vectorized code for pure vertical operations which handle long dense arrays of FP32 or FP64 values.

OTOH, some widely-used libraries like Eigen https://eigen.tuxfamily.org/index.php?title=Main_Page are using manually-written intrinsics under the hood, selecting an implementation with preprocessor macros. If your R library uses Eigen, compiling for AVX2 or AVX512 will probably cause a non-trivial performance win.

If your library uses runtime dispatch to select best implementation in runtime, and is compiled recently (i.e. you don’t have new instruction sets in your CPU which weren’t available back then), you’re unlikely to get much profit.

BTW, I’ve noticed C standard library implemented by VC++ uses runtime dispatch, functions like memcpy() are using AVX vectors internally, when supported.

Most devs don't care, so it depends on the compiler default. However some people who are eagering for optimization will turn on -march=native to get the best profile out of the current running processor family. This is where the troubles come in

E.g. ISPC can compile for multiple targets at once. The runtime system selects the best compatible implementation for the machine running the code.

The cheeky answer would be to throw away the trash every decade, but the real answer is that there is tooling in place to pick the best possible implementation of a function at link time on modern *nix systems to target several levels of SIMD support e.g. SSE2 only, SSE4.2, AVX2, common collection of AVX512 extensions.

What tool you are referring to? Can you please forward me to those resources?

I think crest may be referring to function multiversioning, but that only helps choose/call the implementation, not generate it.

github.com/google/highway supports compiling your single source code once into several versions, and then dispatching to the best one.

Disclosure: I am the main author.