Multi-core SPEC CPU2006

For the record, we do not believe that the SPEC CPU "Rate" metric has much value for estimating server CPU performance. Most applications do not run lots of completely separate processes in parallel; there is at least some interaction between the threads. But since the benchmark below caused so much discussion, we wanted to satisfy the curiosity of our readers. 

Does the EPYC7601 really have 47% more raw integer power? Let us find out. Though please note that you are looking at officially invalid base SPEC rate runs, as we still have to figure out how to tell the SPEC software that our "invalid" flag "-Ofast" is not invalid at all. We did the required 3 iterations though. 

Subtest Application type Xeon
E5-2699 v4
@ 2.8
Xeon
8176
@ 2.8
EPYC
7601
@2.7
EPYC 
Vs
Broadwell EP
EPYC 
vs
Skylake
SP
400.perlbench Spam filter 1470 1980 2020 +37% +2%
401.bzip2 Compression 860 1120 1280 +49% +14%
403.gcc Compiling 960 1300 1400 +46% +8%
429.mcf Vehicle scheduling 752 927 837 +11% -10%
445.gobmk Game AI 1220 1500 1780 +46% +19%
456.hmmer Protein seq. analyses 1220 1580 1700 +39% +8%
458.sjeng Chess 1290 1570 1820 +41% +16%
462.libquantum Quantum sim 545 870 1060 +94% +22%
464.h264ref Video encoding 1790 2670 2680 +50% -0%
471.omnetpp Network sim 625 756 705 (*) +13% -7%
473.astar Pathfinding 749 976 1080 +44% +11%
483.xalancbmk XML processing 1120 1310 1240 +11% -5%

(*) We had to run 471.omnetpp with 64 threads on EPYC: when running at 128 threads, it gave errors. Once solved, we expect performance to be 10-20% higher. 

Ok, first a disclaimer. The SPECint rate test is likely unrealistic. If you start up 88 to 128 instances, you create a massive bandwidth bottleneck and a consistent CPU load of 100%, neither of which are very realistic in most integer applications. You have no synchronization going on, so this is really the ideal case for a processor such as the AMD EPYC 7601. The rate test estimates more or less the peak integer crunching power available, ignoring many subtle scaling problems that most integer applications have.  

Nevertheless, AMD's claim was not farfetched. On average, and using a "neutral" compiler with reasonable compiler settings, the AMD 7601 has about 40% (42% if you take into account that our Omnetpp score will be higher once we fixed the 128 instances issue) more "raw" integer processing power than the Xeon E5-2699 v4, and is even about 6% faster than the Xeon 8176. Don't expect those numbers to be reached in most real integer applications though. But it shows how much progress AMD has made nevertheless...

SMT Integer Performance With SPEC CPU2006 Multi-Threaded Integer Performance
POST A COMMENT

219 Comments

View All Comments

  • TheOriginalTyan - Tuesday, July 11, 2017 - link

    Another nicely written article. This is going to be a very interesting next couple of months. Reply
  • coder543 - Tuesday, July 11, 2017 - link

    I'm curious about the database benchmarks. It sounds like the database is tiny enough to fit into L3? That seems like a... poor benchmark. Real world databases are gigabytes _at best_, and AMD's higher DRAM bandwidth would likely play to their favor in that scenario. It would be interesting to see different sizes of transactional databases tested, as well as some NoSQL databases. Reply
  • psychobriggsy - Tuesday, July 11, 2017 - link

    I wrote stuff about the active part of a larger database, but someone's put a terrible spam blocker on the comments system.

    Regardless, if you're buying 64C systems to run a DB on, you likely will have a dataset larger than L3, likely using a lot of the actual RAM in the system.
    Reply
  • roybotnik - Wednesday, July 12, 2017 - link

    Yea... we use about 120GB of RAM on the production DB that runs our primary user-facing app. The benchmark here is useless. Reply
  • haplo602 - Thursday, July 13, 2017 - link

    I do hope they elaborate on the DB benchmarks a bit more or do a separate article on it. Since this is a CPU article, I can see the point of using a small DB to fit into the cache, however that is useless as an actual DB test. It's more an int/IO test.

    I'd love to see a larger DB tested that can fit into the DRAM but is larger than available caches (32GB maybe ?).
    Reply
  • ddriver - Tuesday, July 11, 2017 - link

    We don't care about real world workloads here. We care about making intel look good. Well... at this point it is pretty much damage control. So let's lie to people that intel is at least better in one thing.

    Let me guess, the databse size was carefully chosen to NOT fit in a ryzen module's cache, but small enough to fit in intel's monolithic die cache?

    Brought to you by the self proclaimed "Most Trusted in Tech Since 1997" LOL
    Reply
  • Ian Cutress - Tuesday, July 11, 2017 - link

    I'm getting tweets saying this is a severely pro AMD piece. You are saying it's anti-AMD. ¯\_(ツ)_/¯ Reply
  • ddriver - Tuesday, July 11, 2017 - link

    Well, it is hard to please intel fanboys regardless of how much bias you give intel, considering the numbers.

    I did not see you deny my guess on the database size, so presumably it is correct then?
    Reply
  • ddriver - Tuesday, July 11, 2017 - link

    In the multicore 464.h264ref test we have 2670 vs 2680 for the xeon and epyc respectively. Considering that the epyc score is mathematically higher, howdoes it yield a negative zero?

    Granted, the difference is a mere 0.3% advantage for epyc, but it is still a positive number.
    Reply
  • Headley - Friday, July 14, 2017 - link

    I thought the exact same thing Reply

Log in

Don't have an account? Sign up now