View Single Post
Old 2022-06-29, 19:00   #16
kriesel's Avatar
Mar 2017
US midwest

22×29×59 Posts

Originally Posted by timbit View Post
I deleted existing gwnum.txt and results.bench.txt.

Non-optimal FFT chosen. It's truly bizarre.

Any thoughts on what a root cause may be?
Please stop routinely giving mprime "benchmark amnesia". Files results.bench.txt and gwnum.txt are for ACCUMULATING performance data. Over time. I have systems that have run prime95 for years for which these files have NEVER been cleared. Mprime/prime95 will repeatedly auto benchmark to handle the case of relative performance being affected by fluctuations in other loadings, whether caused by the user or system activity, until it builds up a sufficient count of redundant benchmark values. You're repeatedly intentionally erasing the history instead.

Perhaps there is a bug in v30.7 regarding benchmark handling. Have you considered trying v30.8b15?

For comparison, here's 48k fft benchmark results done two different ways on 4-core/8HT i5-1035G1, 2 of 2 DDR4-2666 SODIMMs x 8 GiB each, Win10 with prime95 v30.7b9, and the relevant portion of results.bench.txt produced from them both.
There is a considerable effect of what I think is memory bandwidth constraint visible, given that 4 cores/4workers produce only two to three times the total iteration throughput of a single core/worker. Note, this benchmark was while a multi-tab web browser session and multiple remote desktop session clients were also running. Prime95 gets ~59% of CPU while these & other tasks (Windows Explorer, AV, system services, etc.) keep the HT busy up to 90% of the 8 logical cores. That's my normal way of operating this particular system, so that's what I benchmark for.
Originally Posted by kriesel View Post
Please bite the bullet and benchmark with multiple workers.

edit: for ~77M PRP as DC, 4M fft, all 4 cores in use, checking my system above's results.bench.txt and running fft, I find it is using the fastest fft benchmarked, which happens to be 4M, Pass1=1K, Pass2=4K, clm=1, 4 threads.
Its results.bench.txt is ~0.5MB, gwnum.txt ~0.18MB. There have been rare cases where one grew too large and caused problems, but these sizes seem ok in this version.
Attached Thumbnails
Click image for larger version

Name:	martin48kbenchmark.png
Views:	40
Size:	11.2 KB
ID:	27066   Click image for larger version

Name:	martin48kbenchmark2.png
Views:	14
Size:	11.5 KB
ID:	27067  
Attached Files
File Type: txt martin48kbenchmark.txt (10.2 KB, 14 views)

Last fiddled with by kriesel on 2022-06-29 at 19:55
kriesel is offline   Reply With Quote