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). [Correction 2009-12-28: No they haven't. It was just a proposal.]
Now, back to the Intel/AMD settlement:
2.3 TECHNICAL PRACTICES
Intel shall not include any Artificial Performance Impairment in any Intel product or require any Third Party to include an Artificial Performance Impairment in the Third Party’s product. As used in this Section 2.3, “Artificial Performance Impairment” means an affirmative engineering or design action by Intel (but not a failure to act) that (i) degrades the performance or operation of a Specified AMD product, (ii) is not a consequence of an Intel Product Benefit and (iii) is made intentionally to degrade the performance or operation of a Specified AMD Product. For purposes of this Section 2.3, “Product Benefit” shall mean any benefit, advantage, or improvement in terms of performance, operation, price, cost, manufacturability, reliability, compatibility, or ability to operate or enhance the operation of another product.
In no circumstances shall this Section 2.3 impose or be construed to impose any obligation on Intel to (i) take any act that would provide a Product Benefit to any AMD or other non-Intel product, either when such AMD or non-Intel product is used alone or in combination with any other product, (ii) optimize any products for Specified AMD Products, or (iii) provide any technical information, documents, or know how to AMD.
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.