Sr2sieve on PPC/Linux

BlisteringSheep · 2006-11-09, 18:10

Machine is a IBM JS21 blade with two dual-core 970MP cpus running at 2.5GHz. O/S is RedHat Enterprise Linux AS release 4 with custom 2.6.9-39 kernel. Compiled with gcc 3.4.3 (RedHat 3.4.3-22.1). Using sr2sieve-1.2.2 compiled with "-O3 -ffast-math -mtune=G5 -mtune=970 -m64 -fomit-frame-pointer -maltivec -mabi=altivec".

sr2sieve started: 991 <= n <= 49999997, 273000000000000 <= p <= 273025000000000
p=273000018600083, 155627 p/sec, 0 factors, 0.07% done, ETA 09 Nov 11:12
p=273000037280177, 155666 p/sec, 0 factors, 0.15% done, ETA 09 Nov 11:06
p=273000055960087, 155512 p/sec, 0 factors, 0.22% done, ETA 09 Nov 11:04
p=273000074640019, 155679 p/sec, 0 factors, 0.30% done, ETA 09 Nov 11:03
p=273000093320117, 155758 p/sec, 0 factors, 0.37% done, ETA 09 Nov 11:03
[.....]
p=273021433320121, 155665 p/sec, 8 factors, 85.73% done, ETA 09 Nov 11:01
p=273021452040133, 155877 p/sec, 8 factors, 85.81% done, ETA 09 Nov 11:01
p=273021470760167, 156099 p/sec, 8 factors, 85.88% done, ETA 09 Nov 11:01
p=273021489440093, 155466 p/sec, 8 factors, 85.96% done, ETA 09 Nov 11:01

Other p-ranges are producing similar p/sec values.

This is not using the assembly code routines in expmod-ppc64.s or mulmod-ppc64.s As-is, they will not compile under Linux. If I modify them (by changing the rN notations to N), they compile and link cleanly, but do not produce correct results.

BlisteringSheep · 2006-11-09, 18:16

Quote:

Originally Posted by BlisteringSheep

p=273021489440093, 155466 p/sec, 8 factors, 85.96% done, ETA 09 Nov 11:01

Note that this is for one core. All 4 cores are producing at approximately the same rate. I did run a test where only one core was utilized and got approximately the same rate (as expected).

I also forgot to mention that I am using SoB.dat:
file size: 14425197
md5sum: e80397fd1764bb5d135a00f5f899fdcc

rogue · 2006-11-09, 19:14

Quote:

Originally Posted by BlisteringSheep

This is not using the assembly code routines in expmod-ppc64.s or mulmod-ppc64.s As-is, they will not compile under Linux. If I modify them (by changing the rN notations to N), they compile and link cleanly, but do not produce correct results.

That's very odd. I wrote the ppc64 code and I know it works in OS X. Is there any means you have for debugging? You should be able to write a small program that calls the expmod/mulmod and check the results.

Could you tell me where you d/l'd source for sr2sieve and the SoB.dat file? I can do some testing over the next couple of days and find out what's going on. Of course, that assumes I can reproduce the error in OS X. PM me with your e-mail and I'll get back to you with my findings.

axn · 2006-11-09, 19:16

I see that you are using ver 1.2.2? Geoff has since put in some more improvements in there - ver 1.3.x would be the latest. Can you contact geoff to get the source for that version? Also, if you can pass on the build errors to geoff, maybe he'll have a look at it.

To be fair srsieve (and its siblings) sieve better with larger number of k's and smaller n ranges compared to JJSieve, proth_sieve etc. So you can't really expect it to match that kind of speeds for SoB/PSP. But still, with the newer version and assembly opts working, it should give you a nice speed boost.

BlisteringSheep · 2006-11-09, 19:28

Quote:

Originally Posted by axn1

I see that you are using ver 1.2.2? Geoff has since put in some more improvements in there - ver 1.3.x would be the latest. Can you contact geoff to get the source for that version? Also, if you can pass on the build errors to geoff, maybe he'll have a look at it.

