Re: dodeca3
[B]R. Gerbicz[/B]
Thanks for your quick reaction! The new version is indeed up to 2 times faster than before. I'll now check whether it correctly detects already known DodecaProths. Once I wrote a similar program to search for a long arithmetic progression of primes so I have some /limited/ experience. 
Dodecaproth n 'weights'
I'm defining the 'weight' of an n as the number of PRP tests that dodeca_30 needs to perform when checking that n for a range of 0,10T.
The lower the weight the faster it will be to check that n. The higher the weight the slower it will be. n=80 weight=45489 n=81 weight=50735 n=82 weight=36134 n=83 weight=31322 n=84 weight=79800 n=85 weight=11925 n=86 weight=71370 n=87 weight=46678 n=88 weight=10297 n=89 weight=452294 n=90 weight=19023 n=91 weight=31650 n=92 weight=57436 n=93 weight=18424 n=94 weight=76983 n=95 weight=17651 n=96 weight=23206 n=97 weight=72811 n=98 weight=77654 n=99 weight=86727 n=89 sticks out somewhat! And I've already taken n=88 :) 
[QUOTE=Greenbank]
n=89 weight=452294 n=89 sticks out somewhat! And I've already taken n=88 :)[/QUOTE] See my benchmarks for n=89, comparing dodeca_2_5 and 3_0 ( just for [0T,1T] ): dodeca_2_5: Number of Prp tests=1225 Time=46 sec. dodeca_3_0 Number of Prp tests=45391 Time=23 sec. So it isn't very important the number of prp tests, see my mpz_powm() instruction for n=89 bits modulus takes about say 50000 clock cycles, so if we are checking 45391 prp tests, then that take about 2*10^9 clock cycles or about 1.3 sec. for my pc ( 1.7 GHz ), so the prp testing time is about 5% of the total time, 95% is the sieving time! That was the reason why I've decreased all parameters in 2_5 version of dodeca program. I've also defined the weight of n ( for dodeca numbers ). See post #28 in this thread. 
R.Gerbicz
Why is [I]k[/I] maxed to 2^60 in dodeca.c? There are 4 more bits in 8byte unsigned int and furthermore, if you keep k/105 instead of [I]k[/I], the range can be extended to 105*(2^641) without using gmp variables, not so?

new dodeca program version 4.0
1 Attachment(s)
In this version there is no limitation on k, and I've also decreased prime_limit from 2000 to 1000 ( and try also O1 optimization flag ).
See the attachment for the code. Or download exe from [URL="http://www.robertgerbicz.tar.hu/dodeca_4_0.exe"]http://www.robertgerbicz.tar.hu/dodeca_4_0.exe[/URL] 
My first tests indicate that ver.4 is about 30% slower than ver.3. Please tell me, can I use ver.3 to test n=103 for k<2^60 (by removing the n>=100 condition from the source).

[QUOTE=Kosmaj]My first tests indicate that ver.4 is about 30% slower than ver.3. Please tell me, can I use ver.3 to test n=103 for k<2^60 (by removing the n>=100 condition from the source).[/QUOTE]
In some cases it is possible because it is using sieve_limit=1000. Yes you can change ver.3, by removing that condition. Note that in all of the new programs now you can change sieve_limit in the source and to do this you have to change also number_of_primes, because there is an error checking for this in the program, you can also change block_length and magic_constant, and of course magic_constant>=block_length>=sieve_limit has to be true . But note that in hexadeca program you can change only sieve_limit ( and number_of_primes ), don't change block_length otherwise the program won't search for the whole interval for n=76 ( there is no magic_constant for this hexadeca ). I've changed the source in dodeca_4_0 to use sieve_limit=2000 and number_of_primes=303 but this was still slower by 7% for n=99. I don't know why perhaps because we are using in that part mpz_t integers and not long variables. 
All times are UTC. The time now is 02:59. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2021, Jelsoft Enterprises Ltd.