Single-Thread SPEC CPU2006 Estimates

While it may have been superceded by SPEC2017, we have built up a lot of experience with SPEC CPU2006. Considering the trouble we experience with our datacenter infrastructure, it was our best first round option for raw performance analysis.   

Single threaded performance continues to be very important, especially in maintainance and setup situations. These examples may include running a massive bash script, trying out a very complex SQL query, or configuring new software - there are lots of times where a user simply does not use all the cores. 

Even though SPEC CPU2006 is more HPC and workstation oriented, it contains a good variety of integer workloads. It is our conviction that we should try to mimic how performance critical software is compiled instead of trying to achieve the highest scores. To that end, we:

  • use 64 bit gcc : by far the most used compiler on linux for integer workloads, good all round compiler that does not try to "break" benchmarks (libquantum...) or favor a certain architecture
  • use gcc version 7.4 and 8.3: standard compiler with Ubuntu 18.04 LTS and 19.04. 
  • use -Ofast -fno-strict-aliasing optimization: a good balance between performance and keeping things simple
  • added "-std=gnu89" to the portability settings to resolve the issue that some tests will not compile 

The ultimate objective is to measure performance in non-aggressively optimized"applications where for some reason – as is frequently the case – a multi-thread unfriendly task keeps us waiting. The disadvantage is there are still quite a few situations where gcc generates suboptimal code, which causes quite a stir when compared to ICC or AOCC results that are optimized to look for specific optimizations in SPEC code. 

First the single threaded results. It is important to note that thanks to turbo technology, all CPUs will run at higher clock speeds than their base clock speed. 

  • The Xeon E5-2699 v4  ("Broadwell") is capable of boosting up to 3.6 GHz. Note: these are old results compiled w GCC 5.4
  • The Xeon 8176 ("Skylake-SP") is capable of boosting up to 3.8 GHz. 
  • The EPYC 7601 ("Naples") is capable of boosting up to 3.2 GHz. 
  • The EPYC 7742 ("Rome") boosts to 3.4 GHz. Results are compiled with GCC 7.4 and 8.3

Unfortunately we could not test the Intel Xeon 8280 in time for this data. However, the Intel Xeon 8280 will deliver very similar results, the main difference being that it runs a 5% higher clock (4 GHz vs 3.8 GHz). So we basically expect the results to be 3-5% higher than the Xeon 8176. 

As per SPEC licensing rules, as these results have not been officially submitted to the SPEC database, we have to declare them as Estimated Results.

Subtest Application Type Xeon
E5-2699
v4
EPYC
7601
Xeon
8176
EPYC
7742
EPYC
7742
Frequency   3.6 GHz 3.2 GHz 3.8 GHz 3.4 GHz 3.4 GHz
Compiler   gcc 5.4 gcc 7.4 gcc 7.4 gcc 7.4 gcc 8.3
400.perlbench Spam filter 43.4 31.1 46.4 41.3 43.7
401.bzip2 Compression 23.9 24.0 27.0 26.7 27.2
403.gcc Compiling 23.7 35.1 31.0 42.3 42.6
429.mcf Vehicle scheduling 44.6 40.1 40.6 39.5 39.6
445.gobmk Game AI 28.7 24.3 27.7 32.8 32.7
456.hmmer Protein seq. 32.3 27.9 35.6 30.3 60.5
458.sjeng Chess 33.0 23.8 32.8 27.7 27.6
462.libquantum Quantum sim 97.3 69.2 86.4 72.7 72.3
464.h264ref Video encoding 58.0 50.3 64.7 62.2 60.4
471.omnetpp Network sim 44.5 23.0 37.9 23.0 23.0
473.astar Pathfinding 26.1 19.5 24.7 25.4 25.4
483.xalancbmk XML processing 64.9 35.4 63.7 48.0 47.8

A SPEC CPU analysis is always complicated, being a mix of what kind of code the compiler produces and CPU architecture.

Subtest Application type EPYC 7742
(2nd gen)
vs
7601
(1st gen)
EPYC
7742
vs
Intel Xeon
Scalable
 

Gcc 8.3
vs 7.4

400.perlbench Spam filter +33% -11% +6%
401.bzip2 Compression +11% -1% +2%
403.gcc Compiling +21% +28% +1%
429.mcf Vehicle scheduling -1% -3% 0%
445.gobmk Game AI +35% +18% +0%
456.hmmer Protein seq. analyses +9% -15% +100%
458.sjeng Chess +16% -16% -1%
462.libquantum Quantum sim +5% -16% -1%
464.h264ref Video encoding +24% -4% -3%
471.omnetpp Network sim +0% -39% 0%
473.astar Pathfinding +30% +3% 0%
483.xalancbmk XML processing +36% -25% 0%

