US FTC Sues Intel For Anti-Competitive Practices

Vigile writes "And here Intel was about to get out of 2009 with only a modestly embarrassing year. While Intel and AMD settled their own antitrust and patent lawsuits in November, the FTC didn't think that was good enough and has decided to sue Intel for anti-competitive practices. While the suits in Europe and in the US civil courts have hurt Intel's pocketbook and its reputation, the FTC lawsuit could very likely be the most damaging towards the company's ability to practice business as they see fit. The official hearing is set for September of 2010 but we will likely hear news filtering out about the evidence and charges well before that. One interesting charge that has already arisen: that Intel systematically changed its widely-used compiler to stunt the performance of competing processors."

Comments

I especially like..

[Anonymous Coward]

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

[InsaneProcessor]

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

[Kryis]

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

Re:I especially like..

[plasmacutter]

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

[228e2]

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

Re:I especially like..

[betterunixthanunix]

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.

Re:I especially like..

[MBGMorden]

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

Re:I especially like..

[Cornelius the Great]

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

[fuzzyfuzzyfungus]

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

[Anonymous Coward]

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

[PCM2]

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

[gujo-odori]

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

[Chees0rz]

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

[InsaneProcessor]

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

[jocabergs]

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

[Anonymous Coward]

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

[NSIM]

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

[earlymon]

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

[HarrySquatter]

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

Re:I especially like..

[Dog-Cow]

You are an idiot.

What Intel did is sabotage.

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

Re:I especially like..

[MobyDisk]

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

[Anonymous Coward]

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

[HarrySquatter]

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

[Pentium100]

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

[Anonymous Coward]

cpuid

I rest my case.

Re:I especially like..

[Anonymous Coward]

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

Re:I especially like..

[DJRumpy]

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

[EndlessNameless]

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

[Anonymous Coward]

The obligation is that they sell their compiler as a general purpose compiler for all x86 processors. Nowhere in their documentation does it say that it will not optimize code for non-Intel processors. It does, however, specify features (such as SSE2) that it can optimize for. AMD parts do support SSE2.

Re:I especially like..

[lorenlal]

I say, yes. There is a big difference.

It's a case of simple dishonesty. Intel put more effort into making their compiler perform poorly on non-Intel platforms. They spent extra resources resources to make it happen. Suppose Microsoft decided to modify their products to perform slower on any hardware that was branded by Apple? It wouldn't affect most users, just the ones who also presumably bought a competitive OS (OS X). If they purchased Office for OS X, Microsoft could claim, "Oh that's because you're running it on a Mac, Macs don't perform as well with Office applications."

Simply: It's bad faith. You're spending your time trying to hurt your competition, and not trying to make a better product. That's the simple definition of anti-competitive.

Re:I especially like..

[networkBoy]

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

[EndlessNameless]

I'll oblige since you're apparently unable to do basic research yourself.

The relevant section of law is 15 U.S.C. 1-7. The law was known as the Sherman Antitrust Act prior to its incorporation into the U.S.C.

A deliberate attempt to remove competition by a potential monopoly is considered a violation of the law per the Supreme Court's decision in Spectrum Sports, Inc. v. McQuillan.

Three criteria were established for determining if behaviour constitutes attempted monopolization: (1) predatory/anticompetitive behavior, (2) intent to monopolize, and (3) a reasonable chance of becoming a monopoly.

Unless you're a dolt, crippling the compiler product in the presence of competing processors is obviously predatory or anticompetitive in nature. While you can argue the other two criteria, I doubt anyone will seriously believe Intel doesn't want to be the only game in town or Intel has no chance of becoming a consumer CPU monopoly.

Thus, should it be demonstrated that Intel crippled their compiler for AMD processors, they are in violation of federal law. I don't understand why you couldn't have found this all by yourself; this is not new law by any stretch of the imagination.

Re:I especially like..

[Penguinoflight]

They don't have to track anything. Try reading /proc/cpuinfo on a linux box some time. The CPU tells you exactly what it does and doesn't support. Phenom II's support SSE4a (a smaller set containing some of the same things you find on sse4.1 from Intel.) SSE5 is actually being developed by AMD, not Intel, and will put the advantage of total instructions back to AMD.

As a whole this argument is focused incorrectly. Intel isn't primarily harming AMD, they're harming AMD and Intel customers; AMD customers because their processors with technology licensed from Intel don't perform according to spec, Intel customers because they have to pay more for the same technology. This is the real reason that an out of court settlement isn't enough, the FTC is doing the right thing by pursuing consumers rights.

Re:I especially like..

[Anonymous Coward]

How accurate/useful/specific are the feature flags though?

"In April 2005, AMD introduced a subset of SSE3 in revision E (Venice and San Diego) of their Athlon 64 CPUs."

"AMD currently only supports 4 instructions from the SSE4 instruction set, but have also added two new SSE instructions that is named SSE4a."

