LLR Version 3.8.9 released

[chip]

i7-2600K @ 4500 (cores 1,3,5,7) RAM @ 1866

321 Prime Search. b=3, n~=9.5M, windows 6.1.7601, cllr64.exe 3.8.9
Using all-complex AVX FFT length 512K, Pass1=128, Pass2=4K, a = 5

1-core Time per bit: 2.215 ms. 1.00x
2-core Time per bit: 2.275 ms. 1.95x
3-core Time per bit: 2.595 ms. 2.56x
4-core Time per bit: 3.095 ms. 2.86x

ESP Prime Search. b=[91549...238411], n~=3.4M, windows 6.1.7601, cllr64.exe 3.8.9
Using all-complex AVX FFT length 320K, Pass1=256, Pass2=1280, a = 3

1-core Time per bit: 1.355 ms. 1.00x
2-core Time per bit: 1.370 ms. 1.98x
3-core Time per bit: 1.415 ms. 2.87x
4-core Time per bit: 1.730 ms. 3.13x

27 Prime Search. b=27, n~=4.2M, windows 6.1.7601, cllr64.exe 3.8.9
Using all-complex AVX FFT length 240K, Pass1=1280, Pass2=192, a = 5

1-core Time per bit: 1.065 ms. 1.00x
2-core Time per bit: 1.072 ms. 1.99x
3-core Time per bit: 1.078 ms. 2.91x
4-core Time per bit: 1.110 ms. 3.84x

P.S. CPU no throttling.

[pepi37]

Can any software can multi-thread one prime number?
Lets say I do search one number with 10.000.000 digits and then divide that search on 4 cores in parallel

[chip]

i7-2600K 4500MHz HT off memory 1866MHz
L2 Cache Hit Ratio vs FFT size:
link 1
link 2
link 3
Efficiency: 98.5%, 96.5%, 88.0% respectively (based on the comparison value "time per bit")
Four ESP FFT 384K has efficiency 76%

[pepi37]

It will be very useful option to add to LLR when llr finish compute candidate from list, then remove it ( like PRIME95) does...
It would not be too hard to implement to application.

[henryzz]

Originally Posted by pepi37

It will be very useful option to add to LLR when llr finish compute candidate from list, then remove it ( like PRIME95) does...
It would not be too hard to implement to application.

Please make this optional. Removing all the candidates from primed ks(possibly to another file) would be a nice feature as well.

[TheMawn]

Originally Posted by Prime95

There was one Mac built using a 32-bit Intel Core (not Core 2) CPU. A pity really, as I could release a prime95 of roughly half the size if I could ditch 32-bit support.

Lol. My two cents is that if that is the only thing stopping you, go for it. I would take any Mac off life support if it so much as coughs funny, and I would take any Core off life support, period.

[paulunderwood]

I have noticed, when testing ~9500k bit Wagstaff numbers (using the vrba-reix algorithm), that memory usage is 1.3% for the first number tested (after resumption) and then 1.9% for subsequent tests on a 2GB system. I think the results are good, but could this behavior be a memory leak?

debian and gentoo; llr64 3.8.9, dynamically linked

[paulunderwood]

Some more testing shows this behaviour only if a number is resumed -- it is 1.3%

[pepi37]

I have found this little disproportion in llr time

2*10^350156-1 is not prime. RES64: EC7C7E5598C4A371. OLD64: C5757B00CA4DEA50 Time : 322.996 sec.
2*10^350207-1 is not prime. RES64: 6C3C4597BC9FCFC5. OLD64: 44B4D0C735DF6F4D Time : 385.333 sec.
2*10^350348-1 is not prime. RES64: 5DD901176F43DDB8. OLD64: 198B03464DCB9925 Time : 323.997 sec.

Since those are small number L2 or L3 cache is not question. I recheck this number on other machine , with different version of LLR and also got bigger time. But question was, why time before and after number was smaller. What is so specific in this number so computation time is higher!

[Prime95]

Originally Posted by pepi37

What is so specific in this number so computation time is higher!

Ewww, do you really want to understand the nitty gritty details of FFT size selection?

I'd need to know the FFT length of the faster runs. I suspect that exponent (350207) / smaller-FFT-length is close to one of the "magic fractions" that gwnum thinks might generate higher than expected roundoff errors. For example, if there are exactly 18.5 bits per FFT word, then FFT words alternate between 18 and 19 bits. Now when you square such a number all the 19-bit times 19-bit multiplies are not randomly distributed in the result, instead they end up in every other column. This leads to a higher than expected roundoff error. Anytime the bits-per-word is "very near" a multiple of 1/2, 1/3, 1/4, 1/5, 1/6, 1/7, 1/8 gwnum might choose a larger FFT length.

[pepi37]

If I never ask I will never learn :)
Thanks for crystal clear explanation :)