AMD released new Ryzen processors today. Phoronix published an article that benchmarked these processors. Anand Tech also published a review. TechReport also wrote a review.

The posting is *not* measured on these new processors. Instead, it looks at dissecting the workloads when run on earlier AMD (Ryzen 1700) and Intel (Haswell i7-4770s) processors.

One thing I sometimes find frustrating on the Phoronix reviews is relatively little analysis behind what the benchmarks are testing or why the results might be different. So what I like to do is dig in a bit more what might be behind the numbers.

I don’t have these test systems (and keeping up would be relatively expensive); so instead I’ll look at some analysis of the benchmarks on earlier systems. These include my i7-4770s (Haswell) and a first generation Ryzen 1700 that I just installed. While it doesn’t dig into the details behind the newest performance, the analysis might help me understand what is being tested and help refine my tools.

Below is a table that compares the benchmark numbers in the Phoronix Article with my systems. The last column are links to deeper dives I’ve started on the benchmarks as I investigate them. I also update them on the workloads page.
As few high-level items I noticed in this exploration:

• The amount of runtime for workload itself varies from <1 second (redis) to >40 minutes (blender). Redis is a single-threaded benchmark that essentially tests latency of messages.
• The two Rodinia benchmarks are fairly different allowing some compare/contrast with each other. The CFD Solver has largest delays in backend (memory?) and LavaMD smaller code without much memory traffic.
• Timed linux kernel compile has a much higher amout of stalls in the front end
• The timed kernel compilation likely doesn’t fully accomplish a “make clean” as there are ~26000 processes in the 2nd and 3rd runs compared to ~29000 in the first
• OpenSSL interesting to dig deeper as a higher IPC benchmark with moderately higher Intel than AMD IPC

Otherwise multiple opportunities for “next steps” of digging deeper in each of the benchmark pages e.g. dissecting backend bound workloads into core/memory or investigating frontend issues like icache/iTLB or fetch/decode issues.

NOTE: As I was working through analysis of these benchmarks, Phoronix released another article looking at the performance governor including additional benchmarks. That seems to be primarily an issue of Linux kernel policies that increase frequencies (and power) improving benchmarks. However, it also includes 12 additional workloads that I’ll incrementally add to my database and then make a posting as I’ve start their analysis (now added: cachebench, luajit, john-the-ripper, gimp and apache-benchmark; skipped xonotic and tesseract as they are GPU; others a planned later).