mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Hardware > GPU Computing

Reply
 
Thread Tools
Old 2010-09-20, 07:15   #320
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

3·2,083 Posts
Default

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!
mdettweiler is offline   Reply With Quote
Old 2010-09-20, 07:52   #321
msft
 
msft's Avatar
 
Jul 2009
Tokyo

2·5·61 Posts
Default

Thank you mdettweiler,
this news is good news
msft is offline   Reply With Quote
Old 2010-09-23, 00:08   #322
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

3×2,083 Posts
Default

And another one:
M24560839
mdettweiler is offline   Reply With Quote
Old 2010-09-23, 02:27   #323
frmky
 
frmky's Avatar
 
Jul 2003
So Cal

3·5·132 Posts
Default

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.
frmky is online now   Reply With Quote
Old 2010-09-23, 02:46   #324
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

3×2,083 Posts
Default

Quote:
Originally Posted by frmky View Post
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 u0 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).
mdettweiler is offline   Reply With Quote
Old 2010-09-23, 05:44   #325
The Carnivore
 
The Carnivore's Avatar
 
Jun 2010

3×5×17 Posts
Default

Quote:
Originally Posted by MooMoo2 View Post
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.
The Carnivore is offline   Reply With Quote
Old 2010-09-23, 05:56   #326
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

3×2,083 Posts
Default

Quote:
Originally Posted by The Carnivore View Post
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.
mdettweiler is offline   Reply With Quote
Old 2010-09-23, 06:39   #327
Historian
 
Historian's Avatar
 
Mar 2010

4310 Posts
Default

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
Historian is offline   Reply With Quote
Old 2010-09-23, 06:49   #328
frmky
 
frmky's Avatar
 
Jul 2003
So Cal

3·5·132 Posts
Default

Quote:
Originally Posted by Historian View Post
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!
frmky is online now   Reply With Quote
Old 2010-09-23, 07:18   #329
Historian
 
Historian's Avatar
 
Mar 2010

43 Posts
Default

Quote:
Originally Posted by frmky View Post
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.

Last fiddled with by Historian on 2010-09-23 at 07:18
Historian is offline   Reply With Quote
Old 2010-09-23, 07:27   #330
Historian
 
Historian's Avatar
 
Mar 2010

538 Posts
Default

Quote:
Originally Posted by Historian View Post
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.
Historian is offline   Reply With Quote
Reply

Thread Tools


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

All times are UTC. The time now is 22:09.


Fri Dec 9 22:09:49 UTC 2022 up 113 days, 19:38, 0 users, load averages: 1.13, 0.98, 0.96

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.

≠ ± ∓ ÷ × · − √ ‰ ⊗ ⊕ ⊖ ⊘ ⊙ ≤ ≥ ≦ ≧ ≨ ≩ ≺ ≻ ≼ ≽ ⊏ ⊐ ⊑ ⊒ ² ³ °
∠ ∟ ° ≅ ~ ‖ ⟂ ⫛
≡ ≜ ≈ ∝ ∞ ≪ ≫ ⌊⌋ ⌈⌉ ∘ ∏ ∐ ∑ ∧ ∨ ∩ ∪ ⨀ ⊕ ⊗ 𝖕 𝖖 𝖗 ⊲ ⊳
∅ ∖ ∁ ↦ ↣ ∩ ∪ ⊆ ⊂ ⊄ ⊊ ⊇ ⊃ ⊅ ⊋ ⊖ ∈ ∉ ∋ ∌ ℕ ℤ ℚ ℝ ℂ ℵ ℶ ℷ ℸ 𝓟
¬ ∨ ∧ ⊕ → ← ⇒ ⇐ ⇔ ∀ ∃ ∄ ∴ ∵ ⊤ ⊥ ⊢ ⊨ ⫤ ⊣ … ⋯ ⋮ ⋰ ⋱
∫ ∬ ∭ ∮ ∯ ∰ ∇ ∆ δ ∂ ℱ ℒ ℓ
𝛢𝛼 𝛣𝛽 𝛤𝛾 𝛥𝛿 𝛦𝜀𝜖 𝛧𝜁 𝛨𝜂 𝛩𝜃𝜗 𝛪𝜄 𝛫𝜅 𝛬𝜆 𝛭𝜇 𝛮𝜈 𝛯𝜉 𝛰𝜊 𝛱𝜋 𝛲𝜌 𝛴𝜎𝜍 𝛵𝜏 𝛶𝜐 𝛷𝜙𝜑 𝛸𝜒 𝛹𝜓 𝛺𝜔