"Also, if Intel must provide good support for all AMD chips, then they will have to do the same for any other competitor (and there are some iirc)."
Again, nobody in this discussion is saying that Intel must provide good support for all AMD chips. All anyone is saying is that Intel should stop explicitly checking for non-Intel chips and running deliberately slow code on them.
Again, it would be just fine if Intel optimized their compiler exclusively for Intel CPUs and let non-Intel CPUs deal with whatever code they generated. That's what everyone would expect Intel to do. Nobody sane expects Intel to optimize for AMD CPUs in their compiler. We just expect Intel not to put extra effort into crippling them.
I understand you. But, is it possible that say, between two features, say SSE 4 and AVX, the less powerfull one happens to be the most efficient for a given algorithm on platform A, and the least efficient on platform B? If yes, how would a the compiler know which path to choose without knowing which platform it is targeting?
It wouldn't, but the sane way to handle that would be to special-case platform A, and let platform B fall back to feature detection, rather than falling back to the worst possible code.
All right, then I suppose that what you are saying is that Intel should leave the genuine Intel chips detection out, and let customers implement specialized paths for AMD products, if the automatically selected path happens to underperform (for a certain performance expectation level), which might be less likely to occur if all the generated paths are available. Did I get this right?
And for people looking to extract every last bit of power from their chips (AMD or not), they might have to implement the path by hand anyway.
> rather than falling back to the worst possible code.
Note that (I think it might have been said elsewhere), it's not the worst possible code, but the least efficient one generated by the compiler (which happens to be quite good already). /pedantic mode
There are two reasonable choices for Intel to follow:
1. They decide to implement the best possible x86 compiler for all CPU vendors. In this case, they optimize for AMD chips (and anyone else selling x86 chips) just like they currently do for Intel, possibly including AMD-specific code paths.
2. They decide to implement the best possible compiler for Intel x86 CPUs. In this case, they should just ignore the existence of other vendors and do the best they can for their own stuff. If it runs fast on AMD, great. If it doesn't, not their problem.
I'm not sure which of those two what you said falls under, but I think it's one of those. Unfortunately, they have chosen a third path, where not only do they specialize for Intel, but they check for non-Intel and deliberately pessimize performance there.
2nd choice (sorry for my confused english). But then there might be legal consequences to factor in. Engineers shouldn't probably care about that.
As for the first choice, ideally Intel should do that to provide the best possible compiler out there, but that would really be shooting oneself in the foot, unless they are guaranteed to always have the upper hand on the hardware side. It would also require them to study AMD cpus deeply (how instructions get translated to microcode, how that microcode is optimized, etc) - they probably have people doing that (if that's legal).
Again, nobody in this discussion is saying that Intel must provide good support for all AMD chips. All anyone is saying is that Intel should stop explicitly checking for non-Intel chips and running deliberately slow code on them.
Again, it would be just fine if Intel optimized their compiler exclusively for Intel CPUs and let non-Intel CPUs deal with whatever code they generated. That's what everyone would expect Intel to do. Nobody sane expects Intel to optimize for AMD CPUs in their compiler. We just expect Intel not to put extra effort into crippling them.