Comparing 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
14 stage from µop cache


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.

Inside the Beast(s) Heavy SMT: Multi Threading Prowess
Comments Locked

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...

Log in

Don't have an account? Sign up now