Posts by Redstar3894

11) Message boards : Sieving : ppsieve/tpsieve CUDA testing (Message 24176)
Posted 4863 days ago by Redstar3894

Win7 64
i7-920 w/6GB RAM
GTX 260 Core 216 (Factory OC)
Driver 197.45
BOINC running CPU tasks only

Here's two tests I ran using Ken's latest build...with the standard cudart.dll as agreed on earlier....

D:\Patrick\ppsieve-cuda-vc\Release>ppsieve-cuda.exe -p42070e9 -P42070030e6 -k 1201 -K 9999 -N 20000 ppsieve version cuda-0.1.1 (testing) nstart=76, nstep=32, gpu_nstep=32 ppsieve initialized: 1201 <= k <= 9999, 76 <= n <= 20000 Sieve started: 42070000000000 <= p < 42070030000000 Thread 0 starting Detected GPU 0: GeForce GTX 260 Detected compute capability: 1.3 Detected 27 multiprocessors. Thread 0 completed Waiting for threads to exit Sieve complete: 42070000000000 <= p < 42070030000000 Found 0 factors count=955289,sum=0x2dbc17167afb6a8d Elapsed time: 0.71 sec. (0.05 init + 0.67 sieve) at 45328606 p/sec. Processor time: 0.31 sec. (0.06 init + 0.25 sieve) at 120778519 p/sec. Average processor utilization: 1.39 (init), 0.38 (sieve)

And the second one...

D:\Patrick\ppsieve-cuda-vc\Release>ppsieve-cuda.exe -p42070e9 -P42070003e6 -k 1201 -K 9999 -N 2000000 -z normal ppsieve version cuda-0.1.1 (testing) nstart=76, nstep=32, gpu_nstep=32 ppsieve initialized: 1201 <= k <= 9999, 76 <= n <= 2000000 Sieve started: 42070000000000 <= p < 42070003000000 Thread 0 starting Detected GPU 0: GeForce GTX 260 Detected compute capability: 1.3 Detected 27 multiprocessors. 42070000070587 | 9475*2^197534+1 42070000198537 | 3373*2^1046686+1 42070000300049 | 9139*2^461846+1 42070000345343 | 1715*2^635711+1 42070000464001 | 4179*2^1577462+1 42070000949861 | 4707*2^571847+1 42070001011573 | 7113*2^215532+1 42070001040127 | 6471*2^37907+1 42070002482267 | 9951*2^1920408+1 42070002690167 | 2553*2^1888870+1 42070002698543 | 4239*2^368773+1 42070002875941 | 4081*2^1494668+1 Thread 0 completed Waiting for threads to exit Sieve complete: 42070000000000 <= p < 42070003000000 Found 12 factors count=95668,sum=0x37dacb7121ccffe4 Elapsed time: 4.31 sec. (0.05 init + 4.27 sieve) at 737011 p/sec. Processor time: 0.37 sec. (0.08 init + 0.30 sieve) at 10613046 p/sec. Average processor utilization: 1.73 (init), 0.07 (sieve)

13) Message boards : Sieving : ppsieve/tpsieve CUDA testing (Message 24112)
Posted 4865 days ago by Redstar3894

Here's my result from the shorter test Scott posted above:

D:\Patrick\ppsieve-cuda-vc\Release>ppsieve-cuda.exe -p42070e9 -P42070003e6 -k 1201 -K 9999 -N 2000000 -z normal ppsieve version cuda-0.1.1 (testing) nstart=76, nstep=32, gpu_nstep=32 ppsieve initialized: 1201 <= k <= 9999, 76 <= n <= 2000000 Sieve started: 42070000000000 <= p < 42070003000000 Thread 0 starting Detected GPU 0: GeForce GTX 260 Detected compute capability: 1.3 Detected 27 multiprocessors. 42070000070587 | 9475*2^197534+1 42070000198537 | 3373*2^1046686+1 42070000300049 | 9139*2^461846+1 42070000345343 | 1715*2^635711+1 42070000464001 | 4179*2^1577462+1 42070000949861 | 4707*2^571847+1 42070001011573 | 7113*2^215532+1 42070001040127 | 6471*2^37907+1 42070002482267 | 9951*2^1920408+1 42070002690167 | 2553*2^1888870+1 42070002698543 | 4239*2^368773+1 42070002875941 | 4081*2^1494668+1 Thread 0 completed Waiting for threads to exit Sieve complete: 42070000000000 <= p < 42070003000000 Found 12 factors count=95668,sum=0x37dacb7121ccffe4 Elapsed time: 11.19 sec. (0.05 init + 11.14 sieve) at 282411 p/sec. Processor time: 4.18 sec. (0.06 init + 4.12 sieve) at 763818 p/sec. Average processor utilization: 1.30 (init), 0.37 (sieve)

