US FTC Sues Intel For Anti-Competitive Practices 230
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."
Intel (Score:5, Funny)
Re:Intel (Score:5, Interesting)
The thing is they DIDN'T out compete the rest of the market. Intel did many of the same things as Microsoft - ie, strong arming their customers (large corporate customers not individuals) to "encourage" them to sell ONLY Intel chips. Intel may have the edge in performance now but their entire Pentium 4 line was horrendous compared to AMD's offerings (and costed MORE). They still went into almost all computers though because Intel wouldn't let most companies offer AMD chips as an alternative.
Now they've managed to leap-frog back into the performance lead (they're still more expensive overall), but that doesn't mean that they outcompeted anything. Heck I'm fairly certain that had Intel not behaved as they did AMD's increased profits would have manifested into more R&D investment and AMD might would still be in front for performance.
Re: (Score:3, Interesting)
For the sake of argument, AMD also could not make nearly enough chips for everyone - one of the reason being thei cross license agreemtn with Intel prevented them for outsourcing x86 production.
I do agree with your points, though.
Re: (Score:3, Insightful)
AMD is actually in the lead... Intel has no GPU. HAHA
Ya, but at the end of the day, AMD still only has ATI GPUs. Thanks but no thanks. I've been burned far too many times by ATI over the years.
Re: (Score:3, Interesting)
All GPUs are crap.
And, nVidia's GPUs either come unbonded from the package (early 8 series GPUs,) rip themselves in half (the "fixed" 8 series GPUs,) or don't actually exist (Fermi (10 series?) GPUs)
Re: (Score:2)
I still have a perfectly functional Cirrus Logic ISA video card. Y'know, the kind from back in the day when they knew how to reliably build shit to last.
Re: (Score:2)
My understanding is that the GPU teams are much less rigorous than the CPU teams, in terms of design and test. Right now, ATI is becoming much more disciplined than NVidia due to AMD's influence. The GPU guys historically could get away with being sloppy, since it really meant video artifacts and somebody dying in a game. For CPUs, a mistake could cost a lot of money possibly someone dying in reality; as a result, Intel and AMD were much more thorough in there methodologies. Now, with CPU and GPU melding an
Re: (Score:3, Insightful)
Dear God I hope this is true... my laptop just went in for service because the goddamned nVidia GPU was heating up the CPU (they're both connected to the same heatsink) past 80C. Until they become far more reliable it's back to integrated graphics for me (at least on portables).
Re:Intel (Score:4, Insightful)
Re: (Score:3, Insightful)
Intel's compiler is actually one of the best optimizing compilers out there (when it doesn't detect an AMD processor and not bother doing the optimizations...). It's used in a lot of high-performance computing environments.
Re:Intel (Score:4, Interesting)
Well, since it's written and designed by INTEL to optimize code for INTEL processors, I'd say that anyone who thought it was going to do anything to help an AMD processor was, well, shouldn't be programming anyway.
I used the Intel compiler when it came out and then dropped it like a hot potato when it started "optimizing" out lines of code. Like the calculation that it was supposed to be doing. When I reported this problem to Intel, with code snippet, they said "what bug?". Bye bye, Intel, bye bye any reason to use Intel CPUs.
And as I recall, even optimizing out the results only got me a 5% increase in speed.
It's used in a lot of high-performance computing environments.
Our HPC people here use the Portland Group. On AMDs.
Re: (Score:3, Interesting)
Well, since it's written and designed by INTEL to optimize code for INTEL processors, I'd say that anyone who thought it was going to do anything to help an AMD processor was, well, shouldn't be programming anyway.
You mean because any reasonable programmer should have fully expected Intel to be engaged in anti-competitive practices?
Or because it's totally reasonable that when the compiler generates code to pick between, say, SSE2 and x87 codepaths, it would check the SSE2 CPUID feature bit, but then ignore
Re: (Score:2)
No, I mean I don't expect a manufacturer of product A to fully support someone else's products. It's stupid to assume they will, and hardly a major revelation when it turns out they don't.
Or because it's totally reasonable that when the compiler generates code to pick between, say, SSE2 and x87 codepaths, it would check the SSE2 CPUID feature bit, but then ignore it because the manufact
Re: (Score:3, Insightful)
I hope you're not trying to claim everyone's using either gcc or MS Visual C++.
gcc, while free and flexible (and generally "good enough"), is mildly terrible. The output tends to be substantially larger and slightly slower than that from other compiler products, like the Intel compiler mentioned. And as for Visual... I haven't used it in a long time, so I won't comment, other than to say it's not ubiquitous.
I have had high recommendations from some pretty smart people for the Intel compiler, which is why it
Re: (Score:2)
'Slightly slower' is better than 'wrong answer'. I can't remember the last gcc bug I've had to work around to get the right answer. I do remember the helpful Intel compiler optimizing out the calculation that was the reason the program existed in the first place. And the hours it took debugg
Hopefully this will free up Nvidia to compete (Score:5, Interesting)
Re: (Score:3, Interesting)
Here we go again... (Score:3, Insightful)
Re: (Score:2)
Actually, no - the companies pay fines when they are caught. Besides - you don't want to have laws enforced in this country?
AMD was robbed (Score:5, Insightful)
Re: (Score:3, Informative)
Re:AMD was robbed (Score:5, Insightful)
The reputation that AMD earned with the k5 and k6 was appropriate...Intel holding the lead during the time of the Athlon was as much Intels past ability to make a consistantly reliable product as it was any illegal practice.
The compatibility issues on those chips was fewer than the compatibility problems with Intel's own chips. But if there is a problem with an Intel chip, the compiler manufacturers work around it, and the OS vendors emulate the broken instruction or code around it. If AMD has a similar problem, there are press releases and everyone suddenly thinks "oh, I need Intel Inside (r)"
On the flip side, there was a period of a year or two where Intel's 440 motherboards were constantly experiencing compatibility problems. This was around the RDRAM era, which was another blight on Intel. But people continued to buy Intel during that period, even though AMD was winning in reliability AND performance AND price.
There were fishy things happening during that time. Big OEMs making press releases about switching to AMD, then signing-on with Intel for a few years more. Yeah, maybe they were bluffing to get a bargain. Or maybe Intel did back-door dealings with the decision makers.
Re: (Score:2)
The funny thing about the K6's "problems" was that it was never AMD's fault.
But, AMD CPUs were cheaper, and AMD CPUs ended up in budget machines that had cheaper, crappier motherboards with crap chipsets. End result, unreliable machine.
Re: (Score:3, Interesting)
Reality would like a word with you. For AMD to have had 50% or more market share, they would have had to build 50% of the chips being sold. AMD has never had that kind of manafacturing capacity. In fact, one of the reasons why Intel is so successful is they have always invested heavily in their fabrication technology. Sure, Intel manipulated AMD out of sales. But the reason they were in a position to do so, was that AMD couldn't supply the volume of chips with the predictability to satisfy any of the major
Re:AMD was robbed (Score:5, Insightful)
Intel, at the time, had the market share, the fabs and the cash but what they didn't have is a superior product and wouldn't have more several years. If you are Intel what do your do? By any means necessary, your make sure your competitor does not get enough market share or money to threaten your monolopy. If you have the break a few laws in the process, so be it. Limit how much of your competitors chip the computer manufacturers will buy. Illegal but sure. Sell chips below cost. Why not.
Now they are being called to task for their past actions. Not by just the FTC but by Japan, South Korea, the EU. They just settled a lawsuit from AMD for $1.25 billion.
I am not saying that AMD is blameless for their current situation. They could have invested more heavily in fab technology. The purchase of ATI was possibly ill advised. They jury is still out on that one. They slipped up with the release of the Barcelona chip. All I am saying is that given a level playing field, things could have turned out much differently.
Re: (Score:2)
What an uninformed post. AMD did not neglect their fabs. Hell they spent 2.5 billion building a new one in 2003 (Fab 36); and guess what, they still own nearly half of Global Foundries (spinoff) that is building a new fab in NY. They were consistently 6 months or so behind Intel when stepping down to a smaller process, which was faster than anyone else in the industry.
Hmm and I wonder why they would have to sell off their fabs after investing heavily in them, perhaps it is because they were not getting the
Intel's response (Score:4, Informative)
Read the FTC release (Score:5, Insightful)
The FTC press release [ftc.gov] 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).
Re: (Score:2)
Good point on the Atom pricing. I couldn't believe it when I heard about that, it is like Intel is going out of their way to get sued for anti competitive behavior.
Re: (Score:2)
Selling an Atom alone for more than the price of the same Atom bundled with a chipset
This never happened. You're lying and you got modded insightful. Nice job.
Re: (Score:2)
Would you care to provide evidence that Intel never sold an Atom alone for more than the price of the same Atom bundled with a chipset?
There are certainly articles like this one at Reuters [reuters.com] saying it did.
Re: (Score:2)
I don't need evidence, you made an assertion. But here's a hint - a lot of the articles you're referring to had poor wording. Intel sold the Atom chip for $X alone, and for <$X in a 3 chip set. The 3 chip set, however, was still more than X.
See: Here [dailytech.com]
They had to correct the wording, it is actually:
Huang says that Intel sells the Atom chip alone for $45 but within a three-chip set (Atom processor, northbridge, southbridge) sells for only $25.
In other words, Oh Noesies! Intel gives bundle pricing like everyone else in the world!!
For the record, I guess saying you "lied" is a bit strong, I guess misinformed would be more polite but people keep sa
Re: (Score:2)
Ok, given the prices listed here [intel.com], it looks like the un-discounted components of a common 1.6Ghz/945GSE Atom chipset are $44/$26/$13 for the processor/northbridge/southbridge, for a total of $83.
Intel doesn't seem to show bundle discounts anywhere I can find on their public site, so I can only guess at what exactly they are. If only the CPU received any discount at all, the discounted bundle bundle would cost $64, but if we assume the other components are discounted at the same rate needed to bring the Atom
Re: (Score:2)
Unintended consequences... (Score:2)
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 a
Re: (Score:2, Insightful)
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 ma
Won't Change A Thing (Score:4, Insightful)
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.
Not the worst thing Intel has done (Score:2)
Re: (Score:2)
Except they didn't do that, either.
They gave discounts to PC vendors who bought a lot of Intel chips.
They never tied the discounts to the vendors' not using AMD chips.
After getting literally hundreds of millions of pages of documents in deposition and finding no credible evidence (and asking for delays of the trial date to continue requesting documentation), AMD came to that conclusion and accepted Intel's settlement.
Intel's compiler writers didn't want to have to validate their compiler against AMD's parts
Re: (Score:2)
Because failing to optimize it for AMD was not what they did.
Failing to optimize is justified, in that you can not expect to put forth the effort for your competitors.
What they did was put forth effort to explicitly sabotage their competitors. They could have just said "We're not optimizing for AMD" and gone on their merry way. Instead, they added code to make any pro
WTF? (Score:2)
>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..
I tend to avoid both Intel and nVidia (Score:2)
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.
Re: (Score:2)
Well, that's a sample set of 1.
Only 0.599999999 billion more to go before we get a statistical significance as to the world's opinion.
Re: (Score:2)
Re:I especially like.. (Score:5, Informative)
Re: (Score:2)
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.
Re: (Score:2)
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?
Re: (Score:2)
Re: (Score:3, Informative)
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
Interesting, but... (Score:3, Interesting)
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.
Re: (Score:3, Insightful)
Somehow I doubt the FTC gives a rat's ass about what the EULA says.
Re:I especially like.. (Score:5, Informative)
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.
Re:I especially like.. (Score:4, Insightful)
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?
Re:I especially like.. (Score:5, Informative)
Re: (Score:3, Insightful)
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.
Re: (Score:3, Interesting)
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
Re:I especially like.. (Score:4, Insightful)
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.
Re: (Score:3, Insightful)
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 equi
Re: (Score:3, Informative)
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
Re: (Score:3, Informative)
No, as Intel has a dominant share of the market, and is abusing that dominance. That's one of the litmus tests for determining whether or not it is predatory or anti-competitive. Having a monopoly is not a requirement.
Re: (Score:2)
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.
Re: (Score:3, Insightful)
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 appli
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
Re:I especially like.. (Score:5, Insightful)
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.
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:3, Insightful)
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
Re:I especially like.. (Score:5, Insightful)
//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.
Re: (Score:2)
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 tha
Re: (Score:2)
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
Re: (Score:3, Informative)
Re: (Score:2)
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: (Score:2)
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.
Re: (Score:3, Informative)
Re:I especially like.. (Score:5, Informative)
Re: (Score:2)
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 w
Re:EU I can understand... (Score:5, Insightful)
Re: (Score:2)
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 :)
Re:Intel compiler not that good on their own parts (Score:5, Informative)
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.
Re:Well, duh. (Score:4, Informative)
There is no conspiracy; Intel just broke the law. If you are competing with me, you have to follow the law, no matter how much you want me out of the game.
Re: (Score:2)
Personally I'm not a lawyer and I'd really like to know exactly what law it is that Intel broke.
I could understand if Intel had a monopoly in the compiler business. Or if they paid Microsoft to sabotage their compiler on AMD. But they don't, and they didn't.
Re: (Score:2)
It doesn't seem like you know what a monopoly is and why Microsoft got into trouble in the past since this is pretty much the same situation. When you have a significant portion of the market and you utilize anticompetitive practices you get yourself into a lawsuit. This is why Microsoft got into trouble a while back and why Apple hasn't gotten into trouble yet. If Apple had larger marketshare than Microsoft they would be in much hotter water than MS ever was.
If Intel had only done the nasty compiler trick
Re:Well, duh. (Score:5, Informative)
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.
Re: (Score:2, Interesting)
Do you even have any clue how a compiler works?
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.
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.
In defending the liberties of others, you're often forced to side with scum.
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.
So if I design two products (say, iTunes and an iPod) that work well together .. and then a third party comes along and designs something that works with either of them, that's okay and I get that. But if the product
Re:Well, duh. (Score:4, Informative)
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.
Even if it was legal, it'd be a bad idea... (Score:2)
> 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 t
Re: (Score:2)
If there were published standards about how CPUs connect to the mainboard, and if the mainboard's major components were made interoperable (open BIOS, SMC, all that jazz--) that would be unbundling. The bottom line here is that if these parts were interchangable -- so that you didn't have to decide on the CPU first and then the rest of the system, that would be "unbundled". That would be a more fair marketplace than what exists right now.
It used to be this case. AMD K6 processors worked in Intel Pentium
Re: (Score:2)
The ironing, it is delicious.
No there wouldn't.
No they wouldn't.
Re: (Score:2)
That's because they do. If your compiler makes the code use SIMD extensions it'll improve the performance everywhere they're implemented properly. The only sort of optimization that wouldn't work everywhere is stuff that takes into account intimate knowledge of model-specific details, and that's unlikely to work any worse than unoptimized code (and if it does, so what). If
Re: (Score:2)
While it is true that you need to do instruction scheduling to get top notch performance for a given processor, so the code is optimized for the number of functional units, cycle time of each instruction, etc, you should not disable a code path just because the CPU processor vendor name is different from "GenuineIntel". Such optimizations as you cla
Re:Well, duh. (Score:4, Funny)
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.
Re: (Score:3, Insightful)
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
Re:Well, duh. (Score:4, Insightful)
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.
Re: (Score:3, Informative)
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
Re: (Score:2)
No, the difference is that there is a WIDE gulf between what you can do as a normal company and what you can do as a monopoly.
Apple controls roughly 10% of the personal computer market. They hold a monopoly only on computers that they make... which is what ever company holds, and is no monopoly at all.
Intel, on the other hand, took in 80% of the worldwide microprocessor revenue last year. This (arguably- this is part of what the court will have to decide) makes them a monopoly, which would make them subject