There's a pile of different SIMD ("SSE") instruction sets, and it's pretty much anybody's guess what the system your program is running on is likely to have.
cat /proc/cpuinfo sometime and just look at all the stuff under 'flags'
> There's a pile of different SIMD ("SSE") instruction sets, and it's pretty much anybody's guess what the system your program is running on is likely to have.
It is nowhere near that bad. There are three lineages of chips--Intel Atoms (/E-cores), Xeons (/P-cores), and AMD's chips--and within each lineage, a newer chip is a strict superset of the features of the previous chip. The exception to this rule are the features that are so bad that no one uses them (most notably MPX), and AVX-512 which landed in the desktop P-cores before big-little happened, where they were turned off because the E-cores don't support AVX-512.
If your computer isn't over a decade old, it's not a guess which SSE instruction sets your hardware has--it has all of the SSE instruction sets.
Where can I find FMA4 in modern AMD CPUs? What about 3dNow? XOP?
Even SSE isn't guaranteed as Intel chips never implemented SSE4a.
AVX-512 is especially weird. Cannon lake implemented VBMI, but not Cooper or Cascade Lake only for it to reappear on Ice, Tiger, and Rocket lake then disappear on Alder Lake and reappear on Sapphire Rapids. BF16 was in Cooper Lake only to disappear for Ice, Tiger, rocket, and Alder lake before reappearing again on Sapphire Rapids.
RISC-V looked at that and said "Watch me, I can do even more".
Also, it's a safe assumption that everyone is on x86-x64-v2 now which includes up to SSE4.2. And almost everyone is on x86-x64-v3 which includes AVX2. In practice there are about three main "bubbles" of supported extensions. Intel did try to throw a wrench into that with AVX512 but luckily AMD took a saner route and everything converges on more or less the same set of supported subsets of AVX512.
Nah, RISC-V looked at that and decided to formalize the concept of extensions properly and put it through a proper standards process instead of letting it be dominated by the whims of manufacturer's product and marketing pipeline.
The big promise of RISC-V for embedded was that vendors would not have to maintain toolchains like that. There's no real benefit over using a proprietary core if you have to maintain your toolchain.
Absolutely, that's why the toolchains (gcc and llvm) support specifying which extensions to use.
Most people are gonna build for a profile, but embedded can build for whatever custom set of extensions the core they are using has, which does not have to be a profile.
+1. It's a weird thing to complain about considering building for ARM already involves a bunch of board specific compiler arguments in regards to FPU, MMU, etc.
If anything, choosing the extension set is cleaner.
There's a pile of different SIMD ("SSE") instruction sets, and it's pretty much anybody's guess what the system your program is running on is likely to have.
cat /proc/cpuinfo sometime and just look at all the stuff under 'flags'