Fast Mersenne Testing on the GPU using CUDA

[axn]

Originally Posted by Oddball

Speaking of that post, here's a quick summary of the arguments for both sides:

That post describes the technical complexities of developing a suitable FFT for LLR. It doesn't deal with any "sides".

Originally Posted by Oddball

Pro-LLR GPU side:
1.) Allows people with GPUs freedom of choice. If an GPU program for LLR is developed, those with GPUs can choose to either sieve or test for primes.
2.) Allows for faster verification of large (>1 million digit) primes.
3.) GPU clients are not optimized yet, so there's more potential for improvement.
4.) GPUs are more energy efficient than old CPUs (Pentium 4's, Athlons, etc), judging by the amount of electricity needed to LLR one k/n pair.

Anti-LLR GPU side:
1.) Reduces the number of participants. Those without fast CPUs would be discouraged from participating since they would no longer be able to do a significant amount of "meaningful" LLR work (defined as LLR work that has a reasonable chance of getting into the top 5000 list).
2.) GPUs are much less effective at primality testing than at sieving or trial factoring. Computing systems should be used for what they are best at, so CPU users should stick to LLR tests and GPU users should stick to sieving and factoring.
3.) GPUs have a high power consumption (~400 watts for a GPU system vs. ~150 watts for a CPU system). Even when comparing power needed per primality test, they are less efficient than core i7's and other recent CPUs.
4.) GPUs have a higher error rate than CPUs. It's much easier to check factors than it is to check LLR residues, so GPUs should stay with doing trial division.

Aside from you, I haven't actually seen any arguments advanced by any persons for not developing a primality testing program for GPU. One person hardly makes a "side". The arguments against a GPU-based LLR reads like a what's-what of fallacy files.

[CRGreathouse]

Originally Posted by Oddball

3.) GPUs have a high power consumption (~400 watts for a GPU system vs. ~150 watts for a CPU system). Even when comparing power needed per primality test, they are less efficient than core i7's and other recent CPUs.
4.) GPUs have a higher error rate than CPUs. It's much easier to check factors than it is to check LLR residues, so GPUs should stay with doing trial division.

Do we have numbers on those?

[Oddball]

3.) GPUs have a high power consumption (~400 watts for a GPU system vs. ~150 watts for a CPU system). Even when comparing power needed per primality test, they are less efficient than core i7's and other recent CPUs.
4.) GPUs have a higher error rate than CPUs. It's much easier to check factors than it is to check LLR residues, so GPUs should stay with doing trial division.

Originally Posted by CRGreathouse

Do we have numbers on those?

There's this:
http://www.mersenneforum.org/showpos...&postcount=152
"487W for GTX 295 under full load!"

The Phenom II system I have right now draws ~150 watts at full load.

The reference for claim #4 is here:
http://mersenneforum.org/showpost.ph...&postcount=379

"Consumer video cards are designed for gaming rather than technical computing, so they don't have as many error-checking features."
There's not enough data to provide more accurate figures.

[Oddball]

Originally Posted by axn

That post describes the technical complexities of developing a suitable FFT for LLR. It doesn't deal with any "sides".

In that post, the quote that Prime95 posted was referring to The Carnivore, who was describing the impatience of the pro-GPU side. I wasn't the first person who made the claim of different sides.

Aside from you, I haven't actually seen any arguments advanced by any persons for not developing a primality testing program for GPU. One person hardly makes a "side".

Here's another person with an anti-GPU point of view:
http://mersenneforum.org/showpost.ph...&postcount=327

Here's what George has to say:
http://mersenneforum.org/showpost.ph...&postcount=339

"if msft develops a CUDA LLR program then it will be modestly more powerful (in terms of throughput) than an i7 -- just like LL testing.
From a project admin's point of view, he'd rather GPUs did sieving than primality testing as it seems a GPU will greatly exceed (as opposed to modestly exceed) the thoughput of an i7."

But I'm done debating this issue; it's been beaten to death, and none of the users involved are going to change their minds.

[mdettweiler]

Originally Posted by Oddball

"if msft develops a CUDA LLR program then it will be modestly more powerful (in terms of throughput) than an i7 -- just like LL testing.
From a project admin's point of view, he'd rather GPUs did sieving than primality testing as it seems a GPU will greatly exceed (as opposed to modestly exceed) the thoughput of an i7."

