Will Intel have to remove from the compiler a function that deliberately delivers bad code for AMD processors?

Many programmers consider the Intel compiler the best optimizing compiler available on the market, and prefer to use it for the most demanding of performance programs. In addition, Intel supplies many highly optimized libraries for various technical and scientific purposes. In many cases, there are no worthy alternatives to the Intel libraries.

Unfortunately, programs compiled with an Intel compiler or libraries work much worse on AMD and VIA processors. The reason is that for software code, the compiler (or library) can produce several versions of machine code, each of which is optimized for a specific processor and instruction set, for example, SSE2, SSE3, etc. The system includes a function that determines which type of processor it is running on and selects the most appropriate version. This feature is called the processor dispatcher. The Intel Processor Manager checks not only the instruction set supported by the processor, but also the identifier of the processor manufacturer . If the identifier is the string “GenuineIntel”, then the most optimal code is selected. But if the processor is not from Intel, then in most cases the slowest possible option will be chosen, even if the processor is fully compatible with the best version.

I, like many other people, have complained about this behavior for many years, but Intel refused to change its controller. If Intel declared its compiler as compatible only with Intel processors, then there would most likely be no complaints. The problem is that they try to hide what they are doing. Many programmers believe that the Intel compiler is compatible with AMD processors. This is true, but in the secret of the programmer, he includes in the program a biased processor controller, who chooses the worst version of the code when working on processors of all companies except Intel. If programmers knew this fact, they would most likely use another compiler. Who wants to sell programs that do not work well on AMD processors?
')
Due to its size, Intel can afford to invest more money in its compiler than other processor manufacturers. The Intel compiler is relatively cheap, gives excellent performance and has excellent support. Selling such a compiler, of course, is not in itself a profitable business. On the contrary, it is obviously a way to support sales of Intel processors. There would be no point in adding new instruction sets to microprocessors if there were no tools to use them. AMD also produces a compiler, but the current version only works under Linux, and there is no version under Windows yet.

Many people have expressed the suspicion that this biased dispatcher is used in common performance measurement programs ( link ). This is a very serious question. We know that many customers make purchasing decisions based on published test results, and biased tests give an unfair market advantage worth billions of dollars.

Legal battle

AMD has repeatedly sued Intel for unfair competition, starting at least since 2005, and in November 2009, a settlement was reached . It concerns many issues of unfair competition, apparently, including the Intel compiler. We give a quote from it:

2.3 Technical Practices

Intel does not have the right to include any Artificial Performance Disruptions in any Intel products or require any third party to include Artificial Performance Violations in this third party product. In this section 2.3, “Artificial Disruption of Performance” refers to Intel’s positive engineering action or Intel’s design action (but not inaction), which (i) impairs the performance or performance of the Specified AMD Product, (ii) is not a consequence of the Improved Intel Product and (iii) ) intentionally manufactured to impair the performance or performance of the specified AMD Product. For the purposes of this Section 2.3, “Improving the Product” means any benefit, advantage or improvement in terms of performance, operation, price, cost, manufacturability, reliability, compatibility or ability to work or improve the performance of another product.

Under no circumstances will this section 2.3 impose, and cannot be interpreted as imposing, any obligation on Intel to (i) take any action that the Product Improvement will produce for any AMD or third-party product, regardless of whether this AMD product or third parties, alone or in combination with any other product, (ii) optimize any products for the said AMD Products or (iii) provide AMD with any technical information, documents or know-how.

It looks like AMD is winning. If we consider that "any Intel product" is Intel's compilers and libraries, "any third party" are programmers using these compilers and libraries, and "artificial performance violations" are the processor’s identifier verification of the manufacturer, then this arrangement obliges Intel change the dispatcher. I will definitely check the next version of the compiler and the Intel libraries to see if they will do it or find a loophole in this agreement.

Interestingly, the story did not end there. Just a month after an agreement between AMD and Intel, the US Federal Trade Commission (FTC) filed an antitrust complaint against Intel. The accusations in the FTC complaint are unusually strong:

