US FTC Sues Intel For Anti-Competitive Practices

Vigile writes "And here Intel was about to get out of 2009 with only a modestly embarrassing year. While Intel and AMD settled their own antitrust and patent lawsuits in November, the FTC didn't think that was good enough and has decided to sue Intel for anti-competitive practices. While the suits in Europe and in the US civil courts have hurt Intel's pocketbook and its reputation, the FTC lawsuit could very likely be the most damaging towards the company's ability to practice business as they see fit. The official hearing is set for September of 2010 but we will likely hear news filtering out about the evidence and charges well before that. One interesting charge that has already arisen: that Intel systematically changed its widely-used compiler to stunt the performance of competing processors."

Re:I especially like..

[InsaneProcessor]

The compiler identified the CPU and changed it's behavior to be unoptimized if not the "golden" part. This falsely caused publicly used benchmarks to show competitors parts to be slower.

Re:I especially like..

[plasmacutter]

I like the complaint about the compiler. After all, Intel should be required to optimize their compiler for their competitor. To each according to his need...

The allegation is their compiler can, but deliberately does NOT, apply optimization to code if it detects the processor is AMD.

This is analogous to video game consoles refusing to use generic memory sticks or hard drives. Of course, intel will try to claim it's more like trying to attach a sata drive to an IDE port, but we all know the instruction sets for X86 are standard across both chips.

Serves Nvidia right

[Anonymous Coward]

That serves Nvidia right.
Nvidia are a bunch of assholes, they don't want to license out SLI.

Intel did the right thing.
Nvidia wanted to play hardball, then they cried about it.
Nvidia didn't want to license SLI, so Intel didn't want to license to Nvidia.

Re:Intel compiler not that good on their own parts

[MBGMorden]

because of the hardware differences, and didn't put in a switch for AMD, well, who says they had to,

Apparently, the government. You see it wasn't a case where they simply didn't setup their compiler to optimize for AMD's parts. They explicitly made it run worse if you were running non-Intel hardware. Normally that would just be incredibly sleezy, but Intel is quite possibly in a monopoly position, which makes some behavior that's normally just sleezy illegal instead.

Intel's response

[parallel_prankster]

http://blogs.wsj.com/digits/2009/12/16/intel-responds-to-ftc-suit/ [wsj.com]

Re:Well, duh.

[betterunixthanunix]

No, the company designed a compiler that performed a lot of optimizations for the particular instruction set they implemented, and then hard coded the compiler to not actually apply those optimizations on their competitors' implementations. The optimizations would have worked, and Intel had the compiler deliberately not apply them.

There is no conspiracy; Intel just broke the law. If you are competing with me, you have to follow the law, no matter how much you want me out of the game.

Re:AMD was robbed

[0racle]

There were no shortage of 'experts' i.e. small business owners who ran local repair shops and snot-nosed brats who don't really know anything but heard bad stories about the k5 and k6 who turned everyone they could against AMD chips forever. I worked at a small business that catered to IT support for local small businesses and the 'senior' there would almost fly into a rage at the mention of using AMD or an Apple product, with the latter literally causing him to insult the client for even suggesting such a thing. Why? Because AMD made some bad chips in the past and well, he just didn't understand OS X.

The reputation that AMD earned with the k5 and k6 was appropriate, but they solved whatever their issues were with the k6-2 and you're right the Athlon was much better then the P4. Unfortunately, too many people that are held by others as being 'in the know' never kept up.

Intel holding the lead during the time of the Athlon was as much Intels past ability to make a consistantly reliable product as it was any illegal practice.

Re:I especially like..

[InsaneProcessor]

Let's break it down. For instructions sets like SSSE3, SSE4, etc. Intel designed bits to identify if these instructions are supported. All competitors comply with these bits. What they did do is: if the part isn't identified as "Genuine INTEL" the compiler stopped code optimizations. This is a provable fact.

Re:Well, duh.

[Virak]

So Intel should be required to test out their competitors products for compatibility with these optimizations, as well as its own products?

Are you fucking kidding me? Intel didn't just "not test" it with AMD's stuff, they went out of their way to make sure it wouldn't work on it. And if AMD's processors didn't run x86 code properly a whole lot more people would notice then just the ones using Intel's compilers. Do you even have any clue how a compiler works?

I'm not defending Intel here

You are saying that what Intel did with their compiler is perfectly legitimate. I don't see how you can spin that as anything but defending them.

the issue is whether Intel is allowed control over its own products

And that issue is long-settled: they are not allowed control over their own products to they extent they can harm competition in the market as they please. The only possible "issue" is whether their actions did or did not illegally harm competition.

If you ask me, the solution is to unbundle the CPU from the rest of the system architecture. I know, it's difficult to imagine even amongst IT people because the CPU has long been the center of the system -- everything is designed around that. Well, maybe it's time for that to change. And the FTC should put its focus there -- just as we unbundled Internet Explorer from Windows -- the software, it's time to unbundle the hardware.