(And no, I didn't change wikipedia.)

What do the flags say here? Yay or nay? Do they go into specific instructions?

Seems like some CPUs only support subsets of features, limiting how useful the flags are for determining what kind of optimizations the compiler can make. Kinda promotes using the lowest common denominator approach for chips you don't control.

Re:I especially like..

[PCM2]

What Intel did is sabotage.

What did Intel sabotage? Its own product?

Re:I especially like..

[Bill, Shooter of Bul]

Eh, just look at the things Microsoft did to DRDOS. Or anyone else, for that matter. When there are few competitors, you can't deliberately sabotage the competition. Its anti-competitive, monopolistic behavior.

An astute observer may note that this isn't that far from what video game consoles do. Or the Iphone. Or Itunes. I'm not sure I know the difference between these cases. Perhaps this is due to my imaginary law degree, but I prefer to blame it on the dragons.

Re:I especially like..

[cheesybagel]

GCC and PGI have support for AMD processors. AMD often used these compilers for benchmark result submissions in the past. But the Intel C++ compiler is often faster at doing benchmark results since it has more advanced static optimization support.

Re:I especially like..

[PCM2]

In the latter case, there is a deliberate effort to expend resources with the intention of harming your competitor.

I don't see that as being entirely clear. We're talking about an Intel compiler. AMD is free to write its own compiler; it chooses not to (to my knowledge). As I said before, Intel might be in a monopoly position in the chip market, but it does not have a monopoly on compilers. People who want their code to run on AMD CPUs could choose to compile their software with GCC, LLVM, MS C++, OpenWatcom, or whatever else might be out there.

You say Intel's compiler is sabotaging AMD. I could just as easily argue that Intel has sabotaged its own compiler. If customers bothered to test, they could just as easily say, "Hmm! When I compile with the Intel compilers, my binaries run like crap on AMD CPUs! Intel's compiler sucks."

Suppose Microsoft wrote a piece of software that ran on any x86 CPU, but it did a special check to see whether you were running Mac OS X. If it detected a Mac, the software would exit -- even though it otherwise could run. Jerk move? Sure. But should it be illegal?

Re:I especially like..

[cheesybagel]

No it was much worse than that. There is a CPU instruction named CPUID which tells you the processor family, manufacturer, and has a set of feature flags saying which extensions (e.g. SSE, SSE 2, 3DNow) that particular processor supports. Intel's compiler enabled SSE optimizations only if the processor manufacturer string was "GenuineIntel" and the processor family number was high enough, instead of checking in the flags vector if the processor supported SSE.

Re:I especially like..

[cheesybagel]

AMD essentially dumped SSE5 for Intel AVX. There are a couple of new instructions in there, but that's basically what happened.

Re:I especially like..

[pwfffff]

"Atheism is clearly a religion, or at least a religion-like movement, for some value of religion and for some subset of atheists"

OK... so did you have a point hidden in that wall of off-topic text? I sure as hell couldn't find it.

Re:I especially like..

[cheesybagel]

The flags do not lie. Processor manufacturers are not that stupid. There are different flags named 'sse4a', 'sse4_1', 'sse4_2'. Intel themselves initially only supported a part of the SSE 4 specification they made. This is why there are separate 'sse4_1' and 'sse4_2' flags. If a processor has a flag it means it implements a certain set of well defined instructions. Intel keeps its instruction extensions close to their vest usually, so AMD only gets to know them after Intel has already designed their own processor. AMD can sometimes do microcode changes to support instructions, in fact they did this in their initial SSE implementation, but other times you need to change the hardware functional units which takes years to do.

Intel Pentium II processors did not have SSE instructions either. No one asked for Intel to do additional work, just that they followed the proper way of doing it, which was no extra work at all. Intel's practice predates SSE 4 instruction development. It is known they did this even before Opteron came out.

Re:I especially like..

[cheesybagel]

No, it does it at run time. AMD specifically made a code patch utility that changed the binary to circumvent this Intel compiler 'feature'.

Re:I especially like..

[aztracker1]

Okay, so you suggest that every software company release mutliple builds for platforms differing in name only.

if SSE3:
use it
elif SSE2:
use it
elif SSE:
use it
el
crappy codepath here


is a lot different than...
if GENUINE_INTEL:
test for sse
else
sucks to be you

Re:I especially like..

[aztracker1]

but inside the if (intelCPU) block, the test for hasSSE3, hasSSE2, hasSSE... other browsers support that, so they are intentionally not allowing those code paths for other cpus.

Re:I especially like..

[DoubleDownOnEleven]

Wouldn't this only apply if Intel had a monopoly on compilers?

Re:I especially like..

[Chris Burke]

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.

Re:I especially like..

[Khyber]

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

[chriso11]

So basically, Intel made an extra effort to ensure that the compiler would work worse with competitor's CPUs. The code to check the supported extensions was already in the compiler and AMD's chips respond in a compliant manner to indicate which ones they support.

If the AMD chip was changed only in that it would respond that it is a GenuineINTEL, code compiled on Intel's compiler would produce a significant improvement in performance. While AMD is far from perfect, their CPUs are price competitive with equivalent Intel chips. If it weren't for AMD, we would still be paying >$1000 for a Pentium 4. That's why I generally avoid buying Intel chips - they're the top dog, yet they don't play fair.

Re:I especially like..

[chriso11]

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

[DoubleDownOnEleven]

A dominant share of the compiler market or processor market?
That's really what I was getting at, not monopoly status.
The compiler favors Intel CPUs. There are other compilers out there that don't, I imagine. gcc is pretty popular, etc.
The issue raised above was whether Intel had an obligation to not cripple their product, and EndlessNameless responded with the anti-trust act. In this case, the product is not a CPU, but a compiler. I'm asking, does the anti-trust act apply to this issue, when there are plenty of competing compiler products out there.

Re:I especially like..

[PCM2]

So what's your point? From how I understand it, the first one is what Intel did. But even if it was the second one, I don't see how it's "a lot different." And even if we agree for argument's sake that is is a lot different, I don't see why it should be against the law, any more than it should be against the law for mechanics to refuse to work on Fords.

Re:I especially like..

[chriso11]

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

[Kryis]

"Intel® Professional Edition Compilers include advanced optimization features, multithreading capabilities, and support for Intel® processors and compatible processors. They also provide highly optimized performance libraries for creating multithreaded applications."

Taken directly from http://software.intel.com/en-us/intel-compilers/.

The difference is MS would be saying "We don't support OS X", and actively enforcing it. Intel are saying that their compiler does work for AMD processors, without any mention of the fact that they put time and money into actively making it worse for AMD processors (instead of just not doing anything to improve performance specifically for them)

Re:I especially like..

[DoubleDownOnEleven]

Straw-man argument. Of course the compiler can affect CPU performance. The point I was trying to make is that I agree with HarrySquatter's comments above - as far as I know, Intel is not forcing people to use their compiler.
Any other practices by Intel, anti-competitive or otherwise, don't apply to this particular chain of comments.

Re:I especially like..

[vakuona]

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

Is there? No seriously, is there?

In a sense, everything that I do that gives me competitive advantage impacts my competitors' businesses negatively. Like the earlier commenter said, why is it incumbent upon Intel to write a compiler that works equally well on their competitors' products?

Not disclosing that it doesn't work as well on Intel's competitors' products may be a sneaky trick, but it seems like there should be due diligence on the part of the people using the compiler. Intel does not have a monopoly on compilers. Last I heard, people use Intel compilers because they produce very good code. Cry me a river if Intel would like to produce good code for Intel processors and not others.

Don't get me wrong: I think Intel is being sneaky and underhanded. But I don't see it having done anything illegal, and I don't see how anything it has done should be illegal.

Intel's compiler is not just used by Intel. Because of Intel's dominant position in the hardware market, and the intimate knowledge of said hardware, their compiler is pretty good for 80% of the CPUs out there. Because of the resources at their disposal, the same compiler is good for the other 20% of CPUs as well. Software vendors use the compiler to compile executables. Software vendors have little to zero interest in shipping multiple binaries to support CPUs that should be binary compatible . So, they will ship binaries that perform better on Intel's hardware regardless of the fact that some of AMDs hardware can run the software as well if not better. This is anticompetitive because until AMD achieves parity with Intel in install base, then vendors have an incentive to use Intel's broken compiler because in the short term, it delivers a better outcome for most customers, but in the long term, it cripples competition and customers suffer.

Re:I especially like..

[vakuona]

No, not its own product. It's sabotaging the software that other vendors create to not run as fast on AMD CPUs thus making them seem slower than they really are, and discouraging customer from buying them, or forcing AMD to sell them at lower prices, which hurts AMD unfairly. If Intel can't play fair, they should get out of the compiler business, because the compiler are used to run compile software that run on both companies' CPUs, and so they have to play fair.

Re:I especially like..

[Rockoon]

The first one is not what Intel did.

Re:I especially like..

[Rockoon]

This isnt all of it really. Sure, they ignored the feature flags.. but they also intentionally did not do other far more general optimizations, such as eliminating dead and/or redundant code.

Re:I especially like..

[Daengbo]

The ZDNet article on this claims that ICC inserted null loops for non-Intel processors.

Re:I especially like..

[Daengbo]

When Intel uses its compiler to benchmark the competition, it becomes sabotage.

Re:I especially like..

[misnohmer]

No, it causes the the Intel part to excel in performance, it does not cripple the AMD part. There is a difference (if I build a faster race car, I'm not "falsely causing public race results to show my competitive cars as slower"). Seriously, why should Intel optimize for AMD parts?
1. It cost Intel to develop, test and support features. Why on Earth would you expect them to pay millions to help their competition?
2. AMD does not give Intell all of their datasheets, design files, access to developers, etc to help with the effort.
3. If Intel reverse engineered AMD parts and put that in the compiler, they'd get hit for doing that. Why bother?
4. Intel made some decisions in their design to make things easier for their compiler, AMD made different decisions which Intel may not like nor care about figuring out how to use

I guess the only error Intel made was to allow AMD processors at all. It should be Intel compiler only - lots of companies develop software only for their own hardware; Apple for example not only specifically blocks OS X from running on non-Apple hardware, but they will sue your pants off if you figure out a workaround. Courts recently upheld Apple's right to do so. Intel should follow suit and slap such a license agreement on their compiler, then anyone who uses it on AMD processor should be happy they're not being sued.

BTW, AMD releases libraries optimized for their new processors, should they get sued by the FTC?

Re:I especially like..

[BikeHelmet]

Why on earth would AMD use Intel's compiler for benchmarks, it just seems like common-sense that they would want to control the compiler to ensure that it's output is properly optimized for their processor.

They don't. Well, except to collect performance data I suspect.

Companies like Adobe use ICC for all their products. Maya is compiled with ICC. Many of the top programs used in benchmarking(office/productivity software) are compiled with ICC. When used as benchmarks these programs always conclude that Intel CPUs are faster.

But that's not where the antitrust comes in. Optimizing your compiler for your CPU better than a competitor's CPU is completely acceptable. What isn't is a secret handshake wink wink that shunts off 100% compatible CPUs from your competitor to a slower code path.

You can defend it by saying you planned to add new features/instructions that only your CPUs would support, but it won't hold up in court. AMD was able to prove their CPUs were 100% compatible at the time. That means if you run the faster code path, it always works fine. That's why they had grounds for an antitrust suit.

P.S. If you compile these programs with GCC, AMD usually wins the benchmarks. However, scores will be lower for both AMD and Intel CPUs. ICC just does a better job...

You could say that AMD CPUs do better with garbage code. I wonder if that'll have implications for JIT'd languages?

What I personally do to determine which CPU is fastest is look at gaming benchmarks. I like games, so why not? I pick some low resolution benchies, testing fast videocards, and for a game/engine that hits the CPU hard. Then I look at the numbers. Ex:

Athlon II X 245 (2.9ghz) - 153fps
Athlon II X4 620 (2.6ghz) - 171fps
Core i7 920 (2.66ghz) - 174fps
Athlon II X4 630 (2.8ghz) - 175fps

Since I'll be running at high detail levels, this lets me conclude that any quad-core will work and I should go for the cheapest.

Of course, some games are compiled with ICC too... there's no perfect way to read benchmarks.

Re:I especially like..

[NSIM]

If this is the case, then what I can't understand is why AMD hasn't made a huge public fuss about it in the past. Surely it would have been trivial for their engineers to discover this problem and make it widely known, yet it never came up before today!

Re:I especially like..

[Anonymous Coward]

You didn't count in the validation effort. For advanced compiler optimization, because of its complexity in algorithm, it is not just as simple as turn on the optimization switch. One has to do full validation of all test suites for the target platform if you don't want to see some surprising results. That means it is not free for Intel compiler to support AMD CPUs. You can expect Intel to argue that they turned off some optimizations since they didn't have resource to test them for competitor's product.

Re:I especially like..

[FreakyGreenLeaky]

I don't understand why you couldn't have found this all by yourself
That's what you get when engaging with a Brand X Fanb0!y.

Re:I especially like..

[uninformedLuddite]

Didn't Intel invent SSE?

Re:I especially like..

[sznupi]

Or simply you've never heard about it before today.

Re:I especially like..

[NSIM]

OK, so point me to resources that discuss this issue prior to the FTC announcement

Re:I especially like..

[sznupi]

Slashdot (use search box)

Re:I especially like..

[Anonymous Coward]

The accusation against Intel is not that they did the first example or even the second. More like:

if GENUINE_INTEL
do best_optimization_routine
else
do slopppiest_working_code_routine

The problem was that the non-Intel "optimizations" were actually worse than completely unoptimized code. If you faked the CPUID, the optimized "Intel" binary would still run perfectly fine on an AMD processor (with a substantial performance boost). And vice versa---the shitty "AMD" binary would run flawlessly yet more slowly on an Intel processor than unoptimized binary.

Re:I especially like..

[NSIM]

Care to do better, you made the claim that this was public before the FTC announcement, so show me something.

Re:I especially like..

[MobyDisk]

That's a good point. I've never used the Intel compiler myself, and really, I would expect Intel to do something jerky like this any time I used a vendor-specific tool.

However, at GDC 2008, Intel had a big display where they were going on about their compilers and how well they optimized things. Apparently they have tools that can analyze the code and generate multithreaded code (sounded like OpenMP, kinda) and SIMD instructions (SSE, SSE2, etc.). They unambiguously claimed that those optimizations applied to both Intel and AMD processors. They went out of their way to assure people that they weren't doing this. So it is really funny to find out that they are. I hope they do the presentation again next year and so I can ask their engineers some very pointed questions about this. It sounds like they were flat-out lying.

Re:I especially like..

[MobyDisk]

That was a very good informative reply, but please try to tone down the attitude. Searching law is not "basic research" and you don't need to make people feel angry or stupid for not knowing it. This is a very intelligent discussion so no need for insults.

Re:I especially like..

[sznupi]

google: site:slashdot.org intel amd compiler

First result. 2005. Not the only story throughout the years which touched on this of course.

PS. And it was you who made the claim - that this was something new. Without actually spending less than 1 minute to verify your impression. So I'm confused; your UID says otherwise, but you act like you discovered the internet this month.

Re:I especially like..

[NSIM]

All I was asking for was a link, thanks for providing it.

Re:I especially like..

[shutdown -p now]

That was a very good informative reply, but please try to tone down the attitude. Searching law is not "basic research" and you don't need to make people feel angry or stupid for not knowing it.

With all due respect, while you may be true in general, there's no excuse for an American to not know about the Sherman Act; he shouldn't even need to search the law to remember about its existence, or applicability to this case (or any other involving monopoly abuse)!

Re:I especially like..

[MobyDisk]

1) How do you know he is an American?
2) Assuming he is an American, I agree that everyone should know about it. But that is not a valid reason to insult someone. It closes people's minds, rather than opening them.

