PARI/GP is based on GMP by default (aarch64/GMP-6.2.1 kernel):Have you compared the speed of pari against gmp/BigNum for factorisation or prime test? I haven't tried gmp with the Pi5 yet, it wasn't very fast on the Pi4, it only uses a single thread.
Code:
? \v GP/PARI CALCULATOR Version 2.15.4 (released) arm64 running linux (aarch64/GMP-6.2.1 kernel) 64-bit version compiled: Dec 9 2023, gcc version 12.2.0 (Debian 12.2.0-14) threading engine: pthread (readline v8.2 enabled, extended help enabled)? https://github.com/Hermann-SW/9383761-d ... -p-1-mod-4
For factoring primes I use multithreaded cado-nfs, that was able to factor RSA-100 on Pi400 in 12.1h first, then overclocked and with a ARM bug I reported fixed, took only 1.8h(!) on Pi400 :
viewtopic.php?p=2124800&hilit=cado+nfs+ ... w#p2124800
Later I did measure factoring times on Pi400 and only 13:30min on overclocked Pi5(!):
Code:
| | Pi400 | Pi5 || RSA | 2.2GHz | 3GHz ||-----+---------+---------+| 100 | 1:49:54 | 0:13:30 || 110 | 4:41:35 | 1:27:27 || 120 | — | 5:05:17 |https://github.com/Hermann-SW/RSA_numbe ... ring-rsa-x
Cool -- how long did the computation take for you on what CPU?I achieved a T5K a couple of weeks ago through SRBase, unfortunately I didn't notice until after the five days registration window so it was then registered as anonymous.
210060*91^331939-1
210060*91^374955-1 was also found by someone else on the same day, I've not seen similar primes occur on the same day before.
Code:
? #digits(210060*91^331939-1)%1 = 650288? http://jpenne.free.fr/
Runs on x86 architecture only because of gwnum lib, which is able to parallelize computation of single multiplication(!) of big numbers.
I learned that I have to force LLR to run on chiplet0 of my 16C/32T 7950X CPU, just did that and proved your number as prime in only 21min ...
Code:
hermann@7950x:~$ taskset -c 0-7,16-23 ./sllr64 -t16 -d -q"210060*91^331939-1"Base factorized as : 7*13Base prime factor(s) taken : 13Resuming N+1 prime test of 210060*91^331939-1 at bit 1005663 [46.55%]Using zero-padded AVX-512 FFT length 288K, Pass1=768, Pass2=384, clm=2, 16 threads, a = 3210060*91^331939-1 may be prime. Starting Lucas sequence... Using zero-padded AVX-512 FFT length 288K, Pass1=768, Pass2=384, clm=2, 16 threads, P = 6210060*91^331939-1 may be prime, trying to compute gcd's U((N+1)/13) is coprime to N!210060*91^331939-1 is prime! (650288 decimal digits, P = 6) Time : 1260.674 sec. hermann@7950x:~$ sCode:
hermann@7950x:~$ ps -o etime= -p 2591 03:20hermann@7950x:~$top - 10:17:39 up 13 min, 2 users, load average: 10.34, 5.59, 2.39Tasks: 464 total, 2 running, 462 sleeping, 0 stopped, 0 zombie%Cpu(s): 0.0 us, 3.7 sy, 25.2 ni, 71.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 stMiB Mem : 31190.9 total, 29557.6 free, 798.1 used, 835.2 buff/cacheMiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 30006.2 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2591 hermann 39 19 1995820 84544 2816 R 1068 0.3 36:57.92 sllr64 I recently figured out that >950,000 decimal digits are needed to see 16 threads being used:
https://mersenneforum.org/showthread.ph ... post649334
So what do I use PARI/GP for?
Not factoring, and not prime proving.
Although I learned that its precomputed prime tables allow to really fast use of "prime()":
https://pari.math.u-bordeaux.fr/archive ... 00030.html
Code:
$ gp -p4M? for(n=1,2^18, prime(n));time = 1,315 ms.We have all the necessary primes:? prime(2^18)% = 3681131This small code does compute all xyz coordinates for n=61:
https://github.com/Hermann-SW/GP3D/blob ... gp#L32-L41
Code:
assert(getenv("n")!=0); n=eval(getenv("n")); print("n=",n); assert(n%4!=0&&n%8!=7); Q=qflllgram(get_tqf(n))^-1; M=Q~*Q; S=[x|x<-Vec(qfminim(M,n)[3]),qfeval(M,x)<=n]; jscad.open();https://github.com/Hermann-SW/GP3D/blob ... .gp#L5-L29 )
If I would replace "qfeval(M,x)<=n" by "qfeval(M,x)==n" I would get only those 3-tuples [x,y,z] with x^2+y^2+z^2==n.
I can see those by enabling white sphere surface with radius sqrt(61) for above animation:
Statistics: Posted by HermannSW — Tue Feb 06, 2024 9:54 am