Okay, now I'm definitely sure you don't understand the slightest bit about the technology involved. The CPU is already "unbundled" from everything to the maximum extent technically possible. They cannot "unbundle" it any further. The code would've run just fine on AMD's chips precisely because it is "unbundled" and is an interchangeable piece of hardware with multiple independent implementations. Intel has absolutely no defense here, certainly not on technical grounds, and you're just making yourself look like a fool trying to argue for them.

Re:I especially like..

[Anonymous Coward]

Better to know what you're talking about instead just guess. ICC detects the CPU features and enable optimizations for supported CPUs. So for all others unsupported CPU, it disable the optimizations. You can blame Intel to not invest their money & time to code and test their optimization for AMD processors.

For example, lets see the release notes http://www.intel.com/software/products/compilers/docs/cwin/release_notes.htm /QxO
Specifies that the compiler is to generate SSE3, SSE2 and SSE instructions and to optimize for the Intel® Pentium® 4 processor and Intel® Xeon® processor with SSE3. Generated code should operate on processors not made by Intel that support SSE3, SSE2 and SSE instruction sets, such as some AMD* processors. This value does not enable some optimizations enabled in the S, T, and P processor values. (IA-32 and Intel® 64 architecture only, default: off)

Above option enable SSE3, SSE2 & SEE but not SSE4 on soem AMD processors. Intel states clearly what they can support in their release notes. And Intel compiler is expensive and it's not the compiler dominate the market (it's Microsoft compiler and GNU C/C++ compilers). Most of the processors benchmarks you can find on the Internet were done by tools compiled by MS VC++ or gcc/g++ but not ICC.

Re:Well, duh.

[Brian Stretch]

Intel's compiler treated any CPU that didn't report being GenuineIntel as an i386 instead of checking for the SSE, SSE2, etc flags like an honest company would have. If you hacked the compiled code to skip the GenuineIntel flag test it magically performed MUCH faster on AMD hardware.

Given that end users have no control over which compiler a software developer uses, AMD users suffered artificially poor performance if their vendors either chose or were coerced into using Intel's compilers.

This is a very old issue. Here is one glaring specific example from four years ago:
http://yro.slashdot.org/comments.pl?sid=155593&cid=13042922

Benchmark companies in particular just happened to favor Intel compilers. Some of those benchmark makers were really, really shady:
http://www.vanshardware.com/articles/2001/august/010814_Intel_SysMark/010814_Intel_SysMark.htm

Re:Well, duh.

[Virak]

Yes, actually, but that's not the material issue here. If they want to put in an instruction that says "if processor_type 'Intel' then skip_optimizations=1" then all the power to them. It's theirs. Not AMDs. Not yours.

Unless it is part of a massive pattern of grossly anti-competitive behavior which they then get repeatedly sued all over the world for. Then, not so much.

But if the product is then changed so the third party's products no longer work, that's always bad? It's always anticompetitive?

If they intentionally and maliciously change it for no purpose but to prevent their competitor's product working with it, yes.

What you're suggesting here is that not "harming the competition" is more important than a company's right to design its products to be as beneficial to use together as possible.

"Suggesting"? I guess I was too subtle. I'll state it very explicitly: The proper functioning of the market is far more important than the ability of a company to do with its products as it pleases. And this doesn't make their products more "beneficial to use together", it just makes it less beneficial to use it with the product of a competitor to them in a different market, as has been repeatedly pointed out to you by both me and others. And after talking about how we should "unbundle" things like with Windows and IE, it doesn't make much sense to be saying companies should be allowed to do that sort of stuff freely.

And no, they're very bundled -- I can't use an AMD processor with an Intel chipset. Motherboards are designed around the CPUs -- and while the peripherals (memory, expansion cards, etc.) may have standardized interfaces, the guts of the system does not.

If there were published standards about how CPUs connect to the mainboard, and if the mainboard's major components were made interoperable (open BIOS, SMC, all that jazz--) that would be unbundling. The bottom line here is that if these parts were interchangable -- so that you didn't have to decide on the CPU first and then the rest of the system, that would be "unbundled". That would be a more fair marketplace than what exists right now.

"But then Intel can't make their products work as best possible with each other! What right do you have to tell them what to do with their own products!" And so on. Your arguments are once again not being internally consistent, even within the same post. While it'd certainly be nice if hardware manufacturers were completely open about all their stuff, this sort of thing in particular (making every processor work on every motherboard) is quite a bit of effort for very little benefit, particularly in this case. Being able to run an AMD processor on a motherboard for an Intel processor whilst giggling to yourself about how funny it is is about all you get out of it. It wouldn't prevent any of the highly anti-competitive things Intel has been doing, not even just the specific case of them being jerks with their compiler.

