4 ms·
Until the opposite has been shown, the assumption should be that a CPU that indicates that it supports AVX2 does support AVX2.
by nemetroid 7y ago
Until the opposite has been shown, the assumption should be that a CPU that indicates that it supports AVX2 does support AVX2.
- roenxi 7y agoThat is not the case, this is at the boundary of software and hardware and real-world concerns dominate. It is quite possible that a library highly optimised to a specific hardware set could have ghastly bugs on hardware it isn't tested on and testing has a cost. Intel is being reasonable and in a sense prudent by only supporting hardware they understand very well. It isn't like they are sending the lawyers out to sue anyone writing high performance code on AMD chips - that would be unreasonable.
- the8472 7y agoThe usual approach (e.g. taken in the linux kernel, llvm, hotspot jvm) is to look at the cpuid capability flags and rely on them by default and only blacklist specific CPU models when they don't implement advertised features correctly, not the other way around.
- yxhuvud 7y agoThen don't test it. It is perfectly ok (and even expected) for Intel to not test on AMD. Just don't intentionally cripple it.
- bitL 7y agoThere are over 10 different x86 CPUs, some with very dodgy implementation of basic x86, not mentioning extensions. It could have been just a typical "safe" corporate decision to run optimized code path only on specific Intel CPUs. They use different code paths for different Intel CPUs/generations as well. Now imagine they had to believe that Hygon/SiS/Vortex implement it properly... It's not completely black/white.
- p1necone 7y agoYup, the number of people in this thread buying into Intel's excuses is astounding to me.