Intel's "cripple AMD" function (2009)

http://www.agner.org/optimize/blog/read.php?i=49

by luu • 13 years ago

356 124 13 years ago

gcp• 13 years ago

This is an old article. As far as I know, the settlement that was been reached was entirely laughable and most certainly doesn't remove the "cripple AMD" function. Now Intel just has to notify customers that it may not get optimal performance on other CPUs, and reimburse them the cost of the compiler if they can demonstrate that they mistakenly bought the compiler thinking that wouldn't happen, or something like that.

There is no new info in the linked article regarding the "new" FTC investigation.

wmf5• 13 years ago

(2009)

Since then Intel settled the lawsuit by paying $10M and agreeing to add the following disclaimer to their compilers: "Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors..." http://software.intel.com/en-us/articles/optimization-notice... http://www.anandtech.com/show/3839/intel-settles-with-the-ft...

lotyrin2• 13 years ago

Yep, and that's been interpreted such that - just in case - we add a link on every page of software.intel.com to http://software.intel.com/en-us/articles/optimization-notice

Whether or not the current page has anything to do with compilers.

Also, judging by the URL they made it an 'article' instead of a 'page' again... I'll have to see if I can get someone to fix that.

nowarninglabel• 13 years ago

Happy to see you guys are using Drupal. I usually remove article as one of the first steps in an install and replace with something that confuses people less and/or restrict permissions appropriately, but it's hard to always get people to always follow the right path.

shocks• 13 years ago

I presume the notices are images so they can't be indexed by search engines?...

tharko• 13 years ago

The notice is only visible in Italian, Chinese, and Korean

fnordfnordfnord• 13 years ago

Intel paid $10M into a pool to reimburse customers who purchased the Intel compiler. Intel later paid over $1B to AMD settling a number of cases with AMD and the US DOJ. Intel was also fined by the EU ca 2009.

gwern• 13 years ago

Since then Intel settled the lawsuit by paying $10M and agreeing to add the following disclaimer to their compilers

Is it just me or does that not actually fix the problem?

fnimick2• 13 years ago

It fixes the legal problem. Intel isn't required to provide an optimized compiler for competitors' chips, but it is required to note that its compiler that is compatible with those chips doesn't optimize code for them.

