Software for IBM AIX

[rogue]

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

[pacionet]

Originally Posted by rogue

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

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]

Originally Posted by pacionet

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 ?

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]

Originally Posted by ldesnogu

It should be 64-bit. Just print sizeof(int64) and check it's 8.
If it is 8, then your issue is somewhere else.

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

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=0000000000000001. (e=0.00000 (0.0824785~0@0.000) t=76.88s)

[rogue]

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]

I ran the tests in testm/abcm.in

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)

Base 2:

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)

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

[ldesnogu]

Originally Posted by pacionet

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

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]

-ffast-math can definitely cause problems.

Follow this link 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]

Without -ffast-math and with -O1:

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

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:

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)

How can I test if the yeafft is correctly compiled ?

Other tests with composite and known residues (failed) (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]

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

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

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

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

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

[rogue]

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?