LLR / Gwnums version
Are there any plans to implement Gwnums 24.13 in LLR? Latest LLR v.3.6 is based on 24.11 :sad:

[QUOTE]Are there any plans to implement Gwnums 24.13 in LLR? Latest LLR v.3.6 is based on 24.11 [/QUOTE]
I dont know, maybe George or Jean can answer this? :question: I'm not sure it is nessesary, without knowing the exact difference. 
[QUOTE=TTn]I'm not sure it is nessesary, without knowing the exact difference.[/QUOTE]
Looking at the speed increase from prime95 24.11 to 24.13 I guess it would be a good idea to update LLR too. 
[QUOTE]Looking at the speed increase from prime95 24.11 to 24.13 I guess it would be a good idea to update LLR too.[/QUOTE]
I particularly meant, the exact difference in code. Usually speed increases, translate to errors. Since George and Jean know exactly what they are doing, maybe that is why it hasn't been done yet. Or otherwise pesonal time is a factor. It is a valid question though. TTn 
Jean mentioned that he is testing the new gwnum version, have a look [URL=http://www.mersenneforum.org/showthread.php?t=4212]here[/URL] post #6 (and subsequent posts about the performance on HT cpu's). The new PRP based on 24.13 has been just released but note that brand new versions are risky without proper testing. LLR3.6 is very well tested and unless any new versions are more than 10% faster, IMO it's not worth the trouble to migrate.

Am I the only one to notice new 3.6.2 version of LLR? I will give it a try later today... but perhaps somebody is already using it?

LLR3.6.2 / gwnum V24.14
[QUOTE=Cruelty]Am I the only one to notice new 3.6.2 version of LLR? I will give it a try later today... but perhaps somebody is already using it?[/QUOTE]
Congratulations for your watch ! LLR Version 3.6.2 is identical to LLR Version 3.6 about the features, but with two advantages : 1) It is linked with very last gwnum version : V24.14 2) I tested it on all the verified Riesel an Proth primes from the Chris Caldwell database, and found neither false negative result nor error message of any kind. So, I think all LLR users have better to use this version now! Happy hunting and Best Regards, Jean 
If i use llrnet, can i just replace llr.exe?

[QUOTE=Pconfig]If i use llrnet, can i just replace llr.exe?[/QUOTE]
No, the llrnet executable is llrnet.exe, not llr.exe, and its last version is based on llr version 3.5, I will ask to Vincent for upgrading it, but actually, I think he is too much busy... 
Jean,
Is multiplying number mod a^a1 as fast as multiplying numbers mod k*2^n+1. Which one is faster? Secondly can LLR support a^a1/a1 and a^a+1/a+1? Citrix 
Present features of LLR program
[QUOTE=Citrix]Jean,
Is multiplying number mod a^a1 as fast as multiplying numbers mod k*2^n+1. Which one is faster? Secondly can LLR support a^a1/a1 and a^a+1/a+1? Citrix[/QUOTE] Presently, the LLR program is a special one, it is devised to prove the primality of numbers of the k*2^n1 and k*2^n+1 forms. On numbers of any other form, it can only do PRP tests, and is then equivalent to George Woltman's PRP program. Its speed performances are mainly due to the using of the gwnum library code, so, they are the best for calculus modulo k*2^n+b or k*2^nb, with k and b not larger than 2^20, either for primality proving or PRP tests. Jean 
So testing k*2^nb for k=736320585 is not the optimal way to use LLR?

Using LLR with big k's
[QUOTE=Cruelty]So testing k*2^nb for k=736320585 is not the optimal way to use LLR?[/QUOTE]
If b != 1, LLR will do a PRP test... If b == 1, LLR will do a proving test ; k being large, gwnum will work in generic mode in both cases, so you will not get the IBDWT performances, but I don't know if a faster program is presently available (try Openpfgw, but it also uses the gwnum code...). Jean 
Jean,
which is the fastest k to test, in terms of speed. Are all k under 2^20 the same speed? What is the difference in speed between a k under 2^20 and a k between 2^20 and 2^21? Citrix 
[QUOTE=Citrix]Jean,
which is the fastest k to test, in terms of speed. Are all k under 2^20 the same speed? What is the difference in speed between a k under 2^20 and a k between 2^20 and 2^21? Citrix[/QUOTE] It is rather more complicated... and it requires to give precisions about how the gwnum code proceeds to do multiplications modulo N = k*2^n+b numbers (surely, George Woltman would do that better than me...). 1) The speed is determined by the FFT length necessary to process a number N of given bit length. 2) According to the k size, the gwnum code uses three different algorithms to do multiplications : pure IBDWT, Zero paded IBDWT, generic mode. 3) The pure IBDWT algorithm can only be used with k values from 1 to around 2^20 ; it is the most efficient, because it requires the smallest FFT length, and makes the modular reduction totally free. Nevertheless, the FFT length for a given size of N increases smoothly by a factor of 2 when k goes from 1 to 2^20, then, the Zero padded algorithm becomes the better. 4) The Zero padded IBDWT can be used for k values up to around 2^48, and the performances continue to decrease smoothly. 5) For higher k values, the generic mode is used, and the speed for given size of N is around three times smaller than the IBDWT one. I hope this rather involved explanation will satisfy you. Jean 
The smaller the k the faster it will be? Did I get it right?
Citrix 
[QUOTE=Citrix]The smaller the k the faster it will be? Did I get it right?
Citrix[/QUOTE] Yes, for a given bit length of the number to test ! 
I've been trying to find a generic top5000 prime with LLR 4.62 recently. I chose Proth tests with n=409600, k increasing from 600 to 1000000, since 2^20 is 1048576.
But around k=65487, running on a P4 2.8GHz nonhyperthreaded, I noticed that LLR said I was using a zeropadded FFT. Which according to the thread above shouldn't happen, right? :surrender Looking through the log, there seems to have been a big jump in time taken between 60000 and 62000. While I can't completely rule out other processes for this jump, considering the size of the k, that zeropadded message is weird. :question: 
All times are UTC. The time now is 21:40. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2022, Jelsoft Enterprises Ltd.