Intel's compiler cripples code on AMD and VIA chips

@Deanjo
AMD uses the string "AuthenticAMD" not "Genuine AMD"
And it's sort of cute how it's a play on the genuine thing.

"For the brainwashed Intel zealots who don't get it, or can't read let me just repeat what Deanjo said above!

[...]"

Once again for the benefit of those who are a little slow in the head. Patents are a government granted monopoly; they do not grant rights to their owner, they dimish the (non-IP) property rights of non-holders.

Abolish this government granted monopoly and you don't have to prevent Sony from making HD playback from Sony's bluray players only available on Sony TVs. Only an idiot would buy a Sony bluray player, sane people would wait a year or two for the bluray clone players to show up that can play back HD from bluray discs on any TV.

Even with patents, if Sony had done this the HD-DVD format would have won and Sony would have lost money.

This was noticed years ago. Essentially what happens is that if you don't have an Intel processor, it falls back to a vanilla 386-compatible code path, regardless of whether the processor indicates that it supports MMX/SSE/etc or not.

It's not that the compiled code uses SSE2 but is optimized for Intel processors without regard for AMD's implementations. There'd be no issues at all in that case. It's that if it detects that you're not running an Intel processor, it executes different code that *doesn't even use SSE2*. This makes a huge difference in many workloads.

When we were using the Intel compiler, we patched the binaries to essentially remove the vendor ID checks prior to release so that the code path would be selected based on our customers' CPU capabilities, not who manufacturered them.

Unfortunately, outside of people who were seriously chasing performance, not many people knew about it. Intel set their suits on anyone who published ways (or software) to patch around the checks, so it wasn't widely publicized. The end result is a lot of software out there runs much more slowly than it should on non-Intel processors.

I have worked with the ICC lately and I don't see the problem. Generic compiler options tell the compiler to include that alternative code which may slow down execution on non-Intel CPU's but there is also a compiler switch which tells the compiler not to generate that alternative code. You get sleeker binaries that run exactly the same code on every cpu. However, you have to make sure yourself that the target cpu supports the compiled instruction set since there is no fall-back mode anymore. The main intention behind the alternative code paths is compliance and not performance. Keep that in mind.

I don't understand why anybody gets outraged. This is nothing new, has been reported for years and any coder worth their money knows that Intel compilers optimize for Intel CPUs.

If it bothers the coder, go with a Microsoft or GNU compiler, easy peasy.

As for the end-user, complain to the software vendor if you know they're using Intel's compiler.

I am thinking some of the readers of this story are BLIND!!!! Either literally, or blind with love for Intel..

The fact that Intel optimizes code for its processors is fine... no problem there...

The problem arises when compiling code for other processors. The allegation that they make the code run as SLOWLY as possible is absolutely huge. I don't have a problem with them not optimizing competitor code but if allegations are true, it's a terrible thing indeed and they should be spanked.

No wonder why Intel performs significantly better in many synthetic benchmarks compared to AMD. But AMD seems to perform the same or even better in the real world.

This answers it for me.

OK I have an Intel CPU, I have an AMD CPU and have had others, there was one VIA in there ages ago but at this time it does not matter. The issue is that applications are then distributed into the marketplace with the assumption that the code runs equally well on an AMD and a Intel CPU all things being equal but the vendor id string.

This is not the case. Since AMD is licensing the x86 instruction set from Intel and several additions to that set (MMX, SSE... ETC) Intel knows darn well what instructions are enabled and not enabled in an AMD CPU. Do they have to support it? NO. Do they have to disclose that the complier will not optimize code for a non-Intel Processor? (answer forthcomming). Does a developer have the responsibility to understand what the product they are using is doing? YES

That last question puts it on Intel's shoulders to disclose what the heck their compiler is doing. I think this is in the best interests of computing in general... Just like I can write an application with a dialog box that says YES/NO and make both buttons do yes anyway, And also include a EULA that says any damage to your computer by this software is not my responsibility. Accountability in software development from the tools to product is very shabby, And this is just another continued example.

Intel is causeing more CPU cycles because of this. They should be paying my power bill, staffing charges, and be held accountable to the almighty Al Gore for why they are increasing the damn carbon footprint.

