Intel Compiler Patcher

The problem that was described was true but if it is still working on current compiled executables I'm not to sure about that.

Supposedly Intel removed these "checks" a good while ago
 
It's a real thing. In some cases, the compiler will generate multiple code paths. Take memcpy() for example. Early on the program will check some information on your processor and set the feature level accordingly. At the beginning of the function, it just jumps to whatever implementation.

Both AMD and Intel processors can make use of a vectorized version, but AMD would nevertheless branch down the generic, slower one.

As far as I know, they still do this but I'm not completely positive
 
It's a real thing. In some cases, the compiler will generate multiple code paths. Take memcpy() for example. Early on the program will check some information on your processor and set the feature level accordingly. At the beginning of the function, it just jumps to whatever implementation.

Both AMD and Intel processors can make use of a vectorized version, but AMD would nevertheless branch down the generic, slower one.

As far as I know, they still do this but I'm not completely positive

wasn't that fixed (removed) since Intel Core 2 Series?. i've never encountered with this "issue" (cheating path) again since those times.. have you any know of an actual app just to make some test would be add some fun.
 
wasn't that fixed (removed) since Intel Core 2 Series?. i've never encountered with this "issue" (cheating path) again since those times.. have you any know of an actual app just to make some test would be add some fun.

Cinebench 11.5 still had it. the new one does not. If you look in the disclaimer for 11.5 it mentions ICC and its bias or possible bias in accordance with the lawsuit. May be a number of programs that still do but they would be ones still utilizing old code. So if it supports AVX2 it isn't likely gonna be an issue, doesn't have to be since AMD until recently does not support AVX2 ( not sure if they have a chip out yet that does). Problem is a lot of times these patchers will return false positives. Seen one guy tried this with WoW and thought he had something. No one else could replicate it.
 
Mind linking WoW thread about this ? :)

Lol not sure if I can find it again. Was a while back. But I will give it a go.

Edit so far only this for added info, not WoW related: http://www.overclock.net/t/1554359/reddit-amd-sabotage-wiki/50#post_23945209

Edit2: Holy crap that was a lot of reading and searching but found it. http://us.battle.net/wow/en/forum/topic/4079871855

Biggest problem is he doesn't give a lot of info on what he did, just an overview. Didn't get a lot of attention.
 
Last edited:
A lot of stuff is compiled using the Microsoft or GNU compilers anyway. So it's no magic bullet.
 
Thanks for the link JustReason
If you read the overclocker.net thread you can see it is not just about ICC compiled stuff there seem to be some results from spoofing vendor ID.

http://www.overclock.net/t/1554359/reddit-amd-sabotage-wiki/70#post_23952148
Had a proper look at Starcraft II.

Neither SC2 or Warcraft use Intel compiler.

They both do use a vast amount of code to detect to CPU.
Besides just checking the usual stuff; available instructions and core count they check pretty much all of the possible CPU information.

There is definitely some vendor dependant behavior built in but not by Intel but Blizzard themselves.
The solution Blizzard uses is much more complex than the one Intel automatically adds to every piece of code spit out by their compilers.
Definitely patchable but requires more work.
 
Last edited:
Thanks for the link JustReason
If you read the overclocker.net thread you can see it is not just about ICC compiled stuff there seem to be some results from spoofing vendor ID.

http://www.overclock.net/t/1554359/reddit-amd-sabotage-wiki/70#post_23952148

Funny thing is I didn't think about that when I saw the discussion like a year ago. Of course it was about ICC but it was Software Bias that was the main argument. I just stated that no matter how you look at it, most software will have bias, just inherent. Most software will be built to the use, so say in one segment Intel is the primary use CPU. So the software may use AVX2 instead of AVX1 because of the speed and efficiency increase. So then someone uses the software whilst using an AMD CPU. In this case there is an inherent bias, however it is not intended nor a form of mal-intent. This is where the discussion gets mirky and fanboys on both sides PLAY with the facts. ICC back in the day was in fact Bias in a Mal-intent Intended kind of way. But because of the heavy use by a lot of software its use continued on. Now all software had to add the bias acknowledgement in the fine print by law but weren't forced to change or adapt the software to rid the bias. This is why Cinebench 11.5 continued with its use until updated to 15.

