Intel Compiler Patcher boosts AMD processors' performance?

[Static~Charge]

I was skimming Major Geeks (one of my favorite download sites) and spotted this in today's listing:

Intel Compiler Patcher (ICP) 1.0

Intel Compiler Patcher (ICP) scans your hard drive for executable files compiled with the Intel C++ Compiler making it possible to disable the CPU dispatcher in detected files addressing an issue that causes non Intel chipsets to run these programs slower.

In other words, it is believed that Intel uses this to make their processor faster than the competition, mainly AMD. Here's more on the theory behind this.

The compiler or library can make multiple versions of a piece of code, each optimized for a certain processor and instruction set, for example SSE2, SSE3, etc. The system includes a function that detects which type of CPU it is running on and chooses the optimal code path for that CPU. This is called a CPU dispatcher. However, the Intel CPU dispatcher does not only check which instruction set is supported by the CPU, it also checks the vendor ID string. If the vendor string says "GenuineIntel" then it uses the optimal code path. If the CPU is not from Intel then, in most cases, it will run the slowest possible version of the code, even if the CPU is fully compatible with a better version.

To be clear, this program will work on any non-Intel processor. Please see the readme.html inside the zip.

http://www.majorgeeks.com/files/details/intel_compiler_patcher.html​

Interesting.... Did Intel do this deliberately, to make AMD's processors perform poorly? Unfortunately, I don't have access to any AMD processors to test this utility. Does anyone here want to give it a try and report their results?

 

[R-T-B]

So Intel's compiler is optimized for Intel processors? Who knew? /s

 

[dorsetknob]

guess this could be a buy the popcorn and wait for the fanboys thread

Interesting.... Did Intel do this deliberately, to make AMD's processors perform poorly?

there were story's and rumors circulating a while back to this idea

 

[uuuaaaaaa]

I may try cinebench when I get home with and without this to see if there are any differences...

 

[R-T-B]

I hate to break it to you guys, but very few programs actually use Intel's compiler, and if they do, they usually expect to run on Intel hardware. The "Intel" part of "Intel compiler" should be a hint...

 

[Static~Charge]

"Intel compatible" is one thing; "Intel exclusive" is a different story....

 

[R-T-B]

"Intel compatible" is one thing; "Intel exclusive" is a different story....

not quite sure what you are getting at here...

 

[medi01]

So Intel's compiler is optimized for Intel processors? Who knew? /s

There is no reason to check for vendor id (querying "do you support SSE" is standard), unless criminal energy is involved.

If confirmed, it IS a big deal.

I hate to break it to you guys, but very few programs actually use Intel's compiler, and if they do, they usually expect to run on Intel hardware. The "Intel" part of "Intel compiler" should be a hint...

Last time I was into compilable programs, Intel's compiler beat Microsoft's.

 

[Static~Charge]

not quite sure what you are getting at here...

AMD's processors are Intel compatible; they are capable of running that code. Looking for the vendor string of "GenuineIntel" doesn't tell the compiler anything useful about a particular processor's capabilities; it only says "This is one of mine." The code still has to identify which Intel processor it's running on in order to implement the correct optimizations.

Rather than hobbling AMD's processors with poorly optimized code, the compiler should check for supported features and optimize accordingly, regardless of the brand of processor. As it stands now, Intel's compiler is effectively saying "I don't like competing against you in this footrace, so instead of giving you sneakers, I'll give you flip-flops." It's petty, spiteful, and unnecessary.

Of course, I'm looking at this as a consumer, not as a manufacturer that has a vested interest in making their own products look good and their competitor's products look bad....

 

[FordGT90Concept]

There is no reason to check for vendor id (querying "do you support SSE" is standard), unless criminal energy is involved.

The article said that it is coded for each CPU's specific dispatcher to prevent blocking. So yeah, it is pretty important for the compiler to check the Vendor ID and Device ID to make sure it is optimizing for each specific processor. The software likely does nothing if it sees anything other than Vendor ID 0x8086 as it should be because it would likely make performance worse for AMD; not better. AMD is free to make their own compiler to optimize code for their own processors. If they do/did, it would only target AMD processors as well.

There is absolutely nothing fishy about this unless Intel compiler deliberately makes software slower (as in not status quo) on AMD's hardware.


Optimizing a dispatcher goes far beyond just singular instructions. That's why it must look at more than whether or not a specific instruction exists.

 

[cdawall]

This is old hat info. Intel has been doing this for years look into the testing that spoofs the vender ID of AMD processors and how performance changes.

 

[R-T-B]

Last time I was into compilable programs, Intel's compiler beat Microsoft's.

Yet, but this is important, only on Intel hardware.

This is old hat info. Intel has been doing this for years look into the testing that spoofs the vender ID of AMD processors and how performance changes.

I'm pretty sure the intel compiler is even advertised to "boost performance on Intel processors"

I mean this is like complaining that the AMD drivers don't boost your NVIDIA cards performance. OF COURSE THEY HAVE A BIAS FOR THEIR HARDWARE!

 

[medi01]

The article said that it is coded for each CPU's specific dispatcher to prevent blocking. So yeah, it is pretty important for the compiler to check the Vendor ID and Device ID to make sure it is optimizing for each specific processor. The software likely does nothing if it sees anything other than Vendor ID 0x8086 as it should be because it would likely make performance worse for AMD; not better.

I'm talking about "does this thing has SSE" kinds of checks.
"Oh, and is it also an Intel CPU" has no meaning in this context.

Yet, but this is important, only on Intel hardware.

No, faster overall, also on Athlons.

I mean this is like complaining that the AMD drivers don't boost your NVIDIA cards performance. OF COURSE THEY HAVE A BIAS FOR THEIR HARDWARE!

Yeah, they were. Drivers, I mean. Compiler was not.

PS
And, yeah, frankly, I don't think compiler tricks could cover the IPC gap between Intel/AMD in 14nm vs 28nm times.

 

[RejZoR]

When majority of programmers use Intel compilers, it presents a problem. You can't compare AMD and NVIDIA for things that are done differently. It should however never be a reason for standardized things. CPU instructions are standardized. You either support it or you don't. There is no in between. Dropping support for it just because CPU has the wrong vendor ID even though it fully supports that instruction set is just lame and dirty.