Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
The Courts Intel United States News

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."
This discussion has been archived. No new comments can be posted.

US FTC Sues Intel For Anti-Competitive Practices

Comments Filter:
  • by Apple Acolyte ( 517892 ) on Wednesday December 16, 2009 @02:35PM (#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?
  • Re:Intel (Score:5, Interesting)

    by MBGMorden ( 803437 ) on Wednesday December 16, 2009 @02:41PM (#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 (Score:3, Interesting)

    by obarthelemy ( 160321 ) on Wednesday December 16, 2009 @02:53PM (#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.

  • by WiiVault ( 1039946 ) on Wednesday December 16, 2009 @03:25PM (#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.
  • Re:Intel (Score:1, Interesting)

    by Anonymous Coward on Wednesday December 16, 2009 @03:31PM (#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.

  • Interesting, but... (Score:3, Interesting)

    by tjstork ( 137384 ) <todd.bandrowsky@ ... Wcom minus berry> on Wednesday December 16, 2009 @03:31PM (#30462110) Homepage Journal

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

    by jpmorgan ( 517966 ) on Wednesday December 16, 2009 @03:41PM (#30462320) Homepage

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

    by Obfuscant ( 592200 ) on Wednesday December 16, 2009 @03:54PM (#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:Well, duh. (Score:2, Interesting)

    by girlintraining ( 1395911 ) on Wednesday December 16, 2009 @03:56PM (#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:Intel (Score:3, Interesting)

    by Chris Burke ( 6130 ) on Wednesday December 16, 2009 @06:49PM (#30465786) Homepage

    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 it because the manufacturer ID doesn't say Intel and use the x87 codepath even though the processor supports SSE2?

    I mean, we're not talking about some minutia of optimization for some specific part of P4 microarchitecture or something, like load ordering to avoid stlf pitfalls or accounting for bank sizes in the L1 caches. We're talking about two codepaths, one of which is faster on every architecture that supports them, and deliberately choosing the slower one even though the processor supports the faster one.

    It's not a matter of "optimizing for Intel", it's a matter of "deliberately de-optimizing anything but Intel". Any programmer would think de-optimizing competitor's parts is the same as optimizing your own parts? The compiler would have "helped" AMD parts, had it simply not gone out of its way not to.

    So yeah, I'm going with the first explanation. I mean, you are right that everyone should have already known this. Anyone in the computing industry who has been paying attention for the last couple decades knows Intel has been engaging in anti-competitive practices.

    It's just sad that now that finally authorities are taking notice, so many are coming out of the woodwork to defend them.

  • Re:Intel (Score:3, Interesting)

    by bhtooefr ( 649901 ) <bhtooefr&bhtooefr,org> on Wednesday December 16, 2009 @06:59PM (#30465966) Homepage Journal

    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)

  • by Chris Burke ( 6130 ) on Wednesday December 16, 2009 @07:21PM (#30466288) Homepage

    This changes things in a more fundamental way. If I'm understanding you correctly, this isn't a matter of Intel not supporting a feature, but purposely crippling a feature even after detecting that the chip would support it.

    Yes, you understand exactly correctly. You could even hack binaries compiled with ICC so that they would skip the check for "GenuineIntel", so that it would only see that SSE3 (or whatever) was supported and use that codepath, and it would not only run correctly but also much faster on AMD platforms than without the hack.

    Intel also does more subtle things. For example if there are multiple ways to code up some routine which perform equally well on Intel's parts, but one of them hits a divot in some AMD microarchitecture, they would use that one. Their math library has spit out some really weird code before, and the only explanation for its organization is that it hurts AMD. That's a lot harder to prove intent for in any particular case, since it could plausibly and in any particular case actually fall into the category of "happy coincidence".

    The CPUID feature bit stuff though is blatant.

Always try to do things in chronological order; it's less confusing that way.

Working...