Re:I especially like..

[networkBoy]

That may be true, I don't know as I don't have the source to the compiler.

But even if true, and even if it went so far as to actually take the absolute most conservative code path when not on an Intel CPU, it is the Intel Compiler, I would not expect it to run at all on a competing architecture. The point of the compiler is *not* for general purpose computing, the purpose is for highly optimized code on an Intel machine. If you want a GP compiler use Visual Studio or GCC...

I think the whole thing is a red herring. Furthermore it's funny that this suit, brought basically at behest of a company who does most of their manufacturing overseas is against a company that does tons of manufacturing inside the USA...
So much for the Obamma administration stimulating jobs for Americans.

Re:I especially like..

[Anonymous Coward]

Microsoft have been caught doing this very thing. Back in the days of DR-DOS they engineered the windows installer so that it would crash if it detected DR-DOS and report a misleading error message. IIRC DR actually won a lawsuit over this but it dragged on so long that the product was obsolete by the time it was resolved.

DR won the lawsuit because that behaviour is, in fact, illegal.

Intel

[ArbitraryDescriptor]

Our competitive practices aren't like your competitive practices.

Re:Intel

[gandhi_2]

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

[MBGMorden]

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

[will3477]

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

[caerwyn]

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

[Anonymous Coward]

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

Re:Intel

