Distributed sieving discussions

[rogue]

Originally Posted by geoff

The limit is actually 2^62 for i386 machines and 2^52 for others. 4e12 was the limit of the prime sieve, beyond that some composites would be sieved, but that only affected the efficiency not the results. In the current version the prime sieve will generate all primes up to 2^62, although it takes a lot of memory (> 1GB).

I've considered a means to reduce the memory footprint for the sieve. It involves storing the prime differences for the prime array instead of the primes themselves. IIRC correctly, it should cut the memory requirement for the sieve in half. It could be cut further if one assumes that the upper 32 bits of each composite in the composite array are always the same, but that would require a little more effort to manage.

[michaf]

Originally Posted by axn1

Are you looking for expected factors per G or actual factors per G ?

Actual factors would do, but some interpolation on the expected would be nice :)

[michaf]

axn1,

Do you want to remove all the factors (and the new prime) from the sr5data file, or would you like me to do it, and then upload.
If it's me, it would be handy if I get all factor files mailed too.
If it's you, please mail me the sr5data file :>

Oh, and one other little thing, who sieved from 0-25e9?

And yet another one; I can now only start my computer in safe mode, which is rather annoying, so I won't be crunching numbers until I get either a new PC, or get this darned thing running smoothly again :>

[axn]

Originally Posted by michaf

Do you want to remove all the factors (and the new prime) from the sr5data file, or would you like me to do it, and then upload.
If it's me, it would be handy if I get all factor files mailed too.
If it's you, please mail me the sr5data file :>

I have an updated dat file with all the factors + the new prime, removed. Unfortunately, there is no notable speed increase, so no need to switch (yet).

Originally Posted by michaf

Oh, and one other little thing, who sieved from 0-25e9?

That'd be me No point in publishing statistics for that range since there are just too many factors.

Originally Posted by michaf

And yet another one; I can now only start my computer in safe mode, which is rather annoying, so I won't be crunching numbers until I get either a new PC, or get this darned thing running smoothly again :>

Wishing your computer a speedy recovery

[geoff]

Originally Posted by rogue

I've considered a means to reduce the memory footprint for the sieve. It involves storing the prime differences for the prime array instead of the primes themselves. IIRC correctly, it should cut the memory requirement for the sieve in half. It could be cut further if one assumes that the upper 32 bits of each composite in the composite array are always the same, but that would require a little more effort to manage.

I think it will be quite a while before memory becomes a problem. As the memory used by the prime sieve increases, the bitmap memory will be reduced by finding primes.

[geoff]

Originally Posted by axn1

I have an updated dat file with all the factors + the new prime, removed. Unfortunately, there is no notable speed increase, so no need to switch (yet).

Finding a prime for a light weight sequence will in general have less effect on sieving speed than finding one for a heavy sequence.

If it is not too much trouble, could the page with the current data file also contain a list of the primes found since the file was updated? This would make it easier for anyone wanting to delete the primes from their own copy of the file (using sr5sieve -d <K> to delete K*5^n+/-1).

edit: Just as good might be to announce updated data files in the thread where the primes are announced, then the new primes are the ones posted since the last announcement.

[michaf]

I'll update the dat-file, _and_ report the found primes on there, anyone who wants to do it for themselves is able then, and anyone who is too lazy can download the new dat-file ;)

Originally Posted by geoff

Finding a prime for a light weight sequence will in general have less effect on sieving speed than finding one for a heavy sequence.

If it is not too much trouble, could the page with the current data file also contain a list of the primes found since the file was updated? This would make it easier for anyone wanting to delete the primes from their own copy of the file (using sr5sieve -d <K> to delete K*5^n+/-1).

edit: Just as good might be to announce updated data files in the thread where the primes are announced, then the new primes are the ones posted since the last announcement.

[michaf]

I just tried sieve some candidates with P1 factoring with Prime95, and I have absolutely NO clue on how I get prime95 to handle composite exponents :>

srfile has the nice option to output P1 worktodo.ini for prime95, but it all just gets skipped because of the compositeness of the exponents...

help :)

edit: a download of a newer version of prime95 worked a bit... only srfile doesn't output a working .ini file, if I change the last number to 8 or more, it works...

[michaf]

Is it worth sieving out some candidates by P-1 factoring?
(It sure isn't now, the quickest one is about 7 minutes on my PC, while the actual PRP test takes only 3 minutes)

When we get to higher grounds, say 200k, it gets more efficient, about 10% chance of finding a factor, and a normal prp test takes about 60 minutes.

Then again, if the sieving effort has gone beyond 300T (that is 300e12) or something like that, P1 isn't going to find too many factors anymore. (The three I found are max 167T)

One other thing: I found this one with P1:
278974*5^200001-1 has a factor: 28175678171
at 28e9, how could it have been missed by the current distr. sieving?
edit: DUH :> that's because the separate factor files aren't cleared out of my dat-file of course...

[geoff]

Originally Posted by michaf

Is it worth sieving out some candidates by P-1 factoring?

It is not efficient to do P-1 tests yet, but they can be used as a check that the sieve is not missing any factors, or just for the fun of finding some larger factors.

Can the administrators handle P-1 factors being reported?

As far as the worktodo.ini entries output by srfile, I haven't done much testing with this. If there are changes needed let me know.

[michaf]

Originally Posted by geoff

Can the administrators handle P-1 factors being reported?

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