15) Message boards : Number crunching : Alternative Platforms (Message 24098)
Posted 4865 days ago by Redstar3894

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).

Hmmmm....I haven't tried GCW in a while....maybe I'll add that to the rotation and see how it runs...

But yeah, I've more or less written off SGS and GFN32768 due to the above reasons...probably going to add 27121 to that list as well...

I've been looking over programmers notes for the PowerPC 970FX and based on my learnings and (limited) knowledge of programing, it doesn't seem that there will be any easy way to get a similar extended precision (i.e. Genefer80) running on the PPC, since, (as you know) the 80-bit floating point standard is unique to the x87 instruction set and therefore to the x86 architecture...though since the PPC 970 does have 2 FPU's as well as the AltiVec units, something could possibly be done with those....or not...again, forgive my interpretations if I'm way off, some of this is way over my head...

-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.

Interesting, so the MacPPC version does not include the graphite loop optimizations....
Also, I was under the impression that since I specified:

-Wl

that all options following that would be passed to the linker...so that's why I placed -O2 there....but again, I'm probably wrong.... thanks for being patient here....

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.

I knew I forgot something...I'll see if -ffast-math with -fno-unsafe-math-optimizations makes any difference and I'll play around with the Graphite Loop Optimizations because it seemed like those helped phrot (not to mention allowing genefer to compile with -O3)...I'll try and read up some more on all this and see if I can take a look at moving things around in the code as well

17) Message boards : Number crunching : Alternative Platforms (Message 23932)
Posted 4878 days ago by Redstar3894

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.

I discovered this problem later, (though I caught it before I was sent any GFN workunits)...It's a shame, because -O3 and -ffast-math make it SO much faster....

I should have some time to kill this weekend, so maybe I'll try building genefer while selectively enabling the subflags of -O3 and -ffast-math, from what I read on that thread, it seems like one or two of the flags is the culprit...probably disabling "-fno-associative math" and "-funsafe-math-optimizations"...at least on the PS3 (and yet to be determined on the G5)

From the GCC Manual:

-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.

I would try taking a look through the code itself, but as I said before, my knowledge of C is rudimentary at best, so maybe if I'm feeling adventurous later...I'll post the results here if I find some problems/answers... ;)

On the contrary, as you said in the other thread http://www.primegrid.com/forum_thread.php?id=1800&nowrap=true#22784, phrot seems to be running VERY well when compiled with -O3 (though not -ffast-math)....I'm getting about ~94s per PPSE10k unit, about ~100s per PPSE11k unit, ~2100s per PPSE unit...

I also was able to gain about ~2s per PPSE10/11k wu's by compiling phrot with -floop-block and -ftree-loop-distribution (I'm using GCC 4.4.3) so I'm not sure if that is just by chance or the Graphite/PPL loop optimizations will actually benefit the code....

I didn't launch this effort with any major expectations to speak of, so I'm very satisfied with the results and if I were able to get genefer fully optimized, that would just be the icing on the cake... :)

Rogue, seriously, thank you so much for all your help and patience with me here, I really appreciate it!

19) Message boards : Number crunching : Alternative Platforms (Message 23916)
Posted 4879 days ago by Redstar3894

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.

I had a feeling it was something along those lines....I'll have to take a look to see if that was explicitly defined when I built phrot....
(Again, I apologize for my relative ignorance when it comes to these things...)

In other news, I have succeeded in building genefer! :)

I took your suggestion and added in a new #elseif with a CPU_TARGET linux/ppc/ppc64 and that did the trick :)

I can provide a diff with my modifications if you like, or just post them here....

Also, when building genefer, I had to use the '-pipe' CFLAG, I kept getting error messages about temporary files....not sure if that was a general error or something I was doing incorrectly, but it works now, I've checked it against several sources and it appears to be running correctly :)

If you had any recommendations about optimizing genefer, I would greatly appreciate them, what I ended up using is

'-O3 -pipe -mcpu=970 -mtune=970 -maltivec -Wl,-lm -O2'

(where the last two are passed to the linker) In hindsight, I probably didn't need to use '-lm' since it's not linking external libraries, but it seemed to work okay....

And PRPNet has been humming along rather smoothly for the last few hours, it's not the quickest in the world (at least compared to the i7 that I'm used to), but it gets the job done... :)

So I just wanted to especially thank rogue for his support and patience in helping me figure this out! I definitely couldn't have done it without your help, Thank You! :)

Next I guess I'll try re-working some sieve applications to see if they can be built on PPC/Linux

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.

But that will probably have to wait until I have some more free time... ;)

Toggle Menu

Join PrimeGrid

Returning Participants

Community

Leader Boards

Results

Other