AMD Rome Second Generation EPYC Review: 2x 64-core Benchmarked
by Johan De Gelas on August 7, 2019 7:00 PM ESTJava Performance
The SPECjbb 2015 benchmark has 'a usage model based on a world-wide supermarket company with an IT infrastructure that handles a mix of point-of-sale requests, online purchases, and data-mining operations'. It uses the latest Java 7 features and makes use of XML, compressed communication, and messaging with security.
We test SPECjbb with four groups of transaction injectors and backends. The reason why we use the "Multi JVM" test is that it is more realistic: multiple VMs on a server is a very common practice.
The Java version was OpenJDK 1.8.0_222. We used the older JDK 8 as the most recent JDK 11 has removed some deprecated JAVA EE modules that SPECJBB 1.01 needs. We applied relatively basic tuning to mimic real-world use, while aiming to fit everything inside a server with 128 GB of RAM:
We tested with huge pages on and off.
The graph below shows the maximum throughput numbers for our MultiJVM SPECJbb test. Since the test is almost identical to the one that we have used in our ThunderX2 review (JDK8 1.8.0_166), we also include Cavium's server CPU.
Ultimately we publish these numbers with a caveat: you should not compare this with the official published SPECJBB2015 numbers, because we run our test slightly differently to the official run specifications. We believe our numbers make as much sense (and maybe more) as most professionals users will not go for the last drop of performance. Using these ultra optimized settings can result in unrepeateable and hard to debug inconsistent errors - at best they will result in subpar performance as they are so very specific to SPECJBB. It is simply not worth it, a professional will stick with basic and reliable optimization in the real non-HPC world. In the HPC world, you simply rerun your job in case of an error. But in the rest of the enterprise world you just made a lot users very unhappy and created a lot of work for (hopefully) well paid employees.
The EPYC 7742 performance is excellent, outperforming the best available Intel Xeon by 48%.
Notice that the EPYC CPU performs better with small pages (4 KB) than with large ones (2 MB). AMD's small pages TLB are massive and as result page table walks (PTW) are seldom with large pages. If the number of PTW is already very low, you can not get much benefit from increasing the page size.
What about Cavium? Well, the 32-core ThunderX2 was baked with a 16 nm process technology. So do not discount them - Cavium has a unique opportunity as they move the the ThunderX3 to 7 nm FFN TSMC too.
To be fair to AMD, we can improve performance even higher by using numactl and binding the JVM to certain CPUs. However, you rarely want to that, and happily trade that extra performance for the flexibility of being able to start new JVMs when you need them and let the server deal with it. That is why you buy those servers with massive core counts. We are in the world of micro services, docker containers, not in the early years of 21st century.
Ok, what if you do that anyway? AMD offered some numbers, while comparing them to the officialy published SPEJBB numbers of Lenovo ThinkSystem SR650 (Dual Intel 8280).
AMD achieves 335600 by using 4 JVM per node, binding them to "virtual NUMA nodes".
Just like Intel, AMD uses the Oracle JDK, but there is more to these record breaking numbers. A few tricks that only benchmarking people can use to boost SPECJBB:
- Disabling p-states and setting the OS to maximum performance (instead of balanced)
- Disabling memory protection (patrol scrub)
- Using older garbage collector because they happen to better at Specjbb
- Non-default kernel settings
- Aggressive java optimizations
- Disabling JVM statistics and monitoring
- ...
In summary, we don't think that it is wise to mimic these settings, but let us say that AMD's new EPYC 7742 is anywhere between 48 and 72% faster. And in both cases, that is significant!
Facebook
Twitter
RSS
180 Comments
View All Comments
wrkingclass_hero - Sunday, August 11, 2019 - link
What does AMD have to do to get a Gold or Platinum recommendation?oRAirwolf - Thursday, August 15, 2019 - link
This is a good questionimaskar - Sunday, August 11, 2019 - link
Single thread performance is very important for those who lives in cloud. A quick example: suppose I provision 2 core/4gig vm (this is of course hyperthreads). And on AWS I have a choice - m5 and m5a, where AMD is cheaper. What do I sacrifice? Not really throughput, because you don't run your prod workloads at 100% CPU. But there is the latency. If those cores clocked lower, I would get the same amount of responses, but slower. And since in microservice world you have a chain of calls, you get this decrease 10 times. Is it worth it?That was the case for 1st gen EPYC. Would 2nd gen have latency parity?
notashill - Sunday, August 11, 2019 - link
It's hard to say until the cloud instances actually launch.The current m5a instances are using a custom SKU which is clocked at 2.5GHz max boost.
Rome's IPC is ~15% higher and clock speeds are all around higher so single threaded performance should be quite a bit better, but ultimately the exact numbers will depend on which SKUs the cloud vendors decide to use and how high they clock.
duploxxx - Tuesday, August 13, 2019 - link
did you actually ever work with hypervisors?there are other things than raw clock speed.... its all about scheduling and when there are more cores / socket available the scheduling is more relaxed, less ready time..... EPYC generation 1 is already awesome for hypervisor way better choice than most Intel counter parts for sure if you look at socket cost... but than again I am probably talking to a typical retard ****
JoeBraga - Wednesday, August 14, 2019 - link
Can you Explain better? But the license isn't bought by the quantity of coresor Per socket?imaskar - Wednesday, August 14, 2019 - link
He probably talks about VmWare, which is licensed per socket, not per core. So with EPYC gen2 you need twice less licenses for the same cloud capacity (assuming cores are equal).JoeBraga - Wednesday, August 14, 2019 - link
Now I understoodimaskar - Wednesday, August 14, 2019 - link
Rather than calling others retards, you could first dig a little deeper into an issue. No, I don't work with hypervisors directly, I'm from the other side. I write software and I want good latency (not insane one like for HFT, but still a good one). Because for throughput we could just spin one more instance. You can't buy latency horizontally.I'm not taking numbers out of the blue. There is a benchmark for AMD instances vs Intel instances on AWS. I'm not sure if we are allowed to post links to other resources here. Put this string into Google and you will surely find it: "A Look At The AMD EPYC Performance On The Amazon EC2 Cloud". Despite this article being very enthusiastic about those instances, you can really see that per core performance on Intel is better, meaning better latencies for web apps.
I will probably write my own set of benchmarks, because that one seems to completely ignore web servers. I am very enthusiastic about AMD instances, but they are definitely not a no-brainer.
quadibloc - Tuesday, August 13, 2019 - link
The new Ryzen chips compete well with what Intel is currently producing. But while they doubled AVX 2 support, so as to match what Intel has, Ice Lake will double that - as has been known for some time. So if this is what AMD thought would be competitive with Ice Lake, as Forrest Norrod said, AMD was not trying hard enough - and they're just lucky Ice Lake was late. AMD's position relative to Intel with its previous generations of Ryzens seems to be the limit of their ambitions. Combine that with Intel reacting to its current issues, and it looks to me that AMD will have to rethink some aspects of its strategy to avoid Intel being ahead when it comes time for next year's chips from both companies.