# AMD Super Pi History To Be Rewritten, Courtesy The Stilt



## Sin (Jun 21, 2013)

*AMD Super Pi History To Be Rewritten, Courtesy Of The Stilt*

AMD's typically underwhelming Super PI performance, that was usually attributed to architectural limitations when it comes to the X87 instruction set, appears to have been nothing more than a blunder on the part of the developers responsible with BIOS development and optimization for AMD platforms. Finnish overclocker, The Stilt, figured out how to considerably improve performance by going through the BIOS developers guides. The exact same guides available to the BIOS R&D teams of motherboard vendors, a surprising fact considering a single man managed to outdo an entire industry. Here is the download link to the patch: click

The Stilt posted a video in which he showed a 4.1GHz A10-6800K completing SuperPI in 17 minutes and 34 seconds. The fastest 5GHz Richland SuperPI 32M is around 18 minutes and 15 seconds. A lot faster! For more information, check out the thread in the HWBot forums.





*View at TechPowerUp Main Site*


----------



## xvi (Jun 21, 2013)

There has to be a drawback. Power consumption? Lower performance in other areas?

(p.s. Submit your scores to HWbot while you can)


----------



## robal (Jun 21, 2013)

I don't know how to feel about this.
Stilt said "sad"... 
I'm more like "horrified".

Excellent work. Respect !


----------



## dj-electric (Jun 21, 2013)

Testing ATM, will post results


----------



## Mathragh (Jun 21, 2013)

If anything, it seems to lower the Physx performance in Fluidmark(although it probably does nothing), which is supposedly X87 heavy.

Without patch: scored 1403, 1406 and 1417 for an average of 1408,7
with patch: scored 1407, 1380, 1378 for an average of 1388,3

Will try to do some superPI later, but apparently either Kanter was wrong, or the patch doesn't work for all x87 code.

Not trying to say the patch doesn't work, but I was thinking of physx being a good candidate for seeing some improvements.

Edit: it could of course also mean the patch isn't working correctly; The program reports my µcode being out of date, and that I should update my bios. So either Asus is lazy, or theres a bug in the program (I've got the latest bios). Also, it keeps saying fix required, even after I've pressed fix(from the second click on, it reported there was nothing left to fix).






Edit2: Oops, after some deeper digging in the original post, it seems the code is protected on Zambezi, meaning that indeed there is nothing that can be fixed for my CPU. Bummerrrr.


----------



## natr0n (Jun 21, 2013)

There is a multicore super pi and way better benchmarks exist.

I don't know what the purpose of this is really.


----------



## Mathragh (Jun 21, 2013)

natr0n said:


> There is a multicore super pi and way better benchmarks exist.
> 
> I don't know what the purpose of this is really.



The underlying idea is that the handling of X87 code is sub-optimal in all of AMD's latest CPU's. So not only superPI should see a benefit, but all other programs relying on those instructions aswell. SuperPI was mentioned as the program benefiting greatly because it is almost totally reliant on X87 only.


----------



## Ralfies (Jun 21, 2013)

Mathragh said:


> The underlying idea is that the handling of X87 code is sub-optimal in all of AMD's latest CPU's. So not only superPI should see a benefit, but all other programs relying on those instructions aswell. SuperPI was mentioned as the program benefiting greatly because it is almost totally reliant on X87 only.



Are there any important programs that rely on x87 instructions these days?


----------



## QuackDuck (Jun 21, 2013)

Mathragh said:


> The underlying idea is that the handling of X87 code is sub-optimal in all of AMD's latest CPU's. So not only superPI should see a benefit, but all other programs relying on those instructions aswell. SuperPI was mentioned as the program benefiting greatly because it is almost totally reliant on X87 only.



you have a Zambezi.... the patch doesn't work 100% on zambezis...


----------



## Mathragh (Jun 21, 2013)

QuackDuck said:


> you have a Zambezi.... the patch doesn't work 100% on zambezis...