[larry bagina]

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

Re:Intel

[obarthelemy]

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

[idontgno]

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

[Anonymous Coward]

*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

[Obfuscant]

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

[Obfuscant]

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.

Re:Intel

[Anonymous Coward]

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

[Anonymous Coward]

All competitive practices are equal. Some are just more equal than others.

Re:Intel

[Anonymous Coward]

AMD is actually in the lead... Intel has no GPU. HAHA

Re:Intel

[GooberToo]

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

[Chris Burke]

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

[bhtooefr]

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

[jstults]

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

I'll second that, here's an example from the Octave mailing lists:

To conclude, on my computer, for this test, Octave is approximately as fast as C, gfortran is a little bit faster and ifort is 10 times as fast.

For scientific computing it's tough to beat ifort on intel iron.

Re:Intel

[Khyber]

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

[Obfuscant]

You mean because any reasonable programmer should have fully expected Intel to be engaged in anti-competitive practices?

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

Or because it is totally reasonable not to expect manufacturer A to understand every nuance of every product produced by someone else.

Suppose they did try to optimize for every AMD chip. I suspect that you'd be the first in line to complain that they didn't do it right for some certain version, and because they didn't do it right they are obviously "anti-competitive" and should have the FTC shut them down.

By the way, a compiler that is told it is creating code for a specific chip isn't doing a very good job of optimizing its output if it has to pick AT RUN TIME what kind of code to run. That's a very poor optimizing compiler, IMNSHO. Why you WANT to use it is a mystery. Do you imagine that the CPU you are running your code on will mysteriously lose SSE2 abilities, or mysteriously gain them?

I mean, we're not talking about some minutia of optimization for some specific part of P4 microarchitecture or something,

Yeah, it's not like the Intel compiler did exactly that kind of optimization or anything. Oh, wait, that's the kind of stuff it did. Does.

It's not a matter of "optimizing for Intel", it's a matter of "deliberately de-optimizing anything but Intel".

It's a matter of not being responsible for the microarchitecture of your competitor's products and generating code that WORKS as a fall-back instead of just failing to run at all. What would you prefer -- that it produces code that doesn't run on AMD at all?

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

Defend them against ridiculous claims based on ridiculous assumptions? Absolutely. Intel isn't responsible for writing optimizing compilers for other people's products. It's the INTEL compiler. If AMD wants to write an optimizing compiler for its products, fine. Do it. They are the ones who know the tricks of their CPUs, it's not Intel's responsibility to reverse-engineer every chip AMD makes so they can know what optimizations will and will not work.

What's next? OMG, Intel compiler won't produce code for my Z80! They're being anticompetitive for Zilog. And it won't produce optimized Atmel code. OMG, anti-Atmel.

I've been there with the Intel compiler and I left it a long time ago. Not because it didn't produce optimizations for AMD chips, because it didn't produce WORKING optimizations for Intel ones. I didn't expect AMD optimizations because there were no compiler flags to tell it I was USING an AMD chip in the first place. It would be stupid to assume that a compiler that you can't tell you are using a certain chip would produce optimized code for that chip.

That means it is pretty stupid to claim "anti-competitive" when a compiler you know doesn't do anything special for AMD chips doesn't actually do anything special for AMD chips.

Re:Intel

[chriso11]

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 and critical processing being run on the GPU portion, sloppiness is not acceptable.

I really think that AMD has a good head start here - I don't think that Intel can make a good GPU, and NVidia has a long road ahead in making a CPU (x86 or x64).

Re:Intel

[Rockoon]

As someone who programs in assembly language, may I be the first to say that you are completely full of shit. The Intel compiler is not all that CPU specific. The Intel compiler, for the most part, performs more AST (Abstract Syntax Tree) optimizations than any other compiler. It is the AST optimizations that make it the greatest.

For the record, I am a big fan of ICC's optimizations. I am the sort of person who tells other programmers that if they arent using ICC then they shouldn't be performing micro-optimizations yet. The ICC vs AMD debacle is long over, and whats left is still the best C compiler on the planet. Its not even a close comparison. Its the best C compiler for Intel CPU's and its also the best C compiler for AMD CPU's. All they had to do to re-enable performing well on AMD's is to stop fucking them over on purpose.

As far as the response from Intel asking "what bug?" from you. I'll bet almost anything after reading your shit about architecture that you only think that you found a bug...

Re:Intel

[Chris Burke]

Okay, obviously you need some background on x86 programming in general and the complaint against the Intel compiler in specific.

The history of x86 is one of constant additions of new capabilities to the ISA. Long ago, Intel realized it was a pain to figure out whether the chip you were running on supported any particular capability, so they added the CPUID instruction, and redefined one of the reserved must-be-zero bits in an already extant control register to indicate whether the chip supported CPUID. The CPUID instruction has a number of well-defined sub-functions that all return various pieces of information about the chip you are running on. This includes things like whether particular modes, instructions, or instruction sets like SSE are supported.

These bits are defined by Intel, and supported by every compatible manufacturer. So if you want your code to check if it supports SSE, you use the Intel-defined CPUID function/bit to determine if it supports SSE. Any chip that supports it will tell you so, so it's anything but a mystery or a difficult problem to figure out.

What Intel's compiler did is ignore the bit saying SSE was supported if the manufacturer of the chip was not Intel. Intel's own manual tells you this is not how you check for CPU capabilities, you use the appropriate feature bits. But instead they deliberately avoided using features that AMD chips supported, and instead used what would be on any processor a slower code path.

So, with that out of the way...

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.

They don't have to fully support AMD, they just have to not go out of their way to degrade AMD processors. Nobody thinks Intel should spend extra effort making AMD go fast. But they should not spend extra effort making AMD go slow. Not only is it right, it's the law.

Suppose they did try to optimize for every AMD chip. I suspect that you'd be the first in line to complain that they didn't do it right for some certain version, and because they didn't do it right they are obviously "anti-competitive" and should have the FTC shut them down.

You suspect incorrectly, probably because you didn't understand the complaint.

By the way, a compiler that is told it is creating code for a specific chip isn't doing a very good job of optimizing its output if it has to pick AT RUN TIME what kind of code to run. That's a very poor optimizing compiler, IMNSHO.

Except as I already explained, it's pretty easy to pick at run time because there's a well defined interface for figuring that out. You output code optimized for processors with whatever features you want, and a default code path for processors without those features. This is what the Intel compiler does, and in general does it quite successfully, so I'd say you should maybe put a little more H into your O if you catch my drift.

Why you WANT to use it is a mystery. Do you imagine that the CPU you are running your code on will mysteriously lose SSE2 abilities, or mysteriously gain them?

Yeah, what a mystery why someone would want to be able to ship the same binary to customers whose processors have different features, and give them each an optimal experience. How bizarre! And you question whether others have any business programming...

It's a matter of not being responsible for the microarchitecture of your competitor's products and generating code that WORKS as a fall-back instead of just failing to run at all. What would you prefer -- that it produces code that doesn't run on AMD at all?

Just in case you didn't understand the implications of the explanation I gave at the top of the post, the optimized Intel code runs perfectly on AMD chips that support the necessary feature. In fact, at one point AMD released a patch fo

Re:Intel

[Anonymous Coward]

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.

Originally the compiler did the appropriate checks for SSE/SSE2/SSE3 flags and was manufacturer agnostic, later Intel added an explicit check to disable the use of these registers on AMD CPUs regardless of whether the processor supported them.

