Hacker News Reader

Comment by freehunter | Hacker News Reader

Intel is the market leader by a good margin, and in the past has been known to use unfair tactics to keep other players out of the market. AMD has been in a lot of lawsuits with Intel due to this.

In this case, it's not just that Intel isn't playing nice with AMD, it's that they're specifically using poor optimizations during compile if you're not using an Intel processor. That's not by accident, that's done on purpose to make non-Intel processors seem worse. What you're allowed to do while competing in the market changes when you're the dominant player in the market.

View on HN

I am usually not a free market extremist, but if Intel makes an excellent software product after years and millions of dollars in R&D, and make it only work for certain platforms, power to them.

The problem is that they penalized AMD without telling anyone. The market only works if you know what you're buying.

To make an obligatory car analogy, imagine if Ford opened up gas stations that sold really good gas, but this gas was somehow made to run much less efficiently in non-Ford cars. And further that they didn't tell anyone this, and just left you to assume that if you filled up your Prius with Ford gas and subsequently got 20MPG, the car was to blame.

It's even worse than that - since companies are distributing binaries compiled with icc, it's more like a Ford gas refinery distributing gas to normal gas stations that secretly runs terribly in other cars. There simply is no way for the consumer to know what they're getting.

This nock on effect is where the real harm is done. The fact that Intel is not checking for feature flags, but rather the existence of an Intel processor is actionable. They aren't following their own best practices for accessing optional features of the chip.

That analogy worked in 2005, but eight years on the fact that the Intel compiler optimizes primarily for Intel processors is common knowledge, and is explicitly stated by Intel repeatedly on all product materials. Invariably someone will bring up the "but what about benchmarks corrupted by this compiler" conspiracies, without a single example of a benchmark so contrived.

It's worth noting that performance and processors isn't as simple as "it has the feature, so use it". Each instructions have timings that vary on different models, and something like SSE(2|3|4) or AVX(2|512) can vary dramatically in its net benefit or detriment by the number of words, alignment, and so on. Many people with the ICC and code that they think will be super fast using it often are surprised to find it hasn't chosen to use them at all, simple setup and teardown eating all possible benefit.

In an ideal world we would have an open compilers that made best in class code for all major processors. Sadly that doesn't exist, and even now we have a case where a lot of the complaints about the ICC are "it crippled the code for my AMD....but still made better code than every other compiler".

People have pointed out that the "Intel" code is faster than the "AMD" code even on AMD chips, so the stuff about performance being difficult to achieve across different CPUs, while true, does not seem to be relevant.

All in all, you seem to be downplaying this far more than it deserves. It is not a case that the "compiler optimizes primarily for Intel processors". If it simply produced code built to be good on Intel and with no attention paid to AMD CPUs at all, that would be fine. Nobody would complain. Nobody would expect anything else, really. But that's not what they do: instead, they generate code that checks for an AMD CPU and then deliberately chooses a suboptimal path in that case. So it's not a case of "optimizes primarily for Intel processors", but rather "intentionally cripples performance on non-Intel processors". That is to say, there is a vast gulf between indifference and purposefully making things worse.

Your first statement does not follow at all.

Do people realize that we're talking very specifically about auto vectorization? This is a very unique, niche area of software (and it is absolutely an optimization, various hysterics notwithstanding), and this notion that various random software you're running are being "crippled" is utterly nonsensical.

I don't even understand what you're saying here.

We seem to be talking past each other, so let me briefly summarize what's going on, since you keep talking about optimizations and how difficult they are, and that just doesn't matter.

Intel's compiler produces multiple code paths, each one optimized for different CPU features.

The generated code always runs the slowest "fallback" code path on AMD CPUs.

Other code paths are still faster than the "fallback" path, even on AMD CPUs, despite not being optimized specifically for them.

Thus, Intel is artificially reducing the performance of their generated code on AMD CPUs. They put in more work to make this happen. If they had simply left out the CPU vendor check, AMD CPUs would perform better.

