Hi All,

Just looking for some feedback on what my options are here....


Is there any variant of LLR or sieve that will compile/run on PPC/Linux?

I have a 1.6 GHz PowerPC G5 running Gentoo, and right now I'm primarily using it as my server, but I would like to see if there is the possibility of running PG and/or PRPNet on it...otherwise my only other option is SETI@Home and I would MUCH rather contribute to PG... :)

I've managed to get the PRPNet client software to compile and execute successfully, but I was unable to get any implementation of LLR or the ppsieve test to compile...probably because it is x86 specific and I don't know anywhere near enough code to make it work on PPC...

Also, I was unable to find the source for Genefer or PFGW, I would be willing to try to create PPC Linux builds for those programs in order to run PRPNet if the source was available somewhere....in hindsight, it probably is available, I'm just not looking in the right places... ;)


So, is this just a pipe dream? or would it be feasible/practical to have a non-x86 (PPC) LLR or sieve implementation? I'm fairly certain (based on the applications list) that a OSX/PPC sieve (probably sr2sieve) implementation does exist, so that should at least be relatively easy to port to Linux (correct me if I'm wrong)

Again, I apologize for this, but I don't know nearly enough C to make this work on my own, so I would GREATLY appreciate any help that could be thrown my way, and if not, I understand, I know all the devs are rather busy... :)


Sorry if that was a little long, just trying to get all my thoughts in here...Thanks! :)
____________

Welcome to the project!

Get phrot source from here: http://home.roadrunner.com/~mrodenkirch/home/Phrot.html
Get genefer source from here: http://home.roadrunner.com/~mrodenkirch/home/Genefer.html

Both can be built and run on PPC. I run both on MacPPC (since I maintain them), so LinuxPPC shouldn't be difficult to build on. PFGW cannot be built on PPC (it's x86 only), so don't worry about it. If you need help building either, let me know.

In an attempt to troubleshoot myself, I'm recompiling GCC after installing FFTW....so I'll try again later today after that's done...

Rogue, I sent you a PM with the details of the various errors I encountered during my attempts to compile Phrot and Genefer

I'll post any updates to this thread if I have some time later today
____________

Okay, after a lot of trial and error and quite a bit of assistance from rogue, I have succeeded in compiling Phrot for 64-bit Linux/PPC....It seems to be working well as of this writing.... :)

I'll take a crack at genefer next, but just so I'm clear, there is not any implementation of LLR for RISC architectures worth mentioning, correct?

And does anyone know if a sieve application exists for PowerPC?
AFAIK, I would imagine that it would likely be very efficient due to the number of registers on the PPC and other RISC processors....but I could be totally misinterpreting the concept...
____________

Make sure you run some of the provided tests with phrot to verify that it is working correctly.

Believe it or not, outside of base 2, phrot on PPC compares fairly well to LLR on x86 (at the same clock rate). Jean is working on an LLR implementation that is built on FFTW, but I would be surprised if it is anywhere near as fast as phrot. The only real advantage it would have is the primality testing that phrot does not do.

Sieve applications do exist for PPC. Look here, http://sites.google.com/site/geoffreywalterreynolds/programs/. These can all be built on PPC. RISC is faster for some things that require fused multiply-add instructions in the FPU, but the extra registers don't help as much as you would expect. This is due to the number of cycles needed for some instructions and the expense of converting between FPU and INT.

Believe it or not, outside of base 2, phrot on PPC compares fairly well to LLR on x86 (at the same clock rate). Jean is working on an LLR implementation that is built on FFTW, but I would be surprised if it is anywhere near as fast as phrot. The only real advantage it would have is the primality testing that phrot does not do.

Was any other process hindering the i7 test? For that number it looks too slow. My Win7 x64 2.66GHz Core2 Q9450 gave:

cllr.exe -d -q"7843*2^134274+1" Starting Proth prime test of 7843*2^134274+1 Using all-complex FFT length 12K, a = 3 7843*2^134274+1 is not prime. Proth RES64: B72949BC5FFC727A Time : 29.368 sec.

I would expect a 2.66GHz i7-920 to be even quicker.

