mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Sierpinski/Riesel Base 5 (https://www.mersenneforum.org/forumdisplay.php?f=54)
-   -   A multiple k/c sieve for Sierpinski/Riesel problems (https://www.mersenneforum.org/showthread.php?t=5785)

geoff 2006-09-26 22:32

[QUOTE=michaf;87924]Is it possible (or even sensible) to let sr5sieve make a save-file for the legendre-symbols?
[/QUOTE]
It is possible, the file would be about 20MB. I'm not really keen on the idea though. If I can I will try to speed up the table building (this will get faster as we find primes for some of the larger k, the time and memory use in this step is proportional to the squarefree part of k).

michaf 2006-09-27 10:15

[QUOTE=geoff;87960]Has anyone else had any problems with this version?[/QUOTE]

For me, running some 40 hours straight now, no problems whatsoever (Athlon 64 X2 3800, winXP SP2)

geoff 2006-09-27 22:25

Version 1.2.5 fixes a division by zero bug in version 1.2.3 and 1.2.4 that will cause a crash if a factor is found within 1 seond of starting.

[QUOTE=em99010pepe;87881]AppName: sr5sieve.exe AppVer: 0.0.0.0 ModName: sr5sieve.exe
ModVer: 0.0.0.0 Offset: 0000600d
[/QUOTE]

The location 0x0600d is a division by zero trap, so I hope this is just the bug above. But if not then run the debugging version in the sr5sieve/tests directory and send me the core file that gets created when it crashes (my email address is in the README.txt).

michaf 2006-09-29 17:26

Geoff,

I seem to get the same error on my machine, with sr5sieve 1.2.5
(sr5sieve-1.2.5-mingw32-i686.zip)

I can reproduce the error, but get different amounts of factors found before it quits.

(on 3 cases, I got 2 or 6 factors)

note, this is on a sieve file of 33M candidates (from n=2-10M), so I get about 10 factors each second stilll)

geoff 2006-09-30 00:26

[QUOTE=michaf;88180]Geoff,

I seem to get the same error on my machine, with sr5sieve 1.2.5
(sr5sieve-1.2.5-mingw32-i686.zip)

I can reproduce the error, but get different amounts of factors found before it quits.

(on 3 cases, I got 2 or 6 factors)

note, this is on a sieve file of 33M candidates (from n=2-10M), so I get about 10 factors each second stilll)[/QUOTE]

Can you run the debugging version in [url]http://www.geocities.com/g_w_reynolds/sr5sieve/tests/[/url] and send me the core file produced when it crashes?

If you start the program from the same place each time (i.e. from the same checkpoint.txt file), does it crash in exactly the same place? Can you post the address Windows says it crashes at (like the offset 0000600d Carlos posted)?

If anyone else is having problems with the latest version then it probably best to go back to version 1.2.2 until I can work out where the bug is.

michaf 2006-09-30 18:02

Geoff,

it gives the following on the debug-version:

AppName: sr5sieve.exe AppVer: 0.0.0.0 ModName: sr5sieve.exe
ModVer: 0.0.0.0 Offset: 000075fd

It crashed now three times in a row on the second factor found, and once on the sixth factor found. I'll do 10 tests now to see what happens.

Result: 6 times 6 factors found, and 4 times 2 factors found before a crash occurs

axn 2006-09-30 18:21

Another crash:

AppName: sr5sieve.exe AppVer: 0.0.0.0 ModName: sr5sieve.exe
ModVer: 0.0.0.0 Offset: 000063ad

This time, well into a 30hr stretch of run. Successfully resumed.

geoff 2006-10-01 00:22

sr5sieve 1.2.6
 
This version fixes another division by zero bug present in 1.2.3-1.2.5 that would cause a crash if two factors were found within 1 millisec of each other.

These recent division by zero bugs were just in the code that calculated the timings for display, so there is no need to repeat any work done with versions 1.2.3-1.2.5.

michaf 2006-10-01 09:36

So far so good :) thanks!

geoff 2006-10-19 23:53

sr5sieve 1.3.0 checks whether -ckb^n is a cubic/quartic residue before adding k*b^n+c to the sieve. This is not really a win for the current base-5 sieve, just a minor speedup for P2 and Katmai P3 machines, little change for Coppermine P3, and a slowdown for the P4. If this version is slower on your machine then use 1.2.7 instead.

The base-2 timings are interesting. The n range is much larger for these projects and so the cost of performing the residue tests is a smaller proportion of the time saved by not sieving the non-residues. sr2sieve (sr5sieve compiled with BASE=2) is the linux32-i686 binary, proth_sieve is the linux_cmov binary, the machine is a Katmai P3/450:

riesel.dat (69 k, 20 million n):
[CODE]
sr2sieve 1.2.7 sr2sieve 1.3.0 proth_sieve 0.42

p=1e12: 12.7 kp/s 17.2 kp/s 24 kp/s
p=1e13: 13.8 kp/s 18.5 kp/s 25 kp/s
p=1e14: 14.9 kp/s 19.6 kp/s 20 kp/s
p=1e15: 15.8 kp/s 20.6 kp/s 6 kp/s
[/CODE]

SoB.dat (20 k, 50 million n):
[CODE]
sr2sieve 1.2.7 sr2sieve 1.3.0 proth_sieve 0.42

p=1e12: 18.2 kp/s 25.7 kp/s 54 kp/s
p=1e13: 19.6 kp/s 27.7 kp/s 56 kp/s
p=1e14: 21.0 kp/s 29.7 kp/s 49 kp/s
p=1e15: 22.5 kp/s 31.1 kp/s 12 kp/s
[/CODE]

Xentar 2006-10-20 07:05

Nice work :)
Speed increase from version 1.2.6, 66k p/s to 1.3.0: 73k p/s
on Intel Core 2.


All times are UTC. The time now is 05:55.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.