BRIGHT SIDE OF NEWS About | Advertise | Contact BSN USER Login
| Register
SUBSCRIBE Newsletter | RSS Feeds
Thursday, September 02, 2010
Email this to a friend.
Your friend's e-mail:
Your Name:
Your e-mail:
Message subject:

Why the FTC lawsuit against Intel has substance





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:

11-
Requiring Intel to correct the deceptive or misleading statements and omissions it has made in the past.

12 -
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?



© 2009 - 2010 Bright Side Of News*, All rights reserved.



Related articles:

Tags:

Share and enjoy :)

  • Digg
  • del.icio.us
  • StumbleUpon
  • TwitThis
  • Reddit
  • Furl
  • Google
  • Technorati
  • Sphinn
  • Mixx
  • Facebook
  • LinkedIn
  • Slashdot
  • Newsvine
  • Ma.gnolia
  • BlinkList
  • connotea
  • Fark
  • MisterWong
  • Netvouz
  • PlugIM
  • Propeller
  • Simpy
  • SphereIt
  • Spurl
  • ThisNext
  • YahooMyWeb
  • co.mments
  • Live
  • MySpace
  • Yahoo! Buzz


Comments:

by: Anonymous on 12/18/2009
At this point, I don't think anyone is interested in a CPU implementation of OpenCL.
We already have plenty of languages to write code for CPUs. What we need is something to unlock the potential of GPGPU.
Regarding Nvidia vs. AMD OpenCL statuses by: Anonymous on 12/17/2009
The AMD OpenCL driver will support both CPU & GPU; Nvidia's only works with its own GPU. Actually, AMD's OpenCL implementation will support even Intel's x86 CPUs, unlike what Intel does for AMD.
This went beyond just cheating, it was full fledged disabling by: Anonymous on 12/17/2009
In this case, it wasn't simply a case of Intel not "optimizing" for other processors. "Optimizing" implies something tuned for one processor, but it will still work on other processors if not optimally. Intel, on the other hand, actually disabled features of the compiler if it detected they were running on non-Intel processors. So when you compared an Intel processor to a non-Intel, you would see a big difference in performance because they weren't even running the same code!
Doesn't all this make benchmarks irrelevent? by: Michael A. McKenney on 12/17/2009
If Intel, AMD, ATI, and Nvidia all cheat, why spend the money on benchmarking software to begin with?
That's not relevant by: Anonymous on 12/17/2009
Intel is far from being monopoly in the compilers market. Microsoft compilers are far more popular.
BTW, from my experience Intel propriety libraries (IPP,MKL) are working very well on AMD CPU's
OpenCL by: Sean Kalinich on 12/17/2009
I think what he means is that AMD has its own Shader Compilers to compile their own OpenCL patches.

Take the recent Sandra OpenCL testing. AMD worked very hard to optimize the testing load for their architecture.
by: Anonymous on 12/17/2009
OpenCL is not a good example. It's an open standard.
Ironically enough, despite AMD bringing OpenCL to the attention in the media, nVidia is currently the only one who has OpenCL-drivers available to end-users.
So nVidia supports OpenCL even better than AMD does, despite the noise that AMD made about it.
http://www.nvidia.com/object/win7_winvista_64bit_195.62_whql.html
"Adds support for OpenCL 1.0 (Open Computing Language) for all GeForce 8-series and later GPUs."

So basically every nVidia user with an 8-series or higher card, who's upgraded to the latest WHQL drivers has OpenCL. AMD still only has a beta for registered developers (which doesn't work half as good as nVidia's drivers and SDK).
Leave a comment:

Author:

Title:

Comment:


Enter the code shown above:

(Note: If you cannot read the numbers in the above
image, reload the page to generate a new one.)




Highlight
  • ARM and GlobalFoundries attack Intel Atom: 2.5+GHz Cortex-A9
  • eBay Security Guards Shun Free Publicity
  • AMD Shows Next Gen Chips: Bulldozer and 1st and 2nd Generation Fusion
  • Activision Allows COD: Black Ops Dedicated Servers but There’s a Catch
  • Activision Allows COD: Black Ops Dedicated Servers but There’s a Catch
Welcoming Gil Russell

Greetings and Welcome,

Today we are announcing the arrival of Mr. Gil Russell as contributing editor for the publication. Gil will analyze the technology and business trends straight from the heart of Silicon Valley. We believe that we can mutually grow and share knowledge and decades of industry experience, all in order to create quality content - we hope you'll enjoy in Gil's future articles.

The BSN* Team

© 2009 - 2010 Bright Side Of News*, All rights reserved.