AMD EPYC 9006 Results Are Here and AMD Delivers a Knockout Part Deux

STH Workloads

These are seven familiar server and developer jobs. Each is pinned to specific versions and built the same way on x86 and Arm. We report them separately, since a single-thread result and a whole-chip result answer different questions. Everything in this section is higher is better. Workloads that report time or latency are converted to a rate.

Linux Kernel Compile

We build the same pinned Linux kernel with the same pinned compiler on every system, x86 and Arm alike, and time the make. This is an update to our classic python driven Linux Kernel Compile benchmark because, well, it was time.

On one thread, the EPYC 9996 does 27.9 kernel builds per hour, about the same as Vera at 28.5. On the whole socket, it reaches 174, well ahead of Vera at 132 and the EPYC 9965 at 95.

x264 Transcode

This encodes video with libx264. Whole-chip runs use many encoders at once, the way a transcoding farm would.

x264 is a big win for the EPYC 9996 at 3,195 frames per second on the whole socket. It looks like we need to fix our chart here for later reviews. We had tested the new exporter with a number of smaller systems, but one thread on a 512-thread CPU scale is too small.

nginx

nginx serves a 1 KiB file over localhost to wrk. We run three versions: plain HTTP as a baseline, HTTPS with TLS 1.3 on persistent connections, and HTTPS with a full handshake on every request.

On one worker, the EPYC 9996 serves 326K HTTP and 246K HTTPS keep-alive requests per second, the most here. The EPYC 9965 is next at 231K and 176K, and Vera is at 153K and 138K. It also leads HTTPS handshakes at 8,011 per second.

PostgreSQL

PostgreSQL 18.6 runs sysbench OLTP over a Unix socket, so there is no network in the way. We show read-only and read-write.

The EPYC 9996 runs 61,607 read-write transactions per second on the whole socket, 16% ahead of the EPYC 9965 and 44% ahead of Vera. Read-only reaches 420,836, so writes are the limit at this scale. Vera’s run uses sysbench rebuilt against LuaJIT 2.1, because the bundled build crashes on Arm.

DaCapo

DaCapo runs real Java applications on the JVM. We show three views, starting with one thread across all five applications.

On a single thread, the EPYC 9996 does 673 DaCapo iterations per hour, the most here, ahead of the EPYC 9965 at 541 and Vera at 539. The single-thread Xeon 6980P result crashed, so we will have to re-run that.

Biojava and jython are single-threaded, so for the whole-chip view we use the three applications that scale.

One JVM across the whole socket is not the ideal case for the AMD EPYC 9996.

For those two single-threaded applications, we run many copies at once and measure total throughput.

Run many JVMs at once and the EPYC 9996 leads by a wide margin. Again, this is largely a factor of having more cores.

DCPerf

DCPerf models hyperscale services. FeedSim is a feed-ranking service, and we report the highest query rate that keeps p95 latency at or below 500 ms. TaoBench is a social-graph cache, and we report total requests per second.

The EPYC 9996 leads both DCPerf tests. Note that for Vera’s DCPerf runs we used a 4K-page kernel, and Grace could not run it on 64K pages. Unfortunately, we had the Supermicro NVIDIA DGX Station packed up before we could re-run this on Grace with the 4K-page kernel.

System Calls and Thread Wake-Ups

This one measures how fast a core can get into the kernel, and how fast a sleeping thread can wake up on the same core or another one. The test reports nanoseconds, but we chart million operations per second so it reads like everything else here.

The EPYC 9996 makes 24.6 million getpid calls per second, the most here, ahead of the EPYC 9965 at 17.2 and well ahead of Vera at 7.5. Kernels and page sizes differ, so I do not love this one, but I wanted to show what we had.

Pipe wake-ups on the EPYC 9996 drop from 1.03 million per second inside one L3 to 0.45 across L3s. It leads every placement it shares with the other chips. Keeping chatty threads inside one L3 still matters.

Again, missing bars are placements a chip does not have, or runs that crashed.