Fast Mersenne Testing on the GPU using CUDA

[flashjh]

Originally Posted by aaronhaviland

1.48 and 1.64, why?

Just wondering/making sure the version was reliable for you to compare with.

[Dubslow]

Why does Prime95 keep roundoff error below .24 if CL and gL both seem to work fine with more than that? (Why not go up to like .45 or something?)

[Prime95]

Originally Posted by Dubslow

Why does Prime95 keep roundoff error below .24 if CL and gL both seem to work fine with more than that? (Why not go up to like .45 or something?)

If the average max roundoff error for 1000 iterations is above 0.24 then it is not uncommon for one or more of the tens of millions of iterations to come out above 0.4 -- which is getting into dangerous territory.

[Dubslow]

Ah, okay, and that's what produces the "reproducible error" message?

[Prime95]

I have some ideas for speeding up the carry propagation step. Before proceeding, can anyone tell me what percentage of the time is spent doing the various steps: forward FFT, point-wise squaring, inverse FFT, carry propagation (which includes applying weights and converting to and from integer).

I can describe the ideas to anyone who wants to run with it, or else you'll have to wait for me to install an nVidia environment and learning how to use it.

[ixfd64]

Hmm, is George hinting that GPU support will be his next project?

[aaronhaviland]

Originally Posted by Prime95

I have some ideas for speeding up the carry propagation step. Before proceeding, can anyone tell me what percentage of the time is spent doing the various steps: forward FFT, point-wise squaring, inverse FFT, carry propagation (which includes applying weights and converting to and from integer).

I can describe the ideas to anyone who wants to run with it, or else you'll have to wait for me to install an nVidia environment and learning how to use it.

Here's a break-down of what various kernel runtimes are on my GPU (sorted by most expensive):

Environment: GTX 460, Cuda3.2, driver 295.20, x86_64

testPrime 216091, signalSize 12288 (profiled approx 5000 iterations)
Kernel                      % of Total GPU Time
CUFFT (Both directions)        77.08%
llintToIrrBal<3>                8.91%
loadIntToDoubleIBDWT            5.44%
invDWTproductMinus2             4.92%
ComplexPointwiseSqr             3.65%


testPrime 26199377, signalSize 1474560, (profiled approx 9000 iterations)
CUFFT (Both directions)        70.79%
llintToIrrBal<3>                8.53%
loadIntToDoubleIBDWT            7.77%
invDWTproductMinus2             7.71%
ComplexPointwiseSqr             5.20%

(Grouped under CUFFT are multiple sub-kernel launches within the CUFFT library, depending on how it breaks down the transform)

I haven't really looked much at optimising the kernels themselves, yet, but am definitely open to ideas.

All of the kernels are memory-bound, and the little amount of work done in each of the three small kernels (loadIntToDoubleIBDWT, invDWTproductMinus2, and ComplexPointwiseSqr) bothers me: there is likely too much overhead lost to launching the kernels, compared to the amount of work done.

[odin]

Hi, I would like to try this against my GTX295. I'm running Windows 7 64 bit.
Can someone please post a compiled version of this program for my platform.
Please also include what version of CUDA I have to install to run it.

Thanks.

[Prime95]

Originally Posted by aaronhaviland

All of the kernels are memory-bound, and the little amount of work done in each of the three small kernels (loadIntToDoubleIBDWT, invDWTproductMinus2, and ComplexPointwiseSqr) bothers me: there is likely too much overhead lost to launching the kernels, compared to the amount of work done.

Thanks. I doubt anything can be done to speed up point-wise squaring. I think we can greatly reduce the memory costs of the carry code which is taking 24% of the time. I think cutting that in half is a reasonable goal.

[aaronhaviland]

Originally Posted by aaronhaviland

I'm a little concerned about the residue mismatch I just got on M(26171441), but since I had restarted it several times, and changed a few things, including the checkpoint format itself, it was most likely my fault. I'm re-starting the test... it's using an FFT length with a high round-off error (around 0.37) so I can test out what an acceptable round-off error should be with this method. (So far, residues are matching CUDALucas through around 250,000 iterations.)

Finally... got a match. Tagged this code in git as v0.9.3:

M( 26171441 )C, 0x449e471e42bfe489, n = 1474560, gpuLucas v0.9.3

Estimated run-time was over-enthusiastic. Run-time was about even with CUDALucas. The estimate calculation has been adjusted slightly to compensate.

As I mentioned, the kernels are *very* memory throughput bound, but I believe I may have already found a few methods to ease some of this strain... need to do more tests.

[GhettoChild]

so I'm wondering where do I get gpuLucas to test it out? Here? https://github.com/Almajester/gpuLucas ? I'm currently using multiple instances of CUDALucas v2.05Beta on both gpus of a GTX 295. I'm able to run a single instance of MFaktC v0.20 simultaneously but that's all, just 3 instances of all these apps together max. I'm looking to try out gpuLucas and compare its performance with CL but is there a version I can download and test without having to compile it myself? I've never used this makefile compiling stuff before and really not confident in how to use it properly, I'm a windows user.