Why different runtimes for constant exponent and (huge) modulus for mpz_powm()?
hermann at stamm-wilbrandt.de
hermann at stamm-wilbrandt.de
Wed Jul 26 22:19:16 CEST 2023
On 2023-07-25 09:02, Niels Möller wrote:
>
> Curious. I would suspect some enviromental factors (e.g., high
> processor
> temperature sometimes leading to some frquency throttling, or something
> else on the machine periodically competing for cpu).
>
Thanks for responding.
That machine runs completely alone.
It just completed 908 rounds of the 11121 rounds.
The pattern changed a bit, once there was an upward phase before going
back:
https://stamm-wilbrandt.de/en/forum/908.png
Eich of the 908 round on x-axis takes nearly 10 minutes, so plateaus
seen take a long time. Im am on that machine only short times for
getting latest data or so.
Because of Ryzen 7000 series burnout risk I applied latest stable 1.24
bios before that run. 7600X CPU max operating temperature is 95°C, and I
operated it with PBO 85°C before bios upgrade. But after upgrade I
cannot set it above 75°C anymore, and maximally measured temperature
with stress test on all threads showed 76°C. So high temperature cannot
be it, and not throttling.
I did "perf stat process" before starting the now >6 days run and saw
that CPU frequency was always in 5.2..5.4GHz range (5.3GHz is nominal
burst CPU frequency).
Here the current state of the PC:
hermann at 7600x:~/9383761-digit-prime$ uptime
21:46:24 up 6 days, 4:12, 1 user, load average: 1.00, 1.00, 1.00
hermann at 7600x:~/9383761-digit-prime$
hermann at 7600x:~/9383761-digit-prime$ ps -ef | grep job
root 629465 629454 99 Jul22 ? 4-04:00:15 ./job 297
hermann 1947666 1942377 0 21:46 pts/0 00:00:00 grep --color=auto
job
hermann at 7600x:~/9383761-digit-prime$
I had to do a hotfix after 2 days of computation to avoid bug that was
guaranteed to happen after 75 day, details here:
https://github.com/Hermann-SW/9383761-digit-prime#hotfix
Total non-computing time by hotfix tool was less than 10 seconds only.
> Maybe it would be helpful to monitor performance related measurements
> such as cpu frequency (or cycle counter), temperature, and count of
> cache misses as computation progresses?
>
AMD is not good at temperature measurement support for Linux, but I
found an article with kernel driver change and then all will be fine. I
do not want to risk current >70 day computation though, so on Linux side
I am blind temperature wise at the moment (all tools get wrong values
with bad kernel support).
But I just learned that I can attach perf to a running process, and did
that, two times 5 seconds, and once 15 seconds. Always showing 5.23GHz,
near nominal 5.3GHz burst frequency.
How do you want me to count cache misses, with perf?
Over longer timeframe I think, multiple of 10min/round?
hermann at 7600x:~/9383761-digit-prime$ ps -ef | grep job
root 629465 629454 99 Jul22 ? 4-04:08:14 ./job 297
hermann 1949425 1942377 0 21:54 pts/0 00:00:00 grep --color=auto
job
hermann at 7600x:~/9383761-digit-prime$ echo 1 | sudo tee
/proc/sys/kernel/perf_event_paranoid
[sudo] password for hermann:
1
hermann at 7600x:~/9383761-digit-prime$ sudo perf stat -e cycles,task-clock
-p 629465 sleep 5
Performance counter stats for process id '629465':
26,173,724,427 cycles # 5.234 GHz
5,000.98 msec task-clock # 1.000 CPUs
utilized
5.001249395 seconds time elapsed
hermann at 7600x:~/9383761-digit-prime$ sudo perf stat -e cycles,task-clock
-p 629465 sleep 5
Performance counter stats for process id '629465':
26,156,801,154 cycles # 5.231 GHz
5,000.58 msec task-clock # 1.000 CPUs
utilized
5.000851191 seconds time elapsed
hermann at 7600x:~/9383761-digit-prime$ sudo perf stat -e cycles,task-clock
-p 629465 sleep 15
Performance counter stats for process id '629465':
78,483,835,106 cycles # 5.232 GHz
14,999.67 msec task-clock # 1.000 CPUs
utilized
15.000559563 seconds time elapsed
hermann at 7600x:~/9383761-digit-prime$
Regards,
Hermann.
More information about the gmp-devel
mailing list