Slashdot Mirror
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."
Our competitive practices aren't like your competitive practices.
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.
Athiesm is a religion like not collecting stamps is a hobby.
Hopefully this will free up Nvidia to continue innovating in the integrated GPU arena. Intel's best attempt at competing against the year-old 9400M apparently only matches half of its performance at best. And wasn't Intel actively preventing Nvidia from competing for inclusion in the newest motherboard designs by failing to license certain Core iX chipset components?
Part of the hardcore faithful who believed in Apple long before it was cool again to do so
... for better or worse, right or wrong. Here's another N-year legal donnybrook for us to enjoy.
Generally, bash is superior to python in those environments where python is not installed.
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.
VLC FOR MAC IS DYING! IF YOU DEVELOP, PLEASE SAVE IT!!
Somehow I doubt the FTC gives a rat's ass about what the EULA says.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
Have you considered the possibility that some legal actions are actually about upholding the law, rather than some sinister ulterior motive?
Back when AMD's microprocessors were the state of the art (Athlon), they should have had 50% or more of the chip market. Intel only was able to preserve its market share through illegal means. Eventually, through the billions in extra profit they made, they were able to pull ahead in this technology race. AMD was deprived of billions is profit which they could have used for more R&D to make their chips more competitive today. I don't know how you restore a market where one player has been cheating illegally for a decade and now has a monolopy, but Good Luck FTC.
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.
Generally yes, but the intel compiler really shines by optimizing for the newer instructions that competitors may or may not have yet. SSSE3 (not to be confused with SSE3), SSE4, SSE5, etc are only found on newer intel chips. Not to mention the ones that AMD adds too (3DNow, CVT16, etc) or the differences between comparable instructions and registers (AMD-V/VT-X, AMD64/EM64T, etc). The x86 ISA as a "standard" is quite a mess.
Should we expect intel to track competitors' features for each target platform?
Sigs are for losers
There are some differences(3Dnow! is AMD only, SSE isn't present on some AMD chips, and a whole bunch of other minutia).
Thing is, though, chips declare which features they support: "flags: fpu vme de pse tsc msr pae..." and who made them "vendor_id: GenuineIntel/AuthenticAMD". Intel's compiler, though, was ignoring the feature flags if the vendor_id was not "GenuineIntel". It would be silly to demand that intel support 3Dnow! or any other AMD-specific oddities, or demand that it ensure that the binaries it produces are equally well optimized for the precise architectural details of AMD's CPUs.
Blatantly ignoring the feature flags on non-intel CPUs, though, is another matter.
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.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
http://blogs.wsj.com/digits/2009/12/16/intel-responds-to-ftc-suit/
There is a difference between not optimising for a competitors processor and deliberately making performance worse for a competitors processor.
Is there? No seriously, is there?
In a sense, everything that I do that gives me competitive advantage impacts my competitors' businesses negatively. Like the earlier commenter said, why is it incumbent upon Intel to write a compiler that works equally well on their competitors' products?
Not disclosing that it doesn't work as well on Intel's competitors' products may be a sneaky trick, but it seems like there should be due diligence on the part of the people using the compiler. Intel does not have a monopoly on compilers. Last I heard, people use Intel compilers because they produce very good code. Cry me a river if Intel would like to produce good code for Intel processors and not others.
Don't get me wrong: I think Intel is being sneaky and underhanded. But I don't see it having done anything illegal, and I don't see how anything it has done should be illegal.
Breakfast served all day!
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.
Palm trees and 8
There is no conspiracy: This is business. Business is inherently anti-competitive. If I'm competing with you, I want you out of the game, and just like in a video game, I will use combo attacks and drop-kick you right as you get up (repeatedly) to keep you from recovering until you throw the controller at me. That's just how the game is played. (See slashdot, we can avoid car analogies!)
Let's make the car analogy... In Indy car racing, you are not allowed to smash into your opponent over and over again until his car is a smoking pile of metal and then run him over as he leaves the flaming wreckage. This is against the rules.
There are rules in business just as in car racing. Intel broke them. Now they have to face the music.
The FTC press release says:
That sounds like a pretty direct strike against Intel's moves in the graphics market lately. Selling an Atom alone for more than the price of the same Atom bundled with a chipset, trying to prevent Nvidia from making chipsets for their Nehalem CPUs, bundling their own GPU on the package of all of their low to mid range next generation CPUs, etc...
It should be interesting to see how Intel responds to this. It's probably too late to make any major changes to Clarkdale/Arrandale before they ship, so on-package GPUs are definitely coming. But imagine if Intel were required to sell bare dice at fair prices (surprisingly enough, packaging a die is one of the most expensive steps of chipmaking), so that others could do the same thing. Imagine an intel chip with an on-package Nvidia or AMD GPU...
Sometimes I wonder if computers will always be built around motherboards as we know them. As motherboards shrink, and we start seeing multiple dice on a single package even in low end consumer gear, could the motherboard eventually be replaced with one big multi-die package? It would certainly reduce size and bring part counts down, and I expect it would allow for lower power consumption and higher speeds as well (although, of course, it would make building your own as an enthusiast impractical).
"The worst tyrannies were the ones where a governance required its own logic on every embedded node." - Vernor Vinge
Which is why there is regulation to keep the sociopathic asshats that run major corporations in line, so they compete like they're supposed to.
Yes, but if you cut the cord for my controller in the middle of the match, I'm going to be quite rightfully pissed. There are rules as to what you can and cannot do within the game, and breaking these rules through unethical means is not going to win you any friends. And in the game of business, you're going to get a lot worse than people getting angry at you if you get caught.
And most fighting games won't let you just constantly knock someone down while they're getting up like that, because trivial and unbreakable infinite combos may be fun while you're the one on top, but they ruin it for everyone else. Your analogy seems to have been even more apt than you had considered.
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.
Athiesm is a religion like not collecting stamps is a hobby.
A lot of benchmarks out there actually used the gcc compiler, so Intel's shenaningans in this regard are somewhat irrelevant.
The most damning anti-AMD benchmarks are the scientific benchmarks based on some variants of STREAM. There, they just get killed by the Nehalems ability to issue more instructions per tick and also the ability to use faster memory. Professional "deciders" know this, and flocked to Nehalem. It's just the hot part right now.
This is my sig.
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?
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.
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.
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.
Like all US Government actions against large technology companies, this won't change a thing. There will be a dog and pony show for the public, followed by a relatively small bribe...err...fine, and business as usual for Intel.
This won't change a thing.
The end result of your philosophy is a society where one or two mafia-like power structures control everything, and everyone else is essentially slaves. Whether those power structures are national governments or corporations the dynamic is much the same. Granted that appears to be what a lot of people want. Preservation of a free society requires limitations on the abuse of power. The FTC part of that mechanism.
I write software that may be run on either Intel and AMD processors, so I need a compiler that works for both. If Intel wants to be in both the compiler business and the microprocessor business, they can't intentionally design their compiler to sabotage AMDs microprocessor business. If there are no limits on that sort of thing, then inevitably one company gets a near monopoly, uses its position to screw over everyone, and everything stagnates and we get poorer. This dynamic is why many impoverished parts of the world are impoverished. To the extent that we embrace that model, our economies will wind up in the toilet also.
They don't. But Intel does have a legal obligation to not cripple the product when detecting competing processors. The issue isn't that the compiler didn't know the capabilities of the other chips. It is that they intentionally ignored those capability bits and checked the manufacturer name instead.
While it is true that increased regulations are often a barrier to entry, thereby decreasing competition, that has nothing to do with this case.
The FTC is not adding a new rule, they are enforcing an old one. And that rule can be summarized as: do not deliberately defraud your consumers in one market to make the competition look bad in another market (in this case, market one: compilers, market 2: CPUs).
Any company that cannot stay within that rule will also not be capable of providing a benefit to the market.
Changa hates change.
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
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.
If they intentionally and maliciously change it for no purpose but to prevent their competitor's product working with it, yes.
"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.
"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.
Thank you. I was not getting the point of this, as the arguments that Intel doesn't have to support AMD's features was simply making more sense. From the initial posts it sounded like Intel simply wasn't supporting features that were untested on AMD chips.
This changes things in a more fundamental way. If I'm understanding you correctly, this isn't a matter of Intel not supporting a feature, but purposely crippling a feature even after detecting that the chip would support it.
//Is there? No seriously, is there?//
Yes, there is quite a difference between not optimizing for your competitor's product and deliberately degrading performance for your competitor's product.
In the former case, there is no additional effort involved; there is a simple decision not to expend resources where they will not provide a return on the investment.
In the latter case, there is a deliberate effort to expend resources with the intention of harming your competitor. And while anti-competitive behaviour may be an unfortunate norm in American business, it is also an illegal behaviour for a company in a monopoly position.
Having hopefully clarified your sloppy manner of thinking (lest others accept it), we can agree your question was deliberately inflammatory and move on.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
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.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
No it was much worse than that. There is a CPU instruction named CPUID 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.
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.
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.
Michael J. Ryan - tracker1.info
This changes things in a more fundamental way. If I'm understanding you correctly, this isn't a matter of Intel not supporting a feature, but purposely crippling a feature even after detecting that the chip would support it.
Yes, you understand exactly correctly. You could even hack binaries compiled with ICC so that they would skip the check for "GenuineIntel", so that it would only see that SSE3 (or whatever) was supported and use that codepath, and it would not only run correctly but also much faster on AMD platforms than without the hack.
Intel also does more subtle things. For example if there are multiple ways to code up some routine which perform equally well on Intel's parts, but one of them hits a divot in some AMD microarchitecture, they would use that one. Their math library has spit out some really weird code before, and the only explanation for its organization is that it hurts AMD. That's a lot harder to prove intent for in any particular case, since it could plausibly and in any particular case actually fall into the category of "happy coincidence".
The CPUID feature bit stuff though is blatant.
The enemies of Democracy are
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.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
So basically, Intel made an extra effort to ensure that the compiler would work worse with competitor's CPUs. The code to check the supported extensions was already in the compiler and AMD's chips respond in a compliant manner to indicate which ones they support.
If the AMD chip was changed only in that it would respond that it is a GenuineINTEL, code compiled on Intel's compiler would produce a significant improvement in performance. While AMD is far from perfect, their CPUs are price competitive with equivalent Intel chips. If it weren't for AMD, we would still be paying >$1000 for a Pentium 4. That's why I generally avoid buying Intel chips - they're the top dog, yet they don't play fair.
No, I don't trust in god. He'll have to pay up front, like everybody else.
The first one is not what Intel did.
"His name was James Damore."
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.
That's a good point. I've never used the Intel compiler myself, and really, I would expect Intel to do something jerky like this any time I used a vendor-specific tool.
However, at GDC 2008, Intel had a big display where they were going on about their compilers and how well they optimized things. Apparently they have tools that can analyze the code and generate multithreaded code (sounded like OpenMP, kinda) and SIMD instructions (SSE, SSE2, etc.). They unambiguously claimed that those optimizations applied to both Intel and AMD processors. They went out of their way to assure people that they weren't doing this. So it is really funny to find out that they are. I hope they do the presentation again next year and so I can ask their engineers some very pointed questions about this. It sounds like they were flat-out lying.