> I think it might be difficult to purposefully cripple AMD in an open source project.
It's not as explicit as it has been in the past, but the CPUID checks for very specific feature sets aligned with particular Intel models may not match AMD models, producing worse code on AMD models that support featuresets above baseline AVX2:
That said, I don't assume malice here and I haven't investigated thoroughly. Most likely they just want to support their own silicon well and that's what they know.
It's possible they would accept similar support for AMD µarchs in the OSS project (or maybe not).
I wouldn't draw too much inference from the ARM example, as I don't see ARM as an Intel competitor. AMD, on the other hand, is currently very competitive with Intel.
ARM seems a competitor to Intel in HPC, particularly in the Fujitsu post-K system (whose actual name I forget), but even the existing ThunderX2 systems.
Interestingly, Intel people don't necessarily have the information to optimize for Intel CPUs even, and the hardware may not tell you. It's really complicated and messy. An example that's relevant to linear algebra is figuring out whether to use FMA, e.g. https://github.com/jeffhammond/vpu-count
I’ve spent time writing CPU detection code for previous projects, and there is nothing that jumps out at me as biased in the linked ISA check. In fact that is really the bare minimum required to split the AVX variants, and will detect AMD support just the same as Intel.
You can compare it to other detection functions - one relatively easy to read, non-vendor biased example that does dig into all the extensions is this Go implementation (not mine): https://github.com/klauspost/cpuid/blob/master/cpuid.go
Right, it looks pretty reasonable to me too. Zen2 still doesn't have AVX-512 anyway, so the super parallel paths this aims to really help aren't applicable anyway.
Zen1-2 should land on the "AVX 2 (Haswell)" path in the linked excerpt -- they have AVX/AVX2, F16C, OSXSAVE, and RDRAND -- which is the best ISA without AVX512 implemented in the compiler. That's entirely reasonable on Intel's part.
(I don't know why they look for RDRAND in a compiler, but whatever.)
Just search the github repo for "cpuid." It's used in two files, and while it does select for featuresets of Intel-specific models, it does so using common feature bits that AMD can implement, and has a fallback path for baseline AVX2-only mode. It isn't clear that they intentionally cripple AMD in any way. There is no explicit check for GenuineIntel, for example.
> And this is an even bigger issue because several popular benchmarking tools were compiled with ICC, skewing CPU reviews in Intel's favour.
A benchmark whose speed also depends on a compiler is not a benchmark of the CPU, but of a combination compiler/CPU. If this is not written down (and, of course, also written down which compiler was used), it is a deception of the reader.
All benchmarks depend on both the CPU and the compiler -- except those coded in assembly language. Everybody knows it, so it is not (by itself) a deception.
I'm not saying that it won't work - but I'd be very surprised if it was well optimised for any vendor other than Intel.
This in and of itself is not proof that they are operating in bad faith; if they provide clean interfaces and reasonable default implementations that's all that can be justifiably expected of them.
The question of good faith actually only comes into play when another vendor provides their own optimised implementations and creates a pull request.
How will the project maintainers respond? Even getting to that point requires a trust based buy in to the project from the other vendor.
Given Intel's history of toxic behaviour in competition I think they need to do far more than they have done (and are likely to ever do) to earn that minimal baseline of trust.
This is an open source project that came from a single person inside Intel. Intel is a huge company and this project is barely a blip on priorities. You don't have to gues, go try it or do some research. It has been maintained for many years now, you can see all of the history on GitHub.
But Intel's history when it comes to compilers and applied optimisations leaves this making me immediately uncomfortable.
The sort of PR work that these guys would need to do in order for me to consider them even remotely trustworthy is beyond even their budget.