Last month the US Federal Trade Commission sued Intel for anti-competitive practices; and in my post on the subject I tried to make sense of part of the FTC’s complaint, that:

Intel secretly redesigned key software, known as a compiler, in a way that deliberately stunted the performance of competitors’ CPU chips.

A few days ago Agner Fog wrote an article that sheds some light on the subject:

The reason is that the compiler or library can make multiple versions of a piece of code, each optimized for a certain processor and instruction set, for example SSE2, SSE3, etc. The system includes a function that detects which type of CPU it is running on and chooses the optimal code path for that CPU. This is called a CPU dispatcher. However, the Intel CPU dispatcher does not only check which instruction set is supported by the CPU, it also checks the vendor ID string. If the vendor string says “GenuineIntel” then it uses the optimal code path. If the CPU is not from Intel then, in most cases, it will run the slowest possible version of the code, even if the CPU is fully compatible with a better version.

Fog also notes a clause in Intel’s November 2009 settlement with AMD [PDF] in which the company undertakes not to:

include any Artificial Performance Impairment in any Intel product, or require any Third Party to include an Artificial Performance Impairment … “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.

It is a fine distinction. At what point does failure to optimise constitute “affirmative engineering”? What riles developers is that even when an non-Intel CPU reports support for an optimisation such as SSE, the Intel-compiled code will not use it unless it is an Intel CPU. You could argue that this is an inaction (failure to optimise) rather than an action (deliberately running slower); but the end result is the same, worse performance on non-Intel processors.

The obvious practical solution is to use other compilers, but for certain types of work Intel’s compiler is considered the best.

Has Intel now agreed to do a better job? You tell me; I don’t think the clause quoted above tells us one way or another. I do think it is legitimate for the government to press Intel at least to take advantage of obvious optimisations on third-party processors, since this benefits everyone. Even so, Intel will always optimise best for its own CPUs and that is to be expected.

Performance tests are another issue. It is deceptive to produce test results showing performance differences without also revealing that in one case the code is optimised, and in another it is not. That said, if Intel has a smart optimisation that is specific to its own CPUs, there is no reason why it should not trumpet the fact. This is a matter of disclosure.

Finally, developers take note: if you are compiling for a general market that might or might not be using Intel CPUs, maybe the Intel compiler is not the best choice.