Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

US FTC Sues Intel For Anti-Competitive Practices

timothy posted more than 4 years ago | from the in-the-interim-please-use-the-ftc-compiler dept.

The Courts 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."

cancel ×

230 comments

Sorry! There are no comments related to the filter you selected.

I especially like.. (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30461074)

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...

Re:I especially like.. (5, Informative)

InsaneProcessor (869563) | more than 4 years ago | (#30461162)

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

Re:I especially like.. (1)

228e2 (934443) | more than 4 years ago | (#30461302)

I wonder if this can be proved without a EULA violation of some sort.

Re:I especially like.. (2, Insightful)

MBGMorden (803437) | more than 4 years ago | (#30461344)

Somehow I doubt the FTC gives a rat's ass about what the EULA says.

Re:I especially like.. (-1, Redundant)

gujo-odori (473191) | more than 4 years ago | (#30461644)

The poster above you said there's a difference between optimizing for your own but not the competitor's and deliberately sabotaging performance. You say there's not. Let's you and him fight :-)

Seriously, though, I don't see this as a problem. For starters, as some people have noted, not many are using Intel's compiler. The two most widely used compilers for x86 chips are Microsoft's and GCC. Secondly, why should they have to optimize their compiler for a competitor's product, really? Rather, it should be assumed by anyone and everyone that a benchmark made using an Intel product is going to do better on Intel chips, and it doesn't even require nefarious behavior on Intel's part to make that leap. Is it not a matter of course that they are going to be able to better optimize a compiler for a chip they made than a chip they didn't? And why doesn't AMD release its own compiler?

Slewing off-topic, when was the last time you met someone who didn't collect stamps who was vehemently and adamantly opposed to others doing so? Concrete example: has anyone ever sued to:

1) Prevent a kid from talking about his stamp collection at school?
2) Prevent a teacher from talking about stamp collecting at school?
3) Prevent a teacher from discussing her stamp collection in school?
4) A government agency (such as the post office, maybe) from displaying information about stamp collecting?
5) I think you get the idea.

Atheism is not technically a religion, since under the normal definition of religion, a belief in some deity is required. However, atheism is certainly a movement, and one that has some very religion-like qualities to it. I know that most atheists (at least in my direct experience) are live-and-let-live people who don't care or mind that others have religion, talk about it, or seek to advance it. You'd never even know they were atheists unless it happened to come up. However, there is a subset of atheists for whom it pretty much is a religion, or perhaps, an anti-religion. For them, there is no tolerance. Religion must be suppressed and removed from public discourse, and those who have a religion other than militant atheism must be drive into the closet.

How does a non-religious atheist behave? I'll take a good friend of mine as an example. His religious upbringing was at least very strongly agnostic, and I'd say atheist. I've heard him say on a number of occasions that he doesn't believe in God or an afterlife, and when you die, that's it. Yet he married a Christian and their kids are baptized. His wife has a free hand to raise the children in her faith. He doesn't usually attend church with her, but does on special occasions like Easter or Christmas, even though he doesn't believe, and he is respectful when he is there, and of her belief at all times so far as I can tell. Contrast that to, say, the behavior of Madeleine Murray O'Hare.

Atheism is clearly a religion, or at least a religion-like movement, for some value of religion and for some subset of atheists, much as Windows or Linux/Windows or Mac OS/PC or Mac hardware bears a strong resemblance to religion for some advocates of those platforms. To deny this is to ignore the facts on the ground, at best, and to practice sophistry or outright falsehood at worst.

Re:I especially like.. (1)

