GPU LL Testing FAQ

[LaurV]

Originally Posted by Dubslow

For me at least, I can (almost) max out a my one GPU (460) with one of my four CPU cores, so mfaktc/TF makes more sense. I think it varies more with hardware setup than with actual stats and total throughput etc.. (Do you type a .. ?)

Note to flash: For reference, PrimeNet reports expected 5 days for 25M, and 19 days for 45M.

I won't exactly call 460 a "Fermi", it contains the first version of GF100 chip, for which the double multiply took 4 times a single multiply operation. For that, TF is more profitable. On a "real" Fermi (5x0, tesla, GF101 chip, quadro, newer stuff with double precision inside), TF become "just a bit" faster (due to clock increase), but CudaLucas become MUCH faster.

At DC front, anyhow, it makes no sense to TF anything behind 68-69 bits, regardless of what GPU you have. Look at GPU-2-72 status, people found a DC-factor every 1.5-2.2 days, in average, and "lowlevel" bits (65-68 bits) are "end of life". For 69-70-etc bits, it will take even more time per factor. So, why should I (here "I" means "any owner of a Fermi GPU card") waste a double-time to TF at DC front, when I can directly LL-DC them? (that is LL at DC front). And get rid of one exponent EVERY day. And a bit more, having a CPU core free for P95 DC or P-1, or whatever.

At LL front the things are different, because a factor found by TF (every 3-5 days, with an average GPU, as it seems now, or say, every 2-3 days with a high-end GPU) will save TWO tests (LL's) AND some P-1 testing on CPU. That is, every factor found would save about 10 days of LL work with the BEST GPU around, or two months of work with the best CPU around (one core). As long as we are still finding factors faster (more often then 10 days per factor) by TF, we should "raise" the bit level and do TF on GPUs.

But we should do LL tests with CudaLucas for all "optimum FFT lengths", regardless if they are on LL-front or DC-front. People don't really get it how CudaLucas works, and why the time per test is almost constant for a very long range of exponents, then it is instantly doubling for the next exponent. CL is using FFT which is powers of 2 in length, contrary to P95 which has a finer "granulation" of FFT. To put it in a graphic, it would look like the attached picture. That is, CL is "not optimum" in the purple areas, it could use a smaller FFT and get the test done faster. Unfortunately we are now with the LL-front exactly on such a "purple" area.
(I did not put any numbers on graphic, in fact I deleted the numbers, this is done on purpose, as the numbers will vary depending on hardware).

The times on P95 are also in stairs, but with a better granulation, as P95 "adapts" the FFT size to the exponent size much better then CL does. But CL multiply them in parallel, getting a better time per iteration, and P95 not. For the same FFT size, the time per iteration is the same (theoretical), regardless of the exponent. The total time increases a little with the exponent increasing, because more iterations will be necessary for a bigger exponent. That is why the stairs are not horizontal. They become "optimum" at their "ends" (marked green on the CL graphic), both for P95 and CL.

[Dubslow]

Originally Posted by LaurV

At DC front, anyhow, it makes no sense to TF anything behind 68-69 bits, regardless of what GPU you have.

I agree here.


My only point is that is makes more sense for me to run mfaktc than CUDALucas, regardless of what assignments people are doing or should be doing etc. I can get (almost) full GPU utilization with only one of four cores with mfaktc. Therefore I run mfaktc. This decision has nothing to do with GIMPS/PrimeNet assignments/status.

[Brain]

Originally Posted by LaurV

People don't really get it how CudaLucas works, and why the time per test is almost constant for a very long range of exponents, then it is instantly doubling for the next exponent. CL is using FFT which is powers of 2 in length, contrary to P95 which has a finer "granulation" of FFT.

This does not apply for CUDALucas >= 1.4 any more. msft implemented non-power-of-2-FFTs. But this version is a only aged a few days and being tested.

[Dubslow]

Originally Posted by Brain

Hi,
here an updated version of the GPU Computing Guide.

Changes:
- New versions of mfaktc, mfakto and CUDALucas. Links to all binaries...
- Missing CUDA 3.2/4.0 libs for CUDALucas can be downloaded, see page 2

Please check for major bugs. If valid maybe an admin could update the stickies...

Happy new year, Brain

The most recent mfakto readme says something to the effect of "With 11.07+ in Win, you do not need the SDK. Same for 11.11+ in Linux." I would double check to be sure though.

What about CUDALucas 1.3? Is that of use?

Also, I would consider removing "MOST NEEDED GIMPS WORK TYPE" from CUDALucas. Because all TF <60M has been moved to GPU only, one could make a decent argument that we're short on TF. GPU272 is barely keeping up with the 45M-55M work, much less the current wavefront. (Obviously what I say is not final, but I think it's worth consideration.)

