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
jospoortvliet - Tuesday, July 26, 2016 - link
The point Johan makes is that his goal is not to get the best bechmark scores but the most relevant real life data. One can argue if he succeeded, certainly the results are interesting but there is much more to the CPU's as usual. And I do think his choice is justified, while much scientific code would be recompiled with a faster compiler (though the cost of ICC might be a problem in a educational setting), many businesses wouldn't go through that effort.I personally would love to see a newer Ubuntu & GCC being used, just to see what the difference is, if any. The POWER ecosystem seems to evolve fast so a newer platform and compiler could make a tangible difference.
But, of course, if you in your usecase would use ICC or xLC, these benches are not perfect.
Eris_Floralia - Friday, July 22, 2016 - link
Are these two processor both tested at the same frequency？or at their stock clock？tipoo - Friday, July 22, 2016 - link
The latter, page 52.92-3.5 GHz vs 2.2-3.6 GHz
abufrejoval - Thursday, August 4, 2016 - link
Well since Johan really only tested one core on each CPU, it would have been nice to have him verify the actual clock speed of those cores. You'd assume that they'd be able to maintain top speed for any single core workload independent of the number of threads, but checking is better than guessing.roadapathy - Friday, July 22, 2016 - link
22nm? *yawwwwwwwwwn* Come on IBM, you can do better than that, brah.Michael Bay - Saturday, July 23, 2016 - link
Nope, 22 is the best SOI has right now. You have to remember it`s nowhere near standard litographies customer-wise.tipoo - Monday, July 25, 2016 - link
In addition to what Michael Bay (lel) said, remember that only Intel really has 14nm, when TSMC and GloFlo say 14/16nm they really mean 20nm with finfetts.feasibletrash0 - Saturday, July 23, 2016 - link
using a less capable compiler (GCC) to test a chip, and not using everything the chip has to offer seems incredibly flawed to me, what are you testing exactlyaryonoco - Saturday, July 23, 2016 - link
He's testing what actual software people actually run on these things.On your typical Linux host, pretty most everything is compiled with GCC. You want to get into exotic compilers? Sure both IBM and Intel have their exotic proprietary costly compilers, so what. Very few people outside of niche industries use them.
You want to compare a CPU with CPU? You keep the compiler the same. That's just common sense. It's also how the scientific method works!
feasibletrash0 - Sunday, July 24, 2016 - link
right, but you're comparing, say 10% of the silicon on that chip, and saying that the remaining 90% of the transistors making the chip does not matter, they do; if the software is not using them, that's fine, but it's not an accurate comparison of the hardware, it's a comparison of the software