mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Software (https://www.mersenneforum.org/forumdisplay.php?f=10)
-   -   Software for IBM AIX (https://www.mersenneforum.org/showthread.php?t=13801)

pacionet 2010-08-30 09:18

Software for IBM AIX
 
I can run some software on some IBM AIX servers.
Until now the only program I can build and run successfully is glucas.
All the others have compile problems, etc.

Are there any other software that can be compiled and run (in a simple way !!!) for IBM AIX (powerpc) to do some prime search ?

I am looking for some software for sieve and/or search of primes; also "small" primes would be good.

ldesnogu 2010-08-30 10:03

"All the others" is rather fuzzy :smile: Which one did you try exactly?

Did you try [url=http://www.hogranch.com/mayer/README.html]mlucas[/url]?

pacionet 2010-08-30 10:13

Yes, I remember some difficulties to compile it.
Anyway I am searching some software for a different kind of primes, for Mersenne I am using glucas.

I didn't think that compile and build on this platform was so annoying !

mdettweiler 2010-08-30 15:27

You may want to check out [url=http://www.mersenneforum.org/showthread.php?p=202851#post202851]Phrot[/url], which is based on Glucas and can do:

-PRP tests on all k*b^n+-c numbers
-Proth tests (a full primality test) on k*2^n+1
-PRP tests on Generalized Fermat numbers

Note that any positive results returned by the PRP tests will need to be proven prime separately; aside from k*2^n+1, which Phrot can prove directly, you'll need to prove the primes with another program such as LLR or PFGW on an x86 machine. However, for most searches that would only be a small fraction of the overall computing time.

pacionet 2010-08-30 19:39

After some time spending trying to install Phrot i find some errors during compiling (it seems that it misses libm functions (sqrt, etc.))

It seems that I should install a particular libm which is not in standard AIX 5.3 distribution ... quite frustrating !!!

xilman 2010-08-30 19:53

[quote=pacionet;227758]After some time spending trying to install Phrot i find some errors during compiling (it seems that it misses libm functions (sqrt, etc.))

It seems that I should install a particular libm which is not in standard AIX 5.3 distribution ... quite frustrating !!![/quote]Sounds most unlikely to me. Over 12 years ago, when I last played with AIX, libm came as standard and had the all usual functions available. Are you sure that you are linking with "-lm" and that the linker can find the libm library? Try "find / -name libm.\*" and see what turns up.

Paul

rogue 2010-08-31 01:19

[QUOTE=pacionet;227758]After some time spending trying to install Phrot i find some errors during compiling (it seems that it misses libm functions (sqrt, etc.))

It seems that I should install a particular libm which is not in standard AIX 5.3 distribution ... quite frustrating !!![/QUOTE]

It could be a 32-bit vs 64-bit issue.

pacionet 2010-08-31 10:09

After some modifications:

1) export OBJECT_MODE=64
2) Adding -maix64 to compile flags
3) Commentig this line of mathtypes.h, because of conflicting definition

//typedef long long int64;

I got the following error:

[CODE]gcc -maix64 -lm -Wall \
-ffast-math \
-o phrot.g5 \
phrot.c \
-O3 -DY_MEM_THRESHOLD=8192 -DY_KILL_BRANCHES -DY_VECTORIZE \
-I../glucas ../glucas/libyeafft.a
In file included from phrot.c:57:
mathtypes.h:7: warning: ignoring #pragma warn
phrot.c: In function 'doPRPTest':
phrot.c:886: warning: format '%lli' expects type 'long long int', but argument 3 has type 'int64'
phrot.c:995: warning: format '%lli' expects type 'long long int', but argument 3 has type 'int64'
[B]ld: 0711-317 ERROR: Undefined symbol: Y_NTHREADS
ld: 0711-317 ERROR: Undefined symbol: Y_2NN
ld: 0711-317 ERROR: Undefined symbol: Y_BS
ld: 0711-317 ERROR: Undefined symbol: Y_DI
ld: 0711-317 ERROR: Undefined symbol: Y_DJ
ld: 0711-317 ERROR: Undefined symbol: Y_IR
ld: 0711-317 ERROR: Undefined symbol: Y_NC
ld: 0711-317 ERROR: Undefined symbol: Y_2N0[/B]
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: ld returned 8 exit status
make: *** [phrot.g5] Error 1[/CODE]

Some libraries still miss ?

pacionet 2010-08-31 10:26

Solved with :

1) ar rc libyeafft.a *.o