The way I see it (from the perspective of a project admin) I figure it's nice to at least have the ability to do both. As a case in point to why this would be of importance, currently NPLB and PrimeGrid are collaborating on a large (covering all k<10000) GPU sieving drive. What with the combined GPU resources of our two projects, we blew through the n<2M range in no time at all--and the 2M-3M range itself is itself moving very rapidly. Yet the primary leading edges of both projects' LLR testing are below n=1M. We won't get to some of this stuff for years, after which GPUs will likely be so much advanced that much of the work done now will be a drop in the bucket compared to the optimal depth relative to the GPUs of then.

Right now, the only work available from k*2^n+-1 prime search projects for GPUs is sieving. Thus, in order to keep the GPUs busy at all, we have to keep sieving farther and farther up in terms of n, which becomes increasingly suboptimal the further we depart from our LLR leading edge. If we had the option of putting those GPUs to work on LLR once everything needed in the forseeable future has been well-sieved, even if it's not quite the GPUs' forte, we could at least be using them for something that's needed, rather than effectively throwing away sieving work that can be done much more efficiently down the road.

Anyway, that's my $0.02...not trying to beat this to death on this end either.

[MooMoo2]

Originally Posted by mdettweiler

The way I see it (from the perspective of a project admin) I figure it's nice to at least have the ability to do both. As a case in point to why this would be of importance, currently NPLB and PrimeGrid are collaborating on a large (covering all k<10000) GPU sieving drive. What with the combined GPU resources of our two projects, we blew through the n<2M range in no time at all--and the 2M-3M range itself is itself moving very rapidly. Yet the primary leading edges of both projects' LLR testing are below n=1M. We won't get to some of this stuff for years, after which GPUs will likely be so much advanced that much of the work done now will be a drop in the bucket compared to the optimal depth relative to the GPUs of then.

Right now, the only work available from k*2^n+-1 prime search projects for GPUs is sieving. Thus, in order to keep the GPUs busy at all, we have to keep sieving farther and farther up in terms of n, which becomes increasingly suboptimal the further we depart from our LLR leading edge. If we had the option of putting those GPUs to work on LLR once everything needed in the forseeable future has been well-sieved, even if it's not quite the GPUs' forte, we could at least be using them for something that's needed, rather than effectively throwing away sieving work that can be done much more efficiently down the road.

You can direct the GPUs to the TPS forum if they're out of work

[mdettweiler]

Originally Posted by MooMoo2

You can direct the GPUs to the TPS forum if they're out of work

Indeed, that is an option. However, speaking solely from the perspective of a project admin (that is, trying to maximize the utilization of resources within my own project), it would seem worthwhile to have GPU LLR as an option--so that if (say) you have a participant who wants to contribute with his GPU at NPLB but is not particularly interested in TPS, he can still have useful work to do. (Or vice versa.)

[CRGreathouse]

Originally Posted by Oddball

There's this:
http://www.mersenneforum.org/showpos...&postcount=152
"487W for GTX 295 under full load!"

The Phenom II system I have right now draws ~150 watts at full load.

I'm seeing 181 watts for the i7 under load. So for your claim "Even when comparing power needed per primality test, they are less efficient than core i7's and other recent CPUs" to hold, the GTX 295 needs to be less than 2.7 times faster than the i7 -- or 10.8 times faster than a single (physical) core. Is that so?

[Oddball]

Originally Posted by CRGreathouse

I'm seeing 181 watts for the i7 under load. So for your claim "Even when comparing power needed per primality test, they are less efficient than core i7's and other recent CPUs" to hold, the GTX 295 needs to be less than 2.7 times faster than the i7 -- or 10.8 times faster than a single (physical) core. Is that so?

Yes. See: http://mersenneforum.org/showpost.ph...&postcount=293

"in a worst-case (for the GPU) scenario, you still need all cores of your i7 working together to match its output! In a best-case scenario, it's closer to twice as fast as your CPU."

[henryzz]

Please remember that your i7 cpu can be running as well as the GPU app on most cores without much more power comsumption.

[Prime95]

Originally Posted by Oddball

From a project admin's point of view, he'd rather GPUs did sieving than primality testing as it seems a GPU will greatly exceed (as opposed to modestly exceed) the thoughput of an i7."

This argument holds less water with this new CUDA program. As expected, IBDWT has halved the iteration times.

A different conclusion is also possible: Perhaps prime95's TF code is in need of optimization.