Sr2sieve on PPC/Linux - Page 2

BlisteringSheep · 2006-11-13, 18:29

Never mind. It wasn't actually using the ASM code. To get it to do that, I have to add -D__ppc64__ and change the entry points in the .s files to remove the leading _. Once I do that it segfaults just like 1.2.2.

Without the ASM code, it is running slower than 1.2.2 for a sr2work.txt of 27300, 273025. It's running around 148000 p/sec vs. 155000 p/sec.

axn · 2006-11-13, 19:47

Quote:

Originally Posted by BlisteringSheep

Without the ASM code, it is running slower than 1.2.2 for a sr2work.txt of 27300, 273025. It's running around 148000 p/sec vs. 155000 p/sec.

Was the starting value 27300 or 273000? The second one should be about 7% faster than the first one.

BlisteringSheep · 2006-11-14, 02:10

Sorry for the typo; it was 273000. I set one core to work on that range (273000-273025) since I've already done it once & can compare the factors273000.txt files. I won't have any way to check the results until tomorrow, but when I last looked at it today it was holding steady in the 148000 p/sec range.

And just for clarity, I did start the new client with the "-s" flag and with SoB.dat present (the same SoB.dat file that I've used for all runs).

BlisteringSheep · 2006-11-15, 20:37

The run with the new 1.3.3 client is complete. The CPU was one core of a 2.5 GHz 970MP. Rate was 149457 p/sec. Used SoB.dat for the range [273000, 273025]. The 1.3.3 client found only:
273007156439257 | 225931*2^40191656+1

For comparison, the 1.2.2 client ran at approximately 155500 p/sec, and found the following:
273005642053939 | 10223*2^30572969+1
273007156439257 | 225931*2^40191656+1
273012258141967 | 258317*2^4553159+1
273013881908563 | 90527*2^22497551+1
273018111521137 | 33661*2^40903200+1
273019346461271 | 24737*2^26923927+1
273020049854507 | 225931*2^25456352+1
273020751694081 | 152267*2^11683419+1
273024206407651 | 10223*2^23639849+1

As a reminder, neither of these are using the assembly code for expmod-ppc64.s or mulmod-ppc64.s. The O/S is RedHat Linux AS4, compiler is gcc3.4.3.

geoff · 2006-11-18, 21:57

Quote:

Originally Posted by BlisteringSheep

The run with the new 1.3.3 client is complete. The CPU was one core of a 2.5 GHz 970MP. Rate was 149457 p/sec. Used SoB.dat for the range [273000, 273025]. The 1.3.3 client found only:
273007156439257 | 225931*2^40191656+1

That is a worry :-(. It is also strange that it is slower than 1.2.2, I would have expected it to be at least one third faster. I will check this range on my system tonight and see if I can figure out what is happening.

Thanks for taking the time to compile and test this.

geoff · 2006-11-22, 02:26

[If a moderator wants to split the non-benchmark related part of this thread into a new thread, it could be called something like 'Sr2sieve on PPC/Linux'..]

Quote:

The run with the new 1.3.3 client is complete. The CPU was one core of a 2.5 GHz 970MP. Rate was 149457 p/sec. Used SoB.dat for the range [273000, 273025]. The 1.3.3 client found only:
273007156439257 | 225931*2^40191656+1

For comparison, the 1.2.2 client ran at approximately 155500 p/sec, and found the following:
273005642053939 | 10223*2^30572969+1
273007156439257 | 225931*2^40191656+1
273012258141967 | 258317*2^4553159+1
273013881908563 | 90527*2^22497551+1
273018111521137 | 33661*2^40903200+1
273019346461271 | 24737*2^26923927+1
273020049854507 | 225931*2^25456352+1
273020751694081 | 152267*2^11683419+1
273024206407651 | 10223*2^23639849+1

I have checked the x86 versions, 1.2.2, 1.2.7, 1.3.3 and 1.3.4 find all 9 factors.

When compiled with DEBUG=yes in Makefile, version 1.4.0 will print some data to check the contents of the Legendre symbol tables. The data for sequence k*b^n+c depends only on k,b,c and the parity of n, so it should not change between different versions of SoB.dat. Can you compile this version and check that your data matches mine below?

Code:

10223*2^n+1: length=40892, popcount=20444, checksum=415534282
19249*2^n+1: length=38498, popcount=19248, checksum=367877264
21181*2^n+1: length=42362, popcount=20764, checksum=436996010
22699*2^n+1: length=22699, popcount=11349, checksum=127778346
24737*2^n+1: length=98948, popcount=47712, checksum=2351574312
33661*2^n+1: length=67322, popcount=32800, checksum=1099217216
55459*2^n+1: length=55459, popcount=26820, checksum=740696994
67607*2^n+1: length=270428, popcount=135212, checksum=1062054378
79309*2^n+1: length=158618, popcount=79308, checksum=1972783320
79817*2^n+1: length=319268, popcount=159632, checksum=3949033080
90527*2^n+1: length=362108, popcount=181052, checksum=2654493066
152267*2^n+1: length=609068, popcount=304532, checksum=2383261450
156511*2^n+1: length=156511, popcount=78255, checksum=1828877729
168451*2^n+1: length=168451, popcount=84225, checksum=2778500758
222113*2^n+1: length=888452, popcount=444224, checksum=3841764096
222361*2^n+1: length=444722, popcount=222360, checksum=2105159460
225931*2^n+1: length=225931, popcount=112965, checksum=4136589190
237019*2^n+1: length=237019, popcount=118509, checksum=1126535552
258317*2^n+1: length=1033268, popcount=516632, checksum=271148168
265711*2^n+1: length=265711, popcount=132855, checksum=470581841

Also in version 1.4.0 there is a small test program 'srtest' that will compute b^n (mod p) for a million random values of p and check the results with GMP. This should reveal any problems in the mulmod()/powmod() functions. (I found some errors in the i386 assembler code using this program, which are fixed in version 1.4.0, but the non-assembler versions checked out fine).

BlisteringSheep · 2006-11-24, 09:11

Here's the output after a compile with ARCH=ppc64 DEBUG=yes using SoB.dat. I get the same output with either 1.4.0 or 1.4.1

Code:

egoforth ~/sieve/sr5sieve-1.4.0 $./sr5sieve -s
sr2sieve 1.4.0 -- A sieve for the Sierpinski/Riesel Base 2 projects.
Read 2473631 terms for 19 sequences from dat format file `SoB.dat'.
10223*2^n+1: length=40892, popcount=10294, checksum=208974936
19249*2^n+1: length=38498, popcount=9638, checksum=184576980
21181*2^n+1: length=42362, popcount=10366, checksum=217615608
22699*2^n+1: length=22699, popcount=5684, checksum=64183523
24737*2^n+1: length=98948, popcount=23851, checksum=1174762933
33661*2^n+1: length=67322, popcount=16419, checksum=549676506
55459*2^n+1: length=55459, popcount=13399, checksum=369474050
67607*2^n+1: length=270428, popcount=67577, checksum=512159987
79309*2^n+1: length=158618, popcount=39586, checksum=3132342957
79817*2^n+1: length=319268, popcount=79951, checksum=4133160645
90527*2^n+1: length=362108, popcount=90493, checksum=3470571527
152267*2^n+1: length=609068, popcount=152467, checksum=3376005395
156511*2^n+1: length=156511, popcount=39092, checksum=3050529412
168451*2^n+1: length=168451, popcount=42016, checksum=3530946516
222113*2^n+1: length=888452, popcount=222064, checksum=4022272985
225931*2^n+1: length=225931, popcount=56698, checksum=2099575468
237019*2^n+1: length=237019, popcount=59267, checksum=2708015900
258317*2^n+1: length=1033268, popcount=258037, checksum=4292259763
265711*2^n+1: length=265711, popcount=66509, checksum=229990624
Built (-ckb^n/p) tables for 11 even, 8 odd, 0 mixed parity sequences.
Used 617 Kb for Legendre lookup tables, 3119 Kb for subsequence bitmaps.
Split 19 base 2 sequences into 184 base 2^360 subsequences.
Using hashtable of 8192 elements (maximum density 0.43).

sr2sieve started: 991 <= n <= 49999997, 273000000000000 <= p <= 273025000000000

Machine is a Apple PowerMac dual 2.0 G5 (970), O/S is gentoo, compiler is gcc 3.4.6. Changes:

sr5sieve.h
- #define BASE 2
- #define REPORT_DUPLICATES 1
expmod-ppc64.s
- _expmod to .expmod
mulmod-ppc64.s
- _mulmod to .mulmod
Makefile
- remove -mdynamic-no-pic
- add -mregnames
- add -D__ppc64__
- add -x assembler-with-cpp to ASFLAGS

rogue · 2006-11-24, 14:16

Quote:

Originally Posted by BlisteringSheep

Machine is a Apple PowerMac dual 2.0 G5 (970), O/S is gentoo, compiler is gcc 3.4.6. Changes:

sr5sieve.h
- #define BASE 2
- #define REPORT_DUPLICATES 1
expmod-ppc64.s
- _expmod to .expmod
mulmod-ppc64.s
- _mulmod to .mulmod
Makefile
- remove -mdynamic-no-pic
- add -mregnames
- add -D__ppc64__
- add -x assembler-with-cpp to ASFLAGS

Does this mean that the asm segfault issue has been resolved or do I still need to help you with it?

BlisteringSheep · 2006-11-24, 15:33

Quote:

Originally Posted by rogue

Does this mean that the asm segfault issue has been resolved or do I still need to help you with it?

It is still segfaulting. Those changes to the asm files and the -x switch were just to get it to compile and link. So if you've got time to work on it, I've finally gotten this PowerMac up.

geoff · 2006-11-25, 23:04

Quote:

Originally Posted by BlisteringSheep

Here's the output after a compile with ARCH=ppc64 DEBUG=yes using SoB.dat. I get the same output with either 1.4.0 or 1.4.1

Code:

egoforth ~/sieve/sr5sieve-1.4.0 $./sr5sieve -s
sr2sieve 1.4.0 -- A sieve for the Sierpinski/Riesel Base 2 projects.
Read 2473631 terms for 19 sequences from dat format file `SoB.dat'.
10223*2^n+1: length=40892, popcount=10294, checksum=208974936

This is a big problem, all the bitmaps are corrupt. I will send you a program to test the bitmap code tomorrow if I can't find the bug tonight.

rogue · 2006-11-27, 01:49

Quote:

Originally Posted by BlisteringSheep

It is still segfaulting. Those changes to the asm files and the -x switch were just to get it to compile and link. So if you've got time to work on it, I've finally gotten this PowerMac up.

I have isolated and resolved the issue. Apparently r2 must be saved and restored in this environment. Under OS X, r2 can be used without such a precaution. I've send the updated code to geoff.

2006-11-14, 02:10	#14
BlisteringSheep Oct 2006 On a Suzuki Boulevard C90 366₈ Posts	Sorry for the typo; it was 273000. I set one core to work on that range (273000-273025) since I've already done it once & can compare the factors273000.txt files. I won't have any way to check the results until tomorrow, but when I last looked at it today it was holding steady in the 148000 p/sec range. And just for clarity, I did start the new client with the "-s" flag and with SoB.dat present (the same SoB.dat file that I've used for all runs). Last fiddled with by BlisteringSheep on 2006-11-14 at 02:12

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-13, 18:29	#12
BlisteringSheep Oct 2006 On a Suzuki Boulevard C90 366₈ Posts	Never mind. It wasn't actually using the ASM code. To get it to do that, I have to add -D__ppc64__ and change the entry points in the .s files to remove the leading _. Once I do that it segfaults just like 1.2.2. Without the ASM code, it is running slower than 1.2.2 for a sr2work.txt of 27300, 273025. It's running around 148000 p/sec vs. 155000 p/sec.

2006-11-15, 20:37	#15
BlisteringSheep Oct 2006 On a Suzuki Boulevard C90 2·3·41 Posts	The run with the new 1.3.3 client is complete. The CPU was one core of a 2.5 GHz 970MP. Rate was 149457 p/sec. Used SoB.dat for the range [273000, 273025]. The 1.3.3 client found only: 273007156439257 \| 2259312^40191656+1 For comparison, the 1.2.2 client ran at approximately 155500 p/sec, and found the following: 273005642053939 \| 102232^30572969+1 273007156439257 \| 2259312^40191656+1 273012258141967 \| 2583172^4553159+1 273013881908563 \| 905272^22497551+1 273018111521137 \| 336612^40903200+1 273019346461271 \| 247372^26923927+1 273020049854507 \| 2259312^25456352+1 273020751694081 \| 1522672^11683419+1 273024206407651 \| 102232^23639849+1 As a reminder, neither of these are using the assembly code for expmod-ppc64.s or mulmod-ppc64.s. The O/S is RedHat Linux AS4, compiler is gcc3.4.3.