Swap performance dramatically less?

[joelshort]

About two years ago I built a desktop PC for PI processing (Ryzen 5-1600 overclocked to 3850mhz, 32GB DDR4-2133 overclocked to 2800mhz, 1TB SSD). 

When I set up the computer I also used Imdisk to create a 15GB Ramdisk on the memory module.  Then I performed PI Benchmarks to set up the number of swap directories and I clearly remember that swap performance being around 20,000.

However recently I did another benchmark and for some reason the swap performance is only around 4000 and 800mb/s transfer rate.  I can't figure out what would have changed.  I have recreated the Ramdisk and as far as I can tell everything is set up properly, just as it always has.

What prompted this is that I got a new laptop, installed PI on it and setup an 8GB Ramdisk, and ran a benchmark.  The Swap performance was 15,000 and a much higher transfer rate than the desktop.  In every spec the desktop should perform better. 

Any idea what could have caused this change?

[joelshort]

Bump.  Any ideas?

[pfile]

i would try using blackmagic or some other disk speed test to see if there is a correlation.

the script can't actually measure the disk speed - what it does is look at the wall clock time for each processing step and report the difference between how much time the process self-reports as runtime and the wall clock time at the end of the process. it assigns this delta to the disk, but undoubtedly there are javascript interpreter delays that get rolled in to this. obviously timing various processes in a computer is rife with such problems so usually programs like blackmagic will read and write enormous amounts of data to try to minimize the overheads as a fraction of the total runtime. PI isn't doing large disk transfers in the benchmark - it's looking at one or two swap reads and writes each time its measuring.

IMO people put way too much emphasis on swap performance. most PI processes are fully CPU bound and the tiny amount of disk read/write at the end of the process is not the long pole in performance, given amdahl's law.

rob

[joelshort]

i would try using blackmagic or some other disk speed test to see if there is a correlation.

the script can't actually measure the disk speed - what it does is look at the wall clock time for each processing step and report the difference between how much time the process self-reports as runtime and the wall clock time at the end of the process. it assigns this delta to the disk, but undoubtedly there are javascript interpreter delays that get rolled in to this. obviously timing various processes in a computer is rife with such problems so usually programs like blackmagic will read and write enormous amounts of data to try to minimize the overheads as a fraction of the total runtime. PI isn't doing large disk transfers in the benchmark - it's looking at one or two swap reads and writes each time its measuring.

IMO people put way too much emphasis on swap performance. most PI processes are fully CPU bound and the tiny amount of disk read/write at the end of the process is not the long pole in performance, given amdahl's law.

rob

Thanks Rob.  I'll check out blackmagic.

I do understand that swap performance isn't hugely important.  It is clear to me that the bottleneck is the CPU.  But I'm just trying to understand what would have caused this change in swap performance and why I can't get it any better when I know that it was much better before when I first set up the Ramdisk.