I stated that optimization is hard (each architecture has timings that impact when something is beneficial/when it isn't): Intel baked this into the ICC, but only for Intel targets (for obvious commercial reasons). You say that no, in some anecdote of apparently some anecdotal piece of code on some anecdotal set of data on some anecdotal AMD processor, this was disproven. But that doesn't disprove it in the general whatsoever. If Intel simply generated and ran Intel-targeted code always, we would have the same debate because why didn't they align their instructions and do it in such an order because that would be better on AMD.

It is entirely probable that simply running the "Intel" code chain will yield code slower than without on some sets of code with some sets of data, on some AMD architectures. Again, in most cases with vectorization you are not suddenly seeing a magnitude improvement, but rather something that can be marginal in some cases with some cases of data. It is a very hard problem, which is exactly why for all of the bluster the Intel Compiler is still considered the best compiler, 8 years into this controversy. AMD has been contributing to the Open64 compiler for years, but you don't hear much about it. And I'll bet their contributions don't put too much care into Intel processors.

1. Old versions of icc ran well on AMD.

2. New icc version adds check for "GenuineIntel".

3. New icc version now runs slowly on AMD.

This, like almost every counter point I've faced thus far, is simply wrong. It is manufactured reality.

ICC 8 added auto-vectorization. It, the very first auto-vectorization version, added the "GenuineIntel" branch for such vectorized code, because despite all of the fiction stated otherwise, vectorizing is actually a very hard task (hence why Intel maintains such a lead, and people are still griping about this 9 years after it came about).

I am hardly standing up for Intel, but this is Reddit-level conversation, where people simply say what they hope is true.

I don't understand your "because" statement. Intel added a check for Intel CPUs because vectorization is difficult. That's a complete non sequitur as far as I can tell. It makes as much sense as saying that I baked a chocolate cake because it rained yesterday.

Yes, various optimizations, including auto-vectorization, are difficult. Why does that mean Intel had to add a check for Intel CPUs in their compiler?

I'm a glutton for punishment, I suppose.

The Intel compiler makes tight, fast x86[^1]. It ALSO can optionally generate auto-vectorized code paths for specific Intel architectures (it is not simply "has feature versus doesn't have feature", but instead chooses the usage profile of features based on the runtime architecture. Each architecture has significant nuances, setup and teardown costs, etc, and anyone who says "they should just feature sniff" does not understand the factors, though that certainly doesn't stop them from having an opinion), for that small amount of niche code that can be vectorized. Saying that because they don't do the latter for AMD processors means they "crippled" them is nonsensical.

Just to be clear, I have heavily used the Intel compiler for back-office financial applications. I'm not just repeating some opinion I happened across. Nor do I have any particularly love for Intel.

Further, if you understand that Intel specifically targets specific Intel architectures with every branch path, saying "well just run it on all things", again, you simply don't understand the discussion, or the architecture based dispatcher. Yeah, "just run it" might run perfectly fine, and for a contrived example might yield better runtimes, but it also can yield runtime errors or actual performance losses.

As I have repeatedly stated, we should expect great cross architecture and platform (including ARM, which with NEON also has vectorization) compilation with auto-vectorization from the dominant compilers, including GCC, LLVM, and VC. But somehow it always returns to the Intel compiler, nine years after they publicly stated "Yeah, this is for Intel targets".

^1 - So much so that in almost all of these conversations, the people who complain about Intel compilers still use them because it still generates the fastest code for AMD processors, vectorization or not. Which is pretty bizarre, really.

Well, your explanation seems completely at odds with what is currently the top-voted comment in this discussion. The linked discussion of the patch he built to fix the problem indicates that the dispatcher does just do CPU feature detection. Here is the URL for reference:

http://www.swallowtail.org/naughty-intel.shtml

According to that, the code simply does a feature check for SSE, SSE2, and SSE3. Except it also does a check for "GenuineIntel" and treats its absence as "no SSE of any kind" even if the CPU otherwise indicates that it does SSE. That check is completely unnecessary and does nothing but slow (or crash!) the code on non-Intel CPUs.

If you still think that's wrong, could you post the relevant code to show it?

That link doesn't actually show what it does to determine whether to use SSE or SSE2 (much less SSE3 and beyond). That it derives a boolean value is not the same as feature detection.

Further the bulk of that entry was from 2004, which is pertinent given that at the time the new Pentium 4 was the first Intel processor with SSE2, and the SSE implementation on the Pentium III was somewhat of a disaster -- both single-precision width (it simulated 128-bits through two 64-bit operations, and for the P3 compilers could optimize for its specific handicap), and sharing resources with the floating point unit. So the feature flag, coupled with "GenuineIntel", was all they needed to know for the two possible Intel variants with support.

Since then the dispatcher and options have grown dramatically more complex as the number of architectures and permutations have exploded.

Well, here's a complete analysis of the function:

http://publicclu2.blogspot.com/2013/05/analysis-of-intel-com...

Unfortunately, it doesn't show the raw assembly. But in the absence of any information to the contrary, I'm perfectly happy to trust this pseudocode. It shows a bunch of feature checks, preceded by a single "GenuineIntel" check. The code that's gated on "GenuineIntel" would work just fine on non-Intel CPUs. It might sometimes produce sub-optimal results, but overall it'll be fine. There are some CPU family checks, but my understanding is that non-Intel CPUs return the same values that Intel CPUs do for similar architectures/capabilities.

We have multiple people saying that the code runs faster if the "GenuineIntel" checks are removed, we have pseudocode for the function in question that shows a bunch of feature detection with a bit of CPU family detection, neither of which are at all Intel specific. And then we have you, who can't seem to substantiate your claims at all.

If you have actual code or other reasonable evidence to support what you're saying, I'd love to see it. But right now, I'm not buying it.

"If Intel simply generated and ran Intel-targeted code always, we would have the same debate because why didn't they align their instructions and do it in such an order because that would be better on AMD."

That same debate might happen. But I doubt we'd see it, because most people would dismiss such a debate as stupid. Why would Intel put any effort into making their compiler optimize code for AMD CPUs?

Again: there is a world of difference between simply not optimizing for AMD, and deliberately running slow code when an AMD CPU is detected.

If Intel just checked CPU features and decided based on that, would it still produce bad code for AMD sometimes? Probably. Would it be as slow? Doesn't sound like it, from people with real-world experience with the compilers. Would people still complain? Yes. Would those complaints have any merit? No.

Just to join the chorus: it's not a hard problem. Intel intentionally adds code to the executables produced by their compiler so as to limit their performance on non-Intel CPUs. They lost a federal lawsuit filed by the FCC on deceptive practices because they did not inform their customers, who thought they were buying a working compiler, that they were doing this.

Instead of simply removing this code, which serves no purpose other than degrade performance on non-Intel CPUs, they reached an agreement to put legal disclaimers on every web page mentioning their compiler that they reserve the right to do this. But because of the slick legal language of the disclosure, most people get the impression that they are simply failing to make AMD specific optimizations, rather than intentionally preventing non-Intel CPUs from utilizing the optimizations already present in the code.

I think we all agree that at this point Intel's practice is fully legal. Their engineers should feel proud of having built a really solid compiler. But Intel-the-company deserves to be shamed for its slimy underhanded practices, and the engineers should feel a certain amount of revulsion for allowing themselves to be used in this way. Perhaps if they stood up for the obvious right approach, they could help change the company for the better.

> People have pointed out that the "Intel" code is faster than the "AMD" code even on AMD chips, so the stuff about performance being difficult to achieve across different CPUs, while true, does not seem to be relevant.

It is relevant, if you consider that optimization isn't just counting cycles at individual instructions. Some optimization pass may be CPU agnostic (and the difference of performances between compilers on AMD probably show that aspect), and some very well depend on CPU peculiarities.

Also, if Intel must provide good support for all AMD chips, then they will have to do the same for any other competitor (and there are some iirc).

> they generate code that checks for an AMD CPU

Is it really what they do? Are they checking for "GenuineIntel" CPU, or for "AuthenticAMD" ones? There's a slight difference, even if AMD is their only real competitor atm.

"Also, if Intel must provide good support for all AMD chips, then they will have to do the same for any other competitor (and there are some iirc)."

Again, nobody in this discussion is saying that Intel must provide good support for all AMD chips. All anyone is saying is that Intel should stop explicitly checking for non-Intel chips and running deliberately slow code on them.

Again, it would be just fine if Intel optimized their compiler exclusively for Intel CPUs and let non-Intel CPUs deal with whatever code they generated. That's what everyone would expect Intel to do. Nobody sane expects Intel to optimize for AMD CPUs in their compiler. We just expect Intel not to put extra effort into crippling them.

I understand you. But, is it possible that say, between two features, say SSE 4 and AVX, the less powerfull one happens to be the most efficient for a given algorithm on platform A, and the least efficient on platform B? If yes, how would a the compiler know which path to choose without knowing which platform it is targeting?

It wouldn't, but the sane way to handle that would be to special-case platform A, and let platform B fall back to feature detection, rather than falling back to the worst possible code.

All right, then I suppose that what you are saying is that Intel should leave the genuine Intel chips detection out, and let customers implement specialized paths for AMD products, if the automatically selected path happens to underperform (for a certain performance expectation level), which might be less likely to occur if all the generated paths are available. Did I get this right?

And for people looking to extract every last bit of power from their chips (AMD or not), they might have to implement the path by hand anyway.

> rather than falling back to the worst possible code.

Note that (I think it might have been said elsewhere), it's not the worst possible code, but the least efficient one generated by the compiler (which happens to be quite good already). /pedantic mode

Edit: clarifications.

There are two reasonable choices for Intel to follow:

1. They decide to implement the best possible x86 compiler for all CPU vendors. In this case, they optimize for AMD chips (and anyone else selling x86 chips) just like they currently do for Intel, possibly including AMD-specific code paths.

2. They decide to implement the best possible compiler for Intel x86 CPUs. In this case, they should just ignore the existence of other vendors and do the best they can for their own stuff. If it runs fast on AMD, great. If it doesn't, not their problem.

I'm not sure which of those two what you said falls under, but I think it's one of those. Unfortunately, they have chosen a third path, where not only do they specialize for Intel, but they check for non-Intel and deliberately pessimize performance there.

2nd choice (sorry for my confused english). But then there might be legal consequences to factor in. Engineers shouldn't probably care about that.

As for the first choice, ideally Intel should do that to provide the best possible compiler out there, but that would really be shooting oneself in the foot, unless they are guaranteed to always have the upper hand on the hardware side. It would also require them to study AMD cpus deeply (how instructions get translated to microcode, how that microcode is optimized, etc) - they probably have people doing that (if that's legal).

Thanks for taking the time to answer me.

Edit: modified my upper comment.

You cannot give these companies an inch with stuff like this. In 2014, we're spoiled and for the most part don't realize that our network providers aren't the only potential toll keepers nickel and dimeing us.

I don't know if you are familiar with mainframe or similar computing technologies. When you buy an IBM mainframe (or Power unix box to a lesser extent), you're essentially metered by a CPU budget. You're not permitted to use the full capacity of your system unless you pay.

This case is a little different, but the point stands. Companies should not be allowed to sabotage the competition or hobble the ability of a device capable of doing a task from doing it. The free market works when the stakeholders don't cheat.

Intel is not the market leader in compilers, however: It is somewhat rare to come across teams using the Intel compiler, and they tend to be in niche modeling/simulation or financial realms, more often than not with the sort of code that you compile for a specific piece of deployment hardware, compiling again when you move it to something different.

Intel makes the ICC seemingly to try to encourage the adoption of newer features in newer processors -- multi-threading for many-core processors, SSE, SSE2, SSE3, AVX, AVX2, soon AVX-512, etc. It is worth noting that simply using a feature (e.g. SSE, AVX) because it is there does not guarantee performance improvements in all scenarios -- the ICC uses specific model timings to make some of its choices.

The obvious solution for this problem is to never have a reason to use the ICC compiler. For the auto-vectorization and use of things like AVX be as advanced in gcc, llvm, and even the Microsoft compiler.

Have you ever seen benchmarks to suggest that Intel is not the market leader in compilers is actually true?

That comment was in relation to market share, not performance. Few would argue that Intel has more than a low single-digit percentage market share of the overall compiler market. People should be far, far more concerned about how GCC, llvm and Visual Studio do in vectorizing code to SSE/AVX.

So if we were to define "market" as "compilers that people pay money for", would Intel be market leader then? (Certainly not a common definition, I agree.)

The gaming industry does use it quite often. It is the Watcom compiler of the modern times.

Reply on news.ycombinator.com