Agner Fog's opinion on intel/amd settlement

[informal]

.. and more evidence for slower than optimal code path for non-"GenuineIntel" MPUs in modern day software(from AMD devcentral).

Mr. Fog's post can be seen here (http://www.amdzone.com/phpbb3/viewtopic.php?f=52&t=137269) .


For years, Intel have made compilers and function libraries that work poorly on AMD and VIA processors. Apparently, the new Intel/AMD settlement requires that Intel change this practice.

First, the technical background:
Intel produces some of the best softare function libraries available for many technical and scientific applications. These function libraries have multiple versions of each function, each optimized for a processor and instruction set, for example SSE2, SSE3, etc. The system includes a so-called CPU dispatcher: A piece of code that detects which type of CPU it is running on and choosing the optimal version of the function for that CPU. However, the Intel CPU dispatcher does not only check which instruction set is supported by the CPU - it also checks if the vendor ID string says 'GenuineIntel'. If the CPU is not from Intel then, in many cases, it will run the slowest possible version of the function, even if the CPU is fully compatible with a better version. The same applies to code built with an Intel compiler. If the programmer chooses support for a specific instruction set or some form of automatic CPU dispatching then the compiled program will work suboptimally or not at all on AMD and VIA processors.

This behavior is not transparent to the programmer. A program that has been built with an Intel compiler or using an Intel function library may, unbeknownst to the programmer, work less than optimally on non-Intel processors.
In my C++ manual, I have shown how it is possible to replace the Intel CPU dispatcher and proven that the Intel software can run faster on an AMD processor if you circumvent this "cripple AMD" feature (http://www.agner.org/optimize/#manual_cpp). Others have shown that a common benchmarking program shows better performance on VIA chips if you change the vendor ID string (http://arstechnica.com/hardware/reviews/2008/07/atom-nano-review.ars/6). Apparently, AMD have put a feature to manipulate the vendor ID string into their next CPUs for the same purpose (http://forums.amd.com/devforum/messageview.cfm?catid=203&threadid=95754).

Was this clause written in order to prevent Intel from deliberately making software that works poorly on AMD processors? It looks like "Intel product" here refers to Intel compilers and function libraries, and "any Third Party" refers to programmers who use these compilers and function libraries.

Am I right that Section 2.3 refers to software? I don't see that it would make much sense in relation to hardware because Intel hardware can't be used in connection with AMD chips anyway.

For years I have criticized Intel for making software with hidden "discrimination" features and they have tried to explain away what they were doing. AMD have never made any comment on this issue to my knowledge, but it appears that they have won a victory here. (Or have they? There seems to be many loopholes in Section 2.3).

I will certainly check the next version of Intel's compiler and function libraries.


AMD devcentral link is here (http://forums.amd.com/devforum/messageview.cfm?catid=203&threadid=95754).



I have already did such an investigation and even more . For example:
1) ABBYY Fine Reader 8.0's ScanMan.exe contains the CPU dispatcher which blocks the SSE2 code path (and chooses x87) on CPU with Vendor = "AuthenticAMD" and Base Family = 0Fh, i.e. on K8 & K10!
2) Several DivX 6.x versions contain similar CPU dispatcher which blocks SSE's (and chooses MMX) on CPU with Vendor != "GenuineIntel".

What unfair play!

[Oliverda]

.. and more evidence for slower than optimal code path for non-"GenuineIntel" MPUs in modern day software(from AMD devcentral).

Mr. Fog's post can be seen here (http://www.amdzone.com/phpbb3/viewtopic.php?f=52&t=137269) .



AMD devcentral link is here (http://forums.amd.com/devforum/messageview.cfm?catid=203&threadid=95754).

http://arstechnica.com/hardware/reviews/2008/07/atom-nano-review.ars/6


This, gentle reader, is where things get fun. I've heard rumors for years that performance in PCMark 2005 could change depending on what CPUID was handed to the benchmark, but this is the first opportunity I've ever had to test that theory. The term CPUID refers to a processor-specific character string that stores information on the chip's manufacturer, available features, make, and model. Different manufacturers use different CPUIDs, including GenuineIntel, AuthenticAMD, CentaurHauls, and the now-obsolete CyrixInstead. Intel and AMD both lock their CPUIDs to prevent them being changed by a third party, but VIA doesn't—and that gives us an opportunity to explore a question that normally can't be explored.

http://media.arstechnica.com/reviews/hardware/atom-nano-review.media/PCM2K5-2.jpg

My my. Swap CentaurHauls for AuthenticAMD, and Nano's performance magically jumps about 10 percent. Swap for GenuineIntel, and memory performance goes up no less than 47.4 percent. This is not a test error or random occurrence; I benchmarked each CPUID multiple times across multiple reboots on completely clean Windows XP installations. The gains themselves are not confined to a small group of tests within the memory subsystem evaluation, but stretch across the entire series of read/write tests. Only the memory latency results remain unchanged between the two CPUIDs.

[demonkevy666]

I've read this before, but it's an on going problem. looks like developer/coder complaints too, if I'm not mistaken.
Intel has been windows optimized for a while.

[FireDragon]

is there anyway to "crack" this lock they put on the CPUID? as things have been said to b "locked" b4 and we make them work all the time, how much of a performance boost would this give a current gen AMD chip if it was possible?

Dragon