- Feb 12, 2013
- 3,818
- 1
- 0
The Book of Bulldozer - Revelations: Episode 2 (SuperPI / x87)
Exactly two year ago, when I tested a Bulldozer based Zambesi CPU for the first I was shocked.
The early sample units were even hotter and slower than the final silicon revision CPUs, which finally were released four months later.
One of the largest single let-down came from the way back: SuperPI.
SuperPI mainly uses legacy x87 instructions which have been almost completely superceded.
SuperPI doesn't show any indication what so ever about SMP performance as it can only utilize a single thread. On top of that it has no real world use or purpose as there are newer programs which can calculate PI almost 100 times faster.
Still, SuperPI can almost be considered as a industry standard.
Nowdays it is generally a VERY poor indicator of real world performance, yet it is so addictive for any old school overclocker. It scales very well along with the CPU/NB/DRAM/IO performance and tweaking it is a big challenge. An overclocker who hasn't ever benched SuperPI simply doesn't exist.
SuperPI has a special place in my heart simply because it was one of the first benchmarks I ever ran... almost 14 years ago...
So, why are all of the 15h (Bulldozer) based CPU/APU/NPUs performing so bad in SuperPI?
Some people say it is because 15h family has 50% less FPs per core than the preceeding 10h family.
In 15h family a compute unit (two cores) share a FP when the 10/12h family had a dedicated FP for each of the cores.
If this would be the only reason, the issue would be solved when the "slave" core of the CU is disabled, leaving a "private" FP for the "master" (BSC) core. However this is not the case and it even shouldn't be as SuperPI is single threaded, remember?
The caches on 15h family have higher latency than 10h family for example, and SuperPI happens to love large & low latency caches.
15h family was initially designed for high frequencies. Just like the F1 engines, they produce no power at low revs. And unfortunately it currently doesn't seem to be possible to build an engine capable reving high enough. We might discuss more about the caches in "Episode 3"... If possible.
source
maybe amd is hamstrung via software implementation afterall...