Re:Intel

[sjames]

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

Well, there's your problem. You asked a cricket! Had you asked an insect more accustomed to working in parallel (I recommend bees) you'd know it's very popular for scientific computation, especially cluster computing.

Re:Intel

[guabah]

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

I didn't knew Intel produced clothes.

Re:Intel

[Obfuscant]

Okay, obviously you need some background on x86 programming in general and the complaint against the Intel compiler in specific.

Yes, obviously, if I don't agree with you, it can't be because you are wrong.

They don't have to fully support AMD, they just have to not go out of their way to degrade AMD processors.

I've got this compiler. It has all kinds of flags to tell it what processor I'm going to be running on. All of them are INTEL processors. Based on that flag, the compiler can make use of Intel's knowledge of their own hardware to optimize execution pipelines, cache, and all kinds of esoteric things that most programmers don't care about because all they know is "binary compatible".

So, I can't tell this compiler the code is going to run on an AMD chip. It CANNOT know what optimizations to make for that AMD chip because it doesn't know it is going to run on one. As the programmer, I KNOW that it will not produce optimizations for AMD chips. Do I blame Intel for not writing a compiler that knows all about AMD chips, or do I pick a different compiler? Yes, big bad company is big and bad, so I blame them. We likes AMD, we does, so Intel is big bad, like nasty hobbitses they steals our ring they does. Or something like that.

Yeah, what a mystery why someone would want to be able to ship the same binary to customers whose processors have different features, and give them each an optimal experience.

What part of the word "optimize" confuses you? You cannot provide an optimal program to everyone because the processors are different. The very act of selecting a "code path" slows the program down. This is why the Intel compiler CAN BE TOLD EXACTLY WHAT PROCESSOR IT IS MAKING CODE FOR. Intel could very well have had their compiler generate code at the very start that said "I don't make code for AMD, you lied when you compiled me" and you get NOTHING done, but no, they gave you generic code instead of nothing. In fact, as I recall, I ran into exactly that when I tried running the code compiled for the Intel CPU I had on an AMD -- without the politeness of an error, just a crash.

Now, if you accept the performance degradation of two "code paths" to begin with, one of which is optimized for the processor you specified, what optimizations do you make for the other path? You don't know what it's going to run on so you can't optimize it. It could be a different Intel CPU. Why aren't you complaining that Intel is deliberately anti-competitive with Intel, because they are doing things deliberately to slow down Intel chips?

Just to hammer this point home, Intel doesn't have to reverse engineer shit. They only have to follow THEIR OWN STANDARD.

Unless you are trying to claim that AMD processors are identical in every way to Intel processors, then they would need to know AMD standards as well if they are truly going to optimize for AMD processors. Binary compatible is not identical. If they optimize one path for the processor they know, then reason says that if you are going to HAVE another path, it should be unoptimized.

If that particular Z80 was fully compatible with Intel's instruction set with no support necessary from Intel's compiler, but Intel put code in specifically to exclude Zilog even though they were fully compatible, then yeah, that'd be anticompetitive. It's a tough concept, I know, but a real programmer like you should be able to figure it out.

I'm sorry you don't understand that optimizing compilers deal with more than just "instruction set", but they do. If AMDs pipelines or caches or whatever are different, then the optimizations are going to be different. It may be as small as one less stage in a pipeline, but that can make a difference. I never got an answer to my bug report, but I suspect that it was a branch being optimized for a certain pipeline that got my result tossed before it was stored. I'll never know, and I'm well past the days when I dig that deeply into the CPU to worry about such thi

Re:Intel

[MBGMorden]

I've still got cards from back then that work too.

Then again, I've still got cards from pretty much every era that works, since I've NEVER had a video card die on me. Crappy drivers or performance yes, but "building shit to last" has never seemed to be much of a problem.

Re:Intel

[bemymonkey]

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

[Anonymous Coward]

Is your brain really that rotten from disuse that you do not realize that you are not talking about the same thing as the parent (or for that matter, the lawsuit) talks about?

Re:Intel

[Anonymous Coward]

The problem with the Intel compiler was that it explicitly disabled faster code paths when detecting an AMD processor even though that processor would've supported it just as well as Intel's.

Rather than check for the presence of a feature (I think it was SSE3 but I'm not sure) it explicitly checked for an Intel CPU. That's just bad practice.

Re:Intel

[Anonymous Coward]

Nobody gives a damn about gate-level micro-optimizations in this context. A cpu supports an extension or it doesn't. Period.

And yes, "make decisions about what code to run at run-time" is what many programs do. Nobody wants to ship 3 executables for the same program, and disk space is cheap. So you smash all three 'programs' into the same binary. The compiler starts your program with a nice simple check. Does CPUID say the processor supports SSE2? Use path A. Just MMX? Path B. Neither? Use slow generic path C.

The processor itself is irrelevant for this argument. If the chip SAYS it supports an extension, we use that extension. If the chip says it supports SSE2, but does not also say 'GenuineIntel', you do NOT intentionally pretend as if the SSE2 extensions don't exist.

Re:Intel

[shutdown -p now]

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.

Can you show an example of such code?

I strongly suspect that you were relying on something that is explicitly identified as "undefined behavior" in ISO C or ISO C++ (whichever one you were using); gcc is quite famous for sticking it to the devs who aren't aware of U.B. and its consequences as well. I would be surprised if ICC didn't follow suit.

Hopefully this will free up Nvidia to compete

[Apple Acolyte]

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:Hopefully this will free up Nvidia to compete

[WiiVault]

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

[kclittle]

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

Re:Here we go again...

[Anonymous Coward]

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

Re:Here we go again...

[Anonymous Coward]

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.

Re:Here we go again...

[chriso11]

Actually, no - the companies pay fines when they are caught. Besides - you don't want to have laws enforced in this country?

Intel compiler not that good on their own parts

[Anonymous Coward]

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

[MBGMorden]

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:Intel compiler not that good on their own parts

[Anonymous Coward]

Hey guess what, Intel chipsets don't support AMD CPUs either, is that anti-competitive as well? Intel went out of their way to design chipsets that interface using a different bus than AMD uses, and a dare say, the performance of an AMD CPU coupled with an Intel chipset would be completely crippled. The compiler argument is the same. No one forced anyone to purchase and use the Intel compiler.

Re:Intel compiler not that good on their own parts

[Chris Burke]

Intel went out of their way to design chipsets that interface using a different bus than AMD uses, and a dare say, the performance of an AMD CPU coupled with an Intel chipset would be completely crippled. The compiler argument is the same.

No it's the opposite, because in the case of the compiler, Intel doing nothing would have resulted in good performance on AMD, but instead Intel went out of their way to make performance on AMD chips suck.

It isn't complicated people.

Re:Intel compiler not that good on their own parts

[Anonymous Coward]

You're right. it's not complicated, regardless, you don't seem to get it. Intel should be under no obligation to write a compiler that makes their competitors products perform better. In fact, the code the Intel compiler produces shouldn't be required to run on AMD chips at all. AMD can write their own compiler if they like, no one is stopping them. What's next, should Intel be requried to design AMD's next CPU so that it can keep up with Nehalem?

Re:Intel compiler not that good on their own parts

[Chris Burke]

You're right. it's not complicated, regardless, you don't seem to get it. Intel should be under no obligation to write a compiler that makes their competitors products perform better.

No, you don't get the ever so subtle difference between "required to make AMD perform better" and "required to not deliberately screw AMD".

One of these is the law. Thus this suit.

In fact, the code the Intel compiler produces shouldn't be required to run on AMD chips at all.

It's funny, because it's AMD who is required to ensure that their chips are compatible with Intel code. And they are. But then Intel decided to deliberately break that. So... Yeah.

Re:Intel compiler not that good on their own parts

[Anonymous Coward]

I get it completely. They didn't produce optimized code for AMD parts, but did for Intel parts. That's not sabotaging AMD, it's just not optimizing for them. Let me go back to the not so subtle examples. Intel's chipsets work better with Intel's parts (that's not screwing AMD), Intel's BIOSes work better with Intel parts (that's not screwing AMD), Intel's motherboards work better with Intel parts (that's not screwing AMD either), Intel's compilers work better with Intel parts (and that's not screwing AMD either). Actually Intel's compilers work quite a bit better with AMD parts than the other 3 do. As to whether it is law, that will actually take more than an allegation.