First of all, the most interesting datapoint was the fact that the code generated by gcc 8 seems to have improved vastly for the EPYC processors. We repeated the single threaded test three times, and the rate numbers show the same thing: it is very consistent. 

hmmer is one of the more branch intensive benchmarks, and the other two workloads where the impact of branch prediction is higher (somewhat higher percentage of branch misses) - gobmk, sjeng - perform consistingly better on the second generation EPYC with it's new TAGE predictor. 

Why the low IPC omnetpp ("network sim") does not show any improvement is a mystery to us, we expected that the larger L3 cache would help. However this is a test that loves very large caches, as a result the Intel Xeons have the advantage (38.5 - 55 MB L3). 

The video encoding benchmark "h264ref" also relies somewhat on the L3 cache, but that benchmark relies much more on DRAM bandwidth. The fact that the EPYC 7002 has higher DRAM bandwidth is clearly visible. 

The pointer chasing benchmarks – XML procesing and Path finding – performed less than optimal on the previous EPYC generation (compared to the Xeons), but show very significant improvements on EPYC 7002. 

Latency Part Two: Beating The Prefetchers Multi-core SPEC CPU2006
Comments Locked

180 Comments

View All Comments

  • Kevin G - Wednesday, August 7, 2019 - link

    Clock speeds. AMD is being very aggressive on clocks here but the Ryzen 3000 series were still higher. I would expect new Threadripper chips to clock closer to their Ryzen 3000 cousins.

    AMD *might* differentiate Threadripper by cache amounts. While the CPU cores work, they may end up binning Threadripper based upon the amount of cache that wouldn't pass memory tests.

    Last thing would be price. The low end Epyc chips are not that expensive but suffer from low cores/low clocks. Threadripper can offer more for those prices.
  • quorm - Wednesday, August 7, 2019 - link

    Here's hoping we see a 16 core threadripper with a 4ghz base clock.
  • azfacea - Wednesday, August 7, 2019 - link

    half memory channels. half pcie lanes. also i think with epyc AMD spends more on support and system development. i can see 48c 64c threadripper coming 30-40% lower and not affecting epyc
  • twtech - Wednesday, August 7, 2019 - link

    If they gimp the memory access again, it mostly defeats the purpose of TR as a workstation chip. You'd want an Epyc anyway.
  • quorm - Wednesday, August 7, 2019 - link

    Well, on the plus side, the i/o die should solve the asymmetric memory access problem.
  • ikjadoon - Wednesday, August 7, 2019 - link

    Stunning.
  • aryonoco - Wednesday, August 7, 2019 - link

    Between 50% to 100% higher performance while costing between 40% to 50% less. Stunning!

    I remember the sad days of Opteron in 2012 and 2013. If you'd told me that by the end of the decade AMD would be in this position, I'd have wanted to know what you're on.

    Everyone at AMD deserves a massive cheer, from the technical and engineering team all the way to Lisa Su, who is redefining what "execution" means.

    Also thanks for the testing Johan, I can imagine testing this server at home with Europe's recent heatwave would have not been fun. Good to see you writing frequently for AT again, and looking forward to more of your real world benchmarks.
  • twtech - Wednesday, August 7, 2019 - link

    It's as much about Intel having dropped the ball over the past few years as it is about AMD's execution.

    According to Intel's old roadmaps, they ought to be transitioning past 10nm on to 7nm by now, and AMD's recent releases in that environment would have seemed far less impressive.
  • deltaFx2 - Wednesday, August 7, 2019 - link

    Yeah, except I don't remember anyone saying Intel was going great guns because AMD dropped the ball in the bulldozer era. AMD had great bulldozer roadmaps too, it didn't matter much. If bulldozer had met its design targets maybe Nehalem would not be as impressive... See, nobody ever says that. It's almost like if AMD is doing well, it's not because they did a good job but intel screwed up.

    Roadmaps are cheap. Anyone can cobble together a powerpoint slide.
  • Lord of the Bored - Thursday, August 8, 2019 - link

    Well, it is a little of both on both sides.
    Intel's been doing really well in part because AMD bet hard on Bulldozer and it didn't pay out.

    Similarly, when AMD's made really good processors but Intel was on their game, it didn't much matter. The Athlon and the P2/3 traded blows in the Megahertz wars, but in the end AMD couldn't actually break Intel because Intel made crooked business deals*backspace* because AMD was great, but not actually BETTER.

    The Athlon 64 was legendary because AMD was at the top of their game and Intel was riding THEIR Bulldozer into the ground at the same time. If the Pentium Mobile hadn't existed, thus delaying a Netburst replacement, things would be very different right now.

Log in

Don't have an account? Sign up now