NSIM (953498) | more than 4 years ago | (#30462012)

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:I especially like.. (1)

Pentium100 (1240090) | more than 4 years ago | (#30463090)

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?

Interesting, but... (2, Interesting)

tjstork (137384) | more than 4 years ago | (#30462110)

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:I especially like.. (1, Informative)

Anonymous Coward | more than 4 years ago | (#30462818)

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

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

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

Re:I especially like.. (1)

Kryis (947024) | more than 4 years ago | (#30461234)

There is a difference between not optimising for a competitors processor and deliberately making performance worse for a competitors processor.

Re:I especially like.. (2, Insightful)

PCM2 (4486) | more than 4 years ago | (#30461630)

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.

Re:I especially like.. (0, Troll)

Dog-Cow (21281) | more than 4 years ago | (#30462672)

You are an idiot.

What Intel did is sabotage.

If you cannot understand this, you are too stupid for words.

Re:I especially like.. (0)

Anonymous Coward | more than 4 years ago | (#30463464)

Oooh, AMD Fanboi get angry! Grrr! Nerd rage!

Re:I especially like.. (4, Insightful)

EndlessNameless (673105) | more than 4 years ago | (#30464030)

//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:I especially like.. (4, Informative)

plasmacutter (901737) | more than 4 years ago | (#30461244)

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.. (3, Insightful)

Cornelius the Great (555189) | more than 4 years ago | (#30461472)

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.. (0)

Anonymous Coward | more than 4 years ago | (#30461578)

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.

Re:I especially like.. (1)

Chees0rz (1194661) | more than 4 years ago | (#30461914)

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.

Re:I especially like.. (5, Informative)

InsaneProcessor (869563) | more than 4 years ago | (#30461946)

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

Re:I especially like.. (-1)

HarrySquatter (1698416) | more than 4 years ago | (#30462556)

And? What obligation does Intel have under the law to make their compiler work optimally with a competitor's product?

Re:I especially like.. (3, Insightful)

MobyDisk (75490) | more than 4 years ago | (#30462682)

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:I especially like.. (1)

HarrySquatter (1698416) | more than 4 years ago | (#30463034)

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.

Re:I especially like.. (2, Insightful)

DJRumpy (1345787) | more than 4 years ago | (#30463510)

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:I especially like.. (1)

earlymon (1116185) | more than 4 years ago | (#30462222)

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:I especially like.. (0)

Anonymous Coward | more than 4 years ago | (#30463460)

cpuid

I rest my case.

Re:I especially like.. (4, Insightful)

fuzzyfuzzyfungus (1223518) | more than 4 years ago | (#30461490)

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.

Re:I especially like.. (1)

jocabergs (1688456) | more than 4 years ago | (#30461976)

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.

Re:I especially like.. (0)

Anonymous Coward | more than 4 years ago | (#30462008)

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.

Re:I especially like.. (1)

betterunixthanunix (980855) | more than 4 years ago | (#30461330)

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.

Intel (4, Funny)

ArbitraryDescriptor (1257752) | more than 4 years ago | (#30461116)

Our competitive practices aren't like your competitive practices.

Re:Intel (0, Troll)

gandhi_2 (1108023) | more than 4 years ago | (#30461158)

They out-competed the rest of the market, and for their sins they must be punished.

that Intel systematically changed its widely used compiler to stunt the performance of competing processors.

so what? and who is using intel's compiler? *cricket... *cricket...

Re:Intel (4, Interesting)

MBGMorden (803437) | more than 4 years ago | (#30461312)

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:Intel (2, Interesting)

obarthelemy (160321) | more than 4 years ago | (#30461478)

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:Intel (0)

Anonymous Coward | more than 4 years ago | (#30463332)

I wonder if HP will be dragged into this. They colluded with Intel to gobble up Compaq who had the rights to the DEC alpha line of processors. This removed one competitor against the Itanium, which was jointly developed by Intel and HP. Shame, the alpha was such a good processor Intel used to use it in there factory product tracking servers.

Re:Intel (4, Insightful)

will3477 (705414) | more than 4 years ago | (#30461348)

You may not be using intel's compiler, but in the scientific community I knew people who wear by it and those same people spend a lot of money on hardware (adding hundreds of nodes to clusters annually).

Re:Intel (2, Insightful)

caerwyn (38056) | more than 4 years ago | (#30461374)

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 (-1, Troll)

larry bagina (561269) | more than 4 years ago | (#30461456)

AMD (or anyone else) can write their own compiler. Or contribute code to gcc or llvm.

Re:Intel (1, Interesting)

Anonymous Coward | more than 4 years ago | (#30462096)

*cough* sabotaging *cough*
Intel got no reason nor legal needs to make it optimize for AMD, BUT making sure AMD cpu's get skullfucked automatically when using Intel compile is quite wrong and bad. And its x86, there is litteraly no difference on the 2 CPU brand big enough to justifiy it skullfucking the non-Intel CPUs. Heck, it should optmize quite fine!
The easiest way to prove it would be to make a AMD cpu spoff Intel, then compare the 2 compiled results. And that is what has been done. It can be only called sabotage.

Re:Intel (3, Interesting)

Obfuscant (592200) | more than 4 years ago | (#30462602)

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...).

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:Intel (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30461380)

Nice pair of lips to reach the free markets cock from there.

Re:Intel (2, Insightful)

idontgno (624372) | more than 4 years ago | (#30461920)

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's a criminal shame they chose to try to cripple the execution speed of code compiled for their binary-compatible competitor.

Re:Intel (1)

Obfuscant (592200) | more than 4 years ago | (#30462896)

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.

'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 debugging to isolate the problem.

Putting in printfs to debug steps and having the code work is usually the sign of a programmer failure to allocate sufficient memory for something. In this case it changed the number of ops in the execution pipeline or prevented pipeline branch optimization -- a purely compiler issue.

And I remember what Intel said when I reported it. "What bug?"

I have had high recommendations from some pretty smart people for the Intel compiler, which is why it's a criminal shame they chose to try to cripple the execution speed of code compiled for their binary-compatible competitor.

Binary compatible does not mean hardware identical, and the Intel compiler is so CPU-specific that it cannot be doing just binary optimization, it has to be using intimate knowledge of the hardware as well. To expect Intel to support that level of hardware specificity for AMD is silly.

Hopefully this will free up Nvidia to compete (5, Interesting)

Apple Acolyte (517892) | more than 4 years ago | (#30461184)

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?

Serves Nvidia right (1, Informative)

Anonymous Coward | more than 4 years ago | (#30461332)

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

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

Re:Hopefully this will free up Nvidia to compete (2, Interesting)

WiiVault (1039946) | more than 4 years ago | (#30461972)

Yes, and this whole suit bodes well for Apple and other companies who need cheap and integrated, but can't deal with the shitfest we know as Intel Integrated. As you said 9400M while still being low-end is quite capable for most uses, even some light gaming. The though of seeing a move back to Intel graphics in the Macbooks is enough to make me ill. Almost as bad as when they dumped PPC and with it the Radeon 9250(?) on Mini and iBook and replaced it with an Intel 950- that was a bloodbath. I remember working at a major electronics store around 2002 and having the Intel rep always tell me how they were just on the cusp of a really bad ass integrated chipset that would blow away ATI and Nvidia. Well random Itel rep, we're still waiting.

Here we go again... (2, Insightful)

kclittle (625128) | more than 4 years ago | (#30461220)

... for better or worse, right or wrong. Here's another N-year legal donnybrook for us to enjoy.

Re:Here we go again... (0)

Anonymous Coward | more than 4 years ago | (#30461814)

...and worst of all: who do you think pays for these mega-million dollar legal circuses? YOU and ME.

Re:Here we go again... (0)

Anonymous Coward | more than 4 years ago | (#30462804)

I think the FTC just pooped in its pants. Seriously, there is no way they have a solid case on this. NO WAY. I just hear more tax payer money going to ridiculously overpriced trials with nothing to show on the other end of the donkey... not even a few digested corns.

Intel compiler not that good on their own parts (0)

Anonymous Coward | more than 4 years ago | (#30461240)

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.

Re:Intel compiler not that good on their own parts (4, Informative)

MBGMorden (803437) | more than 4 years ago | (#30461508)

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.

EU I can understand... (-1, Troll)

gandhi_2 (1108023) | more than 4 years ago | (#30461280)

The EU thing is just a protectionism tax...that I can understand. But this?

The company keeps their revenue positive, even though the global economy is only now seemingly recovering from the disaster of the past 12 months.

We gotta put a stop to that shit right now!

Re:EU I can understand... (5, Insightful)

fuzzyfuzzyfungus (1223518) | more than 4 years ago | (#30461376)

Have you considered the possibility that some legal actions are actually about upholding the law, rather than some sinister ulterior motive?

Re:EU I can understand... (0)

Anonymous Coward | more than 4 years ago | (#30461536)

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.

Re:EU I can understand... (0)

Anonymous Coward | more than 4 years ago | (#30461604)

i knew you were one of them!

Re:EU I can understand... (0)

Anonymous Coward | more than 4 years ago | (#30462068)

i knew you were one of them.

Re:EU I can understand... (1)

mdarksbane (587589) | more than 4 years ago | (#30463540)

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 :)

AMD got good deal then (0)

postmortem (906676) | more than 4 years ago | (#30461362)

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.

AMD was robbed (5, Insightful)

byteherder (722785) | more than 4 years ago | (#30461406)

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.

Re:AMD was robbed (2, Informative)

0racle (667029) | more than 4 years ago | (#30461868)

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

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

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

Re:AMD was robbed (4, Insightful)

MobyDisk (75490) | more than 4 years ago | (#30462874)

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:AMD was robbed (2, Interesting)

jpmorgan (517966) | more than 4 years ago | (#30462320)

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 vendors. Regardless how good AMD's chips were in comparison to Intel's at the time, the major OEMs were still beholden to Intel. Intel was king for the simple fact that there was nobody else big enough to wear the crown.

AMD invested heavily in chip design in the 90s. They brought in a lot smart guys who worked on the Alpha, which heavily influenced the K8. And they were doing well at the time. They did have some market segments sewn up. When they really failed, was when Intel pushed them into a price war. AMD couldn't keep up with Intel's aggressive pricing because they simply could not produce competitive chips as inexpensively as Intel could. And while I don't intend to absolve Intel of any wrongdoing in their part, I would like to put it in perspective... compared to the rest of the industry, AMD neglected their fabs. It wasn't market manipulation that ended their profitability, it was falling yields. Why do you think they eventually spun off Global Foundries?

Yeah, maybe had they made more money they would have been able to invest more heavily in their weak areas. But it's not like they demonstrated any interest in doing so at the time; it's not like credit and tech investment was hard to come by back then. It all seems a bit like 'speculative history' fiction. What would have happened if the Nazis hadn't put jet research on hold at the beginning of the second world war?! That's a very interesting question. But they did.

Re:AMD was robbed (5, Insightful)

byteherder (722785) | more than 4 years ago | (#30463392)

Is there some speculation in my orginal post. Sure. But remember, this was era when AMD market share was rising very rapidly, >+1% per month. Would they have run out of manufacturing capacity at some point. Possibly. Could they have build more. Sure, if they had the money. But that is exacty the point. Intel made sure they would never get the market share to get the money needed to compete. Never.

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.

Well, duh. (1, Insightful)

girlintraining (1395911) | more than 4 years ago | (#30461560)

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!)

Re:Well, duh. (3, Informative)

betterunixthanunix (980855) | more than 4 years ago | (#30461638)

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

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

Re:Well, duh. (0, Troll)

girlintraining (1395911) | more than 4 years ago | (#30461784)

The optimizations would have worked, and Intel had the compiler deliberately not apply them.

So Intel should be required to test out their competitors products for compatibility with these optimizations, as well as its own products? Should Microsoft be required to design Windows so that it's compatible with Norton Antivirus -- or is it the other way around? This compiler was designed by Intel, for Intel. That's the bottom line: If they don't want to support other microprocessors, why should they be compelled to? There's no guarantee that these optimizations won't fail in future versions of their competitors products in ways that can't be anticipated -- due to the fact that their microprocessors are black boxes to Intel.

I'm not defending Intel here -- for all I know, it could have been entirely motivated by greed. But that's not the issue here -- the issue is whether Intel is allowed control over its own products. I think the FTC is overstepping its boundaries. They allowed Intel to become the dominant player in the market despite inferior designs because when they were needed most, they looked the other way because the economy was doing well and the FTC was viewed as a nuisance by congress and so had little to no power. Now that the economy's tanked and Congress has (reluctantly) given them the authority to make needed changes, they're a player again. But they're making the wrong decisions, even if they're making them for the right reasons.

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

Re:Well, duh. (4, Informative)

Virak (897071) | more than 4 years ago | (#30462164)

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

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

I'm not defending Intel here

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

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

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

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

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

Re:Well, duh. (1, Interesting)

girlintraining (1395911) | more than 4 years ago | (#30462640)

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 is then changed so the third party's products no longer work, that's always bad? It's always anticompetitive? What you're suggesting here is that not "harming the competition" is more important than a company's right to design its products to be as beneficial to use together as possible. If the company signed a legal contract stating that the third party's products would be supported, then yes -- I'd say it's illegal. But if the third party never entered into any kind of agreement, then the other is free to do whatever they damn well want with their own products.

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.

You're oversimplifying the issue, and then calling me an idiot? The use of generalizations does not imply that the author's understanding of the subject matter is limited. And no, they're very bundled -- I can't use an AMD processor with an Intel chipset. Motherboards are designed around the CPUs -- and while the peripherals (memory, expansion cards, etc.) may have standardized interfaces, the guts of the system does not.

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

Now I am not getting into any more technical detail than this, because it's pointless dick-waving. We're here to debate an issue that has absolutely nothing to do with the technology!

Re:Well, duh. (0)

Anonymous Coward | more than 4 years ago | (#30463168)

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

If it is done solely to break compatibility with a 3rd party product then definitely, if it is done primarily then probably.

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

No that's not what he's suggesting at all, what hes suggesting is that "harming the competition", just for the sake of harming the competition is anti competitive.

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.

Re:Well, duh. (0)

Anonymous Coward | more than 4 years ago | (#30463386)

Wait a second...

"I can't use an AMD processor with an Intel chipset"

If you're saying Intel shouldn't support their optimizations on AMD then why in hell should AMD support an Intel chipset like you're advocating?

You're picking and choosing now.

Re:Well, duh. (3, Informative)

Virak (897071) | more than 4 years ago | (#30463400)

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

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

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

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

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

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

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

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

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

Re:Well, duh. (0, Flamebait)

RightSaidFred99 (874576) | more than 4 years ago | (#30463626)

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?

Wow, you don't know much about, well, anything do you? If Intel just released a compiler with optimizations that may or may not work on AMD there would be hell to pay. Intel would have to thoroughly validate their compiler against AMD products.

Who's the clueless one, again? "Durr, can't they just release a compiler with optimizations targetted for a processor without thoroughly validating that said optimizations work on said processor?". Jesus Christ dude, really? Are you that stupid? Supporting (yes, even enabling support for) AMD chips would have cost Intel time and money, and not inconsiderable amounts of either. No one in their right mind will dictate that Intel should spend money giving AMD a free fucking compiler.

Re:Well, duh. (1)

Virak (897071) | more than 4 years ago | (#30463908)

Wow, you don't know much about, well, anything do you?

The ironing, it is delicious.

If Intel just released a compiler with optimizations that may or may not work on AMD there would be hell to pay.

No there wouldn't.

Intel would have to thoroughly validate their compiler against AMD products.

No they wouldn't.

Who's the clueless one, again? "Durr, can't they just release a compiler with optimizations targetted for a processor without thoroughly validating that said optimizations work on said processor?". Jesus Christ dude, really? Are you that stupid?

When did I say anything about including AMD-specific optimizations? What I said is that they shouldn't specifically disable the optimizations for AMD chips, which work fine on AMD chips.

Supporting (yes, even enabling support for) AMD chips would have cost Intel time and money, and not inconsiderable amounts of either.

It would have cost them nothing because it would already work by default. They already have to check the completely standard and implemented by AMD CPUID feature flags to see if their own chips support the features in question.

No one in their right mind will dictate that Intel should spend money giving AMD a free fucking compiler.

What a wondrous coincidence this is then, for it is that no one is making such demands and you're just a whiny asshole who fails reading comprehension.

Re:Well, duh. (0)

Anonymous Coward | more than 4 years ago | (#30461950)

It's actually more evil than that. CPU detection happens at runtime, not at compile-time - and if you're not running the program on an intel cpu then you get the least optimized codepath. So you have one binary (say, for instance, of a known benchmark) which runs significantly faster on intel than it does on amd ... but speeds up considerably on amd once you apply a tiny patch to the cpu detection routine.

Re:Well, duh. (1)

jpmorgan (517966) | more than 4 years ago | (#30462396)

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:Well, duh. (0)

Anonymous Coward | more than 4 years ago | (#30462482)

Intel compiler (ICC) is designed by Intel to get the best performance optimization for Intel HW. That's the benefit Intel offer to its customer. ICC is not free and nothing stop software developer/company use other compilers. In fact most of Windows applications are compiled using Microsoft Compiler while on *nix world, it's GNU C/C++ compiler. ICC is only being used on those quite specific applications which need the performance.

Regarding the optimization, to be fair with Intel, the compiler has to detect the CPU features (ex: sse4,..) & models in other to do the *hard-core* optimization. No, the optimizations would could things become broken if not tested carefully and properly. And even though AMD & Intel share the large number of IA32/x64 instructions set, there are alot of AMD or Intel only instruction/implementation (ex: VTx vs SVM, cache mechanism, .. ). If you check Intel optimization guides and AMD optimization guides, you will see many different things. So, in fact, the compile should maintain a list of CPU profiles to know which optimization profile it should use for a particular processor. For each of the release, they should do the testing for those profiles to make sure it's working as expected. Nothing wrong here if they don't spend their time and money to work and test their optimization sets on AMD processors (hence ICC just detect the unsupported/un-tested processors and disable some of those optimizations). You should check ICC manuals in which states quit clearly what kind of optimization it supports on which processors.

Re:Well, duh. (0, Flamebait)

RightSaidFred99 (874576) | more than 4 years ago | (#30463588)

You are such a liar. They did not break any law. Find me any law dictating compiler design. Please.

These regulations are up for interpretation by whoever is in power at the time. Right now we have European style socialists in power, so they're choosing to interpret the regulations in their favor.

As for your laughable argument about the compiler, do you think any company is going to release a compiler and optimizations for their competitor? You do understand, unlike most of these facile idiots, that Intel would need to test the compiler on AMD products, right? Seriously - what kind of buffoon thinks Intel can just optimize for their own processors and just say "Well, we'll hope it works on AMD chips too - here you go!". No. They would need to invest time and considerable resources.

Any "regulation" which requires that a company purchase, develop for, and spend time validating their product on a competitor's product is just laughable.

Re:Well, duh. (4, Funny)

byteherder (722785) | more than 4 years ago | (#30461710)

There is no conspiracy: This is business. Business is inherently anti-competitive. If I'm competing with you, I want you out of the game, and just like in a video game, I will use combo attacks and drop-kick you right as you get up (repeatedly) to keep you from recovering until you throw the controller at me. That's just how the game is played. (See slashdot, we can avoid car analogies!)

Let's make the car analogy... In Indy car racing, you are not allowed to smash into your opponent over and over again until his car is a smoking pile of metal and then run him over as he leaves the flaming wreckage. This is against the rules.

There are rules in business just as in car racing. Intel broke them. Now they have to face the music.

Re:Well, duh. (2, Insightful)

Virak (897071) | more than 4 years ago | (#30461870)

There is no conspiracy: This is business. Business is inherently anti-competitive.

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.

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.

Yes, but if you cut the cord for my controller in the middle of the match, I'm going to be quite rightfully pissed. There are rules as to what you can and cannot do within the game, and breaking these rules through unethical means is not going to win you any friends. And in the game of business, you're going to get a lot worse than people getting angry at you if you get caught.

And most fighting games won't let you just constantly knock someone down while they're getting up like that, because trivial and unbreakable infinite combos may be fun while you're the one on top, but they ruin it for everyone else. Your analogy seems to have been even more apt than you had considered.

Re:Well, duh. (3, Insightful)

shadowofwind (1209890) | more than 4 years ago | (#30462506)

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:Well, duh. (1)

pigeon768 (589860) | more than 4 years ago | (#30463102)

Wait, a company that produces microprocessors also designed a compiler optimized to run best on that microprocessor? It's a conspiracy!

The issue isn't that they designed a compiler that optimizes their processors better, it's that they designed their compiler to run the same code worse on AMD architectures.

A program compiled with ICC will (when you start the program) read the CPUID - if the CPUID contains the string "GenuineIntel" it executes one code path, if it contains "AuthenticAMD" it executes a different one. (This is in addition to necessary checks for things like the CPU flags saying it has support for CMOV, MMX, SSE, SSE2, SSE3, etc.)

The problem is that if you edit the executable in your favorite hex editor and swap the two strings, it will run 10-50% faster on AMD CPUs and 9-33% slower on Intel CPUs. The strings are the same length, so you don't even need to change any offsets or anything. (google for the exact procedure. it's possible I left out a step) It's a completely artificial check that serves no purpose other than to produce code which runs slowly on AMD CPUs.

Re:Well, duh. (2, Informative)

Brian Stretch (5304) | more than 4 years ago | (#30463166)

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

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

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

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

Read the FTC release (4, Insightful)

RalphBNumbers (655475) | more than 4 years ago | (#30461734)

The FTC press release [ftc.gov] says:

"To remedy the anticompetitive damage alleged in the complaint, the FTC is seeking an order which includes provisions that would prevent Intel from using threats, bundled prices, or other offers to encourage exclusive deals, hamper competition, or unfairly manipulate the prices of its CPU or GPU chips

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:Read the FTC release (1)

modemboy (233342) | more than 4 years ago | (#30461982)

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:Read the FTC release (1)

RightSaidFred99 (874576) | more than 4 years ago | (#30463652)

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.

Unintended consequences... (1)

MaWeiTao (908546) | more than 4 years ago | (#30461974)

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.

Re:Unintended consequences... (0)

Anonymous Coward | more than 4 years ago | (#30462350)

So you are basically saying "let Intel do whatever they want. Unfair competition or not." You can't let business run roughshod over competitors, it screws it for all of us when they are free to do whatever they want. In the end there would be only 1 CPU supplier. You always wanted to pay 100x the price you pay now for a CPU right?

Re:Unintended consequences... (2, Insightful)

Changa_MC (827317) | more than 4 years ago | (#30462716)

While it is true that increased regulations are often a barrier to entry, thereby decreasing competition, that has nothing to do with this case.

The FTC is not adding a new rule, they are enforcing an old one. And that rule can be summarized as: do not deliberately defraud your consumers in one market to make the competition look bad in another market (in this case, market one: compilers, market 2: CPUs).

Any company that cannot stay within that rule will also not be capable of providing a benefit to the market.

also Mac OS X (0)

Anonymous Coward | more than 4 years ago | (#30462044)

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.

Re:also Mac OS X (1)

mdarksbane (587589) | more than 4 years ago | (#30463468)

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 to an entire different set of laws. These laws have been on the books for about 100 years, by the way, and are well known to all companies involved.

By the way, these laws exist entirely to protect the ability of the free market to function efficiently. When one player has enough power to not just out-compete all comers, but to actively sabotage them, there is very little that consumer choice can do about it.

This is why, for example, there have been rumors of lawsuits against Apple on antitrust grounds in the mp3 player market, but even there they only hold a 42% marketshare - hardly a monopoly.

Re:also Mac OS X (1)

Zenzilla (793153) | more than 4 years ago | (#30463806)

But intel doesn't want this. By doing this intel would be telling every software company that if they use an intel compiler they must ignore 20% of the market. It will be very little time before a new compiler is used that can compile for all x86 again.

US FTC happily sues Intel, but allows Microsoft... (1)

YankDownUnder (872956) | more than 4 years ago | (#30462160)

...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!)

Won't Change A Thing (3, Insightful)

StormReaver (59959) | more than 4 years ago | (#30462192)

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.

AMD/ATI FTW (1)

Keep Six (1697340) | more than 4 years ago | (#30462250)

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...

e4. (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#30462416)

another special and sold in the win out; either the Whether you a nned to play Lay down paper The failure of guests. Some people

Not the worst thing Intel has done (1)

Locke2005 (849178) | more than 4 years ago | (#30462676)

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!

HEAR (0)

Anonymous Coward | more than 4 years ago | (#30463206)

>>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...."

WTF? (1)

hesaigo999ca (786966) | more than 4 years ago | (#30463280)

>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.

I tend to avoid both Intel and nVidia (1)

thetoadwarrior (1268702) | more than 4 years ago | (#30463744)

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.

Current Intel C++ compiler question (1)

st3v (805783) | more than 4 years ago | (#30463842)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?