FTC sues Intel

[Phynaz]

It was rumored to be coming...

http://news.cnet.com/8301-1001_3-10416443-92.html?tag=newsLatestHeadlinesArea.0

Edit:

Intel's response -
http://finance.yahoo.com/news/Intel-Comments-on-FTC-bw-112159620.html?x=0&.v=1

 

[VirtualLarry]

This was almost guaranteed under Obama.

 

[Idontcare]

The choice of wording by both parties point to irreconcilable differences.

Unfortunately for Intel though they are not an equal-rights partner in the relationship, as such I fully expect the government agency will get what they want out of the deal and Intel dragging their feet isn't likely to reduce the penalties being sought by the government.

RIP standard oil. You had a good run but the proverbial handwriting is on the wall.

 

[Necrosaro420]

This was almost guaranteed under Obama.

So was the senates decision yesterday to deny a bill that would lower drug prices for americans since we are charged 10 times as much as other countries for the exact same drugs.

 

[Cogman]

In addition, the FTC contends that Intel secretly revamped its compiler to slow the performance of rival chips and simply told its customers that the software performed better on its own chips that on those of the competition.

Ok, perhaps Intel did participate in non-competitive practices. But really? "Oh noes, your compiler generates code that is optimized for your processor!"

 

[jvroig]

So was the senates decision yesterday to deny a bill that would lower drug prices for americans since we are charged 10 times as much as other countries for the exact same drugs.

And if we're going to be pro or anti-Obama, let's place it in the Politics section.

Thank you jvroig ! If politics come into this thread anymore, I will lock it.
Markfw900
Anandftech Moderator

On topic: I'm surprised the FTC went through with it, but Intel probably deserves it, what with the alleged "bribing" of Dell and whoever else.

What's more surprising for me is including the nVidia issue in the suit. Jen-Hsun Huang must think this is some sort of early Christmas present, I'm sure he loved reading this development.

 

[jvroig]

Ok, perhaps Intel did participate in non-competitive practices. But really? "Oh noes, your compiler generates code that is optimized for your processor!"

While the end result is the same, I don't think that's exactly what the FTC is complaining about. For software to perform better on Intel CPUs versus AMD CPUs, these two could happen:

1.) Intel made a compiler (or modified it so) that, quite naturally, produces code that is optimized for their processors. Whether it will also fit like a glove for competing processors is not a concern.
2.) Intel modified the compiler not for optimization concerns for ther processors, but rather to deliberately slow non-Intel processors.

You are saying it is case #1, and your reaction is valid for it.

The FTC, however, is clearly claiming #2.

My personal opinion is that the reality is most likely #1. I will, however, be interested in seeing the developments in this case against Intel.

 

[Cogman]

While the end result is the same, I don't think that's exactly what the FTC is complaining about. For software to perform better on Intel CPUs versus AMD CPUs, these two could happen:

1.) Intel made a compiler (or modified it so) that, quite naturally, produces code that is optimized for their processors. Whether it will also fit like a glove for competing processors is not a concern.
2.) Intel modified the compiler not for optimization concerns for ther processors, but rather to deliberately slow non-Intel processors.

You are saying it is case #1, and your reaction is valid for it.

The FTC, however, is clearly claiming #2.

My personal opinion is that the reality is most likely #1. I will, however, be interested in seeing the developments in this case against Intel.

Well, it pretty much HAS to be #1, #2 would have caught and called out a LONG time ago. People that use the Intel compiler are generally very concerned with how the code performs, which means you have a LOT of people that are going to be closely monitoring the assembly that is coming out of the ICC. Any attempt to deliberately slow down AMD CPU's would become instantly obvious.

Even then, even if they made a compiler that generates code to explicitly checks to see if the CPU is an AMD CPU and then use code that is 50x slower. Even if that was the case, Who cares? Intel doesn't exactly have a corner on the compiler market. Almost any other compiler suite is more popular to use then the ICC (not that it is bad, but it is expensive to commercially own and use. Only the most performance conscious developers would go with the ICC over the GCC, MSVC, or Bordlands).