Yeah, I just read =( perhaps some day he/they will crack the password on the register.



Ralfies said:


> Are there any important programs that rely on x87 instructions these days?



Yeah, physx is being one of them in software(CPU) mode.

Apart from that, not that many mainstream programs. Most programmers try to use as least x87 code as possible, since it is ancient, and usually quite inefficient. This might also be the reason why AMD didn't bother with fixing this, although noone is sure.


----------



## AphexDreamer (Jun 21, 2013)

Ever since I tried the benchmark I knew something was up. So I would blame the benchmark.


----------



## TheLaughingMan (Jun 21, 2013)

What else uses this code?

Seriously after doing some research, nothing uses x87 micro-code any more. Compiles, while they still have access to these instructions, never generate code that uses it. Anything that could have been with x87 is almost exclusively SSE of some form. Improving performance of obsolete code to make AMD look better in this one benchmark is silly. Especially when the benchmark is mainly used as a stress test.


----------



## Irony (Jun 22, 2013)

Tried 1M with the fix

Here's with the fix enabled:





And here it is disabled:





It seems to make it alot worse; unless his labels are backwards and disable=enable.


Edit: So, I was just wanting to make sure cuz I couldn't remember my regular score at 4.5 so I OC'ed real quick to 5.2 and tried it because I know for sure that I normally do just over 17 seconds on 1M at 5.2. Down to 14 seconds for 1M with it set to disable. I think his settings are labeled backwards. 











Now I tried running 32M at 5.2ghz.


----------



## Jorge (Jun 22, 2013)

As I have been saying for years, many of the benches used to measure CPU/GPU/APU performance are tainted in that they are optimized for Intel products at the expense of AMD. This can be by intent or incompetence. When you run actual applications, you can see significant increases in AMD performance over many of the benches. When you run AMD processors on Linux, you can see even greater benefits than with Windoze. This ain't rocket science folks, it's reality. There is no financial incentive for benchmark makers to create proper, accurate benches when they profit from delivering benches that make Intel products look superior to AMD.

If all you care about is running bogus benches, then carry on. If you care about actually using your PC, then test with real applications and the best drivers.


----------



## TheLaughingMan (Jun 22, 2013)

How would they benefit from making Intel products look superior?


----------



## QuackDuck (Jun 22, 2013)

Irony said:


> ...
> It seems to make it alot worse; unless his labels are backwards and disable=enable.
> ...
> ]



so you decided that... enable is good and disable is bad...


----------



## boogerlad (Jun 22, 2013)

Jorge said:


> As I have been saying for years, many of the benches used to measure CPU/GPU/APU performance are tainted in that they are optimized for Intel products at the expense of AMD. This can be by intent or incompetence. When you run actual applications, you can see significant increases in AMD performance over many of the benches. When you run AMD processors on Linux, you can see even greater benefits than with Windoze. This ain't rocket science folks, it's reality. There is no financial incentive for benchmark makers to create proper, accurate benches when they profit from delivering benches that make Intel products look superior to AMD.
> 
> If all you care about is running bogus benches, then carry on. If you care about actually using your PC, then test with real applications and the best drivers.



Not just benches. Emulators and rendering run far better on Intel than they do on AMD.


----------



## AphexDreamer (Jun 22, 2013)

So is there going to be a bios update or a way to mod a bios to have the fix?


----------



## birdie (Jun 22, 2013)

Jorge said:


> As I have been saying for years, many of the benches used to measure CPU/GPU/APU performance are *tainted* in that they are optimized for Intel products at the expense of AMD. This can be by *intent or incompetence*. When you run *actual applications*, you can see significant increases in AMD performance over many of the benches. When you run AMD processors on *Linux*, you can see even greater benefits than with Windoze. This ain't rocket science folks, it's reality. There is no financial incentive for benchmark makers to create proper, accurate benches when they profit from delivering benches that make Intel products look superior to AMD.
> 
> If all you care about is running bogus benches, then carry on. If you care about actually using your PC, then test with real applications and the best *drivers*.



This post is so insane, meaningless and factually wrong I cringe thinking what's going on in your head.


----------



## cdawall (Jun 22, 2013)

birdie said:


> This post is so insane, meaningless and factually wrong I cringe thinking what's going on in your head.



It's been proven with quite a few different benchmarks. There should never be a switch asking if the processor is AMD or Intel, ever period end of story. cinebench proved that when AMD was allowed to use the intel data path it was substantially faster, yet there is a line of code that asks if(genuineIntel). 

That is a load of BS. It should not be like that and yet it is. There are quite a few programs AMD has the ability to perform better in, yet due to program design it cannot. If you don't believe that look a little harder. It's not just AMD either there was testing done with a Via nano set to look like an Intel chip and it offered 15-30% better performance. I wouldn't try and argue something that is documented as an Intel owner I would just be mad that they are trying to prevent competition by making the competition look weaker. That is BS and anyone who has looked into it knows that.


