Sr2sieve on PPC/Linux

[Greenbank]

Just a note to say that I've finally had time to look at proth_sieve on PPC linux. Sheep has given me an account on a suitable machine and I'm trying to fix some strange issues at the moment (almost certainly due to the minor differences in the assembly styles).

The result should be a proth_sieve build for PPC-Linux (to go along with the one I have for PPC-OSX. Big thanks to Rogue for his work on the very fast mulmod and expmod assembly!)

As for the Wii, is Broadway 32-bit or 64-bit?

BTW, My PPC builds of proth_sieve are dreadful for Riesel sieving. They are very good for Sierpinksi (SoB and PSP) but haven't been optimised at all for Riesel (and so they are much slower).

[geoff]

sr2sieve 1.4.19 lifts the sieve limit to 2^63 for the ppc64, it was incorrectly set at 2^52 in previous versions.

[BlisteringSheep]

Originally Posted by geoff

sr2sieve 1.4.19 lifts the sieve limit to 2^63 for the ppc64, it was incorrectly set at 2^52 in previous versions.

Geoff,
Since I'm really not particularly bright, can you tell me if this would impact any work that I've already done? The highest PSP combined sieving that I've done is to 448,300. In Riesel, I've gone to 1,001,600.
Thanks,

[rogue]

Originally Posted by BlisteringSheep

Geoff,
Since I'm really not particularly bright, can you tell me if this would impact any work that I've already done? The highest PSP combined sieving that I've done is to 448,300. In Riesel, I've gone to 1,001,600.
Thanks,

This affects how deeply you can sieve (the value of p) not the k, b, or range of n for which you are sieving. In other words, unlikely. If the software sieved to a limit of 2^52 (which is extremely unlikely), it would probably terminate. I can't speak for certain on that.

BTW, the reason for 2^52 was because that is a limit in the FPU. As the PPC version doesn't using the FPU, the limit is actually 2^63 (one bit less than the number of bits in a register).

[jasong]

Originally Posted by rogue

This affects how deeply you can sieve (the value of p) not the k, b, or range of n for which you are sieving. In other words, unlikely. If the software sieved to a limit of 2^52 (which is extremely unlikely), it would probably terminate. I can't speak for certain on that.

BTW, the reason for 2^52 was because that is a limit in the FPU. As the PPC version doesn't using the FPU, the limit is actually 2^63 (one bit less than the number of bits in a register).

I think there may have been some confusion on the part of BlisteringSheep. The values he gave looked more like n-values instead of sieving values. k and n values define WHAT you're sieving, or trying to find values for. The max 2^52 value determines how high a factor can be tested.

2^52 is 4.5*10^15, while 2^63(which is 2048 times bigger) is 9.22*10^18. To get a grasp of how big these numbers are, 2^52 seconds is a little under 143 million years. 2^63 seconds is about 292 billion years. Not that we're counting seconds with these numbers.

[geoff]

Originally Posted by BlisteringSheep

Since I'm really not particularly bright, can you tell me if this would impact any work that I've already done? The highest PSP combined sieving that I've done is to 448,300. In Riesel, I've gone to 1,001,600.

No impact then. I take it 1,001,600 is in billions, and that is less than 2^50.

I was under the impression that SoB had sieved up to p=2^52 for some range of n, but I suppose they stopped when they combined sieves with PSP.

Originally Posted by rogue

If the software sieved to a limit of 2^52 (which is extremely unlikely), it would probably terminate. I can't speak for certain on that.

In principle it should work right up to p=2^63, but a lot of memory will be required and it probably won't be efficient at that depth. It should still be practical to use up to 2^54 at least. The low factor density makes it a bit difficult to do much testing though.

[BlisteringSheep]

Originally Posted by jasong

I think there may have been some confusion on the part of BlisteringSheep. The values he gave looked more like n-values instead of sieving values. k and n values define WHAT you're sieving, or trying to find values for. The max 2^52 value determines how high a factor can be tested.

Oh, there's no doubt that I'm confused. The values are the endpoints of the highest ranges that I've sieved.

Originally Posted by rogue

No impact then. I take it 1,001,600 is in billions, and that is less than 2^50.

Yes, they are in billions (10^9).

I just wanted to confirm whether or not I needed to re-sieve any of the ranges. It looks like the answer is no.

Thanks,

[Greenbank]

Sheep, back looking at this again after a bit of a busy time...

[Greenbank]

OK, sent you a couple of emails. I've found the coredump problem in the lower ranges and so it's all good to go.

To compare sieving speeds of proth_sieve (for PPC 970 and Linux) I did a small range around p = 270005G:-

Sheep's 2.0GHz PPC 970 G5:-

Sieving 273005640000000 <= p <= 273024210000000, 900 <= n <= 50000000
273005642053939 | 10223*2^30572969+1 (xmod 1867044))
273005643639493 | 24737*2^49346863+1 (xmod 648), duplicate)
p = 273005650000003 @ 571kp/s
p = 273005660000023 @ 572kp/s
...

[BlisteringSheep]

I haven't done thorough testing yet, but on a 2.2 GHz 970FX, on adjacent ranges with SoB.dat, sr2sieve (running on 206000-206036) is reporting "343582 p/sec" while proth_sieve (running on 206036-206072) is reporting "612kp/s". Are the two numbers directly comparable? Is 1 kp equal to 1000 p or 1024 p?


Results with riesel.dat are vastly different. On a 2.5 GHz 970MP, proth_sieve reports 53kp/s while sr2sieve reports ~243000 p/sec on the range 1047590-1047664.

[Greenbank]

Yes. 1 kp= 1000 p/s.

So 612kp/sec could be anything from 612000 p/sec to 612999 p/sec.

If you want it to report p/sec then remove the multiple of 0.001 on line 770 in proth_sieve.c and change the two "kp/s" on lines 2360 and 2361 to "p/s". Then run ./build

And the program is not optimised for Riesel at all. I wanted Sierpinski sieving to be as fast as possible. Sorting it out properly for Riesel is on my big list of stuff to do.