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.
There is a difference between not optimising for a competitors processor and deliberately making performance worse for a competitors processor.
Duh, they stated they made a compiler to optimize performance on their chips, and if you jumped through enough hoops, it did -- I got tired of the hoops and quit using it for that reason alone. They made no claims that I recall that their compiler was the best for all x86 parts. If they munged it so it stank in AMD, because of the hardware differences, and didn't put in a switch for AMD, well, who says they had to, and who would have paid for that?
I like intel's parts, but not the company and their practices. Go figure.
This just sounds silly to me, it's not like intel's compiler had a compelling market share or was in general better and easier to use than say, DevStudio or GCC to mention some other extremes. It wasn't even better on their own parts unless you compiled for a very specific one, as I recall.
Their other practices, they can go fry for as far as I care, but I wish AMD was making a more credible push too, despite the impediments intel has put in the way.
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!!
I wonder if this can be proved without a EULA violation of some sort.
Since when does being a Socialist mean 'someone who has a different opinion than me'?
The compiler performed optimizations for x86, which work equally well on their competitors' CPUs. However, the compiler was hard coded to not actually apply optimizations on non-Intel hardware.
Palm trees and 8
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.
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
Abvoiusly both parties (AMD, intel) knew that 'bigger' lawsuit is coming, so they quickly settled for 1.25Bil. Many were surprised why AMD settled for such 'low' amount. After all settlements are done, intel will still have the market share... and much less cash.
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.
This is /.
Where the average reader doesn't get off his chair without his tinfoil hat. And then you still have those who are actually paranoid.
http://blogs.wsj.com/digits/2009/12/16/intel-responds-to-ftc-suit/
Wait, a company that produces microprocessors also designed a compiler optimized to run best on that microprocessor? It's a conspiracy!
These changes -- they improved the performance of the compiled applications when run on the microprocessor it was designed for, correct? Even if they intentionally and "maliciously" modified their compiler so that other microprocessor designs performed more poorly, what does it matter? Shouldn't those other microprocessor companies be releasing compilers for their respective designs as well?
It's not anti-competitive for Intel to tell other microprocessor companies to shove off and build their own. They've got no right to the compiler -- however pervasive its use. At worst, the end-user will see products being released with binaries compiled specifically for their processor architecture (just like Linux does now for kernels and many packages). At worst, the companies will need to invest in designing a compiler (as Intel has done). And if it's cost prohibitive, then maybe they'll look to something that's easy to modify and adapt to their needs, like gcc and its related umbrella of tools.
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!)
#fuckbeta #iamslashdot #dicemustdie
Do you really think Intel's compiler stops supporting every single older chip when they come out with a new one with new instructions? This wouldn't fuck over AMD, it'd just fuck over their compiler business.
i knew you were one of them!
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!
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
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.
I would assume that if Intel used the optimization flags on all products, we'd be reading-
Intel deliberately slows down AMD processors with sabotage code
Different architectures execute even the simplest instructions differently, and there is always an optimal way of performing a task. Intel can't be expected to research that for a competitors product.
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.
It certainly can be argued that Intel was anti-competitive. But then again, there's no reason why AMD couldn't develop their own compilers instead of relying on Intel's.
The irony here is that once the government starts imposing rules that imposes conditions on what a company like Intel can or can't do it has the unintended consequence of making things more onerous for would-be competitors. If someone else wants to compete in this market they're going to be forced to spend a lot more time and money meeting all these requirements. Ultimately you end up in a situation where only those who are already established can thrive, in this particular case that means Intel. Then the government has to step in to prop up a competitor and regulate the monopoly.
I tend to concur, if you look at errors in console games vs. errors in PC games there is a huge difference. A big chunk of this is because console games have 1 hardware configuration to plan for, test on and deploy for. PC games on the other hand have a near limitless number of permutations to deal with in terms of hardware, which is why PC games are dying for the most part. Optimizing cross platform is not an easy thing to do, its doable, but why should Intel have to develop optimizations for AMD? Now, I'm not saying the market is in anyway working properly, personally I think if we developed much stricter standards and dismantled some of these monopolies we would be considerably better off. I think that Intel having 80% mkt share and Microsoft 95% is ridiculous don't get me wrong, but this particular issue I kind of side with Intel on. Aside from this issue I think we would be considerably better off with serious competition to MSFT and Intel, getting them under 50% market share would significantly improve competition and I think regulatory agencies should consider breaking them up.
So are saying that this CPU detection happens during compile-time instead of run-time?
Consider a software company who uses an AMD CPU in their build machines and sells to customers that uses Intel CPUs.
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.
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.
Also Mac OS X is essentially a vendor neutral x86 operating system which has been optimised for Apple hardware.
Except when Apple does it, the law backs up their right to prevent anyone running the OS on non-Apple hardware; when Intel does it, _and_ offers at least scant support for non-Intel CPUs, they're punished for not offering MORE support.
Intel's solution should be to rewrite their EULA to prevent people using their compiler on non-Intel CPUs. And call it the "Apple clause". And aggressively pursue the infinitesimal proportion of people who support use of Intel's compiler to target non-Intel CPUs.
i knew you were one of them.
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.
...to continue to do as they wish, buy whichever politician they want, file their taxes wherever they want, destroy whichever companies they want, push dangerous software out as they wish...hmm...yeah...yet another reason there is fading credibility in the entire US system...(a government FOR the company BY the company!)
YankDownUnder Veni, Vidi, volo in domum redire
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.
Assuming that you're correct, this is a most revealing insight and explains much.
That said - if that's all that there is to it, then I'm glad I'm not an Intel lawyer having to explain that in lay terms.
Pathological kinda promises Path + Logical - but instead, you get stuck with pathetic.
I decided a few months ago to boycott nVidia and Intel because of their questionable business ethics, and because of their product naming schemes. My life is so much easier now when researching new builds for sucktomers. Heck , I won't even buy a mobo with an Intel chipset. I know my dollars won't make a difference, but if everyone did it, hooboy...
You are an idiot.
What Intel did is sabotage.
If you cannot understand this, you are too stupid for words.
One interesting charge that has already arisen: that Intel systematically changed its widely used compiler to stunt the performance of competing processors. If you're giving a compiler away for free to leverage processor sales, why would you bother to optimize it for your competitor's processors? Intel's giving discounts to PC vendors that agree not to use AMD is much more anticompetitive!
I've abandoned my search for truth; now I'm just looking for some useful delusions.
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.
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.
But Intel does have a legal obligation to not cripple the product when detecting competing processors.
Please cite relevant statutory or case law to show this.
AMD may use their own compiler, but what if the maker of a very popular benchmark used Intel's compiler? Reviewers would use that benchmark to test various CPUs and would see that AMD CPUs are slower. This would get published and less people would buy AMD CPUs (since the reviewers say they suck).
How many times have you relied on a benchmark done by a reviewer to decide which video card or CPU to buy?
>>The official hearing is set for September of 2010 but we will likely here news filtering out about the evidence and charges >>well before that.
Hmmm, it's "we will likely HEAR news...."
>One interesting charge that has already arisen: that Intel systematically changed its widely used compiler to stunt the performance of competing processors. I have to say, if I build a compiler, for myself and someone else uses it for themselves. I do not have to worry about them, seeing as I built it for me. If they offer it for free, then they have no responsibility to keep it friendly to anyone but themselves.
Seriously, in this case I hope Intel wins, because they have the right to do what they did....although price fixing is another issue altogether.
cpuid
I rest my case.
Oooh, AMD Fanboi get angry! Grrr! Nerd rage!
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.
I'd say the majority of corporate cases brought are about upholding the law. It's the ones that get dropped that you have to worry about :)
With the exception of my EEE, which I don't really get a choice, I always go with AMD. I've never had issues with them, they're cheaper and quite frankly I'll never forgive Intel for introducing such shitty video cards into the PC market.
I opt for ATI because it's supporting AMD but more importantly I was very impressed with my laptop's graphics card. I've had the laptop for sometime and it still performs well. It's the best video card I've had in a laptop by far.
Does the current Intel C++ compiler (11.1) still cripple the binaries, where it generates separate code paths and uses one of them depending if a CPU is Intel or AMD? I could not find a definitive answer while searching Google.
//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.
The obligation is that they sell their compiler as a general purpose compiler for all x86 processors. Nowhere in their documentation does it say that it will not optimize code for non-Intel processors. It does, however, specify features (such as SSE2) that it can optimize for. AMD parts do support SSE2.
I say, yes. There is a big difference.
It's a case of simple dishonesty. Intel put more effort into making their compiler perform poorly on non-Intel platforms. They spent extra resources resources to make it happen. Suppose Microsoft decided to modify their products to perform slower on any hardware that was branded by Apple? It wouldn't affect most users, just the ones who also presumably bought a competitive OS (OS X). If they purchased Office for OS X, Microsoft could claim, "Oh that's because you're running it on a Mac, Macs don't perform as well with Office applications."
Simply: It's bad faith. You're spending your time trying to hurt your competition, and not trying to make a better product. That's the simple definition of anti-competitive.
Intel put more effort into making their compiler perform poorly on non-Intel platforms
Actually, no, they didn't.
if (intelCPU) {optimize}
else {use default x86 ISA}
It's that simple. They detect if the CPU is theirs, then enable their optimizations, otherwise they don't so as to maintain the best compatibility with:
AMD
VIA
Transmetta
Virtual x86 on Power
etc.
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
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.
They don't have to track anything. Try reading /proc/cpuinfo on a linux box some time. The CPU tells you exactly what it does and doesn't support. Phenom II's support SSE4a (a smaller set containing some of the same things you find on sse4.1 from Intel.) SSE5 is actually being developed by AMD, not Intel, and will put the advantage of total instructions back to AMD.
As a whole this argument is focused incorrectly. Intel isn't primarily harming AMD, they're harming AMD and Intel customers; AMD customers because their processors with technology licensed from Intel don't perform according to spec, Intel customers because they have to pay more for the same technology. This is the real reason that an out of court settlement isn't enough, the FTC is doing the right thing by pursuing consumers rights.
"And we have seen and do testify that the Father sent the Son to be the Savior of the World"
1 John 4:14
Comment removed based on user account deletion
How accurate/useful/specific are the feature flags though?
"In April 2005, AMD introduced a subset of SSE3 in revision E (Venice and San Diego) of their Athlon 64 CPUs."
"AMD currently only supports 4 instructions from the SSE4 instruction set, but have also added two new SSE instructions that is named SSE4a."
(And no, I didn't change wikipedia.)
What do the flags say here? Yay or nay? Do they go into specific instructions?
Seems like some CPUs only support subsets of features, limiting how useful the flags are for determining what kind of optimizations the compiler can make. Kinda promotes using the lowest common denominator approach for chips you don't control.
What Intel did is sabotage.
What did Intel sabotage? Its own product?
Breakfast served all day!
Eh, just look at the things Microsoft did to DRDOS. Or anyone else, for that matter. When there are few competitors, you can't deliberately sabotage the competition. Its anti-competitive, monopolistic behavior.
An astute observer may note that this isn't that far from what video game consoles do. Or the Iphone. Or Itunes. I'm not sure I know the difference between these cases. Perhaps this is due to my imaginary law degree, but I prefer to blame it on the dragons.
Well.. maybe. Or Maybe not. But Definitely not sort of.
GCC and PGI have support for AMD processors. AMD often used these compilers for benchmark result submissions in the past. But the Intel C++ compiler is often faster at doing benchmark results since it has more advanced static optimization support.
In the latter case, there is a deliberate effort to expend resources with the intention of harming your competitor.
I don't see that as being entirely clear. We're talking about an Intel compiler. AMD is free to write its own compiler; it chooses not to (to my knowledge). As I said before, Intel might be in a monopoly position in the chip market, but it does not have a monopoly on compilers. People who want their code to run on AMD CPUs could choose to compile their software with GCC, LLVM, MS C++, OpenWatcom, or whatever else might be out there.
You say Intel's compiler is sabotaging AMD. I could just as easily argue that Intel has sabotaged its own compiler. If customers bothered to test, they could just as easily say, "Hmm! When I compile with the Intel compilers, my binaries run like crap on AMD CPUs! Intel's compiler sucks."
Suppose Microsoft wrote a piece of software that ran on any x86 CPU, but it did a special check to see whether you were running Mac OS X. If it detected a Mac, the software would exit -- even though it otherwise could run. Jerk move? Sure. But should it be illegal?
Breakfast served all day!
Intel's compiler generates both "SSE2+ optimized" floating point code and "plain vanilla, slow" floating point code. Then at run-time, it uses the CPUID instruction to detect whether your CPU was manufactured by "Genu-ineI-ntel". If it is, then it jumps to the fast code (at run time). If it isn't, it jumps to the slow code.
This was proved a couple of years ago by reverse-engineering of the generated code. Patching out the check, so that all machines use the fast code, gives vastly improved floating point performance on AMD's chips--often better than on Intel's own chips! The obvious purpose of this "feature" (and the effect it actually has in practice) was to make Intel's CPU look good and make AMD's CPU look bad. Intel's excuse for doing this (which was basically "our competitors might not implement our custom instruction sets 100% perfectly, so its not safe to use them unless its definitely our chip") does not even pass the laugh test. The whole thing was a blatant anti-competitive measure to try and make AMD and other competitors look bad on benchmarks.
I hope the FTC really takes them to the cleaners over that, and all of their other slimy business practices. Sure we love to rail against Microsoft, but MS is definitely not the only dirty player in tech town.
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.
> 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.
Be that as it may, their intent was clear. They could have done it the normal way, but they went out of their way to make a crappier product. And, frankly, if I catch anyone pulling crap like this (sabotaging their own products in the name of "competition"), I go out of my way to harm their business by any legal means possible. Granted, there's not much I can do against a giant company like Intel, but I'll still try. And I can hold a grudge like that for quite a while, unless they do an about-face. And even though I can only do so much, I don't think I'm the only person who does this.
In other words, even if you think that businesses can or should be able to do this, make damn sure you don't pull crap like this yourself. Because if enough customers like me find out, we can and will try to drive you out of business. Heck, I go one further. I'll shaft even the businesses of those who think it's their right to do something like this, because I believe that they would feed me intentionally crippled products given the opportunity.
And, incidentally, it's not their "right" anyhow. Read chapter 15 of the US Code, in particular the section Intel is accused of violating, per the FTC complaint.
That AC below has it exactly right: "The accusation is that the compiler probed to see if the CPU was AMD based and if it was it stopped all optimizations, not for user safety or reliability but just to fuck over AMD."
AMD essentially dumped SSE5 for Intel AVX. There are a couple of new instructions in there, but that's basically what happened.
"Atheism is clearly a religion, or at least a religion-like movement, for some value of religion and for some subset of atheists"
OK... so did you have a point hidden in that wall of off-topic text? I sure as hell couldn't find it.
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.
No, it does it at run time. AMD specifically made a code patch utility that changed the binary to circumvent this Intel compiler 'feature'.
Okay, so you suggest that every software company release mutliple builds for platforms differing in name only.
if SSE3:
use it
elif SSE2:
use it
elif SSE:
use it
el
crappy codepath here
is a lot different than...
if GENUINE_INTEL:
test for sse
else
sucks to be you
Michael J. Ryan - tracker1.info
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
Wouldn't this only apply if Intel had a monopoly on compilers?
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.
Optimizing cross platform is not an easy thing to do, its doable, but why should Intel have to develop optimizations for AMD?
Right, but if a CPU supports a given optimization that Intel already has and uses, it is wrong to simply disable that optimization solely because the CPU is not an Intel chip. That is what is happening.
No, I don't trust in god. He'll have to pay up front, like everybody else.
A dominant share of the compiler market or processor market?
That's really what I was getting at, not monopoly status.
The compiler favors Intel CPUs. There are other compilers out there that don't, I imagine. gcc is pretty popular, etc.
The issue raised above was whether Intel had an obligation to not cripple their product, and EndlessNameless responded with the anti-trust act. In this case, the product is not a CPU, but a compiler. I'm asking, does the anti-trust act apply to this issue, when there are plenty of competing compiler products out there.
So what's your point? From how I understand it, the first one is what Intel did. But even if it was the second one, I don't see how it's "a lot different." And even if we agree for argument's sake that is is a lot different, I don't see why it should be against the law, any more than it should be against the law for mechanics to refuse to work on Fords.
Breakfast served all day!
This affects the CPU market, where it is pretty much accepted that Intel has a dominant position. If you can't see how a compiler can affect a CPU's performance, then you may be on the wrong website.
The point is that this is ONE ASPECT of Intel's anti-competitive practices, all of which were focused on controlling the CPU marketplace.
No, I don't trust in god. He'll have to pay up front, like everybody else.
"Intel® Professional Edition Compilers include advanced optimization features, multithreading capabilities, and support for Intel® processors and compatible processors. They also provide highly optimized performance libraries for creating multithreaded applications."
Taken directly from http://software.intel.com/en-us/intel-compilers/.
The difference is MS would be saying "We don't support OS X", and actively enforcing it. Intel are saying that their compiler does work for AMD processors, without any mention of the fact that they put time and money into actively making it worse for AMD processors (instead of just not doing anything to improve performance specifically for them)
Straw-man argument. Of course the compiler can affect CPU performance. The point I was trying to make is that I agree with HarrySquatter's comments above - as far as I know, Intel is not forcing people to use their compiler.
Any other practices by Intel, anti-competitive or otherwise, don't apply to this particular chain of comments.
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.
Intel's compiler is not just used by Intel. Because of Intel's dominant position in the hardware market, and the intimate knowledge of said hardware, their compiler is pretty good for 80% of the CPUs out there. Because of the resources at their disposal, the same compiler is good for the other 20% of CPUs as well. Software vendors use the compiler to compile executables. Software vendors have little to zero interest in shipping multiple binaries to support CPUs that should be binary compatible . So, they will ship binaries that perform better on Intel's hardware regardless of the fact that some of AMDs hardware can run the software as well if not better. This is anticompetitive because until AMD achieves parity with Intel in install base, then vendors have an incentive to use Intel's broken compiler because in the short term, it delivers a better outcome for most customers, but in the long term, it cripples competition and customers suffer.
No, not its own product. It's sabotaging the software that other vendors create to not run as fast on AMD CPUs thus making them seem slower than they really are, and discouraging customer from buying them, or forcing AMD to sell them at lower prices, which hurts AMD unfairly. If Intel can't play fair, they should get out of the compiler business, because the compiler are used to run compile software that run on both companies' CPUs, and so they have to play fair.
So, what they're saying is that Intel's compiler produces better code on Intel chips? And that GCC still does not care? And that billions of dollars are going to get spent, ultimately, not to improve compiler performance?
Hell, let's all sue SGI! MIPSpro CC won't produce any code AT ALL unless you run it on a Silicon Graphics machine. It's a travesty - where's the justice?
The first one is not what Intel did.
"His name was James Damore."
This isnt all of it really. Sure, they ignored the feature flags.. but they also intentionally did not do other far more general optimizations, such as eliminating dead and/or redundant code.
"His name was James Damore."
The ZDNet article on this claims that ICC inserted null loops for non-Intel processors.
Put identity in the browser.
When Intel uses its compiler to benchmark the competition, it becomes sabotage.
Put identity in the browser.
I skipped nVidia's cards recently because of questionable power consumption
No, it causes the the Intel part to excel in performance, it does not cripple the AMD part. There is a difference (if I build a faster race car, I'm not "falsely causing public race results to show my competitive cars as slower"). Seriously, why should Intel optimize for AMD parts?
1. It cost Intel to develop, test and support features. Why on Earth would you expect them to pay millions to help their competition?
2. AMD does not give Intell all of their datasheets, design files, access to developers, etc to help with the effort.
3. If Intel reverse engineered AMD parts and put that in the compiler, they'd get hit for doing that. Why bother?
4. Intel made some decisions in their design to make things easier for their compiler, AMD made different decisions which Intel may not like nor care about figuring out how to use
I guess the only error Intel made was to allow AMD processors at all. It should be Intel compiler only - lots of companies develop software only for their own hardware; Apple for example not only specifically blocks OS X from running on non-Apple hardware, but they will sue your pants off if you figure out a workaround. Courts recently upheld Apple's right to do so. Intel should follow suit and slap such a license agreement on their compiler, then anyone who uses it on AMD processor should be happy they're not being sued.
BTW, AMD releases libraries optimized for their new processors, should they get sued by the FTC?
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.
If this is the case, then what I can't understand is why AMD hasn't made a huge public fuss about it in the past. Surely it would have been trivial for their engineers to discover this problem and make it widely known, yet it never came up before today!
You didn't count in the validation effort. For advanced compiler optimization, because of its complexity in algorithm, it is not just as simple as turn on the optimization switch. One has to do full validation of all test suites for the target platform if you don't want to see some surprising results. That means it is not free for Intel compiler to support AMD CPUs. You can expect Intel to argue that they turned off some optimizations since they didn't have resource to test them for competitor's product.
"...Suppose Microsoft wrote a piece of software that ran on any x86 CPU, but it did a special check to see whether you were running Mac OS X. If it detected a Mac, the software would exit -- even though it otherwise could run. Jerk move? Sure. But should it be illegal?..."
Isn't this why you can't install OSX on a "PC" computer? Doesn't the OS look for some little code that says "I'm REAL Mac hardware" or it doesn't install.
Why would this behavior be legal in this case?
I don't understand why you couldn't have found this all by yourself
That's what you get when engaging with a Brand X Fanb0!y.
Didn't Intel invent SSE?
The new right fascists are bilingual. They speak English and Bullshit.
Oh noes! Those terrible EU socialists is attacking our brave American companies again!
Oh, wait...
Or simply you've never heard about it before today.
One that hath name thou can not otter
OK, so point me to resources that discuss this issue prior to the FTC announcement
Slashdot (use search box)
One that hath name thou can not otter
The accusation against Intel is not that they did the first example or even the second. More like:
if GENUINE_INTEL
do best_optimization_routine
else
do slopppiest_working_code_routine
The problem was that the non-Intel "optimizations" were actually worse than completely unoptimized code. If you faked the CPUID, the optimized "Intel" binary would still run perfectly fine on an AMD processor (with a substantial performance boost). And vice versa---the shitty "AMD" binary would run flawlessly yet more slowly on an Intel processor than unoptimized binary.
Care to do better, you made the claim that this was public before the FTC announcement, so show me something.
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.
That was a very good informative reply, but please try to tone down the attitude. Searching law is not "basic research" and you don't need to make people feel angry or stupid for not knowing it. This is a very intelligent discussion so no need for insults.
google: site:slashdot.org intel amd compiler
First result. 2005. Not the only story throughout the years which touched on this of course.
PS. And it was you who made the claim - that this was something new. Without actually spending less than 1 minute to verify your impression. So I'm confused; your UID says otherwise, but you act like you discovered the internet this month.
One that hath name thou can not otter
All I was asking for was a link, thanks for providing it.
That was a very good informative reply, but please try to tone down the attitude. Searching law is not "basic research" and you don't need to make people feel angry or stupid for not knowing it.
With all due respect, while you may be true in general, there's no excuse for an American to not know about the Sherman Act; he shouldn't even need to search the law to remember about its existence, or applicability to this case (or any other involving monopoly abuse)!
1) How do you know he is an American?
2) Assuming he is an American, I agree that everyone should know about it. But that is not a valid reason to insult someone. It closes people's minds, rather than opening them.
Ummm, the SSE5 instruction was AMD's extension not Intel's. After SSE4, the next Intel instruction set is AES, CLMUL, FMA3, and AVX. After AVX came out, the SSE5 instructions were changed to XOP (integer vector), FMA4 (fused multiply/add using the SSE5 format instead of the Intel FMA3 format), and CVT16 instructions (conversion to/from 16-bit floating point). http://en.wikipedia.org/wiki/SSE5 http://en.wikipedia.org/wiki/Advanced_Vector_Extensions
That may be true, I don't know as I don't have the source to the compiler.
But even if true, and even if it went so far as to actually take the absolute most conservative code path when not on an Intel CPU, it is the Intel Compiler, I would not expect it to run at all on a competing architecture. The point of the compiler is *not* for general purpose computing, the purpose is for highly optimized code on an Intel machine. If you want a GP compiler use Visual Studio or GCC...
I think the whole thing is a red herring. Furthermore it's funny that this suit, brought basically at behest of a company who does most of their manufacturing overseas is against a company that does tons of manufacturing inside the USA...
So much for the Obamma administration stimulating jobs for Americans.
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
Microsoft have been caught doing this very thing. Back in the days of DR-DOS they engineered the windows installer so that it would crash if it detected DR-DOS and report a misleading error message. IIRC DR actually won a lawsuit over this but it dragged on so long that the product was obsolete by the time it was resolved.
DR won the lawsuit because that behaviour is, in fact, illegal.