CUDALucas (a.k.a. MaclucasFFTW/CUDA 2.3/CUFFTW) - Page 30

mdettweiler · 2010-09-20, 07:15

The first result is in from Gary's GTX 460:
M25652651
Amazing--a test that would have taken upward of 10 days on one core of a fast CPU took only a little over 2 days!

msft · 2010-09-20, 07:52

Thank you mdettweiler,
this news is good news

mdettweiler · 2010-09-23, 00:08

And another one:
M24560839

frmky · 2010-09-23, 02:27

Since it's limited to only power-of-2 FFTs, doing double checks around 35-36.5M is the most efficient. Just be sure it doesn't switch over to the 4M FFT.

mdettweiler · 2010-09-23, 02:46

Quote:

Originally Posted by frmky

Since it's limited to only power-of-2 FFTs, doing double checks around 35-36.5M is the most efficient. Just be sure it doesn't switch over to the 4M FFT.

I'll keep that in mind--thanks.

Meanwhile, now that I've got MacLucasFFTW set up on this GPU and have confirmed that it's working right, I am available to help test an version of MacLucasFFTW modified to perform LLR tests. Can any of the CUDA gurus out there take a guess at what exactly would be involved in making such a modification? (I tried re-hardcoding the u₀ value manually for a specific LLR test and feeding MacLucasFFTW the number's exponent, but it didn't work--the number is a known prime and it came up composite. I suppose this isn't exactly surprising, since I'm surely oversimplifying the matter by a long shot.)

Alternatively, as Ken_g6 suggested a number of posts back, it might possibly be easier to just make a new program from scratch based on the FFTW-CUDA library that performs Fermat PRP tests. Again, I admit I'm entirely clueless as to how much work would be involved in this. But if it could be done, the result would be even more useful than a CUDA LLR program, since it could be used for any k*b^n+c (as opposed to an LLR test which only works for k*2^n-1).

The Carnivore · 2010-09-23, 05:44

Quote:

Originally Posted by MooMoo2

Enough with the exaggerations on both sides (pro GPU and anti GPU).

I'm neutral on this issue, but will the pro-GPU side learn to show some patience? The issue has been beaten to death already. Yes, we know that some of you want GPUs for k*2^n+/-1 numbers, so quit repeating it every few weeks.

Request:
http://www.mersenneforum.org/showpos...&postcount=177

Quote:

Your efforts in developing this LL application are greatly appreciated, and even more so if you can help in porting it to LLR!

Repetition 1:
http://www.mersenneforum.org/showpos...&postcount=208

Quote:

would you by chance be willing to port this application to the LLR algorithm

Repetition 2:
http://www.mersenneforum.org/showpos...&postcount=274

Quote:

Any progress on this?

Repetition 3:
http://www.mersenneforum.org/showpos...&postcount=324

Quote:

I am available to help test an version of MacLucasFFTW modified to perform LLR tests. Can any of the CUDA gurus out there take a guess at what exactly would be involved in making such a modification?

Bugging doesn't pay off, but patience does. Learn to get some of it.

mdettweiler · 2010-09-23, 05:56

Quote:

Originally Posted by The Carnivore

I'm neutral on this issue, but will the pro-GPU side learn to show some patience? The issue has been beaten to death already. Yes, we know that some of you want GPUs for k*2^n+/-1 numbers, so quit repeating it every few weeks.

Request:
http://www.mersenneforum.org/showpos...&postcount=177

Repetition 1:
http://www.mersenneforum.org/showpos...&postcount=208

Repetition 2:
http://www.mersenneforum.org/showpos...&postcount=274

Repetition 3:
http://www.mersenneforum.org/showpos...&postcount=324

Bugging doesn't pay off, but patience does. Learn to get some of it.

Hey, keep it cool man...my most recent post was mainly to let people know that now I actually have a GPU with which to help test this stuff. It does change the situation a bit and thus it seemed to warrant a new post.

Historian · 2010-09-23, 06:39

The development of GPU clients for LLR is a terrible idea. It's like the Prisoner's Dilemma:

http://en.wikipedia.org/wiki/Prisoner%27s_dilemma

Let's say there are two groups of people - those with good GPUs, and those without one. Let's call them Group A and Group B.

At first, there's no GPU LLR client. Group A has 2500 primes on the top 5000 list, and Group B has 2500.

One day, a GPU LLR client is released. Group A seizes the opportunity to grab a lead in the top 5000 list, and they put all of their GPUs to work. Group B sees that their primes are quickly beginning to get wiped off the top 5000 list, so they buy GPUs and run them to prevent this from happening.

So now we're back to square one, and both groups each have 2500 primes on the top 5000 list, like before. But they are now worse off. Members of group B each have to spend hundreds of dollars to get good GPUs, and the power consumption of both groups have more than tripled. None of the crunchers are happy after seeing their electric bill go up, and they'll have to live with that each month until they retire from prime-finding DC projects.

