GP parfor is really cool

I used parfor earlier sometimes, with my 16C/32T AMD 7950X CPU.


Yesterday I needed to check >2600 >10,000 decimal digit numbers with 
ispseudoprime() and report prime candidates only.

I did start with another unrelated process running with 100% CPU 
utilization. That was a problem, since gp took 3200 CPU%, and the 
machine became unresponsive. It was pingable, but new ssh into was not 
possible. After two minutes ^C was displayed in existing ssh session, 
and after more minutes I was able to execute "killall gp" and all was 
fine again.


Next I did run with numactl restricting gp to 16 threads, and all was 
fine:

hermann@7950x:~$ time numactl -C 0-15 gp -q < 23801.gp
187
2648

real	7m29,400s
user	117m53,276s
sys	0m9,025s
hermann@7950x:~$


Today I did apt remove pari-gp on my 192C/384T 8-socket Intel Xeon 
Ubuntu 24.04.3 server. Then I did build pari after "./Configure 
--mt=pthread" and having installed libreadline-dev. Now 2.17.3 starts 
with reporting:

                    threading engine: pthread, nbthreads = 384

First I did start without numactl, and top reported 38400 CPU% used:

hermann@x3950-X6:~$ time gp -q < 23801.gp
187
2648

real	1m21.723s
user	442m38.595s
sys	0m11.047s
hermann@x3950-X6:~$

Nice, 6× faster than my AMD 7950X CPU PC.

For comparison I did restrict to 192 threads:

hermann@x3950-X6:~$ time numactl -C 0-191 gp -q < 23801.gp
187
2648

real	1m27.705s
user	245m17.224s
sys	0m8.921s
hermann@x3950-X6:~$

Slightly slower than unrestricted, but nearly doubling user time. So I 
will restrict with numactl to 192 from now on.


User time is still slightly double than that of the AMD 7950X CPU, which 
is caused by that CPU launch date 9/2022 versus my Xeon 8890v4 CPUs 
launch date of Q2/2016.

RAM is no problem on the server, it has 1TB with measured 436GB/s memory 
access.


For comparison the small gp script:

n=23801;
m=primepi(n)+1;
P=prime(m)#;
export(P,m);
parfor(i=2,m,if(ispseudoprime(P/prime(i)+1),print(i)));


Regards,

Hermann.