----------



## laszlo (Jun 22, 2013)

let's wait the next similar findings 

i hope will follow soon


----------



## de.das.dude (Jun 22, 2013)

this is why more things should be made open source.

i hope they fire the people who made the blunder. fools getting paid to do something and still dont do it better than some random dude who just did it himself.

 to stilt.


----------



## de.das.dude (Jun 22, 2013)

natr0n said:


> There is a multicore super pi and way better benchmarks exist.
> 
> I don't know what the purpose of this is really.



because occasionally a n00b intel fanboi comes along and yells "haha my intel i is better than your fx because it does pi calculation faster" :shadedshu


----------



## arterius2 (Jun 22, 2013)

de.das.dude said:


> because occasionally a n00b intel fanboi comes along and yells "haha my intel i is better than your fx because it does pi calculation faster" :shadedshu



well actually, my intel IS alot better than [your] fx because it does most things faster.


----------



## m1dg3t (Jun 22, 2013)

My abbacus pWnz yoU ALL!  Suk it!


----------



## eidairaman1 (Jun 22, 2013)

arterius2 said:


> well actually, my intel IS alot better than [your] fx because it does most things faster.



ive compared both, real world apps- they are about the same- in the end the slowest part is the harddrive because of the interface it is on.


----------



## Jorge (Jun 22, 2013)

As we see in this and other threads some folks can't handle reality. It is what it is folks. You can believe reality or not but it doesn't change reality.


----------



## SetsunaFZero (Jun 22, 2013)

Irony the app says x87 instruction BLOCK



> TheStilt said in http://forum.hwbot.org/showpost.php?p=250633&postcount=12
> *Note:* "x87 instruction (NRAC) block" -> Enabled means that the instruction is blocked (default on all 15h family APU/CPU/NPUs). Disabling it make the SuperPI "a bit" faster.



Edit:
small update: Bulldozer Conditioner R1.01B http://forum.hwbot.org/showpost.php?p=250831&postcount=26


----------



## etayorius (Jun 22, 2013)

birdie said:


> This post is so insane, meaningless and factually wrong I cringe thinking what's going on in your head.



What? you seriously did not know Intel compilers give the slowest path possible to non Intel CPUs? seriously? i mean... for yeal? you did not knew? where have you been living all these past years?


http://techreport.com/news/8547/does-intel-compiler-cripple-amd-performance

http://www.theinquirer.net/inquirer/news/1567108/intel-compiler-cripples-code-amd-via-chips

http://www.electronicsweekly.com/mannerisms/computers/intel-skewed-compilers-to-slow-2009-12/


This is one of the reasons why intel had to include in their compilers that using their stuff would not be optmized for non GenuineIntel CPUs, so that developers were aware before deciding to use Intel Compilers, that was the best AMD could get from that whole dirty issue.

Do we have to bring the Intel paying Dell and others not to use AMD:

http://www.businesspundit.com/intel-pays-dell-not-to-use-amd/

Some people are clueless...


----------



## Steevo (Jun 22, 2013)

etayorius said:


> What? you seriously did not know Intel compilers give the slowest path possible to non Intel CPUs? seriously? i mean... for yeal? you did not knew? where have you been living all these past years?
> 
> 
> http://techreport.com/news/8547/does-intel-compiler-cripple-amd-performance
> ...



There was and still may be a time where changing the "friendly name" in the windows registry allowed programs to use the faster intel paths.


----------



## etayorius (Jun 22, 2013)

I do know that AMD CPUs were locked at the chip level to not being able to change the "AuthenticAMD" name, but i think VIA ones can still be changed which some site was able to and improve performance up to 30%.

I do not know about AMD CPUs being able to get more performance through the Registry.


----------



## de.das.dude (Jun 22, 2013)

etayorius said:


> What? you seriously did not know Intel compilers give the slowest path possible to non Intel CPUs? seriously? i mean... for yeal? you did not knew? where have you been living all these past years?
> 
> 
> http://techreport.com/news/8547/does-intel-compiler-cripple-amd-performance
> ...



woah this is some deep shit i wasnt aware of. do enlighten us more.


----------



## TheLaughingMan (Jun 22, 2013)

Actually that was only in the EU, Intel already lost that lawsuit and paid through the nose for it.

