Sr2sieve on PPC/Linux

[BlisteringSheep]

That fixed it. I ran sr5check with all 3 values for EXPERIMENTAL, and they all matched the checked-factors file (the only "oddity" is that in every case they find one factor, "146876293 | 128432*5^814315+1" in a different order. In checked-factors.txt it is the 9995th, while in my factors.txt files it is the 9996th).

I haven't done any speed testing beside the sr5check runs, and the results are:
EXP 0: 96.097 cpu sec
EXP 1: 87.831 cpu sec
EXP 2: 87.896 cpu sec

[geoff]

Originally Posted by BlisteringSheep

That fixed it. I ran sr5check with all 3 values for EXPERIMENTAL, and they all matched the checked-factors file (the only "oddity" is that in every case they find one factor, "146876293 | 128432*5^814315+1" in a different order. In checked-factors.txt it is the 9995th, while in my factors.txt files it is the 9996th).

You will find that 146876293 divides two different terms. That is normal, if a factor divides two terms then the order in which the terms are reported may vary from version to version, or may vary depending on the order the terms were listed in the input file.

It would also be a good idea to do some tests on factors larger than 2^32. (But not too much larger, you need plenty of factors for comparison). You could use the sr5check.txt as input but use a range starting at 5e9, and compare the results to the non-experimantal version of sr5sieve.

If you have GMP installed then building srtest will do some tests on numbers up to the 2^63 limit.

[BlisteringSheep]

Originally Posted by geoff

If you have GMP installed then building srtest will do some tests on numbers up to the 2^63 limit.

I had forgotten that I had gmp installed. I'm running srtest now on it, and also doing some timing tests on another (faster) machine.

Do you have some recommendations for input values to srtest? It completed the default with 0 errors.

Also, the new timing code seems to be working well. It now has enough differentiation to unequivocably choose between the different methods (it uses the /4 variant of each). With older versions, it couldn't differentiate at all between the giant steps methods on faster machines (> 2 GHz).

[geoff]

Originally Posted by BlisteringSheep

Do you have some recommendations for input values to srtest? It completed the default with 0 errors.

If you do a few million iterations that should be enough. On average about half of the iterations will have a modulus between 2^62 and 2^63.

I have to sign off now, I look forward to the timing data tomorrow :-)

[BlisteringSheep]

Originally Posted by geoff

I have to sign off now, I look forward to the timing data tomorrow :-)

Slacker.

I ran sr5check with -p 5000000000 -P 5200000000 on all 3 variants which found 437 factors. All factors matched. Execution times on a 2.0 GHz PowerMac are:
EXP 0: 161.500 cpu sec
EXP 1: 147.473 cpu sec
EXP 2: 147.434 cpu sec


Running with "real" data on a 2.2 GHz 970FX, using the RPS 5th drive Riesel.dat (14 small k's) with p values in the 20650000000000 range yields rates of:
sr2sieve-1.5.6 with vec mods: 792 kp/s
sr2sieve-1.5.10 with EXP 1: 862 kp/s
sr2sieve-1.5.10 with EXP 2: 862 kp/s

I'll take it!

[BlisteringSheep]

More sr5check timings with 1.5.10 on a 2.5 GHz 970MP.

-p 100e6 -P 150e6
EXP 0: 76.546 cpu sec
EXP 1: 69.857 cpu sec
EXP 2: 69.813 cpu sec

-p 5000000000 -P 5100000000
EXP 0: 128.634
EXP 1: 117.334
EXP 2: 117.226

[Cruelty]

Could you send me the test file your are working on (5-th drive)? I'd like to check how does PPC version compare to x86-64 on C2D
You will find my e-mail here.

[geoff]

Originally Posted by BlisteringSheep

Running with "real" data on a 2.2 GHz 970FX, using the RPS 5th drive Riesel.dat (14 small k's) with p values in the 20650000000000 range yields rates of:
sr2sieve-1.5.6 with vec mods: 792 kp/s
sr2sieve-1.5.10 with EXP 1: 862 kp/s
sr2sieve-1.5.10 with EXP 2: 862 kp/s

That is a good result. Since there is no noticable difference between the two new variants, I'll make the EXPERIMENTAL=1 code the default in the next version.

There may still be some gains to be had from refining the assembly, but it seems clear that the basic ideas are faster, although I don't know how much is due to pre-computing b*pMagic and how much from interleaving the mulmods.

[BlisteringSheep]

geoff, are there any other specific tests you'd like me to run? I'm happy to run anything that is useful for you.

[geoff]

Originally Posted by BlisteringSheep

geoff, are there any other specific tests you'd like me to run? I'm happy to run anything that is useful for you.

It would be interesting to see the results from running with the -vv switch on a large input like riesel.dat or SoB.dat, to get an idea of the difference in speed between doing two or four mulmods in parallel (gen/2 and gen/4 methods).

Thanks for all your help, I'll let you know if I think of anything else to try out.

[BlisteringSheep]

Originally Posted by geoff

It would be interesting to see the results from running with the -vv switch on a large input like riesel.dat or SoB.dat, to get an idea of the difference in speed between doing two or four mulmods in parallel (gen/2 and gen/4 methods).

Thanks for all your help, I'll let you know if I think of anything else to try out.

Attached is a full capture of running both gcc-4.1.1 and gcc-4.1.2 versions with all EXPERIMENTAL variants on both riesel.dat and SoB.dat. These were executed sequentially on one core of 2.5 GHz 970MP. They were run with "time" to also capture actual wall-clock execution times.