Intel has been systematically acquiring compiler companies, embedded operating systems, and other low-level software companies with the apparent objective of strengthening x86 support throughout the software ecosystem and deliberately weakening non-Intel, non-x86 support at the same time. So this is a classic case of using the economic power of one monopoly to extend into adjacent markets, simultaneously strengthening the original monopoly (which in this case is by far the dominant interest).

What I wanted to say when mentioning my software was that I find it quite natural not to expect much from Intel compiler code on non-Intel CPUs, regardless of what it does to work worse on these.

It's a compiler made by Intel to exploit specifically their CPU's features. Now while it's not exactly nice that it choses the slowest code path on non-Intel CPUs, I never even used or recommended using the Intel builds of my software on non-Intel CPUs. So what.

...is there actual evidence of the machine checks/vendor string checks being performed, or is this more a case of it not trusting a CPU to have MMX/SSE/etc (even if it claims to) if it's not their own?

The latter would be more excusable than the former; it's not 100% easy to tell which path is going to be most optimal.

To those who are complaining: Well write your own you dopey lot nobody forces you to use Intel software or do they?

For the brainwashed Intel zealots who don't get it, or can't read let me just repeat what Deanjo said above!

"Think of it this way, what intel does would be the same as Sony limiting HD playback to 480p from Bluray when a non Sony TV is detected despite the TV being perfectly capable."

When did Intel's compiler become free? I remember, back when I coded, you had to pay thousands per station for their compilers.

Intel is not obligated, under any circumstances, to optimize for other vendors' chips, no matter what capabilities they may claim they have. In fact, the only way Intel could be hit by a lawsuit is if they generated code that *cannot* be executed by another vendors' chips. Just because some other chips supposedly support processor extensions, instruction ordering, or other optimization features that are compatible with Intel's own chips doesn't mean Intel can or should provide support for it on their own compiler.

Intel can simply claim that when they identify a chip from a vendor that is not Intel they cannot guarantee that an optimization will actually improve performance, or perhaps may result in unexecutable code. In such a case, the compiler defaults to the most generic code generation path, ensuring maximum compatibility.

boy that puts a lot of benchmarks showing intel as the "better" cpu in the trash
but then again i wouldnt buy an intel in the first place
cpu = over-priced
chip-sets = over-priced

It's an Intel compiler - what do you expect? That it optimzies code for the competition?

How much money did AMD and VIA contribute to the development cost of the compiler?

If you want optimal code for a specific CPU architecture, then go and ask the CPU supplier for a recommendation.

If Intel supports an compiler option for AMD and VIA then they will do their best and also will go the "savest" way, which means "most converative" way since they are not the originator of those architectures and thus make sure that the code works as best as possible. But they will not invest an unappropriate amount of time to get the last bit of performance.

Would you spend to working time to make sure a competitor looks as best as possible and even go extra miles without getting paid for it?

Use Intel an compiler for Intel CPUs, use other compilers for other architectures.

Hold the pickles
Hold the lettuce
All we ask is that you get us
Special Sauce

As licensor of all things x86, spIntel's compiler, committed to in-order loads from cacheable memory, must arbitrate how the x86 race, Not prejudiced by chipset, mmc, multi-threading, unless the genetics of which said is entirely known at run time.

To cover every possible gene pair, would be akin to executing fat babies.

So certain birth control practises if the father is known at the time as immaculate conception, but how can satan cast out satan?

A proper setup berth would call for proper Umbilical cord care, if only a stub, if the heart drive is transpanted in another motherboard.

Remember, one man's happy meal is another's Okosama Set.

Oh no. I must be thinking in Drashek.

...the Feds will add on another $500 million fine to InHell for this crime.

Ah, yes. If all the "apparently"s and "appears" innuendo by the press and commentators are true, I'd agree it's nasty. But all we know now is that Intel provides a free compiler to support their processors and it apparently doesn't do as good a job optimizing code for competitor's CPUs --- which they don't have to support at all. It's actually not surprising that machine code for new special Intel features or instructions would be faster than generic instructions supported by other CPUs -- or they wouldn't have them. If it's actually shown that Intel's compiler goes out of it's way to deliberately cripple performance for non-Intel processors, I'd say that's something the FTC should look into to --- which they are.