Second, part of the reason the Intel compiler thing worked was they licensed several instruction sets to only be on Intel. AMD has sense come to an agreement with them about that issue as well which is why all new AMD chips support AVX, SSE4.1, etc. Thus this is no longer an issue.

AMD's core design is slower due to the change in manufacturing when they switched completely over to GloFou.

And while that discuss could be fun, this thread is about x87 code and how this "update" is pointless since nothing real world using it anymore because stuff like SSE4, AVX, and such exist.


----------



## etayorius (Jun 22, 2013)

de.das.dude said:


> woah this is some deep shit i wasnt aware of. do enlighten us more.



It is all over the Internet... Intel has played dirty and smear poo all over AMD with all their might, yet AMD still stand strong.


----------



## cadaveca (Jun 22, 2013)

New version out.


----------



## qubit (Jun 22, 2013)

cdawall said:


> It's been proven with quite a few different benchmarks. There should never be a switch asking if the processor is AMD or Intel, ever period end of story. cinebench proved that when AMD was allowed to use the intel data path it was substantially faster, yet there is a line of code that asks if(genuineIntel).
> 
> That is a load of BS. It should not be like that and yet it is. There are quite a few programs AMD has the ability to perform better in, yet due to program design it cannot. If you don't believe that look a little harder. It's not just AMD either there was testing done with a Via nano set to look like an Intel chip and it offered 15-30% better performance. I wouldn't try and argue something that is documented as an Intel owner I would just be mad that they are trying to prevent competition by making the competition look weaker. That is BS and anyone who has looked into it knows that.



Indeed BS and then some. It's a bloody scandal.


----------



## Heinzketchup (Jun 23, 2013)

hi techis

looks promissing what i read here 

i ask me what happens to arma2 with this patch

so is there someone who can/will test arma2 with this patch


----------



## TheoneandonlyMrK (Jun 23, 2013)

de.das.dude said:


> woah this is some deep shit i wasnt aware of. do enlighten us more.



Im intrigued by this,  given the possible gains im surprised no one's come up with a more complete amd id hack,  also surprised you're not aware of this Ddd.


----------



## BiggieShady (Jun 23, 2013)

theoneandonlymrk said:


> im surprised no one's come up with a more complete amd id hack



I have read that it's possible to change the CPUID of AMD CPUs through AMD virtualization instructions, but I need more info on that.


----------



## etayorius (Jun 23, 2013)

theoneandonlymrk said:


> Im intrigued by this,  given the possible gains im surprised no one's come up with a more complete amd id hack,  also surprised you're not aware of this Ddd.



Same, i am still wondering why anyone has still not come with a cool hack for this... perhaps it´s impossible or very hard to do? i am amazed how they can hack new windows version in a day, but not found a way to make use Intel compiler Fast Path Code lines for AMD.

We could easily see a 10% as a minimum performance boost by just taking the Intel only paths in every application and game, my guess is that the 60% "superior" Intel performance is at least from 10-20% pure Code optimizations.

I remember Alexander Blade (GTA4 and Skyrim modder) got into the optmizations from "SKSE TESVAL" and did his own optimizations called "Skyboost", he easily improve performance up to 40% by just putting a couple files in the skyrim folder, Arisu and Alexander Blade put Bethesda into shame and forced them into actually fix their horrible Compiler optimizations with official 1.4 patch, Alexander later did a new version that increased performance even further on Intel CPUs only... so yeah, there is still a lot of juice to be extracted by using the "GenuineIntel" exclusive compiler paths.


----------



## Super XP (Jun 23, 2013)

AphexDreamer said:


> Ever since I tried the benchmark I knew something was up. So I would blame the benchmark.


This goes for most if not all benchmarks, they seem to be better coded for Intel based systems versus AMD. Obviously this represents unfair benchmark comparisons.


----------



## TheLaughingMan (Jun 23, 2013)

etayorius said:


> Same, i am still wondering why anyone has still not come with a cool hack for this... perhaps it´s impossible or very hard to do? i am amazed how they can hack new windows version in a day, but not found a way to make use Intel compiler Fast Path Code lines for AMD.
> 
> We could easily see a 10% as a minimum performance boost by just taking the Intel only paths in every application and game, my guess is that the 60% "superior" Intel performance is at least from 10-20% pure Code optimizations.
> 
> I remember Alexander Blade (GTA4 and Skyrim modder) got into the optmizations from "SKSE TESVAL" and did his own optimizations called "Skyboost", he easily improve performance up to 40% by just putting a couple files in the skyrim folder, Arisu and Alexander Blade put Bethesda into shame and forced them into actually fix their horrible Compiler optimizations with official 1.4 patch, Alexander later did a new version that increased performance even further on Intel CPUs only... so yeah, there is still a lot of juice to be extracted by using the "GenuineIntel" exclusive compiler paths.



