Friday, June 21st 2013

AMD Super Pi History To Be Rewritten, Courtesy The Stilt

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.
Add your own comment

50 Comments on AMD Super Pi History To Be Rewritten, Courtesy The Stilt

#1
Jorge
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.
Posted on Reply
#3
etayorius
by: birdie
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...
Posted on Reply
#4
Steevo
by: etayorius
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...
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.
Posted on Reply
#5
etayorius
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.
Posted on Reply
#6
de.das.dude
Pro Indian Modder
by: etayorius
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...
woah this is some deep shit i wasnt aware of. do enlighten us more.
Posted on Reply
#7
TheLaughingMan
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.
Posted on Reply
#8
etayorius
by: de.das.dude
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.
Posted on Reply
#9
cadaveca
My name is Dave
New version out.
Posted on Reply
#10
qubit
Overclocked quantum bit
by: cdawall
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. :nutkick:
Posted on Reply
#11
Heinzketchup
hi techis

looks promissing what i read here :nutkick:

i ask me what happens to arma2 with this patch

so is there someone who can/will test arma2 with this patch
Posted on Reply
#12
theoneandonlymrk
by: de.das.dude
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.
Posted on Reply
#13
BiggieShady
by: theoneandonlymrk
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.
Posted on Reply
#14
etayorius
by: theoneandonlymrk
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.
Posted on Reply
#15
Super XP
by: AphexDreamer
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.
Posted on Reply
#16
TheLaughingMan
by: etayorius
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.
Posted on Reply
#17
BiggieShady
by: BiggieShady
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:

code:
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:

code:
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):

code:
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.
Posted on Reply
#18
DigitalUK
doesnt seem to work with Asus Sabertooth R2 with Piledriver 8350 latest bios 1708, Status Outdated (Bios Update recommended).
Posted on Reply
#19
Irony
It said that on mine too but it worked anyway
Posted on Reply
#20
yoyo2004
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 ) :rockout:
Posted on Reply
#21
DigitalUK
i did have 8.08 @ 4.7ghz now getting 8.16 after applying and patching intel compiler.

4.7Ghz cpu/nb 2600 ht2600 ddr1866
Posted on Reply
#22
webh1ker
by: DigitalUK
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.
Posted on Reply
#23
DigitalUK
i thought that was assumed from my previous post, is working fine, score went from 19.4s to 16.1s
Posted on Reply
#24
Vinska
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.
Posted on Reply
Add your own comment