Suggestion: Move the link for LESS_CLASSES mfaktc to the remarks section, next to where you talk about efficiency. (Maybe specifically mention LMH?)

[f11ksx]

CudaLucas v1.41 is running pretty well !
9.3 ms/iter for 54M exponent on GTX-580 card.

Thanks a lot.

[Brain]

Originally Posted by f11ksx

CudaLucas v1.41 is running pretty well !
9.3 ms/iter for 54M exponent on GTX-580 card.

Thanks a lot.

Maybe you could/should join the discussion in the CUDALucas thread. Could you test and reply there that CUDALucas >=1.4 now uses CPU resources if -c flag is set?

Originally Posted by Dubslow

What about CUDALucas 1.3? Is that of use?

There are two 1.3 versions: One by Ethan (EO) which is older (a tuned 1.2b) but laggy for me and another 1.3 version by msft which has additional timing output. As there is a 1.4 (by msft) I'd like to skip 1.3 for confusion reasons...

[Brain]

Changes:
- CUDALucas 1.4.2
- mfakto requirements

GIMPS GPU Computing Cheat Sheet (pdf)

[Brain]

Changes:
- CUDALucas 1.48
- mfaktc for CUDA 4.1

Now, we should really update the sticky post #1 attachments. Otherwise, I'd prefer no such file to having outdated files...

GIMPS GPU Computing Cheat Sheet (pdf)

[ET_]

Originally Posted by Brain

Changes:
- CUDALucas 1.48
- mfaktc for CUDA 4.1

Now, we should really update the sticky post #1 attachments. Otherwise, I'd prefer no such file to having outdated files...

Thank you Brain.

I was wodering if the "Restrictions" on FFT size (CUDALucas 1.48) still hold, as it now supports non power of 2 FFt sizes.

Another question to the forum readers: when you say "Compilable with CUDA Toolkit 3.1" do you mean "the source code compiles, but won't work with CUDA Toolkit < 3.1"?

Luigi

[Brain]

Originally Posted by ET_

Thank you Brain.

I was wodering if the "Restrictions" on FFT size (CUDALucas 1.48) still hold, as it now supports non power of 2 FFt sizes.

I have no reliable values as I never tested 8M FFTs and above. My GTX 560 Ti 1GB will probably be memory limited. Understand the FFT borders as guidelines, I took them from one of msft's posts.

Originally Posted by ET_

Another question to the forum readers: when you say "Compilable with CUDA Toolkit 3.1" do you mean "the source code compiles, but won't work with CUDA Toolkit < 3.1"?

Luigi

Oh, it was just my reaction to today's msft response to CUDA-Compatibility-Mode which works only in CUDA 3.1.
I only compiled it for CUDA 4.0 and 4.1.

[ET_]

Originally Posted by Brain

I have no reliable values as I never tested 8M FFTs and above. My GTX 560 Ti 1GB will probably be memory limited. Understand the FFT borders as guidelines, I took them from one of msft's posts.


Oh, it was just my reaction to today's msft response to CUDA-Compatibility-Mode which works only in CUDA 3.1.
I only compiled it for CUDA 4.0 and 4.1.

Shoichiro just answered my question. CUDALucas v1.48 is worthless with my CUDA Toolkit 3.0 and CC 1.3, so I will stick on v1.3 for now.

Luigi