I don't agree either, but it's a perfectly valid solution (and probably the best for Intel's bottom line).

berkut2• 13 years ago

There are several benchmarks out there showing that the Intel compiler can give a boost for AMD chips over MS VC++ and MingG++ on Windows.

They should have originally used supported flags for different features instead of blacklisting the name, but it's still difficult to know what chips support what and whether it's worth using those features, due to different instruction latency, etc.

ICC get register dynamic code switching to different paths in the exe, so that if the chip supports AVX2, it'll use that code path.

gcb02• 13 years ago

intel paid more than 10M to lawyers so they could debate on legalities of the law instead of the intent of the law, hence not having to fix the problem.

they are not worried about fines. fines are cheap for those companies. they are worried about market control.

they are what they are thanks to phoenix reverse engineering IBM bios and the rise of the generic PC market. Now they fear anyone that can enter the market as easily as they entered and hope to not make the same mistake IBM did.

TwoBit• 13 years ago

How does the Intel compiler compare to others today? We tried using it for game development years ago and it had too many problems to make it worthwhile (e.g. pathological behavior with some C++ code).

nkurz3• 13 years ago

I'm disgusted by their intentionally poor performance on AMD, but Intel's compiler is excellent. I often optimize numeric and SIMD functions for x64 on Linux, and regularly compare the generated assembly code of current versions of GCC, CLang and Intel compilers. I have no experience with MSVC. I'm often using the C++ compiler, but the code is usually straight C and inline assembly.

In my anecdotal opinion, Intel produces faster and better code than GCC and CLang about 2/3 of the time, with GCC usually second, and CLang slowest. I love the idea of CLang, but so far find it's main advantage to be clearer error messages rather than fast code.

Bugwise, I think they all are about equal. Intel's weakness right now (for my work) is that it crumbles under very high vector register pressure. And as a free academic licensee, support seems limited to posting on a forum and hoping a relevant Intel employee wanders by.

If I had just one shot for a compile and was hoping for the best outcome without being able to test and verify, I'd compile with Intel. But considering that GCC comes with source, has a much larger community, and accessible bug trackers, it's probably a better day-to-day compiler. But if you are trying to maximize performance, you should definitely try out Intel.

moconnor• 13 years ago

The Intel compiler is extremely good at finding and exploiting vectorization (SSE/AVX) opportunities; using these instructions in hot loops is becoming key to getting anywhere near peak performance out of modern CPUs.

Most people don't care enough about performance to notice, but recompiling with Intel's compiler often shows a 5-15% difference on number crunching codes and that's before spending time investigating the vectorization output and fine-tuning.

On the other hand, if you really care about speed then someone with some experience in performance tuning will typically be able to make your code run 4-8x faster, vastly outweighing any benefits from the compiler.

sounds5• 13 years ago

Just in case you skimmed moconnor's comment, it bears repeating:

Intel's compiler: 15% speedup

Hand-optimized code: 800% speedup

This gap in compiler tech is still a big deal today. Think about the early mainframes and how the code was all written in machine code or assembler. http://www.pbm.com/~lindahl/mel.html

Compilers can still improve, a lot.

• Parallel code? _still_ hand-written, even though choosing the right language/library can help. Note that choosing that language that makes parallelism easy may cost you when you actually go for the max parallel speedup

• GPU? hand-written. See: litecoin miners and bitcoin miners before that. OpenCL but were hand-tuned for a specific architecture

• Cross-platform? Java and C should be portable, but ask any Android developer how it really works

• And the one we're talking about here: number-crunching code? hand optimized!

I'm actually quite optimistic about the future of compilers. One of the reasons HN is so fun to read is that it comes up often.

w1ntermute• 13 years ago

Can you spoof AMD CPUs to return "GenuineIntel" instead of "AuthenticAMD"?

staticfish• 13 years ago

Couldn't that also potentially break some logic branch through the chip where the app is expected to be running on a GenuineIntel processor? I'm not well versed in this.

sounds5• 13 years ago

Not likely. AMD processors are very carefully designed to correctly execute code, even if it just assumes GenuineIntel and never even checks.

If code is dumb enough to try to use something low-level (let's use Bull Mountain RDRAND as an example) without checking for that specific feature bit, then it obviously is the code that is broken, leading to an illegal operation and it gets killed. That's not the CPU's fault.

Intel and AMD CPU manuals both pound in the point, too. In the sections on these advanced features they always insist that you check the feature bit first.

berkut2• 13 years ago

Possibly, as Intel's compiler uses dynamic code-path selection based on the processor.

But more likely, it would mean slower code execution, as the code path wouldn't be optimised for AMD:

i.e. if the processor check thinks it's running an i7 Sandy Bridge, with an SSE float divide latency of 11, but the AMD chip has a latency of 23, so the unrolled loop that worked well for the i7 doesn't work at all for the AMD chip.

haberman• 13 years ago

Search the linked page for "CPUID manipulation program for AMD" -- there is some info about this.

Apparently when run under virtualization, the CPUID instruction is intercepted and can thus be manipulated. There's also a github project for patching binaries generated from ICC to run the optimal code-paths even for AMD. But there doesn't seem to be a way to manipulate the hardware itself to change its vendor string.

happycube• 13 years ago

At this point, does intel need that function to make AMD's CPU cores look bad?

wmf5• 13 years ago

You're talking about a company whose motto is "only the paranoid survive". Why win when you can utterly dominate?

salient2• 13 years ago

I don't think that's been their motto since Otellini took over. Look where they are now in the mobile market. Otellini put the profitability of their Core chips above improving Atom in the first few years, even when it came to netbook performance, which was already terrible. Combined with the fact that they forced OEMs to not buy AMD alternatives during the same time, Otellini just didn't think it's necessary to improve the performance of Atom too much.

They only started caring about power consumption when it was already obvious to everyone that ARM is going to pose a threat to them eventually. I think if everyone sees something that's by definition not "paranoia". To be paranoid, you have to see and believe something before others see it.

ibrahima• 13 years ago

The thing that's sad is that if Intel hadn't taken so many unethical approaches to keeping AMD down when it actually was competitive with Intel on performance, the market could look totally different today. Back in the Athlon XP and early Athlon 64 days AMD was routinely ahead in benchmarks as well as power consumption, while P4 blustered along with higher and higher clock speeds. If they had gotten the market share their performance "deserved" (in some abstract sense, of course), they could have put more money into R&D and developed better follow on products. Instead, their market share grew only slowly, and eventually when Intel got back to improving performance AMD just fell behind and never recovered.

Intel's engineering prowess has to be respected, but how they got there by abusing their market position is deplorable. At this point I don't think there is any rational reason to buy AMD at any price point, they've been dominated so hard. (Buying ATI may not have helped, but these days that's the only part of AMD that's even still competitive.)

Fasebook• 13 years ago

AMD has 10-16 core server CPUs that are very price competitive with Intel's Xeon performance. They generate more heat however, so they are not economic in datacenters for energy usage reasons, but they are ideal for getting the most powerful workstation possible.

sounds5• 13 years ago

Article is from 2009 but Agner's CPU optimizations manual is still very useful.

http://www.agner.org/optimize/optimizing_cpp.pdf

Instructions on how to patch Intel's CPU detection routine to do your bidding is in section 13.7, pp. 132-133.

The 2009 article also has this interesting tidbit: "It is possible to change the CPUID of AMD processors by using the AMD virtualization instructions. I hope that somebody will volunteer to make a program for this purpose. This will make it easy for anybody to check if their benchmark is fair and to improve the performance of software compiled with the Intel compiler on AMD processors."

dchichkov2• 13 years ago

I've ran into it in practice a few years back, while making WRF (math intensive atmospheric modeling software, I'm maintaining non-commercial soaring prediction site for the bay area) to work on my AMD cluster. Had to patch the executable compiled with the Intel compiler in order to make it work unhindered on AMD's. The patch was just zapping 'Genuine Intel' detection code in the compiled executable... That 'post-linker' patch is available here: http://www.swallowtail.org/naughty-intel.shtml

neurostimulant• 13 years ago

Why not just recompile wrf from source? Dependency hell?

aylons• 13 years ago

Probably it wouldn't work so nice with other compiler. This level of optimization often requires compiler - specific syntax.

Not to say Intel optimization is really good.

greatzebu• 13 years ago

I was trying to build WRF from source a few years ago for a project in grad school, and the bulk of the program was one giant file that crashed gfortran when you tried to compile it. So compiling with a non-Intel compiler can present some problems.

dchichkov2• 13 years ago

Er, I was building it from source... Don't remember exactly was blocking me from using GCC, vaguely remember something about OpenMP support... The config in question was MPI+OpenMP, where OpenMP was used to parallelize withing a node of a cluster and MPI for the cluster itself.

agumonkey3• 13 years ago

Bothered me when I realized that maybe mainstream reviews (the ones able influence the average mass market buyer) were using binaries very biased in favor of intel.

GhotiFish2• 13 years ago

What bothers me is that if a mainstream reviewer benchmarks ICC compiled programs, well, that isn't unfair. Real world programs are compiled with that compiler. AMD processors actually WILL under-perform on certain programs because of this.

That leaves a bad taste in my mouth.

agumonkey3• 13 years ago

How much ICC compiled binaries represent ? I guess on MS Windows it's the vast majority so you're right[1] but on other platform it's probably GCC/Clang, and there neither Intel or AMD are favorited.

[1] or maybe not ? are MS Cxx compilers inheriting from Intel ones ?

wmf5• 13 years ago

Maybe any program compiled with ICC should have the same disclaimer as ICC itself so people know that the program is biased.

aeonsky2• 13 years ago

I'm still not entirely sure why is Intel forced to do this? Is it only because they advertise that it optimizes equally well for any CPU? If not, then I don't really see why they can force them to provide another AMD-friendly version.

rcxdude• 13 years ago

It's because they specifically check for an intel chip, but the 'intel-optimised' version is also faster on AMD chips than the default (and they are well aware of this). Regardless of their advertising it's a scummy and anticompetitive move.

freehunter• 13 years ago

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.

aeonsky2• 13 years ago

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.

corresation8• 13 years ago

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.

nkurz3• 13 years ago

Yes, the this part of the settlement was based on buyers of Intel's compiler being misled into thinking that it produced good code for all processors. Intel is not forced to change their compiler to produce reasonable code on AMD, only to disclose this practice.

http://www.anandtech.com/show/3839/intel-settles-with-the-ft...

Intel's behavior continues to be scummy and reprehensible, but by adding the disclaimer to all pages regarding the compiler they are now legally compliant. Still, it's a good enough compiler that at times it may be worth using and patching the binary to avoid their dirty tricks.

bd_at_rivenhill• 13 years ago

This all seems to indicate that the intel compiler emits multiple, cpu-dependant code paths for a given binary, which seems insane to me due to the amount of extra memory that this would require. Am I missing something here?

tbrownaw• 13 years ago

Probably no more insane than loop unrolling, which I understand is fairly standard and well-accepted.

userbinator2• 13 years ago

Loop unrolling is actually becoming somewhat of an outdated technique for modern processors:

http://www.agner.org/optimize/blog/read.php?i=142 "It is so important to economize the use of the micro-op cache that I would give the advice never to unroll loops."

I don't know how AMD compares.

wmf5• 13 years ago

Usually code isn't that big and maybe these optimizations are only used sparingly so that most of the code is shared.

stephencanon• 13 years ago

Extra code on disk doesn’t cost anything (well disk space, but that is “free” for practical purposes). A compiler can arrange so that all of the code for a given architecture appeared consecutively in the binary, and then the pages and cachelines containing implementations unused by the processor on which you are running are never loaded into memory / never take up space in the cache.

Also, in practice code is a tiny portion of the size of a typical application. Far more space is consumed by resources like images and sounds.

gonzo• 13 years ago

You mean "data".

raverbashing2• 13 years ago

And the question is: how about we stop paying Intel for an unfair product?

I know, their compiler produces the fastest code, but maybe you can get good (enough) results by using libraries and maybe some manual optimization

salient2• 13 years ago

Intel is one of the least ethical tech companies around. Have they even paid their 1 billion euro fine to the EU Commission yet for trying to force OEMs to not use AMD chips in their products?

http://www.engadget.com/2009/05/13/intel-fined-1-45-billion-...

boyter• 13 years ago

I wouldn't be surprised if they had. Off the top of my head they made over $7 billion doing this and can consider the fine as a cost of doing business.

sitkack2• 13 years ago

When companies do this, they should be fully audited and fined 300% profit, split evenly between the harmed company and the government. If that puts them out of business, so be it.

welterde• 13 years ago

There is plenty of space to the bottom though.. Intel at least publishes datasheets, technical documentation, etc. without requiring signing a NDA for most of their chips..

So in my books they still do quite a bit better than Broadcom, Realtek, etc.

userbinator2• 13 years ago

I agree, although Intel is still not as open as they were back in the e.g. 8086 days - stuff related to the BIOS/memory controller init sequence is still AFAIK requiring NDA.

Better than AMD, at least - just try finding the pinout of socket AM2, which was released over 7 years ago.

pconf• 13 years ago

This is one of the reasons I only purchase AMD-based systems. Well that and the fact that AMD's CPU/GMU combo has better graphics performance.

It's either that or support a company whose market advantage is based on anti-competitive practices and who will spend a significant portion of their profits on reducing consumer's choice of CPU (up to the point they no longer have to of course).

coldcode2• 13 years ago

When I worked for a game company we used the Intel compiler for a couple of versions but it caused so many issues for people with AMD we switched back to the MS compiler. In the end the performance difference wasn't enough to matter.

fzltrp7• 13 years ago

That's interesting: could you elaborate on those problems? I was pretty much supporing Intel on the ground that their competitors products were just running a safe path, but your input might change my view entirely.

coldcode2• 13 years ago

It wouldn't be useful anymore, that was 3-4 years ago. At the time besides having AMD issues we had floating point optimization issues which messed up our physics. I doubt it's an issue today.

jrockway• 13 years ago

If I were AMD, I'd just start calling my processor GenuineIntel. (Or maybe make it user programmable, and then absolve myself of any knowledge of what users are setting it to.) When the judge asks why, I'd say because those are the magic words to make certain binaries run faster, and I wanted to run a viable processor business.

This is not an acceptable use of trademarks.

fzltrp7• 13 years ago

This is not an acceptable use of trademarks.

But if you were Intel, would you have your engineers work on competitors' products to make sure they are well supported on your line of tools? Before making an answer, consider that the core implementation of AMD cpus differ significanrly from those of Intel: instruction timings are slightly different, whether you look at them individually or in groups. It's not just a matter of turning a switch to get optimal performances, and that's just the tip of the iceberg.

Now, from a business standpoint, I think it could make sense for them to make their compiler produce fast code for any chip, but the legal implications of having a conccurent's product burn because of code produced with your compiler might make you think twice before going that road. Intel probably chose the safe road for a reason. Also, note that the produced code isn't crippled (as in, it doesn't make AMD cpu execute endless loops, or produce wrong results more than Intel's ones), it just follow the safest path.

hvidgaard• 13 years ago

Add another flag to the compiler to produce code optimized code for any CPU with the warning that it's only been verified to work with Intel CPUs. With todays CPU I do not buy the "safest path" argument - perhaps I could accept that "we only default enable it for implementations we have verified in-house", which makes a lot of sense.

This sounds a lot more like Intel know they make the best compiler, and knowingly put non Intel CPUs at a disadvantage because it would seem that they have a faster CPU.

fest2• 13 years ago

Isn't this crippling a compile-time thing?

Is there something in binary that executes best-performing instructions (as opposed to execute just the instructions compiled in) when it's being executed on a specific CPU? If so, how exactly does it work?

neolefty• 13 years ago

It's actually a runtime switch. A compiled x86 binary that uses extra-wide number-crunching instructions (SSE etc) must also work on older processors that don't have those instructions, so it will have two or more code paths. The code paths all perform equivalent computations, but using different instructions.

For example, if you are adding 4 pairs of 64-bit numbers, and there's a special add-4-pairs-of-64-bit-numbers instruction, but it's specified as part of SSE4 (I made that up, but it's the kind of thing that you would find), then you can ask the CPU if it supports SSE4. If it does, then you say great, use this code path that requires SSE4, and we'll do the whole operation in three instructions: load, add, store. Or something.

However, if the CPU says that it doesn't support SSE4, then you'd better have a backup plan. It doesn't have to run as fast, but it should compute the same answer. If it's compiled C code (as opposed to hand-written assembler), the compiler will have you covered. Instead of a single SSE4 instruction, maybe it will take 4 regular 64-bit x86 add instructions instead.

(And if you've written it in assembler, then you probably provided the compiler with a backup C implementation to use if SSE4 isn't supported.)

Intel's compiler is being unfair to AMD CPUs because -- even if they support the instructions that you want -- it won't use them. It will unnecessarily fall back to the plain old non-SSE x86 instructions.

fest2• 13 years ago

Thanks for your answer, it did not occur to me initially, but it makes a lot of sense!

Intel's "cripple AMD" function (2009)

Related Stories