Now like it or not sometimes these checks have to exist. Unfortunately the problem is they sometimes do little ensure efficient use across a spectrum of CPUs. Unfortunately again part of life, how it is. When we look at all the code possibilities and libraries it can make one wonder ie: why AVX/sse2 rather than FMA4/sse4... . Each code has its benefits with some having inherent positives on select CPUs/generations. So it only makes sense that they may use AVX2 because the majority use Xeon processors and only a few use Opterons.

NOW EVERYTHING ABOVE IS EXAMPLES AND IN NO WAY FACTUAL as to the code and Libraries. In other words I wasn't making references to which library or architecture or company is better. Just random debate.
 
Total FUD. The same performance deltas are seen when software is compiled with gcc and clang.
 
Total FUD. The same performance deltas are seen when software is compiled with gcc and clang.

Great argument and so much detail. Might take a while to wade thru it.

/s

Now that has been said can you refute anything here. Compiling tells us nothing of every single program therefore you cant make that blanket statement.
 
The patcher is old and it can't patch newer icc binaries. Very, very little consumer software is compiled using icc, so the patcher has pretty limited utility for most people.
 
Great argument and so much detail. Might take a while to wade thru it.

/s

Now that has been said can you refute anything here. Compiling tells us nothing of every single program therefore you cant make that blanket statement.

The argument is that the intel compiler "gimps" binaries for amd systems and this somehow explains AMDs poor cpu performance. However programs compiled with other compilers show similar performance differences. How is that possible? Maybe the intel compiler isn't auto gimping its' output.
 
The argument is that the intel compiler "gimps" binaries for amd systems and this somehow explains AMDs poor cpu performance.
The Intel compiler makes non-Intel CPUs use the default, unoptimized path. The default path also ignores any CPU extensions useful for speedups, despite regular ways to detect if they are available. That is what hurts code most, especially when auto-vectorization and loop unrolling can make great use of SSEx and AVX, a big reason that some software makers chose icc.

Just as a reminder, this was one of the issues AMD sued over. AMD got nothing for that, but Intel established a $10 million fund for people who believe they were mislead about code output by icc to get a refund. The judge agreed with Intel that it could do what it wanted with the compiler, as long as it includes a disclaimer that states it only generates optimized code for Intel CPUs. That was something it was already doing before the settlement. Few people took advantage of the refund offered, I imagine that most requests came from 1 AMD Way. :p
 
Huh, ok. Well, I retract my statement then. I guess I read the initial issue as "AMD would be on intels level if not for icc". Either way people should be using gcc (or clang) anyway.
 
Vendor ID spoofing is what is shown in the link from the WoW forums:

Hey Support,

I had some extra time on my hands and went about testing performance differences with wow-64.exe using spoofed CPU ID's using Vmware and found some startling differences.

In laymans terms this is reporting an AMD CPU as an Intel Core I7 to wow-64.exe

Without further ado here are the WOW performance tests done on a Interlagos 8C/16C vs Core I7 3960X with spoofed CPU IDs.

No CPU ID change:
AMD --> 76min/102max
Intel -->148min/212max

CPU ID spoofed:
AMD --> 127min/162max
Intel -->88min/122max

Im not sure exactly how you guys optimize the compiler in terms of intel vs amd but the results are rather interesting.
 
Either way people should be using gcc (or clang) anyway.
Why? Native compilers on Windows are going to be less hassle for most Windows developers, especially for multi-threaded code interacting with Windows API calls (pthreads vs win32 threads). Someone certainly can use gcc/clang/whatever oss compilers ported to Windows, but unless cross platform compatibility is important (and all the work needed to achieve it is bolted onto the code) it's not really helping in most cases.

Under Windows, most commercial consumer software is compiled with MS compilers. It has good performance across a wide range of processor generations and very few performance cliffs (cough, gcc regressions, cough), plus it's free for virtually all uses.
 
Back
Top