So the compiler CAN produce different versions of pieces of code, with each version being optimised for a specific processor and/or instruction set. Duh. What's wrong with that exactly ? It has to be able to do that to generate CPU-specific code -- even if only Intel CPUs were supported.

AMD does provide optimizations for their chips and does so in a very public way. It's called GCC which does not cripple any intel processor (although intel's contributions of intel optimizations to GCC have been few and far) because it does not report back "Genuine AMD". Think of it this way, what intel does would be the same as Sony limiting HD playback to 480p from Bluray when a non Sony TV is detected despite the TV being perfectly capable.

Unfortunately Hector when it comes to buisness manages and finance people always go the safe route. The term i386 reffers to Intel 386 which most programs today (not the latest stuff but what has the most code base) apps today are compiled for. Now imagin your a company that makes software development environments which you sell to companies that make software. Do you think that Mr. Manager (in other words if your lucky a has been programmer but usually someone who has graduated school and has done nothing else but be a manager) needs to be make a decision on which compiler to use in their IDE and they say "The i in i386 stands for Intel lets use that one". Now this seems overly simplistic until you have worked long enough in the domain (17 years for me) to see that often the KISS principle (Keep It Simple Stupid) is taken way too far when it comes to IT.

A computer to me is the culmination of over 2000 years of science put into one device. Now if this device has been 2000 years in the making why in F would we choose such a stupid way to use them...... THEY ARE NOT SIMPLE NOR WILL THEY EVER BE SIMPLE!!!!!!

People need to be smarter to use them, our attempt to simplify such a complex piece of machinery is futile and will never work.

All this bitching just to say that people in IT often don't make educated decisions they just make the popular one. This is why it is wrong since Intel has mislead people into believing that they are the good guys and would not do wrong. In other markets this is called false advertising, Fraud, ....

The games Intel has played are included in the list of "dirty tricks " that can get one put on the next ConAir flight to the Federal Bureau of Prisons processing center at El Reno OK. There are criminal sanctions for violating antitrust laws as well as civil penalties. Rigging benchmarks falls into the same category as rigging bids. Since government procurement contracts often have benchmark standards, bids submitted using bogus benchmarks are subject to criminal prosecution under the False Claims Act. Intel may owe the US Government a bunch of money under that act. I am sure the FTC would like to take credit for recovering several billion dollars the tax payer. False Claims Act may well be the biggest hammer that the FTC has over Intel's head. It could double the amount of penalties the FTC can recover, jail time for Barrett and Otenilli and the staff who wrote the code for conspiracy. It could also mean Intel's troubles with the EU are not over. This explains a lot of the disparities between SPEC.org benchmarks and Passmark. SPEC uses IEEE compilers that each tester can optimize, but you have to publish the optimization.

AMD and VIA are free to invent a new architecture and make their compiler work better on it than intels copy (if they can be bothered to make one).

I don't understand what the problem is. Intel provides a free (?) x86 compiler for their customers to support new features & new instructions used by their CPUs. They don't do this to support new features and new instructions of competitor's CPUs. From what I've read AMD provides their own compiler to support their chips. Do they also support Intel's ? I don't think so. Why would a competitor be required to support another in this scenario ?

Stop intentionally confusing people you intel fantard;optimizing for a specfic processor is different than crippling another

"Intel is a money making machine and who really wants to stop that."
If they're sensible anyone but Intel. Part of capitalism is supposedly competition, oh and the customer, to ignore either just reduces capitalism to its core tenet - theft.

This is news but not new. Just imagine how much work time is waisted and covert that to dollars. But then again it is a perfect example of Capitalism at its best. Intel is a money making machine and who really wants to stop that.

As an experiment fluid analysis code was compiled on Solaris x86 using the Studio 10 compiler (no optimization) and run on a Dual (single core) Opteron.
A clean install of Solaris 10 was performed with no performance tuning. The fluid analysis code was using a number of data sets and timing obtained.
The computer then had a clean install of Windows XP installed and the same code compiled using an Intel compiler with optimisation enabled.
The Solaris x86/Studio 10 compiled code was between 40-80% quicker on the AMD Opteron.