the UNROLLED_MR is a setting that will unroll the main loops to gain performance on CPUs with many registers. PPC is one such CPU. This is in phrot.c

#if defined(__ppc__)
#define UNROLLED_MR
#endif

so if __ppc__ is defined on your box, then it will take advantage of it.

The FPU to INT conversion is a problem with both FFTs and sieves, so those programs try to do as much math work as possible without doing a conversion. IIRC the conversion between the two is much more expensive on PPC than x86.

LLR 3.8.1 might be on par with phrot since it is using special modular reduction which George added specifically for LLR and PFGW. I haven't compared them since LLR 3.8 came out. Even if phrot is now slower than LLR for other bases, I think that it is fairly impressive since it has almost no asm in it.

There is a BIG difference between -funroll-loops and UNROLLED_MR. -funroll-loops is a compiler optimization that can take relatively simple loops (a few lines of C) and unroll them. UNROLLED_MR is coded optimization that takes some fairly complex loops and unrolls them.

Sieve applications do exist for PPC. Look here, http://sites.google.com/site/geoffreywalterreynolds/programs/. These can all be built on PPC. RISC is faster for some things that require fused multiply-add instructions in the FPU, but the extra registers don't help as much as you would expect. This is due to the number of cycles needed for some instructions and the expense of converting between FPU and INT.

There is a BIG difference between -funroll-loops and UNROLLED_MR. -funroll-loops is a compiler optimization that can take relatively simple loops (a few lines of C) and unroll them. UNROLLED_MR is coded optimization that takes some fairly complex loops and unrolls them.

AzureDragon phrot # ./phrot.g5 -d -q"7843*2^134274+1"
Phil Carmody's Phrot (0.72)
Input 7843*2^134274+1 : Actually testing 128499712*1048576^6713+1 (witness=3 6715/14336 limbs)
7843*2^134274+1 [-223680,289213,462807,360724] is composite LLR64=b72949bc5ffc727a. (e=0.03516 (0.0587399~3.90193e-16@0.000) t=91.61s)

7843*2^134274+1 is composite LLR64=b72949bc5ffc727a. (e=0.03516 (0.0587399~3.90193e-16@0.000) t=108.05s )
[2010-05-19 20:17:05 GMT] PPSE10k: 7843*2^134274+1 is not prime. Residue b72949bc5ffc727a

Did you run genefer with the switch that verifies residues? I suggest that you read this thread: http://www.primegrid.com/forum_thread.php?id=1800 regarding genefer compiler options. -O3 causes problems. I haven't looked into it yet. --ffast-math should work, but it doesn't. I really need to spend some time on it. I should be able to do that Memorial Day weekend.

-fassociative-math
Allow re-association of operands in series of floating-point operations. This violates the ISO C and C++ language standard by possibly changing computation result. NOTE: re-ordering may change the sign of zero as well as ignore NaNs and inhibit or create underflow or overflow (and thus cannot be used on a code which relies on rounding behavior like (x + 2**52) - 2**52). May also reorder floating-point comparisons and thus may not be used when ordered comparisons are required. This option requires that both -fno-signed-zeros and -fno-trapping-math be in effect. Moreover, it doesn't make much sense with -frounding-math.

-funsafe-math-optimizations
Allow optimizations for floating-point arithmetic that (a) assume that arguments and results are valid and (b) may violate IEEE or ANSI standards. When used at link-time, it may include libraries or startup files that change the default FPU control word or other similar optimizations.
This option is not turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications. Enables -fno-signed-zeros, -fno-trapping-math, -fassociative-math and -freciprocal-math.

Okay, sorry it's been a while, though I doubt anyone was holding their breath... ;) I got a new Nexus One and I've been enjoying all the Android splendor so I've been otherwise occupied for the last week or so with that to distract me from PG...


Here's an update on how PRPNet has been going on my G5 (single processor 1.8 GHz w/1.2G RAM running Gentoo with kernel 2.6.32) :


I've been able to get phrot tuned pretty well for PPSE10 and 11k, 10k work units take ~94 sec and 11k's take around ~105 sec

PPSE n>450K work units, on the other hand, take around ~2000 sec on average...