I hardly view it as anti-competitive to release a product that is designed from the ground up to make your product work better and others fail. If that where the case, then we might as well charge every console manufacture since the beginning of time of being anti-competitive because they make products that ARE specifically developed to make sure that software compiled with their compilers will work only with their products an no other product.

Perhaps if intel was the only company that had a compiler on the market, then I might consider it to be anti-competitive, but where there are so many other options out there, and many of them are more popular then the ICC, This is just ridiculous.

 

[lopri]

The full allegation here (PDF): http://www.ftc.gov/os/adjpro/d9341/091216intelcmpt.pdf

I find interesting coincidences.

As it did in the CPU markets, Intel recognized the threat posed by GPUs and GP GPU computing and its technological inferiority in these markets and has taken a number of anticompetitive measures to combat it. These tactics include, among others, deception relating to competitors’ efforts to enable their GPUs to interoperate with Intel’s newest CPUs; adopting a new policy of denying interoperability for certain competitive GPUs; establishing various barriers to interoperability; degrading certain connections between GPUs and CPUs; making misleading statements to industry participants about the readiness of Intel’s GPUs; and unlawful bundling or tying of Intel’s GPUs with its CPUs resulting in below-cost pricing of relevant products. Although it is not a necessary element in a Section 5 case, because Intel is likely to achieve a monopoly in the relevant GPU markets and has a monopoly in the relevant CPU markets, it is likely to recoup in the future any losses it suffered as a result of selling relevant products at prices below an appropriate measure of cost.

Recently;

http://www.anandtech.com/mb/showdoc.aspx?i=3639&p=3

Your eyes are not deceiving you. After 100+ clean OS installs, countless video card, motherboard, memory and driver combinations, we have results that are not only repeatable, but appear to be valid. We also tracked in-game performance with FRAPS and had similar results. Put simply, unless we have something odd going on with driver optimizations, a BIOS bug, or a glitch in the OS, our NV cards perform better on the AMD platform than they do on the Intel platform. The pattern reverses itself when we utilize the AMD video cards.

And when the Dark Knight arrived :biggrin: ;

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3448&p=12

In any event, the past couple weeks have been more frustrating than usual when testing AMD hardware. We've switched drivers 4 different times in testing, and we still have issues. Yes, 3 of these four drivers have been hotfix beta drivers, but for people with Far Cry 2 the hotfix is all they've got, which is still broken even after three tries.

I was curious why Anand thought AMD was to blame at the time, because AMD drivers worked fine on LGA775 and AM2/AM2+ platform. It'd have been logical to suspect the new chipset (X58). I haven't heard how that issue was resolved since then, but apparently people run AMD video cards fine on X58 today.

 

[Idontcare]

