Distributed sieving discussions

[geoff]

Originally Posted by michaf

I could always mold the factors into other shapes for srfile to recognise

The problem is that srfile can't deal with factors larger than about 2^62. I could fix this by linking with the GMP library, but I wouldn't be able to cross-compile for Windows if I do that (at least, I haven't figured out how to, yet).

As a stopgap, in version 0.3.8 'srfile --known-factors' will accept a Prime95 results.txt file and remove the factors found therein from the sieve, but it won't perform a check that these factors are genuine.

[michaf]

Originally Posted by geoff

As a stopgap, in version 0.3.8 'srfile --known-factors' will accept a Prime95 results.txt file and remove the factors found therein from the sieve, but it won't perform a check that these factors are genuine.

I think that should suffice; there are not many people P-1-ing,
and there will be only few factors found.
(and on my <pick your favorite 4-letter-word>-system, running in safe mode, p-95 crashes it every now and then running P-1)

[konrad127123]

Originally Posted by geoff

The problem is that srfile can't deal with factors larger than about 2^62. I could fix this by linking with the GMP library, but I wouldn't be able to cross-compile for Windows if I do that (at least, I haven't figured out how to, yet).

Could you make it so that this worked under Linux and #if out the relevant bits when compiling under Windows? This would at least solve part of the problem. I've done a little P-1 factoring with gmp-ecm which shows factors as lines of the form:

Probable prime cofactor (304004*5^596-1)/5908875585165836527 has 404 digits

or

Composite cofactor (318278*5^808-1)/4399968245303 has 558 digits

so support for such input would be useful :)

[geoff]

Originally Posted by konrad127123

I've done a little P-1 factoring with gmp-ecm which shows factors as lines of the form:

In version 0.3.11 `srfile --known-factors FILE' will process factors in gmp-ecm output FILE. The factors are checked if they are smaller than 2^62, otherwise they are not checked (with --verbose it will print which ones were checked and which ones not).

[geoff]

sr5sieve version 1.1.0 is a tiny bit faster than 1.0.0, about 2% on my P3. There is also a 64-bit Linux binary which may be faster than the 32-bit version.

There are no bug fixes, so no need to upgrade immediately.

[geoff]

sr5sieve 1.1.2 should be about 5% faster than 1.1.1, due simply to optimising the loop that initialises the hashtable.

[michaf]

Originally Posted by geoff

sr5sieve 1.1.2 should be about 5% faster than 1.1.1, due simply to optimising the loop that initialises the hashtable.

Always nice :)

Do you know if it's possible to let it use two processors?
Or is it just simpler to run two srsieves?

BTW, Athlon 62 X2 3800+ Normally running at 2.0GHz, OC'd without any troubles at all to 2.208GHz... that makes it run at about 2 * 27000 p's per second!

*edit* Version 1.1.2 makes it run at 2 * 28200 p's per second

[geoff]

Originally Posted by michaf

Do you know if it's possible to let it use two processors?
Or is it just simpler to run two srsieves?

If you run multiple sr5sieve processes you currently need to start each one in a seperate directory, because the checkpoint files use the same name. I will change this in the next version so that each process can be made to use different file names.

It would be possible (but probably not a simple matter to program) to launch one worker thread for each CPU and let the parent thread just handle the record-keeping. This probably wouldn't be any faster than running a seperate sr5sieve process on each CPU, but it would use less memory. I don't plan to do this in the near future.

[michaf]

Running two programs in two dir's is perfectly fine for me.
I was just wondering out lod wether it would be easy enough...
Don't waste too much resources on it, unless you have waaaay too much time on your hands :)

[geoff]

Originally Posted by michaf

Running two programs in two dir's is perfectly fine for me.

I will leave it as is then, unless someone else really wants to be able to run everything in one directory.

Running each process from a seperate directory just means that you need a copy of (or a link to) sr5data.txt in each directory, probably not problem for most.

[geoff]

sr5sieve 1.1.3 is about 10% faster than 1.1.2. This resulted from using 32 bits instead of 64 bits for some local variables in the modular inverse function (so probably only 32-bit machines will see the benefit).