ESP works, but it takes several hours (I haven't kept track of exactly how long, but I believe it's around 6-8)...so I have that set to a low % in prpclient.ini...

Same for SGS, though I ended up commenting that line out because it was taking about 10-12 hours/WU to complete

27121 and GCW13 are also working, but I never completed a WU from either of those projects, I aborted both tasks after about 24 hours (tried 27121 first, then GCW) because they were less than half complete

But then, after I got my nexus one, and thus being otherwise occupied, I left the new 121 project crunching and it finished the first WU after about 36 hours....so I would assume that 27121 and GCW would take about that same amount of time (+ or - 2 hours)...still, 121 seems like the credit is fairly high for one work unit...I would be interested in finding out roughly how long its taking others to finish a WU on x86....

So I'm not sure if the extremely long run-times on the larger numbers are due to my hardware limitations (probably) or just due to the way I optimized phrot...I'll have to play around with optimizations a little more and see what GCC can come up with...my problem is that I'm not willing to wait long enough (damn ADD rears its ugly head) for the longer test units to finish running, so most of my tests were on the (relatively) smaller PPSE10 and 11k WU's....but now I have the new phone to distract me while it is running these tests, so I should be good ;)


Genefer seems to be working very well on GFN65536, but on GFN32768 it detects a roundoff error almost immediately and finishes with phrot (similar to what happens on x86 windows, but the x86 windows version then has the option to usually finish with the 80-bit version of genefer)


Mark: in regards to your above post I was able to successfully compile genefer with "-O3", but it only seemed to work correctly (producing correct residues) with the following CFLAG added on:

Some of the projects have workunits that take a long time on PPC. Workunits on GCW shouldn't take quite as long now that the base 13 tests are done. They will probably vary from five to ten hours, possibly longer, on your computer. I would recommend against SGS because the large k will make phrot inefficient. 27121, PPSE, and GFN65536 are also good choices, even though 27121 has longer workunits.

As for GFN32768, forget about it. The bases are too large for genefer and will trigger round-off errors. Since genefer80 can still handle the larger bases, I would avoid it until genefer80 until the bases get too large for it. The residues for generfer and phrot/llr/pfgw are not compatible, so unless phrot were to find a PRP, the test would be wasted (unless the server is not configured to do double-checks).

-ftree-loop-distribution is not a compiler option on MacPPC. I still haven't had time to work on this issue. The reason why the other one built with -O3 is because you also had -O2, which overrode the -O3.

I did a quick test and see that -funsafe-math-optimizations, which is set by -ffast-math is the problem on MacPPC. Using -ffast-math with -fno-unsafe-math-optimizations works, albeit not much faster than just -O3 without -ffast-math. I might be able to re-arrange parts of the code so that I can use -ffast-math, but I don't know yet. Here is gcc's take on -ffast-math:

This option should never be turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions.

Okay, I've been doing some tweaking with the compiler options (again, I wish my programming knowledge was a little better so I could do more work with the code itself) and I've been able to further optimize phrot and genefer....

Keep in mind, I haven't done any extensive testing or data collection to prove this hypothesis, it is just my general impression from how both were running through PRPNet

I'm not sure whether it is a product of how the code is written or just the way I ran it through GCC, but the time it took to produce results for both programs seemed to make a parabola (if hypothetically plotted on a grid)....smaller bases would take proportionally longer to produce a result, as would larger bases.... what I believe I've managed to do is make it so the larger bases are slightly faster than they were using my original build (i.e. ESP, GCW and 27121 seem to run faster) and the smaller PPSE wu's seem to take about the same amount of time....

Hope that made sense, so here's what worked for me...

Phrot (and YEAFFT) was compiled with the following:

Okay, so at long last and to relatively little fanfare...I would like to present to the PG community a new build of PRPNet!

prpclient-3.3.0alpha-PPC_Linux64

This was tested and working on a 64-bit installation of Gentoo Linux running on a G5 1.8 GHz single processor.

It includes:
Phrot 0.72, which performs PRP tests in a similar fashion to LLR.
Genefer 2.2.0 for RISC, which performs PRP tests on Generalized Fermat Numbers.

