SR2sieve

[Joe O]

PRS52 v0.102b for processor type SSE2

First of all, you are running a very old version of JJsieve. The newer versions were much faster, but SR2sieve is faster than even the last released version.
Head on over to: http://www.geocities.com/g_w_reynolds/sr2sieve/ and pick up the latest version of SR2sieve.
Any references to the url http://www.geocities.com/g_w_reynolds/ should be replaced with the url http://sites.google.com/site/geoffre...olds/programs/.
There are Linux (32bit and 64bit), Windows (32bit and 64bit), and OSX versions available. READ the readme.
There is also now a way to drop SR2sieve in as an almost compatible replacement for JJsieve:

sr2sieve 1.6.10 has a new -j switch that will make it behave in a similar way to JJsieve or proth_sieve, for compatibility with Sobistrator. Checkpoints are written to SoBStatus.dat, ranges are read from nextrange.txt.

It should be possible to start a range with JJsieve and continue it with `sr2sieve -j -s', and vice versa.

I haven't actually tested it with Sobistrator though, so let me know if there are any problems.

Let us know what your speed improvement is after you upgrade.

Since .gz files cannot be attached, the .txt extension was added to two of the following files. Remove the .txt extension before trying to use them. These files are here for convenience only. The latest versions can always be found at http://www.geocities.com/g_w_reynolds/sr2sieve/.

Any references to the url http://www.geocities.com/g_w_reynolds/ should be replaced with the url http://sites.google.com/site/geoffre...olds/programs/.

[vjs]

Joe,

II tried the drop method into a folder currently running jjsieve and come up with the following error.

Line 1: unparsed range in file 'SoBStatus.dat'


also with a core quad should i be using the --sse2 switch or does it autodetect?

[vjs]

O.k. I was pretty sure it was auto detecting...

no dice on the drag and drop solution to getting it started.

Easiest way was to simply get it working, add a new range from where you currently are in Sobistrator to the end point.

Then delete sobstatus.dat.

Restart using the sr2 and the client switch.. seems to be working like a champ.

[Sloth151]

In the sobstatus.dat file jjsieve starts as
pmax=
pmin=

sr2sieve has them in the other order. If you open sobstatus and put the pmax line below the pmin line then things will take off from there.
Found this with the latest sr2sieve using the -s -j command.

[Sloth151]

Someone was looking for speeds changing from jjsieve to sr2sieve

the jjsieve software was jjsievesse2 - not sure which version but the file on the systems are dated about a year ago. The sr2sieve is 1.6.11 using the -s -j arguments

p4 6300 1.86gHz, 1gb ram, xp pro
jjsieve 367kp/s per core
sr2sieve 603kp/s per core 18k dat file
sr2sieve 630kp/s per core 17k dat

p4 4400 2.0gHz, 1gb ram, xp pro
jjsieve 397kp/s per core
sr2sieve 654kp/s per core 18k dat
sr2sieve 676kp/s per core 17k dat

p4 6300 1.86gHz, 2gb ram, vista ultimate 64 bit
sr2sieve 64 bit 865kp/s per core 17k dat file
changing the dat file added about 3% to this machines speed. I dont have the number written down what it was before but I did check it when I updated the dat.

xp boxes are running as a service on boot up. Vista box had it running in a couple of dos windows

[geoff]

In the sobstatus.dat file jjsieve starts as
pmax=
pmin=

sr2sieve has them in the other order. If you open sobstatus and put the pmax line below the pmin line then things will take off from there.
Found this with the latest sr2sieve using the -s -j command.

Thanks, I will try to fix that for the next sr2sieve version. (I actually used Proth sieve 0.42 for Linux for testing, which could be why this problem didn't show up for me).

[Joe O]

Thanks, I will try to fix that for the next sr2sieve version. (I actually used Proth sieve 0.42 for Linux for testing, which could be why this problem didn't show up for me).

Actually Proth_sieve and JJsieve can read them in either order. It was the previous program that required the pmax line first, so of course everyone has continued to have it first.

[vjs]

geoff,

give it a few itterations it seems to correct itself.

[geoff]

Actually Proth_sieve and JJsieve can read them in either order. It was the previous program that required the pmax line first, so of course everyone has continued to have it first.

It is fixed in sr2sieve 1.6.12: pmax is written first but reading can be in either order.