Assessing IBM's POWER8, Part 1: A Low Level Look at Little Endian
by Johan De Gelas on July 21, 2016 8:45 AM ESTMulti-Threaded Integer Performance on one core: SPEC CPU2006
Broadly speaking, the value of SPEC CPU2006's int rate test is questionable, as it puts too much emphasis on bandwidth and way too little emphasis on data synchronization. However, it does give some indication of the total "raw" integer compute power available.
We will make an attempt to understand the differences between IBM and Intel, but to be really accurate we would need to profile the software and runs dozens of tests while looking at the performance counters. That would have set back this article a bit too much. So we can only make an educated guess based upon what the existing academic literature says and our experiences with both architectures.
The Intel CPU performance is the 100% baseline in each column.
| Subtest SPEC CPU2006 Integer |
Application Type |
IBM POWER8 vs Xeon E5-2699v4 Single Thread |
IBM POWER8 vs Xeon E5-2699v4 Max Thread |
IBM POWER8 vs Xeon E5-2699v4 Top performance |
| 400.perlbench | Spam filter | N/A | N/A | N/A |
| 401.bzip2 | Compress | 91% | 139% | 139% |
| 403.gcc | Compiling | 111% | 185% | 185% |
| 429.mcf | Vehicle scheduling | 121% | 167% | 167% |
| 445.gobmk | Game AI | 90% | 156% | 156% |
| 456.hmmer | Protein seq. analyses | 79% | 79% | 101% |
| 458.sjeng | Chess | 69% | 117% | 117% |
| 462.libquantum | Quantum sim |
76% | 160% | 162% |
| 464.h264ref | Video encoding | 80% | 120% | 131% |
| 471.omnetpp | Network sim |
100% | 141% | 141% |
| 473.astar | Pathfinding | 87% | 156% | 156% |
| 483.xalancbmk | XML processing | 70% | 116% | 116% |
On (geometric) average, a single thread running on the IBM POWER8 core runs about 13% slower than on an Intel Broadwell architecture core. So our suspicion that Intel is still a bit better at extracting parallelism when running a single thread is confirmed.
Intel gains the upper-hand in the applications where branch prediction plays an important role: chess (sjeng), pathfinding (astar), protein seq. analysis (hmmer), and AI (gobmk). Intel's branch misprediction penalty is lower if the other branch is available in the µop cache (the Decode Stream Buffer) and Intel has a few clever tricks that the IBM core does not have like the loop stream detector.
Where the POWER8 core shines is in the benchmarks where memory latency is important and where the load units are a bottleneck, like vehicle scheduling (mcf). This is also true, but in lesser degree, for the network simulation (omnetpp). The reason might be that omnetpp puts a lot of pressure on the OoO buffers, and Intel's architecture offers more room with its unified buffers, whereas IBM POWER8's buffers are more partitioned (see for example the issue queue). Meanwhile XML processing does a lot of pointer chasing, but quick profiling has shown that this benchmark mostly hits the L2, and somewhat the L3. So there's no disadvantage for Intel there. On the flip side, Xalancbmk is the benchmark with the highest pressure on the ROB. Again, the larger OOO buffers for one thread might help Intel to do better.
POWER8 also does well in GCC, which has a high percentage of branches in the instruction mix, but very few branch mispredictions. GCC compiling is latency sensitive, so a 3 cycle L1, a 13 cycle L2, and the fast 8MB L3 help.
Finally, the pathfinding (astar) benchmark does some intensive pointer chasing, but it misses the L1- and L2-cache much less often than xalancbmk, and has the highest amount of branch misprediction. So the impact of the pointer chasing and memory latency is thus minimal.
Once all threads are active, the IBM POWER8 core is able to outperform the Intel CPU by 41% (geomean average).
Facebook
Twitter
RSS
124 Comments
View All Comments
Michael Bay - Sunday, July 24, 2016 - link
Hardware does not exist for its own sake, it exists to run software. AT is entirely correct in their methodology.jospoortvliet - Tuesday, July 26, 2016 - link
I'd argue it is the other way around, GCC might leave 5-10% performance on the table in some niche cases but does just fine most of the time. There's a reason Intel and IBM contribute to GCC - to make sure it doesn't get too far behind as they know very well most of their customers use these compilers and not their proprietary ones.Of course, for scientific computing and other niches it makes all the difference and one can argue these heavy systems ARE for niche markets but I still think it was a sane choice to go with GCC.
abufrejoval - Thursday, August 4, 2016 - link
Actually exercising 90% of all transistors on a CPU die these days, is both very hard to do (next to impossible) and will only slow the clock to avoid overstepping TDP.And I seriously doubt that the GCC will underuse a CPU at 10% its computational capacity.
Actually from what I saw the GCC by itself (compiling) was best at exploiting the full 8T potential of the Power8. And since the GCC is compiled by itself, that speaks for the quality of machine code that it can produce, if the source allows it. And that speaks for the quality of the GCC source code, ergo prove you can do better before you rant.
abufrejoval - Thursday, August 4, 2016 - link
Well this is part 1 and describes one scenario. What you want is another scenario and of course it's a valid if a very distinct one.Actually distinct is the word here: You'd be using a vendor's compiler if your main job is a distinct workload, because you'd want to squeeze every bit of performance out of that.
The problem with that is of course, that any distinct workload makes it rather boring for the general public because they cannot translate the benchmark to their environment.
AT aims to satisfy the broadest meaningful audience and Johan as done a great, great job at that.
I'm sure he'll also write a part 4711 for you specifically, if you make it economically attractive.
Hell, even I'd do that given the proper incentive!
Zan Lynx - Sunday, July 24, 2016 - link
Using GCC as the compiler is also why (in my opinion) the Intel chips aren't using their full TDP. Large areas of Intel chips are dedicated to vector operations in SSE and AVX. If you don't issue those instructions then half the chip isn't even being used.Some gamers who love their overclocked Intel chips have actually complained to game engine developers who add AVX to the game engine. Because it ruins their overclock even if the game runs much faster. Then they're in the situation of being forced to clock down from 4.5 GHz to 3.7 in order to avoid lockups or thermal throttling.
Kevin G - Sunday, July 24, 2016 - link
The Xeon E3 v3's had different clock speeds for AVX code: it consumed too much power and got too hot while under total load.This holds true on the E5 v4's but the AVX penalty is done on a core-by-core basis, not across the entire chip. The result is improved performance in mixed workloads. This is a good thing as AVX hasn't broken out much beyond the HPC markets.
talonted - Monday, July 25, 2016 - link
For those interested in getting a Power8 workstation. Check out Talos.https://www.raptorengineering.com/TALOS/prerelease...
137ben - Monday, July 25, 2016 - link
I made an account to say that this article (along with the subsequent stock-cooler comparison article) is why I really love Anandtech. A lot of the code I run/write for my research is CPU-bottlenecked. Still, until the last year or so, I didn't know very much about hardware. Now, reading Anandtech, I have learned so much more about the hardware I depend on from this website than from any other website. Most just repeat announcements or run meaningless cursory synthetic benchmarks. The fact that Johan De Gelas has written such a deep dive into the inner workings of something as complex as a server CPU architecture, and done it in a way that I can understand, is remarkable. Great job Anandtech, keep it up and I'll always come back.JohanAnandtech - Thursday, July 28, 2016 - link
You made me a happy man, I achieved my goal :-)alpha754293 - Wednesday, July 27, 2016 - link
Excellent work and review as always Johan. I would have been interest to see how the two processors perform in floating point intensive benchmarks though...