Well, on Cyryx CPU there were the possibility to fake the CPUID identification strings (amd maybe also the codes) and all INTEL compiled programs gained performance (even 50%+)... And if i am not wrong a virtualization software let do this for all CPUs and many tests were made.
I haven't said anything regarding this. It might be true.
INTEL was condemned for this. 1 billion dollars if I remember well. Plus some other things like relax x86 license for AMD (there was the obligation to own a fab).
No, that's what for the unfair competition in the 2002-2007 period, for abuse of dominant position.
The truth is that for INTEL CPUs (and as you pinpointed not all of them) the correct optimized path was used. For the other INTEL CPUs probabily only a path coherent with the feature set provided by CPUID was selected (this would have been the correct behaviour for all CPUs, even non INTEL, if there is not an optimized path). For non INTEL CPU the slowest path (486/x87 for older compilers, up to SSEn for newer compiler) was selected.
No. As I reported before, the code path selection follows an (Intel's) micro-architecture criterion. Otherwise a fallback/general code-path is used.
See the Agner's page, and below on the other comments.
The L1I? 64KB for Zen and 32KB for INTEL. The ways are higher on INTEL, so AMD Zen cache is not so effective, but it's bigger.
Intel's L1 cache is 32KB, 8-way, with a 64 byte line.
Zen's L1 cache is 64KB, 4-way, but we don't know how many bytes per line it holds (32?).
Well, if it fits in cache (uop or L1I or L2), you spare some cycles... Maybe after a big emulated instruction the uop cache is wiped out, but i doubt that a single emulated instruction has more than 32/64kb of code...
Of course not, but since you continually jump between different instructions, it's quite likely that a uop cache is frequently flushed and reloaded.
I think he's referring to Intel cheating by having its compiler inject GenuineIntel authentication, and then taking the unoptimized path when Intel CPU wasn't detected.
http://www.agner.org/optimize/blog/read.php?i=49
Yes, he was referring to this case.
Thanks for the link, which proves what I've reported before.
You are wrong. This was more about instruction usage than micro-architecture tweaks.
from Agner's page, Intel developers:
"You mentioned we will not support future Intel processors with non-'6' family designations without a compiler update. Yes, that is correct and intentional. Our compiler produces code which we have high confidence will continue to run in the future. This has the effect of not assuming anything about future Intel or AMD or other processors."
and Agner's conclusion:
"In other words, they claim that they are optimizing for specific processor models rather than for specific instruction sets. If true, this gives Intel an argument for not supporting AMD processors properly. But it also means that all software developers who use an Intel compiler have to recompile their code and distribute new versions to their customers every time a new Intel processor appears on the market."