We have been following the Intel litigation trail for many years. Along the way, there have been many rumors about Intel using strong arm tactics to maintain their monopoly. Wednesday?s FTC suit raises the rumor of Intel manipulating their compiler design to the level of a legal accusation.
Every hardware manufacturer wants their products to be seen as leading edge and having the highest performance. Problems arise when the chip manufacturers develop their software so it will only work with their products.
Nvidia is famous for their CUDA [Compute Unified Device Architecture] "parallel computing architecture" [if we avoid marketing speak, C language with proprietary GPU-accelerating extensions]. There is software like Kaspersky Antivirus which is claimed to run 360 times faster because of CUDA. There is Adobe’s Mercury Playback Engine for upcoming CS5, which is CUDA-only. AMD and Apple push OpenCL and we can site many other examples of proprietary hardware and software combinations that are not compatible with their competition?s offerings.
What is unique in the FTC complaint against Intel is the singling out of the Intel compiler and how it affects benchmarking software. On page 3, item 10 of the complaint [PDF Download] says in part "Intel failed to disclose material information about the effects of its redesigned compiler on the performance of non-Intel CPUs. Intel expressly or by implication falsely misrepresented that industry benchmarks reflected the performance of its CPUs relative to its competitors? products.?
We asked Van Smith, President of Cossatot Analytics Labs about his experiences developing benchmarking software. Smith and his assistants created an open source x86 benchmark which is available as a no-charge download.
Smith explained he also worked with the BAPCo consortium?s benchmarking committee. BAPCo stands for Business Applications Performance Corporation and its current members include: AMD, Apple, ARCintuition, Compal, Dell, Hewlett-Packard, Intel, Lenovo, Microsoft, NVIDIA, Samsung, SanDisk, Seagate, Sony, Toshiba, and VIA Technologies. BAPCo is a non-profit consortium with a charter to develop and distribute a set of objective performance benchmarks for personal computers based on popular software applications and operating systems.
Smith said that while on the BAPCo committee he "constantly butted heads with Intel, and some of the correspondence generated during that time demonstrates the extreme and outrageous measures Intel takes to influence that consortium." Smith said that he would not be surprised if the FTC had copies of his correspondence in their files on Intel.
We asked Smith why the FTC was claiming Intel?s compiler was anti-competitive. He pointed to their wording on page 10, section B of the complaint, which says "Intel then designed its compiler and libraries in or about 2003 to generate software that runs slower on non-Intel x86 CPUs, such as [AMD] Opteron. This decrease in the efficiency of Opteron and other non-Intel x86 CPUs harmed competition in the relevant CPU markets."
Smith then gave an in-depth explanation of the problems created by the Intel?s compiler:
"For many years, Intel compilers have improperly included CPUID vendor name string checks before enabling code paths optimized for certain SIMD instruction set extensions like SSE2. For example, if the CPU responds with a vendor name string of "GenuineIntel" and CPUID support for SSE2 is detected, the program will take the appropriate, highly optimized SSE2 code path. If, however, the vendor name string returns anything else like "AuthenticAMD", the program will take a much slower, FPU only code path regardless of whether or not the CPU supports SSE2. SSE2 can lead to a doubling in floating point performance for many conditions. With single precision floating point operations, the boost can be even higher." As you might imagine, things are getting really complicated from a performance standpoint, but the end-result is the same:
"This imposes a severe performance handicap for all non-Intel CPUs. This would not be an issue if Intel’s compilers were rarely used, but Intel’s compilers very often produce the fastest binaries, particularly on Intel parts, so many performance sensitive applications use them." There is no doubt that Intel’s investment in developing its own compiler and compiler tools gives them the benefit of hand-tuning the compiler code to run better on their own products. After all, AMD’s GCC Linux compilers do the same thing for their own processors.
"Worse, a number of benchmarks exhibit performance boosts if the CPUID vendor name string is changed to "GenuineIntel".
Some CPUs, namely those from VIA Technologies, easily allows the user, through a series of MSR writes, to change the CPUID vendor name string to anything the user wants. This facility was added long ago to address many compatibility issues. It is my understanding that AMD CPUs also support such a feature, but it is not nearly as easy to access and might be solely hardware (fuse) based.
In any case, it is relatively easy to test for CPUID vendor name string sensitivity. PCMark05, SysMark 2007 Preview, and Everest Ultimate are three benchmarks that have been affected by the vendor name string value that CPUID returns, but others exist.
Your readers must understand that it is wholly inappropriate to use the CPUID vendor name string for instruction set extension optimization detection. The x86 CPUID instruction explicitly supports flags for all instruction set extensions and checking the state of these flags is all that is necessary in most cases.?
Smith said he is in agreement with the FTC?s contemplated relief for addressing benchmarking and the Intel compiler as outlined on page 22 of their complaint. This will require Intel to stop building hardware and software that impairs the performance of non-Intel CPUs and GPUs.
Smith is very much in favor of items 11 and 12 on page 22, which state:
Requiring Intel to correct the deceptive or misleading statements and omissions it has made in the past.
Prohibiting Intel from coercing or influencing benchmarking organizations to adopt benchmarks that are deceptive or misleading.
Smith feels these requirements will go a long way to making the development of benchmarking applications fair and equal to all manufacturers.
What do you think about the Intel compiler and its claimed negative effect on benchmarking results?