Re:Intel compiler not that good on their own parts

[Anonymous Coward]

No, you don't get it.

Legal:
If (SSE2) { ...code...}
      else {..old slow code..}

Not Legal:
If (SSE2 && GenuineIntelFlag) { ...code...}
      else {..old slow code..}

There is no extra optimizing here. There is deliberate and malicious ignorance of fast extensions that the CPU says it supports, purely because that CPU doesn't flaunt the Made By Intel flag.

Re:Intel compiler not that good on their own parts

[Anonymous Coward]

Your opinion and you're entitled to it, but that does not make it a legal fact. My opinion is that this should not be illegal (and if it is, it's by far not the first example of bad law I've seen). This has many courts to make it past before we know that answer.

EU I can understand...

[gandhi_2]

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

[fuzzyfuzzyfungus]

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

[Anonymous Coward]

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

[Anonymous Coward]

i knew you were one of them!

Re:EU I can understand...

[Anonymous Coward]

i knew you were one of them.

Re:EU I can understand...

[mdarksbane]

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

Serves Nvidia right

[Anonymous Coward]

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.

AMD got good deal then

[postmortem]

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

[byteherder]

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

[0racle]

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

[jpmorgan]

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

[MobyDisk]

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

[byteherder]

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.

Re:AMD was robbed

[Circle of Owls]

AMD could have invested more heavily in fab technology only if there had been a level playing field. Intel kept AMD at subsistence-level profits for just this reason.

Re:AMD was robbed

[modemboy]

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 returns they expected due to market manipulation?

  "AMD couldn't keep up with Intel's aggressive pricing because they simply could not produce competitive chips as inexpensively as Intel could." That statement is just hilarious. For the time period we are talking about here, AMD chips were cheaper and faster than Intel's. No questions about it.

Re:AMD was robbed

[bhtooefr]

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:AMD was robbed

[Hurricane78]

I know how. It’s called IBM. The ones that the Athlon technology came from. Every time Intel gets too strong, IBM helped AMD out. Which of course was, because it helped themselves. But not a bad thing for us too.

Your comment does not hit the core of the problem, though.
The core is, that Intel threatened to not sell chips to mainboard makers anymore, if they would make a board for the Athlon. I know this very well, because I tried to buy such a board. And even months after the chips were out, I only had the choice between two obscure Asian companies and a tiny German one. That German one strangely went bankrupt, two years later, and I bet the Asian ones were those Chinese knockoff companies who had nothing to lose anyway.

Oh, and the quality. Oh boy. I was able to reliably overclock cheap 533 MHz CPUs to 900 MHz. They ran for five years without trouble, before they were replaced. I saved a lot of money that way. :)

Re:AMD was robbed

[sjames]

At least some of the problems weren't actually AMD's fault. The k6 was less expensive, so it went into bargain machines along with the really cheap power supply, the cheap motherboard with the substandard capacitors, and the smallest fan that could even imaginably work.

Re:AMD was robbed

[toddestan]

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.

Well, to be fair for a while you couldn't get a decent chipset in an AMD machine no matter how much you spent. The whole Socket A era was plagued by shitty chipsets - VIA's were pure garbage, then there was SiS and even AMD's own chipsets were flakey. It wasn't until towards the end when the nForce2 came out that AMD users could enjoy a system as stable as a run-of-the-mill P4 running whatever Intel chipset that was popular at the time. Then the 64 bit era happened and nVidia's chipsets rapidly went downhill. At least AMD got their act together, and I can't complain about their chipsets for the Phenom II/Athlon II systems.

Re:AMD was robbed

[Michael Meissner]

Intel had a period where they were focused elsewhere (IA-64), and AMD had come out with guns blazing. However, eventually Intel did wake up, and AMD was slow in getting out the Barcelona chips to compete against the core5 chips.

Re:AMD was robbed

[bhtooefr]

Of course, there was a stable chipset option for the earlier K6s... the Intel 430TX. But, anything needing faster than a 75 MHz FSB (and even then, the 430TX was overclocked,) or anything that was Super Socket 7, couldn't use it.

Re:AMD was robbed

[Klintus Fang]

Back in the Athlon days, AMD lacked the manufacturing capacity to control 50% of the market. If all their fabs were running at 100% at that time, and every chip they made was being sold, the total number of chips sold wouldn't have been anywhere near 50% of the market. Intel doesn't actually have to do anything illegal or sleezy to stay ahead on market share. The fact is that no matter how bad their chips might suck the big manufacturers like Dell et. al. will still have to use Intel chips in the majority of the machines they sell because AMD isn't physically capable of making enough. That is the fine line AMD has to tread. They have to constantly stay ahead in performance while slowly growing their market share and then use the profits to invest in increased manufacturing capacity. It takes years to build a new plant afterall, and if you build too many too quickly, you'll end up with manufacturing capacity you cannot use and you lose tons of money because maintaining a microprocessor manufacturing plant is enormously expensive.

Re:AMD was robbed

[Klintus Fang]

to add to my own comment. this problem with manufacturing costs is surely the reason AMD has spun off their fabs into a separate company. It will be interesting to see if they can be more successful now that they do not have to directly maintain their own fabs.

Re:AMD was robbed

[Anonymous Coward]

FDIV bug anyone?

Intel's response

[parallel_prankster]

http://blogs.wsj.com/digits/2009/12/16/intel-responds-to-ftc-suit/

Re:Intel's response

[GigaplexNZ]

Interestingly, Intels response after effectively admitting guilt and settling with AMD is:

Intel has competed fairly and lawfully.

Well, duh.

[girlintraining]

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.

[betterunixthanunix]

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.

[byteherder]

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.

[girlintraining]

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.

[Virak]

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.

[Anonymous Coward]

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.

[Virak]

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.

[jpmorgan]

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.

[Anonymous Coward]

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.

[shadowofwind]

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.

[girlintraining]

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.

[pigeon768]

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.

[Brian Stretch]

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

Re:Well, duh.

[Anonymous Coward]

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.

[Anonymous Coward]

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.

[Virak]

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.

[RightSaidFred99]

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.

[RightSaidFred99]

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.

[Virak]

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.

[Vancorps]

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 they may have gotten away with it, but all the OEM strong arming and nasty licensing restrictions for AMD also contribute to the lawsuit. Intel did everything it could to prevent AMD from gaining any marketshare. AMD did gain a lot of marketshare regardless but that's not at issue here. It is one thing to compete on merits, and it is another to use your marketshare to cut out competition.

