Performance Testing and Methodology
For general performance testing, we use virtually the same software we use in our motherboard testing and evaluation. Each test is run multiple times to ensure accuracy. The middle result is used in each case. The following system configurations were used for all benchmarking and testing.
Due to the scheduler improvements to Windows 10 build 1903, we decided to use build 1903 for all system testing. While many of the applications here have been used before in our motherboard reviews, even with the same configurations, the numbers are not comparable. Those were all done on builds 1803 and 1809 using the drivers that were current then. All systems were freshly formatted and all the latest drivers and OS patches were used. All of the systems were updated to their latest BIOS revisions. Finally, for the Intel system, I did install the CPU microcode updates relevant to that CPU. It’s important to note that build 1903 does contain improved mitigations for several security flaws on Intel processors. However, I did not go out of my way to download any additional or optional mitigation patches. Hyperthreading also remained enabled for all testing.
We also followed AMD’s recommendations for using CPPC2 which is enabled by using AMD’s balanced power plan. Essentially, we created a “best case” scenario for each system outside of the hardware configurations. For the hardware, it was impossible to use the same memory modules on all of the test systems due to the nature of memory compatibility on different motherboards. That said, we were able to use common frequencies and keep the timings relatively close for the most part. This was not the case with the Threadripper system, which would not cooperate regarding running tighter timings. It simply could not complete all the tests at the same timings used by other systems. The timings in the table are the RAM’s default timings at maximum speeds. They were all run at 16,18,18,36,1T @ DDR4 3200MHz.
Finally, all systems were run at stock and overclocked values. The “stock” settings are their automatic or default base/boost clocks. The boost clocks are shown in the graphs for reference. An overclocked value for each CPU was used as well, running all cores at a fixed speed shown in each table.
One final note is that I’ve left the higher-end CPU’s in the tables for reference purposes. While I don’t think too many people would actually cross-shop a Ryzen 5 3600X and a Ryzen 9 3900X, I think many people are sometimes curious as to what exactly, the price increase gets you in various applications. That said, keep in mind that price-wise, the only CPU the Ryzen 5 3600X is really competing with here is Intel’s Core i5 9600K as they cost almost exactly the same amount at the time of this writing.
Also, keep in mind that the AMD systems are being compared with vastly different AGESA code versions. While I haven’t seen Earth-shattering differences, its something to keep in mind when viewing the results. They are somewhat sporadic in places, however, I don’t think they would change all that much for our purposes here. That is, I don’t think to retest an earlier configuration with an updated AGESA code when the boost clocks were nearly correct, would have much of an impact. We’ve already tested this previously and found very little in the way of performance improvement from an AGESA code change.