(I'm about to say something that could be construed as political but I am merely using a political example as an easy analogy)

Growing up, my father used to say of Richard Nixon that one of the dumb things about it all (Watergate, etc) was that tricky Dick was basically all but assured he would win the election sans the illegal spying and activities anyways. In other words in hindsight the things he did that ultimately led to his undoing were entirely needless in the first place.

I can't help but view Intel's actions with this same line of thinking. Their market share advantage going back 20yrs all but assured them they would maintain a dominate lead in the personal computer markets so long as they continued to reinvest into developing future products. They did not need to resort to any manner of illegal activities in order for their sheer size and momentum to have led them to higher margins and market share.

If it turns out that they really did do what the allegations claim then it was just pure stupidity on their behalf IMO. Like breaking into the bank and stealing your own money (committing a crime in the process) rather than just waiting until the bank opens at 9am to make a lawful withdrawal.

 

[Viditor]

Well, it pretty much HAS to be #1, #2 would have caught and called out a LONG time ago.

It was indeed #2...and it was caught out a long time ago (it was part of the AMD lawsuit).
To their credit, they have since changed the code...mainly due to AMD's suit I would imagine.

http://www.theregister.co.uk/2005/07/12/amd_vs_intel_code/

 

[piesquared]

Yeah, the only outcome of this can be, should be, and almost undoubtedly will be, is guilty as charged.

 

[nyker96]

i thought amd settled with intel already, they got the 1,25billion in the bank. how can the ftc even make a case without the participation of amd doesn't make much sense to me. however, I do think Intel should pay amd for locking them out of tier 1 oems all these years even during time of pentium 4 vs athlon 64 from which amd clearly has a better product.

 

[Fox5]

Ok, perhaps Intel did participate in non-competitive practices. But really? "Oh noes, your compiler generates code that is optimized for your processor!"

It's not that it produces code optimized for Intel. It's that it specifically detects non-intel processors and produces un-optimized code. Why not just output one binary, regardless of the brand of the cpu (or at the very least, make the binary based on detected extensions, not the brand)? Their compiler goes out of its way to produce unoptimized output.

Of course, Intel's compiler is the fastest compiler for both amd and intel processors. AMD's own compiler initiative is a failure, and Microsoft's compiler is merely ok.
GCC is about the same as Microsoft's iirc, though I think AMD is actively contributing to it now that their compiler is defunct.
When it comes to scheduling SSE instructions, Intel's compiler is worlds apart from GCC and Microsoft's.

Well, it pretty much HAS to be #1, #2 would have caught and called out a LONG time ago. People that use the Intel compiler are generally very concerned with how the code performs, which means you have a LOT of people that are going to be closely monitoring the assembly that is coming out of the ICC. Any attempt to deliberately slow down AMD CPU's would become instantly obvious.

http://terapix.iap.fr/forum/showthread.php?tid=134

It was caught a long time ago. When detecting a non-Intel cpu, the Intel compiler just outputs a binary optimized for some ancient version of x86. As in it throws out 20 years of extensions, and produces a binary that will run on a 586.
Also, I think you'll find that more dev houses use ICC than you might think. When server performance is all about performance per watt, what's a license fee for a compiler against code that will run on thousands of servers?


There was an instance with quake 3 a while back, where it was found the dlls included with it don't enable SSE on an Athlon processor. Granted, quake 3 predates athlons with SSE, but the game did have an SSE code path enabled for Intel cpus. Once the DLLs were recompiled to enable SSE for Athlon XPs, the AXPs started outperforming Pentium 4's in the same way Athlon 64's outperformed P4's in most games (not sure about A64's, but it wasn't uncommon for games to not enable SSE on the Athlon XP). What's my point? I dunno, but I think there's a lesson about using Gentoo in all of that.

 

[Markfw]

"What's my point? I dunno, but I think there's a lesson about using Gentoo in all of that. "

I love that... Now if more software worked on unix/linux, and it was easier to use, I would sure switch over.

 

[Idontcare]

Portland group compilers do a pretty good job.

 

[aigomorla]

So was the senates decision yesterday to deny a bill that would lower drug prices for americans since we are charged 10 times as much as other countries for the exact same drugs.

no i think its because we get 10x more drugs then other countries.

 

[Cogman]

It's not that it produces code optimized for Intel. It's that it specifically detects non-intel processors and produces un-optimized code. Why not just output one binary, regardless of the brand of the cpu (or at the very least, make the binary based on detected extensions, not the brand)? Their compiler goes out of its way to produce unoptimized output.

Of course, Intel's compiler is the fastest compiler for both amd and intel processors. AMD's own compiler initiative is a failure, and Microsoft's compiler is merely ok.
GCC is about the same as Microsoft's iirc, though I think AMD is actively contributing to it now that their compiler is defunct.
When it comes to scheduling SSE instructions, Intel's compiler is worlds apart from GCC and Microsoft's.



http://terapix.iap.fr/forum/showthread.php?tid=134

It was caught a long time ago. When detecting a non-Intel cpu, the Intel compiler just outputs a binary optimized for some ancient version of x86. As in it throws out 20 years of extensions, and produces a binary that will run on a 586.
Also, I think you'll find that more dev houses use ICC than you might think. When server performance is all about performance per watt, what's a license fee for a compiler against code that will run on thousands of servers?


There was an instance with quake 3 a while back, where it was found the dlls included with it don't enable SSE on an Athlon processor. Granted, quake 3 predates athlons with SSE, but the game did have an SSE code path enabled for Intel cpus. Once the DLLs were recompiled to enable SSE for Athlon XPs, the AXPs started outperforming Pentium 4's in the same way Athlon 64's outperformed P4's in most games (not sure about A64's, but it wasn't uncommon for games to not enable SSE on the Athlon XP). What's my point? I dunno, but I think there's a lesson about using Gentoo in all of that.

Guess I stand corrected . My point was, who cares what intel does with their software. It's theirs. Nothing is preventing AMD from writing its own compiler that cripples intels processors.

If intel held a monopoly on x86 compilers, then I might start to think foul play. But they don't, not even close.

 

[VirtualLarry]

There was an instance with quake 3 a while back, where it was found the dlls included with it don't enable SSE on an Athlon processor. Granted, quake 3 predates athlons with SSE, but the game did have an SSE code path enabled for Intel cpus. Once the DLLs were recompiled to enable SSE for Athlon XPs, the AXPs started outperforming Pentium 4's in the same way Athlon 64's outperformed P4's in most games (not sure about A64's, but it wasn't uncommon for games to not enable SSE on the Athlon XP). What's my point? I dunno, but I think there's a lesson about using Gentoo in all of that.

I seem to recall some issue with the same sort of thing with F@H. Intel lended a hand at "optimization", and then, magically, the SSE-optimized binary for Intel, wouldn't run the SSE codepath on AMD CPUs, slowing it down heavily. I don't know if it is still like that or not.

 

[Fox5]

Guess I stand corrected . My point was, who cares what intel does with their software. It's theirs. Nothing is preventing AMD from writing its own compiler that cripples intels processors.

If intel held a monopoly on x86 compilers, then I might start to think foul play. But they don't, not even close.

Perhaps not, but they still have the best compiler, and it is capable of producing the best code for AMD as well. And it's used enough, that if it cripples AMD's chips then Intel gets to control whether AMD is a competitor or a low end alternative. How many performance focused libraries, especially on Windows, will be compiled with ICC? DLLs would be a good candidate.
It's a weird situation. It'd be like if Ford made the roads and their own line of cars. People/companies could build alternative roads, but Ford's roads are already there and probably about the best road you could make, especially for a Ford car. However, when a Toyota car tries to drive on the same road, the road suddenly becomes really bumpy for the Toyota car, significantly lowering its 'performance'. Heck, what Intel's compiler does would be the same as if that road turned into a dirt road when a Toyota car drove on it.
As a Toyota car owner, you'd want to avoid Ford roads. But sometimes a Ford road is the only option, or the best option, and you have to use it anyway. But everyone knows that Toyota cars suck on Ford roads, and there's quite a bit of Ford roads. Ford cars and Toyota cars are about even on all other roads. Even still, the value of a Ford car would be greater, just because of the handicap Toyota cars experience on a Ford road.

I seem to recall some issue with the same sort of thing with F@H. Intel lended a hand at "optimization", and then, magically, the SSE-optimized binary for Intel, wouldn't run the SSE codepath on AMD CPUs, slowing it down heavily. I don't know if it is still like that or not.

They probably just used the Intel compiler and that's one of the things it does. Man, looking at these old processors makes me feel all wispy. The Athlon/Athlon XP was such a floating-point beast back in the days, and now it's pretty anemic, even Atom beats it.

 

[lothar]

It's not that it produces code optimized for Intel. It's that it specifically detects non-intel processors and produces un-optimized code. Why not just output one binary, regardless of the brand of the cpu (or at the very least, make the binary based on detected extensions, not the brand)? Their compiler goes out of its way to produce unoptimized output.

Isn't that the same thing?

Isn't that simply a task of changing it from "If no(AMD/non-Intel), then no(unoptimized code)" to "If yes(Intel), then yes(optimized code)"?

How the the 1st instance different from the 2nd?
I'm neither an engineer nor a computer programmer so I'm trying to understand.

 

[Cogman]

Perhaps not, but they still have the best compiler, and it is capable of producing the best code for AMD as well. And it's used enough, that if it cripples AMD's chips then Intel gets to control whether AMD is a competitor or a low end alternative. How many performance focused libraries, especially on Windows, will be compiled with ICC? DLLs would be a good candidate.
It's a weird situation. It'd be like if Ford made the roads and their own line of cars. People/companies could build alternative roads, but Ford's roads are already there and probably about the best road you could make, especially for a Ford car. However, when a Toyota car tries to drive on the same road, the road suddenly becomes really bumpy for the Toyota car, significantly lowering its 'performance'. Heck, what Intel's compiler does would be the same as if that road turned into a dirt road when a Toyota car drove on it.
As a Toyota car owner, you'd want to avoid Ford roads. But sometimes a Ford road is the only option, or the best option, and you have to use it anyway. But everyone knows that Toyota cars suck on Ford roads, and there's quite a bit of Ford roads. Ford cars and Toyota cars are about even on all other roads. Even still, the value of a Ford car would be greater, just because of the handicap Toyota cars experience on a Ford road.



They probably just used the Intel compiler and that's one of the things it does. Man, looking at these old processors makes me feel all wispy. The Athlon/Athlon XP was such a floating-point beast back in the days, and now it's pretty anemic, even Atom beats it.

The car analogy just doesn't work. MSVC is far more prevalent in the software developing world then intels compiler is.

A better analogy is that Coke sells bottle caps that fit their bottles perfectly, Pepsi figures "Hey, their bottle caps will fit our bottles too!" So they start using coke bottle caps on their bottles. Coke then decides to, somehow, make the bottle caps work well with coke bottles and not so well with pepsi.

Should pepsi sue coke? No, they should make their own bottle caps or buy them from one of the other 1000 companies that make them.

 

[jvroig]

How the the 1st instance different from the 2nd? I'm neither an engineer nor a computer programmer so I'm trying to understand.

1st instance is meant to increase the performance of Intel's chips. The 2nd instance is meant not to increase Intel performance, only to slow down AMD.

So according to the FTC, what Intel did was modify an otherwise good compiler in such a way that competing processors will perform poorly by design.

Like I said in an earlier post, while the end result is the same, the actions really aren't quite the same. I'm wondering why Intel would even bother to sabotage the performance of other processors through the use of CPUID, but that is what the FTC is saying, that their compiler checks if it is an Intel CPU, and if it isn't, it executes a slower chunk of code.

In essence, what the FTC claims Intel did is something like this as I understand:

if(CPUID = Geuniune Intel)
{
    Execute good code path
}
else
{
    Slower code path
}

And what's really damning about it is that the "Slower code path" didn't need to exist (or so says the claim). The "good" code path works equally well for AMD processors as well, and deliberately forcing competing processors to take an unneeded slower code path pissed off the FTC.


That is the FTC's claim. Whether that is true or not, it is beyond myself to declare. I already expressed my opinion earlier that I am inclined not to believe the claim, but I am interested in seeing where the case goes.

 

[lothar]

Okay, but how is that any different from

if(CPUID = Geuniune Intel)
{
    Execute [b][u]accelerated[/u][/b] code path
}
else
{
    [b][u]normal[/u][/b] code path

In their case they're claiming Intel forces AMD and other processors to use a slower code path.
How do we know that Intel isn't forcing it's own processor to use a faster code path rather than slowing down the competition?
If the code is done correctly to detect genuine Intel processors then it shouldn't work on any other processor, right?

If this goes through, I can see Intel releasing a junk(their junk might still end up being faster than others on the market but lets say it's still junk) compiler in the future only to optimize it for their own processor at a later update, or they may choose to only update their compiler code for the Intel line while leaving AMD's stagnant and choosing not to develop them since apparently neither AMD nor Microsoft can do so either.
If Intel releases an SSE4.2 compiler, then decide to add an SSE5 code path at a later date for Intel processors only, how is that anti-competitive?

What if they decide not to allow their compiler to work on AMD and say there are other compilers out there for people to use?

 

[jvroig]

How do we know that Intel isn't forcing it's own processor to use a faster code path rather than slowing down the competition?

We don't, but it has been raised before that it is more "sabotage" than "optimization", and as far as I know has been resolved before. The FTC, on the other hand, thinks otherwise. They seem to be pretty confident they can do this even without AMD on their side. That leads me to think they might just have something big, an ace up their sleeve so to speak.