Ryzen 3600 vs 8086k for Prime number finding

[porina]

Enjoy the eye test above, but that's the initial test results. Now what does it mean?

 

First, the test systems:

1a, Ryzen 2600, Noctua NH-D9L, Asrock B450 Gaming-ITX/ac bios 3.3 (AGESA combo 1.0.0.1), Kingston HyperX RGB 4000 @ 3400C18

1b, as above but Ryzen 3600, G.Skill TridenZ 3000C14 (it wouldn't run the faster ram)

2, 8086k, Noctua NH-D14/15, Asrock Z370 Pro4, Corsair Vengeance RGB 3000C15

 

This applies to prime number finding using software similar to Prime95, including LLR and PFGW. Probably genefer too but that is more different. The built in benchmark in Prime95 was used to get raw data, which was processed to give the above chart. The normalisation was applied so that each FFT size is comparable in value, which it wouldn't be if left raw as smaller ones are faster than bigger ones. CPUs were left running at default clocks on each system. They were NOT equally clocked, even though all are 6 core. The 8086k ran at 4.3 GHz all core, the 2600 fluctuated between 3750 and 3800 MHz. The 3600 was around 3900 MHz.

 

I colour coded so that the 8086k is blue, 3600 is green, and 2600 is orange/red. There are three lines for each, corresponding to 1, 2 and 6 workers. A worker is a task. All 6 cores were used in benching, so 1 worker uses 6 cores, 2 workers use 3 cores each, and 6 workers used 1 core each.

 

The FFT size is proportional to the FFT data size, which is 8 times the FFT size. e.g. 1024k FFT = 8192 kB data. There is also some non-FFT data involved which doesn't seem to be significant.

 

We can essentially ignore the 2600. Zen(+) and their weak FPUs were not really significant in performance. That leaves the 8086k going against the 3600, how do they compare?

 

Compare the dark blue and dark green lines. This is running one task per core. Note the blue line drops around 240k FFT, whereas the green line drops around 640k FFT. The 8086k has 2MB/core of L3 cache, which is equivalent to 256k FFT size, so not far from the 240k observed. Above that size, it is slowed down by inadequate ram bandwidth to feed it. The 3600 has 32MB shared between 6 cores, equivalent to 5.3MB/core, or 666k FFT. Again, close to the observed 640k FFT before dropping. In the high area, the 8086k is a bit higher than the 3600, presumably due to its higher clock.

 

If we now compare the mid blue line also, this behaves similarly to the dark green line. Two tasks of 3 cores each running on the 8086k would each have 6MB, similar to the 5.3MB/core of the 3600. Applying two workers to the 3600, we effectively triple the cache to 16MB/worker. This again is seen in the chart by the drop of the mid green line around 2048k FFT.

 

Finally looking at the light lines which are 1 worker using all cores. For the light blue line we see a drop somewhere between 1024k and 2048k, again relating to the 1536k maximum FFT for 12MB cache. The light green line for the 3600 is interesting. It is much flatter. 32MB of cache should drop around 4096k, but it looks like it started a little early. I suspect here we're seeing the limitations of the Zen 2 architecture. The 32MB cache is actually two independent 16MB caches so can't work together. I suspect this is hindering its ability to perform. Even then, it is still way above what the 8086k can offer.

 

To put this in context, what FFT sizes are actually used?

 

GIMPS (Prime95) leading edge work is at 5120k, so the 3600 is ball park 33% faster than 8086k.

 

PrimeGrid runs a variety of projects ranging from 120k to 2880k. For up to about 1024k there isn't a lot between them, but the 3600 takes the lead above that.

 

Additional observations about the 3600: it runs HOT. Keep in mind I'm not using the tiny stock cooler, but a Noctua NH-D9L, it was hitting around 80C. The incremental power usage (load - idle) measured at the wall, running six 128k FFTs was 81W on the 3600, compared to 89W on the 2600. So the 3600 was doing more than twice the work of the 2600 at slightly lower incremental power. Nice. Note the changes to FPU are expected to be 2x, and the bit extra is probably due to the slightly higher average clock on the 3600.

 

Next step of testing will be to remove the variable clock concerns so a more precise IPC can be examined.

[CiBi]

Very interesting.

 

I would love to see more testing in regards to the thermals. I assume you don't by any chance have an AIO watercooler with AM4 mounting laying arround?

I'm wondering about the impact the off-centre assymetrical die has on the waterblocks that have the micro fins centered.

The NH-D9L still running it so hot worries me as well, could you do a comparison with the stock AMD cooling solution?

[porina]

20 minutes ago, CiBi said:

I would love to see more testing in regards to the thermals. I assume you don't by any chance have an AIO watercooler with AM4 mounting laying arround?

I have a 240mm AIO on my Ryzen 1700 system. I was debating dropping the new CPU in there but the bios support is a bit questionable.

20 minutes ago, CiBi said:

The NH-D9L still running it so hot worries me as well, could you do a comparison with the stock AMD cooling solution?

I don't think I'll bother, it isn't going to be pretty.

 

Note AMD's boost strategy is different from Intel's. It is more similar to GPU in that it gradually downclocks as temps go up, so cooling is more about how far you want to sustain boost.