They can and they have. CPUID hacking was how SysMark was outed years ago for bias in their tests. They basically programmed their benchmark to assume any non-Intel processor lacked SSE2, SSE3, and something else. This basically gave Intel a huge advantage. A site hacked the CPUID and changed a few AMD and VIA chips to ID as Pentium class processors and they immediately did much better in all of SysMarks tests. This is the main reason I still to this day refuse to use their software and many sites stopped using them as well.

I don't think this can be done any more. Back then the chips so were similar in design and function, the support instruction sets were really the only things separating them. Now, Intel and AMD's chips are so different I can imagine a CPUID hack just ending in massive system instability issues or lose in overall performance.


----------



## BiggieShady (Jun 23, 2013)

BiggieShady said:


> I have read that it's possible to change the CPUID of AMD CPUs through AMD virtualization instructions, but I need more info on that.



With VMWare using hardware virtualization, in *.vmx file vendor_id string can be changed from GenuineIntel to AuthenticAMD and vice versa:

Intel to AMD:


```
cpuid.0.ebx="0110:1000:0111:0100:0111:0101:0100:0001"
cpuid.0.edx="0110:1001:0111:0100:0110:1110:0110:0101"
cpuid.0.ecx="0100:0100:0100:1101:0100:0001:0110:0011"
```

AMD to Intel:


```
cpuid.0.ebx="0111:0101:0110:1110:0110:0101:0100:0111"
cpuid.0.edx="0100:1001:0110:0101:0110:1110:0110:1001"
cpuid.0.ecx="0110:1100:0110:0101:0111:0100:0110:1110"
```

Intel family number also gets checked (example for family number 6):


```
cpuid.1.eax="0000:0000:0000:0001:0000:0110:0111:0001"
```

Since it's using virtualization, it's not for benching really, just to measure relative AMD/Intel speed penalty on the same cpu.


----------



## DigitalUK (Jun 25, 2013)

doesnt seem to work with Asus Sabertooth R2 with Piledriver 8350 latest bios 1708, Status Outdated (Bios Update recommended).


----------



## Irony (Jun 25, 2013)

It said that on mine too but it worked anyway


----------



## yoyo2004 (Jun 25, 2013)

*I can't believe it !!*

Not only this fix boosted my Fx-8320 ( @ 4GHz ) performance in superPI 32mil ( from 26mins to 19mins ) , but also boosted cinebench R11.5 score ( 6.21 to 6.65 )


----------



## DigitalUK (Jun 26, 2013)

i did have 8.08 @ 4.7ghz now getting 8.16 after applying and patching intel compiler.

4.7Ghz cpu/nb 2600 ht2600 ddr1866


----------



## webh1ker (Jun 26, 2013)

DigitalUK said:


> doesnt seem to work with Asus Sabertooth R2 with Piledriver 8350 latest bios 1708, Status Outdated (Bios Update recommended).



It works perfectly fine with my SabreTooth R2.0 with an FX 8320 @ 4715 Mhz.

You need to apply the Fix and then put the x87 instruction (NRAC) block to *disabled*.
The Bulldozer conditioner program (BDC R1.01B) need to be run as admin.


----------



## DigitalUK (Jun 26, 2013)

i thought that was assumed from my previous post, is working fine, score went from 19.4s to 16.1s


----------



## librin.so.1 (Jun 29, 2013)

Hmmm... it seems this doesn't do magic on all x87 instuctions.
Yes, it does make Super Pi and some other programs faster - that's for sure.
But I decided to make a small benchmark program that uses only FADD, FSUB, FMUL, FDIV, FST and FLD based instructions for the "payload". And I've seen absolutely no change in execution time. Because of this, I believe this "magic" only works with a portion of x87 instructions. Gonna investigate further, if I don't get too lazy.
It'd be swell if I'd manage to form a list of x87 instuctions which are sped up by this.


----------



## grayhoose (Jul 27, 2013)

de.das.dude said:


> woah this is some deep shit i wasnt aware of. do enlighten us more.



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


----------