Intel tried to undermine the performance of other companies' x86 processors in comparison with Intel x86 processors when it reworked and distributed software products such as compilers and libraries.
[...] [...]
The public, OEMs, independent software vendors, and testing organizations had the impression that the slower performance of other companies' processors on applications compiled using Intel products was caused by the processor, not by Intel software. Intel did not disclose the effects of the changes it made in its software, beginning with or around 2003, to its customers and the public. Intel also distributed false or misleading documentation about its compilers and libraries. Intel assured independent software vendors, OEMs, testing organizations, and the public that programs initially run on Intel processors faster than on competitors. In fact, many of the differences are due mainly or entirely to Intel software. Intel’s misleading or false statements and omissions about the operation of their software were taken into account by independent software vendors, OEMs, testing organizations and the public when they purchased and used processors. Thus, the assurances of Intel that the programs initially showed better results on Intel processors than on competitors were and are false or misleading. Intel’s refusal to disclose that these differences are primarily due to Intel software, given the assurances made, was and is fraudulent. In addition, these distortions and omissions could harm the reputation of other manufacturers of x86-processors, and harmed competition.
[...] [...]
Some independent software vendors have requested information from Intel regarding the apparent difference in performance of similar programs when launched on Intel processors and other companies. In response to such requests, Intel has repeatedly misrepresented, directly or indirectly, the source of this problem and the possibility of its resolution.
[...] [...]
Changes to Intel software slowed the performance of x86 processors from other manufacturers without any reasonable technological advantage. Intel's deceptive behavior deprived consumers of the opportunity to make an informed choice between Intel chips and competitors, as well as between Intel Software and competitors, and increased the cost of competition in their respective processor markets. Performance losses due to the compiler and the Intel libraries also caused immediate harm to consumers using x86 processors from companies other than Intel.

The sanctions required by the FTC also go very far:

For those Intel customers who, as stated in the complaint, purchased a compiler from Intel that has inflicted or is detrimental to the actual or apparent performance of microprocessors produced by non-Intel (“Damage Compiler”), it is required that:

1. Intel provided them, at no extra charge, with a replacement for the compiler, which is not a Damaged Compiler;
2. Intel reimbursed them for the cost of recompiling the software that they compiled using Damaged Compiler and replacement, as well as distributing the recompiled software to their customers; and
3. Intel made a public notice and warning in such a way as to ensure that those who purchased software compiled on Defective Compilers purchased from Intel could be transferred to the possibility of replacing this software.

Perhaps the FTC decided that an agreement between AMD and Intel is not a fair and sufficient means of protection against Intel’s monopoly behavior. It compensates AMD for losses, but does nothing for VIA, other microprocessor manufacturers, and customers who have suffered from lack of competition and the “flawed” software produced by the Intel compiler.

My own conclusions

When I started testing the Intel compiler a few years ago, I soon found out that its processor manager was biased. Back in January 2007, I complained to Intel about an unfair processor controller. I have long corresponded with Intel engineers on this issue. They constantly denied the problem, and I brought more and more evidence. They argued that:

Processor Manager, combined with optimizations, is designed to optimize performance on all Intel and AMD processors in order to give the best possible results. This is our goal and we believe that we have achieved it, with one exception. This exception is the lack of support for SSE3 on AMD processors in versions 9.x of our compiler, related to release dates (our compiler was developed before AMD made support for SSE3). The next version of the 10.x compiler, the beta test of which will begin this quarter, and the final version will be released around the middle of this year, will solve this problem, because we had enough time to adapt to the new AMD processors.

It sounds good, but in fact, the processor manager did not support even SSE and SSE2 in AMD processors, not to mention newer versions, and does not support them until now (Intel compiler version 11.1.054). Later I learned that others had turned to Intel with similar complaints and received the same useless excuses ( link link ).

Intel Processor Manager does not only check the processor manufacturer ID and the supported instruction sets. It also checks specific processor models. It will not be able to recognize future Intel processors, the family number of which is different from 6. When I asked Intel engineers about this, they answered:

You mentioned that we cannot support future Intel processors with family names other than '6' without updating the compiler. Yes, this is true and deliberate. We need a high degree of confidence that the program issued by our compiler will not stop working in the future. Thus, we cannot assume anything about future processors from Intel, AMD or other manufacturers. You noticed that we could act more aggressively. We believe that it would be unwise in relation to our customers who want to be sure that their code (compiled with our compiler) will continue to work in the distant future. The methods you have proposed, although they look reasonable, are not conservative enough for our highly optimizing compiler. Our experience leads to a conservative code issue. After we test the functionality with new Intel and AMD processors, we update the compiler. This means that there is some lag with the support of new processors in the official version of the compiler.

In other words, they claim that they optimize for specific processor models, and not for specific instruction sets. If true, this provides Intel with an argument in defense of the inadequate support of AMD processors. But it also follows from this that all software developers using the Intel compiler must recompile their code and distribute new versions to their customers every time a new Intel processor appears on the market. That was three years ago. What happens if I try to run a program compiled by the old version of the Intel compiler on the newest Intel processor? Predict: it will still select the best branch of the code. It is more difficult to guess the reason: Intel manipulates the numbers of the CPUID families in the new processors so that the old Intel compilers consider them to be well-known models. I have described the technical details in another article .

It is possible that at first Intel's CPU dispatcher was really intended to optimize only for known processor models, without regard to future models. If any of my students passed such a decision, I would consider it a serious shortcoming. Perhaps Intel engineers discovered the lack of support for future processors too late to fix it, and were forced to develop the next generation of processors so that existing Intel software would take them for well-known models.

After Intel refused to change its dispatcher, I decided that the most effective way to get them to change their mind would be to spread information about this issue. I contacted several magazines, but no one wanted to write about it. It is a pity, but not surprising, considering that they all depend on the placement of advertising by Intel. The only place where I managed to highlight this was my own manual on optimizing programs , where I described the situation in detail and indicated how to replace an unfair dispatcher. I do not know why AMD has not spread this information. Perhaps they were required to remain silent about the course of the trial? What about VIA and Centaur?

Temporary solutions

At the moment we do not know whether Intel will release a new compiler and new libraries that do not check the manufacturer’s identifier, and if so, when. But here is what we can do before this time:

1. Use another compiler. According to my tests , the Gnu compiler for Linux optimizes performance at a level similar to that of the Intel compiler, but the Gnu function library (Glibc) is worse than Intel's. All other compilers show lower performance. Under Windows, compilers with performance close to the Intel compiler do not exist.
2. Use the Intel compiler and replace the dispatcher. In my C ++ guide, I published code for alternative processor dispatchers for compilers and Intel function libraries and instructions on how to embed them. Of course, they use undocumented details about the Intel software device. This change can in many cases significantly improve performance on non-Intel processors.
3. Do not trust any performance benchmark if its source code is closed or does not use a neutral compiler, such as Gnu or Microsoft.
4. AMD virtualization instructions allow you to change the CPUID of AMD processors. I hope that someone will make a program for this. This makes it easy to check if any given test is fair and to improve the performance of software compiled by the Intel compiler on AMD processors.

Links

My discussion on the Aceshardware forum, 2007 .

Discussion on the Developer Forum
AMD, 2008 .

My discussion on AMDzone 2009 .

Group discussion
comp.arch, 2004 .

Complaint in Intel, discussion in slashdot.org, 2004 .

Mark Mackey complaint to Intel, 2005 .

The unfairness of the PCMark 2005, Arstechnica test has been proven .

Witness's testimonies
John Oram regarding the testing organization BAPCo .

Commentary on AMD Developer Central, 2005 .

AMD sues, 2005 .

Antitrust complaint AMD, 2005 .

The settlement agreement between AMD and Intel, 2009 .

FTC Complaint, 2009 .

Technical details in my C ++ optimization guide .

Discussion on the XtremeSystems forum .