Re:Well, duh.

[Anonymous Coward]

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.

I see. You think optimizations would work the same between an AMD chip and an Intel chip and would be guaranteed to have no side effects. In your rosy little world Intel can just assume any processor with cpuid flags matching a specific feature will work exactly the same as Intel's chips will. I should really stop arguing with clueless people, it leads nowhere.

Re:Well, duh.

[Virak]

I see. You think optimizations would work the same between an AMD chip and an Intel chip and would be guaranteed to have no side effects.

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 your optimization breaks the program on any CPU that properly implements the ISA it's compiled for, your optimization is broken, and the one processor it works on has a bug.

In your rosy little world Intel can just assume any processor with cpuid flags matching a specific feature will work exactly the same as Intel's chips will.

They can because it does, and if it doesn't the other CPU maker has a bug in one of their chips and will shortly be getting a lot of angry customers and bad press and Intel will be getting neither, and the whole situation is a massive win for Intel.

I should really stop arguing with clueless people, it leads nowhere.

What, you were arguing with yourself? You should be more clear about it then.

Re:Well, duh.

[cheesybagel]

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 motherboards and vice-versa using the Socket 7 bus interface. Then Intel switched the processor bus to GTL and refused to license it to AMD. In fact, Intel even refused to license their bus design to chipset manufacturers at a point, because they wanted to corner that market as well. Intel sued VIA Technologies for doing AGTL bus compatible Pentium III chipsets. Only after Intel's own i820 RDRAM chipset turned out to be bugged to hell, and the third party OEMs started screaming they relented.

AMD, for Athlon, licensed the Digital Alpha EV-6 bus and had to make a separate infrastructure for manufacturing chipsets and motherboards. It was an open secret at the time that Intel pressured the Taiwanese motherboard manufacturers to not make any AMD compatible motherboards for Athlon. ASUS distributed their AMD motherboards in plain white boxes, without any ASUS markings, anywhere to escape Intel's wrath.

Re:Well, duh.

[Anonymous Coward]

  You're totally off-base with your understanding of the issue. A compiler is essentially a sophisticated manufacturing tool.
It takes the raw material ( source code ) and fashions it into a finished product that the operating system, running on top
of the hardware can use.

  Think of the compiler as a key-cutter - any suitable blank should produce the same copy of a key. In this case, the key-cutter
  isn't checking the properties of the blank, but the BRAND.
  So, although Brand X is suitable, it's being rejected only because it's Brand Z.

  But, I don't mind that Intel (allegedly) has done this, only that it was secret. This will simply spur greater use
of non-Intel compilers.

Re:Well, duh.

[cheesybagel]

A C++ compiler needs to know nothing about virtualization instructions. Much like it needs to know nothing about instructions for entering into protected mode.

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 claim are never done, because otherwise there would be no forward compatibility for compiled code even within Intel's own processor products.

Re:Well, duh.

[Anonymous Coward]

such restrictions are necessary for a market to truly remain free. just like you're a free citizen yet you are restricted from stealing from or murdering other people. restrictions against deliberate harm will pretty much always be necessary for an entire system to remain free.

Re:Well, duh.

[Anonymous Coward]

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.

No, the end result could be offending companies lose patent and copyright protections and any public right of ways they have secured including broadcast frequencies (all to the extent proportionate to the offense with just penalties and compensation, of course). Just because you only have a hammer in your toolchest doesn't mean mine isn't filled with custom wrenches.

When a company can monopolize a market without government favors (aforementioned patents etc.), I might be concerned. The few which meet that criteria typically have grateful customers and pissed off competitors. I prefer to live in a world of grateful customers than kid-gloves competition.

Re:Well, duh.

[sjames]

Further, they repeatedly denied that the compiled code "de-optimized" when run on an AMD, claiming that the lesser performance was due to an inferior CPU.

Re:Well, duh.

[bhtooefr]

No. What he's saying is, for Intel's compiler developers, there is no AMD to worry about, as support would only be given for uses on Intel CPUs. Therefore, letting the optimizations work on AMD processors without validation would be OK, as Intel wouldn't have to validate for if it works properly.

Re:Well, duh.

[uninformedLuddite]

Get under the desk you will be safe there. Damn the communists, full steam ahead.

Re:Well, duh.

[Anonymous Coward]

Okay, now I'm definitely sure you don't understand the slightest bit about the technology involved.

You have to admit that is funny. Wish I had mod points right now.

The CPU is already "unbundled" from everything to the maximum extent technically possible. They cannot "unbundle" it any further.

That isn't a plane flying past folks it's the whole Boeing corporation

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.

I am completely pedagogged. Will you marry me.

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.

Why should Intel supply the marketplace with a product that enables the consumer to use their competitor's product? They should just put all of the optimizations in for AMD and start to sell the compiler to anyone using it for their competitors products. Is there a law against that? Is this in some communist country?

Re:Well, duh.

[uninformedLuddite]

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.

You could even program his Engine Management System for him so as he might even win the race.

Re:Well, duh.

[MartinSchou]

Yes, but if you cut the cord for my controller in the middle of the match, I'm going to be quite rightfully pissed.

Don't get pissed - get even. Cut the cord for his controller and ... that special cord of his.

Re:Well, duh.

[shutdown -p now]

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?

Not always, no. Only if one of those two products designed to work together (and now also designed to exclude any third-party products) has a monopoly in its market segment.

Re:Well, duh.

[Anonymous Coward]

More than likely, it was a case of not knowing if the AMD version was 100% compatible with the Intel version of the same optimization. Intel certainly should not be expected to do 100% functionality testing on their competitors' chips.

So if the Intel compiler doesn't compile using that optimization with an AMD chip, even if the AMD version is 99.9% compatible, that is much better than compiling using the optimization and generating buggy machine code. Notice that there is no claim about not generating x86 compatible code? So the compiler isn't broken, it just isn't forcing use of optimizations on non-Intel chips even if they claim to support it.

You know what? That should be okay. If AMD wants to make an optimizing compiler, let them. Or, prove to Intel without any doubt that their version of the optimization is 100% compatible before insisting the optimization be supported by an Intel compiler.

No, I don't own an Intel based system, it's actually got an AMD processor, but I think it's ridiculous that what is very likely a value-added feature in a manufacturer's own compiler very likely intended to optimize their own processor optimizations as best as possible is even remotely considered as anti-competitive.

Read the FTC release

[RalphBNumbers]

The FTC press release 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

[modemboy]

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

[RightSaidFred99]

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

[RalphBNumbers]

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 saying it did.

Re:Read the FTC release

[RightSaidFred99]

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

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 saying Intel sold the Atom alone for more than the 3-chip set over and over like it's a fact and it's annoying.

Re:Read the FTC release

[RalphBNumbers]

Ok, given the prices listed here, 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 itself down to $25, that means the whole bundle would cost about $47. That's more than the $44 the Atom alone would cost but not by much, especially on the low end.

If my exact statement was untrue I apologize, but the core fact remains that Intel was using their processor pricing to undermine their chipset competitors.
That may be business as usual in some circumstances, but it's a problem if the business doing it is considered a monopoly, and even if they're not a monopoly it can be a problem if they're found to be dumping (ie, if the price of an Atom with a chipset bundle minus the price of an Atom alone is greater than the chipset's production costs, iirc).