To be fair srsieve (and its siblings) sieve better with larger number of k's and smaller n ranges compared to JJSieve, proth_sieve etc. So you can't really expect it to match that kind of speeds for SoB/PSP. But still, with the newer version and assembly opts working, it should give you a nice speed boost.

Yes, I'm using 1.2.2. I just noticed that 1.3.x was around. The build errors were just because gcc on Linux doesn't want the registers to be named r1, r2, etc., it wants them as 1, 2. I will get in touch with Geoff.

BlisteringSheep · 2006-11-09, 19:54

Quote:

Originally Posted by axn1

To be fair srsieve (and its siblings) sieve better with larger number of k's and smaller n ranges compared to JJSieve, proth_sieve etc. So you can't really expect it to match that kind of speeds for SoB/PSP. But still, with the newer version and assembly opts working, it should give you a nice speed boost.

Does anyone have something that I can run on a PPC 970FX or 970MP under Linux that will perform better for SoB/PSP? I looked/asked around on the Ars forums and this was the best that I got. I've got about 14 dual 970FXs and 42 dual dual-core 970MPs I'd like to use for PSP (sneaker-net only).

http://members.arstechnica.com/x/ego...p-emoticon.gif

axn · 2006-11-09, 20:02

Quote:

Originally Posted by BlisteringSheep

Does anyone have something that I can run on a PPC 970FX or 970MP under Linux that will perform better for SoB/PSP? I looked/asked around on the Ars forums and this was the best that I got. I've got about 14 dual 970FXs and 42 dual dual-core 970MPs I'd like to use for PSP (sneaker-net only).

http://members.arstechnica.com/x/ego...p-emoticon.gif

Not AFAIK

I was just setting your expectation, is all.

Oh, and btw, : alex : will give you

icon

rogue · 2006-11-09, 23:08

Quote:

Originally Posted by BlisteringSheep

Does anyone have something that I can run on a PPC 970FX or 970MP under Linux that will perform better for SoB/PSP? I looked/asked around on the Ars forums and this was the best that I got. I've got about 14 dual 970FXs and 42 dual dual-core 970MPs I'd like to use for PSP (sneaker-net only).

http://members.arstechnica.com/x/ego...p-emoticon.gif

There should be a PPC version of proth_sieve. I worked on it with Greenbank.

BTW, if you are interested, I have a program that can PRP test k*b^n+/-1 numbers on PPC. It's not bug free and the residues are not compatible with LLR, but it has a decent change of finding a prime.

Otherwise, if you are interested in finding 200,000 digit primes on PPC, go over to the pies_project group in Yahoo. I found 6 primes of that size on PPC.

BlisteringSheep · 2006-11-10, 02:54

Quote:

Originally Posted by rogue

There should be a PPC version of proth_sieve. I worked on it with Greenbank.

Greenbank gave me proth_sieve_G5, which I'm running on OS/X on my PowerMac. He didn't have a Linux client for me, though.

geoff · 2006-11-13, 02:42

Quote:

Originally Posted by BlisteringSheep

Yes, I'm using 1.2.2. I just noticed that 1.3.x was around. The build errors were just because gcc on Linux doesn't want the registers to be named r1, r2, etc., it wants them as 1, 2. I will get in touch with Geoff.

The sr2sieve 1.3.1 binaries were compiled just by changing these settings in sr5sieve.h:

#define BASE 5
#define REPORT_DUPLICATES 0

to:

#define BASE 2
#define REPORT_DUPLICATES 1

and then renaming the resulting executable for sr5sieve to sr2sieve.

Sorry I don't know how the register names or calling conventions work for PPC/Linux, but if you do get it to compile and can let me know what changes were needed that would be great.

The 1.3.1 or later version should be quite a bit faster than earlier versions with SoB.dat, but they depend heavily on powmod, so I expect rogue's assembler would make a big difference.

