Assessing IBM's POWER8, Part 1: A Low Level Look at Little Endian
by Johan De Gelas on July 21, 2016 8:45 AM ESTComparing with Intel's Best
Comparing CPUs in tables is always a very risky game: those simple numbers hide a lot of nuances and trade-offs. But if we approach with caution, we can still extract quite a bit of information out of it.
| Feature | IBM POWER8 |
Intel Broadwell (Xeon E5 v4) |
Intel Skylake |
| L1-I cache Associativity |
32 KB 8-way |
32 KB 8-way |
32 KB 8-way |
| L1-D cache Associativity |
64 KB 8-way |
32 KB 8-way |
32 KB 8-way |
| Outstanding L1-cache misses | 16 | 10 | 10 |
| Fetch Width | 8 instructions | 16 bytes (+/- 4-5 x86) | 16 bytes (+/- 4-5 x86) |
| Decode Width | 8 | 4 µops | 5-6* µops (*µop cache hit) |
| Issue Queue | 64+15 branch+8 CR = 87 |
60 unified | 97 unified |
| Issue Width/Cycle | 10 | 8 | 8 |
| Instructions in Flight | 224 (GCT SMT-8 modus) | 192 (ROB) | 224 (ROB) |
| Archi regs Rename regs |
32 (ST), 2x32 (SMT-2) 92 (ST), 2x92 (SMT-2) |
16 168 |
16 180 |
| Load Bandwidth (per unit) Load Queue Size |
4 per cycle 16B/cycle 44 entries |
2 per cycle 32B/cycle 72 entries |
2 per cycle 32B/cycle 72 entries |
| Store Bandwidth Store Queue Size |
2 per cycle 16B/cycle 40 entries |
1 per cycle 32B/cycle 42 entries |
1 per cycle 32B/cycle 56 entries |
| Int. Pipeline Length |
18 stages |
19 stages |
19 stages 14 stage from µop cache |
| TLB | 2048 4-way |
128I + 64D L1 1024 8-way |
128I + 64D L1 1536 8-way |
| Page Support | 4 KB, 64 KB, 16 MB, 16 GB | 4 KB, 2/4 MB, 1 GB | 4 KB, 2/4 MB, 1 GB |
Both CPUs are very wide brawny Out of Order (OoO) designs, especially compared to the ARM server SoCs.
Despite the lower decode and issue width, Intel has gone a little bit further to optimize single threaded performance than IBM. Notice that the IBM has no loop stream detector nor µop cache to reduce branch misprediction. Furthermore the load buffers of the Intel microarchitecture are deeper and the total number of instructions in flight for one thread is higher. The TLB architecture of the IBM POWER8 has more entries while Intel favors speedy address translations by offering a small level one TLB and a L2 TLB. Such a small TLB is less effective if many threads are working on huge amounts of data, but it favors a single thread that needs fast virtual to physical address translation.
On the flip side of the coin, IBM has done its homework to make sure that 2-4 threads can really boost the performance of the chip, while Intel's choices may still lead to relatively small SMT related performance gains in quite a few applications. For example, the instruction TLB, µop cache (Decode Stream Buffer) and instruction issue queues are divided in 2 when 2 threads are active. This will reduced the hit rate in the micro-op cache, and the 16 byte fetch looks a little bit on the small side. Let us see what IBM did to make sure a second thread can result in a more significant performance boost.
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