Re:Read the FTC release

[cheesybagel]

They did the same thing with Centrino. A Centrino system contained a Pentium M processor with an Intel chipset. Intel gave kickbacks to companies which used both, in order to apply for the Centrino label.

Unintended consequences...

[MaWeiTao]

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

[Anonymous Coward]

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

[Changa_MC]

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

[Anonymous Coward]

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

[mdarksbane]

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

[Zenzilla]

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.

Interesting, but...

[tjstork]

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:Interesting, but...

[sznupi]

Intel's shenanigans (in general, not just this one) are very relevant, also when for example looking at Nehalem.

What do you think helped Intel finance their R&D in fabs and microarchitectures?

US FTC happily sues Intel, but allows Microsoft...

[YankDownUnder]

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

[StormReaver]

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

[Keep Six]

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.

[Anonymous Coward]

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

[Locke2005]

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!

Re:Not the worst thing Intel has done

[blair1q]

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, so they defaulted the behavior when the part wasn't an Intel part. Big whoop. AMD typically fabricated benchmark superiority by comparing software simulations of their unreleased products against released Intel parts that weren't even the current generation. How is that not a worse and more deliberate attempt to stifle sales of those Intel parts?

Re:Not the worst thing Intel has done

[jeff4747]

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?

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 program built with their compiler run poorly on AMD chips.

Re:Not the worst thing Intel has done

[vakuona]

Intel does not have to optimise for AMD. Intel should not use its dominant position in the hardware market to influence other software to be slower on AMDs processors. Because software vendors are going to be using the same compiler to compile software that should run on AMDs processors, then they have a duty to play fair. Imagine if Microsoft purchased AMD, and "optimised" Windows to run better on AMD CPUs by ignoring instructions that are present on Intel CPUs whilst using the very same instructions on AMD CPUs. There would be an almighty uproar. It's pretty much the same thing Intel is doing here.

HEAR

[Anonymous Coward]

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

[hesaigo999ca]

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

Re:WTF?

[BoothbyTCD]

Except, you know, for the Sherman Anti-Trust Act. But other then blatantly violating a bedrock law of American capitalism that has been on the books for 70+ years they were perfectly within their rights...

Re:WTF?

[hesaigo999ca]

I was specific about my point, purely about the fact they are being sued for having software they made for their cpus, which happens to work for another (by luck) and now they seem responsible
for its maintenance.....I was not talking about their other issues.

Bad man, very,very,very bad man.

I tend to avoid both Intel and nVidia

[thetoadwarrior]

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.

Re:I tend to avoid both Intel and nVidia

[blair1q]

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:I tend to avoid both Intel and nVidia

[thetoadwarrior]

I'm not saying my way holds any relevance. It's just my preference.

Re:I tend to avoid both Intel and nVidia

[Anonymous Coward]

Except for my laptops, which have been usually employer-provided, I've bought only AMD processors for my x86 boxes for the last 12 years.
Why? Because they've been Good Enough for what my clients, most of my friends and I do.

The very first AMD box I built, a K6, still works, although it's been only a kid's toy for several years.

I continue to support them because, without AMD, Intel would be a monopoly in both body and spirit.

Now, with Nehalem finally sporting most or all of the features, 10 years after, that allowed AMD to remain competitive with Chipzilla, I might consider an Intel
setup for my next rig but I'm waiting for USB 3.0 and SATA 6Gb/s to become more widely available.

Current Intel C++ compiler question

[st3v]

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

That charge was conclusively proven years ago

[Anonymous Coward]

Intel's compiler generates both "SSE2+ optimized" floating point code and "plain vanilla, slow" floating point code. Then at run-time, it uses the CPUID instruction to detect whether your CPU was manufactured by "Genu-ineI-ntel". If it is, then it jumps to the fast code (at run time). If it isn't, it jumps to the slow code.

This was proved a couple of years ago by reverse-engineering of the generated code. Patching out the check, so that all machines use the fast code, gives vastly improved floating point performance on AMD's chips--often better than on Intel's own chips! The obvious purpose of this "feature" (and the effect it actually has in practice) was to make Intel's CPU look good and make AMD's CPU look bad. Intel's excuse for doing this (which was basically "our competitors might not implement our custom instruction sets 100% perfectly, so its not safe to use them unless its definitely our chip") does not even pass the laugh test. The whole thing was a blatant anti-competitive measure to try and make AMD and other competitors look bad on benchmarks.

I hope the FTC really takes them to the cleaners over that, and all of their other slimy business practices. Sure we love to rail against Microsoft, but MS is definitely not the only dirty player in tech town.

Even if it was legal, it'd be a bad idea...

[Xenographic]

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

Be that as it may, their intent was clear. They could have done it the normal way, but they went out of their way to make a crappier product. And, frankly, if I catch anyone pulling crap like this (sabotaging their own products in the name of "competition"), I go out of my way to harm their business by any legal means possible. Granted, there's not much I can do against a giant company like Intel, but I'll still try. And I can hold a grudge like that for quite a while, unless they do an about-face. And even though I can only do so much, I don't think I'm the only person who does this.

In other words, even if you think that businesses can or should be able to do this, make damn sure you don't pull crap like this yourself. Because if enough customers like me find out, we can and will try to drive you out of business. Heck, I go one further. I'll shaft even the businesses of those who think it's their right to do something like this, because I believe that they would feed me intentionally crippled products given the opportunity.

And, incidentally, it's not their "right" anyhow. Read chapter 15 of the US Code, in particular the section Intel is accused of violating, per the FTC complaint.

That AC below has it exactly right: "The accusation is that the compiler probed to see if the CPU was AMD based and if it was it stopped all optimizations, not for user safety or reliability but just to fuck over AMD."

Onoz!

[Anonymous Coward]

So, what they're saying is that Intel's compiler produces better code on Intel chips? And that GCC still does not care? And that billions of dollars are going to get spent, ultimately, not to improve compiler performance?

Hell, let's all sue SGI! MIPSpro CC won't produce any code AT ALL unless you run it on a Silicon Graphics machine. It's a travesty - where's the justice?

Re:AMD/ATI FTW

[springbox]

I skipped nVidia's cards recently because of questionable power consumption

Sidebar..

[Anonymous Coward]

"...Suppose Microsoft wrote a piece of software that ran on any x86 CPU, but it did a special check to see whether you were running Mac OS X. If it detected a Mac, the software would exit -- even though it otherwise could run. Jerk move? Sure. But should it be illegal?..."

Isn't this why you can't install OSX on a "PC" computer? Doesn't the OS look for some little code that says "I'm REAL Mac hardware" or it doesn't install.

Why would this behavior be legal in this case?

EU hates US companies

[Anonymous Coward]

Oh noes! Those terrible EU socialists is attacking our brave American companies again!

Oh, wait...

SSE5 is not an Intel instruction set

[Michael Meissner]

Ummm, the SSE5 instruction was AMD's extension not Intel's. After SSE4, the next Intel instruction set is AES, CLMUL, FMA3, and AVX. After AVX came out, the SSE5 instructions were changed to XOP (integer vector), FMA4 (fused multiply/add using the SSE5 format instead of the Intel FMA3 format), and CVT16 instructions (conversion to/from 16-bit floating point). http://en.wikipedia.org/wiki/SSE5 http://en.wikipedia.org/wiki/Advanced_Vector_Extensions