instead of

ar rc libyeafft.a [drty]*.o

as in Proth documentation

and changing Makefile

gcc [B]-maix64 -lm -lpthread[/B] ${GCC_MARCH} -Wall

Still got this warnings

[B]phrot.c:886: warning: format '%lli' expects type 'long long int', but argument 3 has type 'int64'
phrot.c:995: warning: format '%lli' expects type 'long long int', but argument 3 has type 'int64'[/B]

Now I try to run some self test (if any) to test Proth working

ldesnogu 2010-08-31 10:56

[quote=pacionet;227868]gcc [B]-maix64 -lm -lpthread[/B] ${GCC_MARCH} -Wall

Still got this warnings

[B]phrot.c:886: warning: format '%lli' expects type 'long long int', but argument 3 has type 'int64'
phrot.c:995: warning: format '%lli' expects type 'long long int', but argument 3 has type 'int64'[/B][/quote]
To fix this warning the best solution is to use PRId64 (from <inttypes.h>. The less portable one is to replace %lli with %li.

pacionet 2010-08-31 11:44

Mmmmm...
Now I builded successfully Phrot (no errors or warning) but I got the following result

bash-3.2$ [B]phrot.g5 -q 5028*10^83982+1[/B]
Phil Carmody's Phrot (0.72)
Input 5028*10^83982+1 : Actually testing 5028*1000000^13997+1 (witness=3 13998/28672 limbs)
5028*10^83982+1 is composite LLR64=0000000000000001. (e=0.00000 (0.0824785~0@0.000) t=133.91s)

On this proven prime number:

[url]http://primes.utm.edu/primes/page.php?id=79257[/url]


I fear that the problem is in maththypes.h

[B]//typedef long long int64;[/B]

while in <inttypes.h>

[B]#ifdef __64BIT__
typedef long int64;
#else /* _ILP32 */
#if defined(_LONG_LONG)
typedef signed long long int64;
#endif
#endif[/B]

If i don't comment the line

[B]//typedef long long int64;[/B]

I got the following error:

In file included from phrot.c:57:
[B]mathtypes.h:9: error: conflicting types for 'int64'[/B]
/usr/include/inttypes.h:622: error: previous declaration of 'int64' was here

rogue 2010-08-31 12:39

With the distribution there should be a few files that you can use to test your build.

pacionet 2010-08-31 12:52

[QUOTE=rogue;227879]With the distribution there should be a few files that you can use to test your build.[/QUOTE]

The first test, as written before, failed (test a proven prime).
I think the problem is in that type definition int64.

What definition I have to use ? The one in mathtypes.h or the one in /usr/lib/inttypes.h ? How should I modify the include statements ?

ldesnogu 2010-08-31 12:55

[quote=pacionet;227880]The first test, as written before, failed (test a proven prime).
I think the problem is in that type definition int64.

What definition I have to use ? The one in mathtypes.h or the one in /usr/lib/inttypes.h ? How should I modify the include statements ?[/quote]
It should be 64-bit. Just print sizeof(int64) and check it's 8.
If it is 8, then your issue is somewhere else.

pacionet 2010-08-31 13:38

[QUOTE=ldesnogu;227881]It should be 64-bit. Just print sizeof(int64) and check it's 8.
If it is 8, then your issue is somewhere else.[/QUOTE]

It's 8
(fprintf(stderr, "sizeof(int64)=%lu\n",sizeof(int64)); )

[CODE]bash-3.2$ phrot.g5 -q 5028*10^83982+1
[B]sizeof(int64)=8[/B]
Phil Carmody's Phrot (0.72)
Input 5028*10^83982+1 : Actually testing 5028*1000000^13997+1 (witness=3 13998/28672 limbs)
5028*10^83982+1 is composite LLR64=0000000000000001. (e=0.00000 (0.0824785~0@0.000) t=76.88s)[/CODE]

rogue 2010-08-31 14:33

Do you have problems with other bases? What about k*b^n-1 numbers? What about base 2 numbers? What about composite numbers with known residues? Could you run a few more tests on numbers of these forms and let us know the result?

pacionet 2010-08-31 15:13

I ran the tests in testm/abcm.in

[CODE]phrot.g5 testm/abcm.in
sizeof(int64)=8
Phil Carmody's Phrot (0.72)
Input 10*1017^20086-1 : Actually testing 10*1034289^10043-1 (witness=3 10044/20480 limbs)
10*1017^20086-1 is composite LLR64=0000000000000000. (e=0.00000 (0.0704057~0@0.000) t=63.10s)
Input 1000866867*10^5066-1 : Actually testing 100086686700*1000^1688-1 (witness=3 1692/3584 limbs)
k>b^2 not supported for LLR residues
1000866867*10^5066-1 is composite LLR64=0000000000000000. (e=0.00000 (2.33299e-08~0@0.000) t=1.90s)
Input 10025*82^10025-1 : Actually testing 67408100*551368^3341-1 (witness=3 3343/7168 limbs)
10025*82^10025-1 is composite LLR64=0000000000000000. (e=0.00000 (0.0107054~0@0.000) t=15.95s)
Input 1003509507*10^5066-1 : Actually testing 100350950700*1000^1688-1 (witness=3 1692/3584 limbs)
k>b^2 not supported for LLR residues
1003509507*10^5066-1 is composite LLR64=0000000000000000. (e=0.00000 (2.33299e-08~0@0.000) t=1.90s)
Input 1004245242*10^2534-1 : Actually testing 100424524200*1000^844-1 (witness=3 848/1792 limbs)
k>b^2 not supported for LLR residues
1004245242*10^2534-1 is composite LLR64=0000000000000000. (e=0.00000 (1.52791e-08~0@0.000) t=0.48s)
Input 1004521518*10^2541-1 : Actually testing 10045215180*10000^635-1 (witness=3 638/1280 limbs)
k>b^2 not supported for LLR residues
1004521518*10^2541-1 is composite LLR64=0000000000000000. (e=0.00000 (1.23057e-06~0@0.000) t=0.34s)
Input 10056710664*10^5062-1 : Actually testing 100567106640*1000^1687-1 (witness=3 1691/3584 limbs)
k>b^2 not supported for LLR residues
10056710664*10^5062-1 is composite LLR64=0000000000000000. (e=0.00000 (2.33216e-08~0@0.000) t=1.90s)
Input 1007731725*10^2536-1 : Actually testing 1007731725*10000^634-1 (witness=3 637/1280 limbs)
k>b^2 not supported for LLR residues
1007731725*10^2536-1 is composite LLR64=0000000000000000. (e=0.00000 (1.22936e-06~0@0.000) t=0.34s)
Input 1008509502*10^5026-1 : Actually testing 10085095020*1000^1675-1 (witness=3 1679/3584 limbs)
k>b^2 not supported for LLR residues
1008509502*10^5026-1 is composite LLR64=0000000000000000. (e=0.00000 (2.32207e-08~0@0.000) t=1.88s)
Input 100876776*10^2534-1 : Actually testing 10087677600*10000^633-1 (witness=3 636/1280 limbs)
k>b^2 not supported for LLR residues
100876776*10^2534-1 is composite LLR64=0000000000000000. (e=0.00000 (1.22815e-06~0@0.000) t=0.34s)
Input 101029929*10^2558-1 : Actually testing 10102992900*10000^639-1 (witness=3 642/1536 limbs)
k>b^2 not supported for LLR residues
101029929*10^2558-1 is composite LLR64=0000000000000000. (e=0.00000 (1.76749e-06~0@0.000) t=0.41s)[/CODE]

Base 2:

[CODE]bash-3.2$ phrot.g5 -q 299*2^19752-1
sizeof(int64)=8
Phil Carmody's Phrot (0.72)

Current line of input doesn't matched checkpointed test. Current test will be restarted
Input 299*2^19752-1 : Actually testing 1224704*1048576^987-1 (witness=3 989/2048 limbs)
299*2^19752-1 is composite LLR64=0000000000000000. (e=0.00000 (0.0184696~0@0.000) t=1.27s)[/CODE]

I don't know where to find tests with known residues.

ldesnogu 2010-08-31 16:11

[quote=pacionet;227890]It's 8
(fprintf(stderr, "sizeof(int64)=%lu\n",sizeof(int64)); )[/quote]
So I'd say the definition of int64 is not the issue.

Are you sure yeafft is correctly compiled?

Another thing to try: remove -ffast-math.

rogue 2010-08-31 16:18

-ffast-math can definitely cause problems.

Follow [URL="http://www.mersenneforum.org/showpost.php?p=226473&postcount=737"]this link[/URL] to find some PFGW residues. If your build of phrot results in residues with lots of zeros, then the problem is with the build, most likely -ffast-math.

Since gcc varies slightly from platform to platform it could be another compiler option. I recommend using -O1 and removing all -f switches to see if it works. If it does, then use -O2, then -O3 or add -f switches one at a time to figure out which one is causing the problem.

pacionet 2010-08-31 16:47

Without -ffast-math and with -O1:

[CODE]gcc -maix64 -lm -lpthread -Wall \
-O1 \
-o phrot.g5 \
phrot.c \
-O1 -DY_MEM_THRESHOLD=8192 -DY_KILL_BRANCHES -DY_VECTORIZE \
-I../glucas ../glucas/libyeafft.a[/CODE]


The testm seems work:

Input 103914*4001^4001-1 : Actually testing 103914*4001^4001-1 (witness=3 4003/8192 limbs)
103914*4001^4001-1 is PRP. (e=0.00000 (6.28077e-07~3.53103e-16@0.000) t=15.16s)
Input 103951848*10^2555-1 : Actually testing 103951848*100000^511-1 (witness=3 513/1152 limbs)
103951848*10^2555-1 is PRP. (e=0.00005 (0.000150342~2.35792e-16@0.000) t=0.35s)
Input 1041845805*10^2562-1 : Actually testing 1041845805*1000^854-1 (witness=3 858/1792 limbs)
1041845805*10^2562-1 is PRP. (e=0.00000 (1.53901e-08~2.54359e-16@0.000) t=0.54s)
Input 104297193*10^5069-1 : Actually testing 1042971930*10000^1267-1 (witness=3 1270/2560 limbs)
104297193*10^5069-1 is PRP. (e=0.00000 (1.88708e-06~3.51235e-16@0.000) t=1.52s)


[...]

but this test fails:

[CODE]bash-3.2$ phrot.g5 -q 5028*10^83982+1
sizeof(int64)=8
Phil Carmody's Phrot (0.72)
Input 5028*10^83982+1 : Actually testing 5028*1000000^13997+1 (witness=3 13998/28672 limbs)
5028*10^83982+1 is composite LLR64=0000000000000000. (e=0.00098 (0.0824785~8.27893e-18@0.000) t=164.23s)[/CODE]

How can I test if the yeafft is correctly compiled ?

Other tests with composite and known residues ([B]failed[/B]) (with the same options, ffast-math removed and O1)

56093*36^58139-1 is composite: RES64: [00BFD059739B458C]
My result: LLR64=0000000000000000.

56093*36^59413-1 is composite: RES64: [3A3314C49046512B]
My result: LLR64=0000000000000000

pacionet 2010-08-31 17:30

Others configuration (different compile flags), same (wrong) results:

[CODE]gcc -maix64 -lm -lpthread -Wall \
\
-o phrot.g5 \
phrot.c \
-O3 -DY_MEM_THRESHOLD=8192 -DY_KILL_BRANCHES -DY_VECTORIZE \
-I../glucas ../glucas/libyeafft.a[/CODE]


[CODE]gcc -maix64 -lm -lpthread -Wall \
\
-o phrot.g5 \
phrot.c \
-O1 -DY_MEM_THRESHOLD=8192 -DY_KILL_BRANCHES \
-I../glucas ../glucas/libyeafft.a
[/CODE]

[CODE]gcc -maix64 -lm -lpthread -Wall \
\
-o phrot.g5 \
phrot.c \
\
-I../glucas ../glucas/libyeafft.a
[/CODE]

Tell me I found a bug in IBM hardware and they'll give me some million dollars to keep it secret :))))))) !!!!

rogue 2010-08-31 17:40

Since you are getting residues of 0's, then either phrot is built incorrectly or YEAFFT is built incorrectly. What compiler flags were used to build the YEAFFT library?

pacionet 2010-08-31 18:49

[QUOTE=rogue;227924]Since you are getting residues of 0's, then either phrot is built incorrectly or YEAFFT is built incorrectly. What compiler flags were used to build the YEAFFT library?[/QUOTE]

I followed the instructions in phrot readme file and I have used the yeafft of glucas. Remaking glucas I found these:

[...]
[CODE]gcc -DHAVE_CONFIG_H -I. -I. -I. -O3 -DY_MEM_THRESHOLD=8192 -DY_KILL_BRANCHES -DY_VECTORIZE -c `test -f 'ynorm_16.c' || echo './'`ynorm_16.c
source='yeafft.c' object='yeafft.o' libtool=no \
depfile='.deps/yeafft.Po' tmpdepfile='.deps/yeafft.TPo' \
depmode=gcc3 /bin/sh ./depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I. -O3 -DY_MEM_THRESHOLD=8192 -DY_KILL_BRANCHES -DY_VECTORIZE -c `test -f 'yeafft.c' || echo './'`yeafft.c
source='yeafft1.c' object='yeafft1.o' libtool=no \
depfile='.deps/yeafft1.Po' tmpdepfile='.deps/yeafft1.TPo' \
depmode=gcc3 /bin/sh ./depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I. -O3 -DY_MEM_THRESHOLD=8192 -DY_KILL_BRANCHES -DY_VECTORIZE -c `test -f 'yeafft1.c' || echo './'`yeafft1.c
source='yeainit.c' object='yeainit.o' libtool=no \
depfile='.deps/yeainit.Po' tmpdepfile='.deps/yeainit.TPo' \[/CODE]
[...]

Maybe one of
-O3
-DY_MEM_THRESHOLD=8192
-DY_KILL_BRANCHES
-DY_VECTORIZE

can cause problems ?

rogue 2010-08-31 19:04

[QUOTE=pacionet;227935]I followed the instructions in phrot readme file and I have used the yeafft of glucas. Remaking glucas I found these:

Maybe one of
-O3
-DY_MEM_THRESHOLD=8192
-DY_KILL_BRANCHES
-DY_VECTORIZE

can cause problems ?[/QUOTE]

The -D values are specific to glucas and are unlikely to cause problems. -O3 could be a problem. Try rebuilding with -O1, then rebuild phrot and see what happens. If -O1 works, then try -O2 and do it again.

pacionet 2010-08-31 19:38

[QUOTE=rogue;227937]The -D values are specific to glucas and are unlikely to cause problems. -O3 could be a problem. Try rebuilding with -O1, then rebuild phrot and see what happens. If -O1 works, then try -O2 and do it again.[/QUOTE]

I was not lucky.
Rebuilt yeafft with -O1

[CODE]gcc -DHAVE_CONFIG_H -I. -I. -I. -O1 -DY_MEM_THRESHOLD=8192 -DY_KILL_BRANCHES -DY_VECTORIZE -c `test -f 'ynorm_16.c' || echo './'`ynorm_16.c
source='yeafft.c' object='yeafft.o' libtool=no \
depfile='.deps/yeafft.Po' tmpdepfile='.deps/yeafft.TPo' \
depmode=gcc3 /bin/sh ./depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I. -O1 -DY_MEM_THRESHOLD=8192 -DY_KILL_BRANCHES -DY_VECTORIZE -c `test -f 'yeafft.c' || echo './'`yeafft.c
source='yeafft1.c' object='yeafft1.o' libtool=no \
depfile='.deps/yeafft1.Po' tmpdepfile='.deps/yeafft1.TPo' \
depmode=gcc3 /bin/sh ./depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I. -O1 -DY_MEM_THRESHOLD=8192 -DY_KILL_BRANCHES -DY_VECTORIZE -c `test -f 'yeafft1.c' || echo './'`yeafft1.c
source='yeainit.c' object='yeainit.o' libtool=no \
depfile='.deps/yeainit.Po' tmpdepfile='.deps/yeainit.TPo' \
depmode=gcc3 /bin/sh ./depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I. -O1 -DY_MEM_THRESHOLD=8192 -DY_KILL_BRANCHES -DY_VECTORIZE -c `test -f 'yeainit.c' || echo './'`yeainit.c
source='radix_2.c' object='radix_2.o' libtool=no \
depfile='.deps/radix_2.Po' tmpdepfile='.deps/radix_2.TPo' \[/CODE]

and phrot

[CODE]gcc -maix64 -lm -lpthread -Wall \
\
-o phrot.g5 \
phrot.c \
-O1 -DY_MEM_THRESHOLD=8192 -DY_KILL_BRANCHES -DY_VECTORIZE \
-I../glucas ../glucas/libyeafft.a[/CODE]

Same wrong result ... with residues with a lot of zeros:

[CODE]phrot.g5 -q 5028*10^83982+1
sizeof(int64)=8
Phil Carmody's Phrot (0.72)

Input 5028*10^83982+1 : Actually testing 5028*1000000^13997+1 (witness=3 13998/28672 limbs)
5028*10^83982+1 is composite LLR64=0000000000000000. (e=0.00098 (0.0824785~8.27893e-18@0.000) t=173.92s)[/CODE]

[CODE]bash-3.2$ phrot.g5 -q 56093*36^58139-1
sizeof(int64)=8
Phil Carmody's Phrot (0.72)
Input 56093*36^58139-1 : Actually testing 72696528*46656^19379-1 (witness=3 19381/40960 limbs)
56093*36^58139-1 is composite LLR64=0000000000000000. (e=0.00047 (0.00021126~1.53918e-15@0.000) t=267.87s)[/CODE]


On the other hand glucas seems to work

[CODE][Thu Aug 26 19:53:09 2010]
bash-3.2$ glucas 23209
Going to work with exponent 23209
Starting from iteration 1. Exponent 23209.
M23209. Saved file at iteration 4096. Res64: 60DD379FEFC017FE.
M23209. Saved file at iteration 8192. Res64: 57B014FAC6BAED3A.
Iter. 10000 ( 43.09%), Err= 0.086, 0.35 user 52% CPU (0.000 sec/iter).
M23209. Saved file at iteration 12288. Res64: 92B6CB2BE3CD9ECE.
M23209. Saved file at iteration 16384. Res64: 5322CA8405A26B7B.
Iter. 20000 ( 86.18%), Err= 0.078, 0.35 user 52% CPU (0.000 sec/iter).
M23209. Saved file at iteration 20480. Res64: 4EAA7F09C57C7B75.
[Tue Aug 31 21:24:56 2010]
M23209 is a known Mersenne prime!
[/CODE]

[CODE]bash-3.2$ glucas 216091
M216091. Saved file at iteration 167936. Res64: 65DAC3959C92014B.
Iter. 170000 ( 78.67%), Err= 0.000, 6.25 user 100% CPU (0.001 sec/iter).
M216091. Saved file at iteration 172032. Res64: 82AC0AEF60948C69.
M216091. Saved file at iteration 176128. Res64: 95582DC8C101C4E9.
Iter. 180000 ( 83.30%), Err= 0.000, 6.25 user 100% CPU (0.001 sec/iter).
M216091. Saved file at iteration 180224. Res64: DA6BE8F46193EDFC.
M216091. Saved file at iteration 184320. Res64: 4C0C54F6B3BB5100.
M216091. Saved file at iteration 188416. Res64: 406A52E8ECC1101E.
Iter. 190000 ( 87.93%), Err= 0.000, 6.26 user 100% CPU (0.001 sec/iter).
M216091. Saved file at iteration 192512. Res64: DD896660D12E8357.
M216091. Saved file at iteration 196608. Res64: BCFE65FA0F9F4778.
Iter. 200000 ( 92.55%), Err= 0.000, 6.25 user 100% CPU (0.001 sec/iter).
M216091. Saved file at iteration 200704. Res64: F4E92A3E32F77E9F.
M216091. Saved file at iteration 204800. Res64: 78897F6C7A3E982E.
M216091. Saved file at iteration 208896. Res64: 1007948E422A60B9.
Iter. 210000 ( 97.18%), Err= 0.000, 6.26 user 100% CPU (0.001 sec/iter).
M216091. Saved file at iteration 212992. Res64: 240FD3A839CB978D.
[Tue Aug 31 21:35:15 2010]
M216091 is a known Mersenne prime![/CODE]

rogue 2010-08-31 19:42

Interesting. Can you remove the -maix64 setting from the build of phrot and see what happens? Which version of gcc is installed?

Beyond that I would need to run your build of phrot with a debugger.

pacionet 2010-08-31 23:56

Nice ...

without the [B]-maix64[/B] flag it seems to work

PRP:

[CODE]phrot.g5 -q 5028*10^83982+1
sizeof(int64)=8
Phil Carmody's Phrot (0.72)

Input 5028*10^83982+1 : Actually testing 5028*1000000^13997+1 (witness=3 13998/28672 limbs)
5028*10^83982+1 is PRP. (e=0.05469 (0.0824785~4.62227e-16@0.000) t=450.37s)[/CODE]

Known residue:

[CODE]phrot.g5 -q 56093*36^58139-1

RES64: [00BFD059739B458C]

LLR64=00bfd059739b458c[/CODE]


Anyway, I remember that in all previous attempts (probably when libyeafft was compiled with -O3 ?) without -maix64 flag gcc complains and output some errors.

So, resuming, the final working configuration (flags) for me is:

[CODE]YEAFFT: [B]-O1[/B] -DY_MEM_THRESHOLD=8192 -DY_KILL_BRANCHES -DY_VECTORIZE

PHROT: gcc [B]-lm -lpthread[/B] -Wall -o phrot.g5 phrot.c \
-O1 -DY_MEM_THRESHOLD=8192 -DY_KILL_BRANCHES -DY_VECTORIZE \
-I../glucas ../glucas/libyeafft.a[/CODE]


Thanks

rogue 2010-09-01 00:56

Definitely try to get -O2 working, maybe YEAFFT with -O2 and phrot with -O1 or vice versa. You probably won't get to the 133 seconds (vs. 450) for that test, but if you can regain even 50% of the speed, then your efforts will be worth it.

Before you participate in any projects, I strongly recommend that you run through the provided tests and do a bunch of those base 36 composite tests. If all tests have correct results, then you are good to go. If you still have a bad build, then a lot of the work you do for projects will be suspect and possibly tossed.

pacionet 2010-09-01 14:02

[QUOTE=rogue;227988]Definitely try to get -O2 working, maybe YEAFFT with -O2 and phrot with -O1 or vice versa. You probably won't get to the 133 seconds (vs. 450) for that test, but if you can regain even 50% of the speed, then your efforts will be worth it.

Before you participate in any projects, I strongly recommend that you run through the provided tests and do a bunch of those base 36 composite tests. If all tests have correct results, then you are good to go. If you still have a bad build, then a lot of the work you do for projects will be suspect and possibly tossed.[/QUOTE]

Before joining any project , I think I should try to install a sieve on the same machine. Any suggests ?

rogue 2010-09-01 15:36

[QUOTE=pacionet;228025]Before joining any project , I think I should try to install a sieve on the same machine. Any suggests ?[/QUOTE]

d/l Geoff Reynold's srsieve programs and build them. They have some PPC code in them, but you might need to modify the makefile and some sources to use it.


All times are UTC. The time now is 11:33.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.