If that ever happens, the person we'll have to blame for that mess will be msft.

frmky · 2010-09-23, 06:49

Quote:

Originally Posted by Historian

The development of GPU clients for LLR is a terrible idea. It's like the Prisoner's Dilemma:

And this is why GIMPS should be restricted to 90 MHz Pentiums only. P90 years forever!

Historian · 2010-09-23, 07:18

Quote:

Originally Posted by frmky

And this is why GIMPS should be restricted to 90 MHz Pentiums only. P90 years forever!

The transition from Pentiums to Core i7's was gradual and didn't have huge sudden jumps in power consumption.

On the other hand, a possible transition from CPUs to GPUs will be very abrupt and have huge sudden jumps in power consumption.

Historian · 2010-09-23, 07:27

Quote:

Originally Posted by Historian

The development of GPU clients for LLR is a terrible idea. It's like the Prisoner's Dilemma:

http://en.wikipedia.org/wiki/Prisoner%27s_dilemma

The Prisoner's Dilemma analogy actually works better than I originally thought. From the occasionally reliable wikipedia:

Quote:

The prisoner's dilemma applies to the decision whether or not to use performance enhancing drugs in athletics. Given that the drugs have an approximately equal impact on each athlete, it is to all athletes' advantage that no athlete take the drugs (because of the side effects). However, if any one athlete takes the drugs, they will gain an advantage unless all the other athletes do the same. In that case, the advantage of taking the drugs is removed, but the disadvantages (side effects) remain

Now replace "athletics" with "prime searching projects", "athlete" with "cruncher", "drugs" with "GPUs", and "side effects" with "higher costs":

Quote:

The prisoner's dilemma applies to the decision whether or not to use GPUs in prime searching projects. Given that GPUs have an approximately equal impact on each cruncher, it is to all crunchers' advantage that no cruncher buys the GPUs (because of the higher costs). However, if any one cruncher buys the GPUs, they will gain an advantage unless all the other crunchers do the same. In that case, the advantage of buying the GPUs is removed, but the disadvantages (higher costs) remain

That matches almost exactly what I was describing in an earlier post.

2010-09-23, 06:39	#327
Historian Mar 2010 43 Posts	The development of GPU clients for LLR is a terrible idea. It's like the Prisoner's Dilemma: http://en.wikipedia.org/wiki/Prisoner%27s_dilemma Let's say there are two groups of people - those with good GPUs, and those without one. Let's call them Group A and Group B. At first, there's no GPU LLR client. Group A has 2500 primes on the top 5000 list, and Group B has 2500. One day, a GPU LLR client is released. Group A seizes the opportunity to grab a lead in the top 5000 list, and they put all of their GPUs to work. Group B sees that their primes are quickly beginning to get wiped off the top 5000 list, so they buy GPUs and run them to prevent this from happening. So now we're back to square one, and both groups each have 2500 primes on the top 5000 list, like before. But they are now worse off. Members of group B each have to spend hundreds of dollars to get good GPUs, and the power consumption of both groups have more than tripled. None of the crunchers are happy after seeing their electric bill go up, and they'll have to live with that each month until they retire from prime-finding DC projects. If that ever happens, the person we'll have to blame for that mess will be msft. Last fiddled with by Historian on 2010-09-23 at 06:43

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Don't DC/LL them with CudaLucas	LaurV	Data	131	2017-05-02 18:41
CUDALucas / cuFFT Performance on CUDA 7 / 7.5 / 8	Brain	GPU Computing	13	2016-02-19 15:53
CUDALucas: which binary to use?	Karl M Johnson	GPU Computing	15	2015-10-13 04:44
settings for cudaLucas	fairsky	GPU Computing	11	2013-11-03 02:08
Trying to run CUDALucas on Windows 8 CP	Rodrigo	GPU Computing	12	2012-03-07 23:20

2010-09-20, 07:15	#320
mdettweiler A Sunny Moo Aug 2007 USA 6298₁₀ Posts	The first result is in from Gary's GTX 460: M25652651 Amazing--a test that would have taken upward of 10 days on one core of a fast CPU took only a little over 2 days!

2010-09-20, 07:52	#321
msft Jul 2009 Tokyo 1001100010₂ Posts	Thank you mdettweiler, this news is good news

2010-09-23, 00:08	#322
mdettweiler A Sunny Moo Aug 2007 USA 2·47·67 Posts	And another one: M24560839

2010-09-23, 02:27	#323
frmky Jul 2003 So Cal 2,663 Posts	Since it's limited to only power-of-2 FFTs, doing double checks around 35-36.5M is the most efficient. Just be sure it doesn't switch over to the 4M FFT.