BlisteringSheep · 2006-11-13, 18:00

I've gotten 1.3.3, changed BASE to 2 and REPORT_DUPLICATES to 1. In the assembly files, I had to change the comment style from "//" to "/* */" and strip the leading 'r' from the register names.

It compiled cleanly and is running cleanly. I'm getting ready to start it on a set of data that I've processed before to check correctness and speed.

2006-11-09, 18:10	#1
BlisteringSheep Oct 2006 On a Suzuki Boulevard C90 2·3·41 Posts	sr2sieve Machine is a IBM JS21 blade with two dual-core 970MP cpus running at 2.5GHz. O/S is RedHat Enterprise Linux AS release 4 with custom 2.6.9-39 kernel. Compiled with gcc 3.4.3 (RedHat 3.4.3-22.1). Using sr2sieve-1.2.2 compiled with "-O3 -ffast-math -mtune=G5 -mtune=970 -m64 -fomit-frame-pointer -maltivec -mabi=altivec". sr2sieve started: 991 <= n <= 49999997, 273000000000000 <= p <= 273025000000000 p=273000018600083, 155627 p/sec, 0 factors, 0.07% done, ETA 09 Nov 11:12 p=273000037280177, 155666 p/sec, 0 factors, 0.15% done, ETA 09 Nov 11:06 p=273000055960087, 155512 p/sec, 0 factors, 0.22% done, ETA 09 Nov 11:04 p=273000074640019, 155679 p/sec, 0 factors, 0.30% done, ETA 09 Nov 11:03 p=273000093320117, 155758 p/sec, 0 factors, 0.37% done, ETA 09 Nov 11:03 [.....] p=273021433320121, 155665 p/sec, 8 factors, 85.73% done, ETA 09 Nov 11:01 p=273021452040133, 155877 p/sec, 8 factors, 85.81% done, ETA 09 Nov 11:01 p=273021470760167, 156099 p/sec, 8 factors, 85.88% done, ETA 09 Nov 11:01 p=273021489440093, 155466 p/sec, 8 factors, 85.96% done, ETA 09 Nov 11:01 Other p-ranges are producing similar p/sec values. This is not using the assembly code routines in expmod-ppc64.s or mulmod-ppc64.s As-is, they will not compile under Linux. If I modify them (by changing the rN notations to N), they compile and link cleanly, but do not produce correct results.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
srsieve/sr2sieve enhancements	rogue	Software	300	2021-03-18 20:31
32-bit of sr1sieve and sr2sieve for Win	pepi37	Software	5	2013-08-09 22:31
sr2sieve question	SaneMur	Information & Answers	2	2011-08-21 22:04
sr2sieve client	mgpower0	Prime Sierpinski Project	54	2008-07-15 16:50
How to use sr2sieve	nuggetprime	Riesel Prime Search	40	2007-12-03 06:01

2006-11-09, 19:16	#4
axn Jun 2003 31×163 Posts	I see that you are using ver 1.2.2? Geoff has since put in some more improvements in there - ver 1.3.x would be the latest. Can you contact geoff to get the source for that version? Also, if you can pass on the build errors to geoff, maybe he'll have a look at it. To be fair srsieve (and its siblings) sieve better with larger number of k's and smaller n ranges compared to JJSieve, proth_sieve etc. So you can't really expect it to match that kind of speeds for SoB/PSP. But still, with the newer version and assembly opts working, it should give you a nice speed boost.

2006-11-13, 18:00	#11
BlisteringSheep Oct 2006 On a Suzuki Boulevard C90 11110110₂ Posts	I've gotten 1.3.3, changed BASE to 2 and REPORT_DUPLICATES to 1. In the assembly files, I had to change the comment style from "//" to "/* */" and strip the leading 'r' from the register names. It compiled cleanly and is running cleanly. I'm getting ready to start it on a set of data that I've processed before to check correctness and speed.