Works well on PPSE10 and 11k, GFN65536, ESP, 121, 27121, and GCW. See the above posts for more information on why GFN32768 and SGS are specifically NOT recommended.

I've posted the download link above, as well as the direct link here.

I would especially like to thank Mark (rogue) for all his help in getting this put together, I couldn't have done it without him!

Please PM me or email me (redstar3894 AT gmail DOT com) directly if anyone has any questions.
____________

Congrats on the PPC64 app. I have an IBM Power 3 (ppc64) running pps sieve at the moment, running Gentoo Linux, of course.

I was wondering if you could compile a generic app without altivec? IBM power doesn't support it. Is your app able to run the PPS LLR work units?

http://www.primegrid.com/show_host_detail.php?hostid=107509

I managed to squeeze out one work unit for the just completed Summer Solstice Challenge.
____________
6r39 7ri99

Beware the dual headed Gentoo with Wine!

Congrats on the PPC64 app. I have an IBM Power 3 (ppc64) running pps sieve at the moment, running Gentoo Linux, of course.

I was wondering if you could compile a generic app without altivec? IBM power doesn't support it. Is your app able to run the PPS LLR work units?

http://www.primegrid.com/show_host_detail.php?hostid=107509

I managed to squeeze out one work unit for the just completed Summer Solstice Challenge.

Okay, finally got the G5 back up and running *somewhat* smoothly... :p

So now that my build platform is back up and running, I should have some new build(s) created in the next few days (depending on available time, of course), and also incorporating any fixes (as referenced in the PRNet Discussion Thread) from Mark and Lennart.

The prpclient-3.3.(x)alpha-ppc_linux_64 will be renamed to prpclient-(x.x.x)alpha-ppc_linux_G5 (ppc 970/970FX) which will remain a 64-bit build compiled with AltiVec (though the benefits remain to be seen at this point) and it should also work on POWER6 (if anyone will ever be running PRPNet on one)

I will also add the following builds to the list of supported architectures:

prpclient-(x.x.x)alpha-ppc_linux_G4 (ppc 7xxx) 32-bit build for PPC with AltiVec
prpclient-(x.x.x)alpha-power_linux_64 (POWER3,4,5) 64-bit build for IBM POWER processors (same as ppc 970 but without AltiVec)

Please let me know if I'm off on the naming scheme here, and I'll change the build designations accordingly.

Like I said earlier, this is dependent on both my time and any changes Mark makes to the client source. And also please note that the two new builds I am adding will be run AT YOUR OWN RISK as I have no way to reliably test them on the architectures they will be built for.
____________

I have updated the PRPNet builds to the latest version (as of this writing, 3.3.2)

prpclient-3.3.2alpha-PPC_Linux_G5 - 64-bit PowerPC build with AltiVec

prpclient-3.3.2alpha-Power_Linux_64 - 64-bit generic PPC/POWER 64-bit build (without AltiVec)


These were tested and working on a 64-bit installation of Gentoo Linux running on a G5 1.8 GHz single processor.

It includes:
Phrot 0.72, which performs PRP tests in a similar fashion to LLR.
Genefer 2.2.0 for RISC, which performs PRP tests on Generalized Fermat Numbers.

Both builds work well on PPSE10 and 11k, GFN65536, ESP, 121, 27121, and GCW. See the above posts for more information on why GFN32768 and SGS are specifically NOT recommended. The generic build is slightly slower (from the benchmarks I ran) than the AltiVec-enabled build for just about all tests, but should still work fairly well on machines without the benefit of those added instructions.

I've posted the download links above, and the links on the PRPNet thread should be updated shortly.

I would especially like to thank Mark (rogue) for all his help in getting this put together, I couldn't have done it without him! Also, I would be remiss if I didn't thank Lennart and John for administering PRPNet and PrimeGrid itself, as well as Rytis for making it all possible. :)

Please PM me or email me directly (redstar3894 AT gmail DOT com) if there are any questions/issues or further requests.


NOTE: When rebuilding my system, I neglected to build the powerpc 32-bit (G4) toolchain, so the previously announced G4 build will be somewhat delayed, but I will update this thread and/or this post with any details as they come up.
____________