Re:I especially like..

[EndlessNameless]

I'll oblige since you're apparently unable to do basic research yourself.

The relevant section of law is 15 U.S.C. 1-7. The law was known as the Sherman Antitrust Act prior to its incorporation into the U.S.C.

A deliberate attempt to remove competition by a potential monopoly is considered a violation of the law per the Supreme Court's decision in Spectrum Sports, Inc. v. McQuillan.

Three criteria were established for determining if behaviour constitutes attempted monopolization: (1) predatory/anticompetitive behavior, (2) intent to monopolize, and (3) a reasonable chance of becoming a monopoly.

Unless you're a dolt, crippling the compiler product in the presence of competing processors is obviously predatory or anticompetitive in nature. While you can argue the other two criteria, I doubt anyone will seriously believe Intel doesn't want to be the only game in town or Intel has no chance of becoming a consumer CPU monopoly.

Thus, should it be demonstrated that Intel crippled their compiler for AMD processors, they are in violation of federal law. I don't understand why you couldn't have found this all by yourself; this is not new law by any stretch of the imagination.

Re:I especially like..

[cheesybagel]

No it was much worse than that. There is a CPU instruction named CPUID [wikipedia.org] which tells you the processor family, manufacturer, and has a set of feature flags saying which extensions (e.g. SSE, SSE 2, 3DNow) that particular processor supports. Intel's compiler enabled SSE optimizations only if the processor manufacturer string was "GenuineIntel" and the processor family number was high enough, instead of checking in the flags vector if the processor supported SSE.

Re:I especially like..

[cheesybagel]

The flags do not lie. Processor manufacturers are not that stupid. There are different flags named 'sse4a', 'sse4_1', 'sse4_2'. Intel themselves initially only supported a part of the SSE 4 specification they made. This is why there are separate 'sse4_1' and 'sse4_2' flags. If a processor has a flag it means it implements a certain set of well defined instructions. Intel keeps its instruction extensions close to their vest usually, so AMD only gets to know them after Intel has already designed their own processor. AMD can sometimes do microcode changes to support instructions, in fact they did this in their initial SSE implementation, but other times you need to change the hardware functional units which takes years to do.

Intel Pentium II processors did not have SSE instructions either. No one asked for Intel to do additional work, just that they followed the proper way of doing it, which was no extra work at all. Intel's practice predates SSE 4 instruction development. It is known they did this even before Opteron came out.

Re:I especially like..

[aztracker1]

but inside the if (intelCPU) block, the test for hasSSE3, hasSSE2, hasSSE... other browsers support that, so they are intentionally not allowing those code paths for other cpus.

Re:I especially like..

[Khyber]

No, as Intel has a dominant share of the market, and is abusing that dominance. That's one of the litmus tests for determining whether or not it is predatory or anti-competitive. Having a monopoly is not a requirement.

Re:I especially like..

[Rockoon]

The first one is not what Intel did.

Re:I especially like..

[BikeHelmet]

Why on earth would AMD use Intel's compiler for benchmarks, it just seems like common-sense that they would want to control the compiler to ensure that it's output is properly optimized for their processor.

They don't. Well, except to collect performance data I suspect.

Companies like Adobe use ICC for all their products. Maya is compiled with ICC. Many of the top programs used in benchmarking(office/productivity software) are compiled with ICC. When used as benchmarks these programs always conclude that Intel CPUs are faster.

But that's not where the antitrust comes in. Optimizing your compiler for your CPU better than a competitor's CPU is completely acceptable. What isn't is a secret handshake wink wink that shunts off 100% compatible CPUs from your competitor to a slower code path.

You can defend it by saying you planned to add new features/instructions that only your CPUs would support, but it won't hold up in court. AMD was able to prove their CPUs were 100% compatible at the time. That means if you run the faster code path, it always works fine. That's why they had grounds for an antitrust suit.

P.S. If you compile these programs with GCC, AMD usually wins the benchmarks. However, scores will be lower for both AMD and Intel CPUs. ICC just does a better job...

You could say that AMD CPUs do better with garbage code. I wonder if that'll have implications for JIT'd languages?

What I personally do to determine which CPU is fastest is look at gaming benchmarks. I like games, so why not? I pick some low resolution benchies, testing fast videocards, and for a game/engine that hits the CPU hard. Then I look at the numbers. Ex:

Athlon II X 245 (2.9ghz) - 153fps
Athlon II X4 620 (2.6ghz) - 171fps
Core i7 920 (2.66ghz) - 174fps
Athlon II X4 630 (2.8ghz) - 175fps

Since I'll be running at high detail levels, this lets me conclude that any quad-core will work and I should go for the cheapest.

Of course, some games are compiled with ICC too... there's no perfect way to read benchmarks.