I doubt that .NET was meant to solve the problem of underlying variation in instruction set of Intel processors because that concern does not exists for 98% of the applications anyway they rarely have to look for the compiler settings and for the rest of the 2%, the compiler flags are huge set of options and that kind of tweaks are NOT available for .NET anyway.
Additionally, such applications that want to exploit certain underlying processor's instruction set have no way to do so without detecting CPUID and landing into so called "unmanaged code" because .NET is all about very high level IR that even has object oriented features as well.
The .NET JIT compiler absolutely does query CPUID flags and generates different optimized code depending on available features, as well as the performance profile of each CPU model. This is similar to always passing `-march=native` to GCC.
This can have a huge effect on a wide range of applications, not just those using particular CPU features. For example, each libc implementation typically has a separate implementation `memcpy()` for each set of CPU features.
Okay thank you. I need to read more on the subject the.
The "Performance Improvements in .NET" blog lists the new JIT support for instruction sets each year.
https://devblogs.microsoft.com/dotnet/performance-improvemen...