mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > PrimeNet > GPU to 72

Closed Thread
 
Thread Tools
Old 2020-04-05, 11:23   #166
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
Jun 2011
Thailand

205448 Posts
Default

Quote:
Originally Posted by KEP View Post
Now let me see if I understand it correctly. As I read you, we should prioritiez 76-77 then 75-77, then 74-77 and if any remain 73-77 bit, before doing 78 bit on candidates already P-1 tested.
That what Chris says , as he likes to have his constant feed for the LL-ers/PRP-ers. I didn't say anything about 73-77, or 74-77, etc. My argument is solely on the side that the "last bit" should always be done ONLY after we do some P-1. With a "good" card, you can go to 5%, but even with a "not so good" card, at least a 3% P-1 should be done before doing the last bit (I mean, not necessarily by the same card, let other people do it, who have the hardware and like to do P-1).

Also, I am talking solely on the line of GPUs I went over time: gtx580, Titan (classic and black), 1080Ti, 2080Ti. These all cards were always the "good" side (i.e. good FP64 ratio) .

Quote:
I'm not sure how you have investigated this, but as soon as we go above n=120M, optimum bit will be 79 bit and around 153M it will increase to 80 bit. Is it your interpretation, that the rule of thumb, is for most if not all n as follows:

TF(Optimum bit)-1,P-1 factoring,TF(Optimum bit)?
Exactly.

Quote:
Does anyone know what the daily need to keep the P-1 factorers satisfied is? In other words, how many tests does the P-1 users complete tests each day?
Here somebody else has to answer.

Last fiddled with by LaurV on 2020-04-05 at 11:27
LaurV is offline  
Old 2020-04-05, 14:06   #167
chalsall
If I May
 
chalsall's Avatar
 
"Chris Halsall"
Sep 2002
Barbados

2×3×1,499 Posts
Default

Quote:
Originally Posted by LaurV View Post
My argument is solely on the side that the "last bit" should always be done ONLY after we do some P-1.
As always, it's a little complicated. Basically, what we're dealing with here is a disparate resource management problem.

Thanks to James' analysis, we know that for the more modern cards it is "optimal" to TF to 78 bits before running the FC ***on the same card***. Older cards shouldn't go as high.

But this assumes each and every deployed card will switch between the work types (TF'ing vs. FC'ing) when appropriate. In reality, this doesn't happen, so instead, different people will choose different depths to "pledge" to. And some just like TF'ing, so don't really care if they TF past the optimal for their particular card(s). And, since BOINC isn't issuing FC work, this economic cross-over analysis doesn't really apply.

Now, with regards to P-1'ing, again it comes down to resource availability. Because George sets the B1/B2 bounds as a function of the TF'ed depth, it takes /slightly/ less time (with an associated slightly less probability of finding a factor during the run) the higher a candidate has been TF'ed.

And, of course, whichever work type does the next step (TF a bit, or P-1) and finds a factor helps the other work-type workers, since further work is no longer needed.

With regards to how many P-1 jobs are done per day, that varies widely. R. Propper can do hundreds a day -- I have no idea what his long-term plans are.
chalsall is online now  
Old 2020-04-05, 15:02   #168
axn
 
axn's Avatar
 
Jun 2003

3·1,531 Posts
Default

Quote:
Originally Posted by chalsall View Post
Thanks to James' analysis, we know that for the more modern cards it is "optimal" to TF to 78 bits before running the FC ***on the same card***.
This is a misconception. The correct way to read that chart is: "It is "optimal" to TF to 78 bits before running two LL (FC & DC) on the same card"

IOW, if your intent is to speed up /only/ the FC (in order to accelerate the next prime find), then you should do 77 bits.
axn is offline  
Old 2020-04-05, 15:32   #169
chalsall
If I May
 
chalsall's Avatar
 
"Chris Halsall"
Sep 2002
Barbados

2·3·1,499 Posts
Default

Quote:
Originally Posted by axn View Post
IOW, if your intent is to speed up /only/ the FC (in order to accelerate the next prime find), then you should do 77 bits.
Absolutely true.

But, as we all know, James' analysis is an absolute ideal optimization of resources. That simply isn't possible at GIMPS, because of the huge disparity in the completely autonomous (and volunteer) participants.

Short of an omniscient and omnipotent entity stepping forward to manage /all/ the resources, we do the best we can as the simple humans we are.

Further, the opposite argument to yours can be made. If we have TF'ing resources that aren't going to be redirected to FC'ing, should they optimally TF the ranges years ahead of the wavefronts? Or should they instead TF past the optional only a few months ahead?

I would argue the latter, where people are willing.
chalsall is online now  
Old 2020-04-05, 15:52   #170
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
Jun 2011
Thailand

22×2,137 Posts
Default

Everything nice with what you and axn say, except that you point that link to a T4, which is not a "good" card in my definition - it spits out a lot of TF indeed, but it is very weak at FP64. That is more like a "gaming" card, and it should be used mostly for TF. So, you could be right, but - and here is the but: nobody have such card, and nobody uses one, except Colab, and even that, only seldom (for lucky guys ). How many users play with a T4? Guys who can afford Teslas, won't spoil them at TF. The comparisons should be done for 10xx, 16xx, and 20xx cards as most people play those.

Last fiddled with by LaurV on 2020-04-05 at 16:07
LaurV is offline  
Old 2020-04-05, 16:12   #171
chalsall
If I May
 
chalsall's Avatar
 
"Chris Halsall"
Sep 2002
Barbados

899410 Posts
Default

Quote:
Originally Posted by LaurV View Post
How many users play with T4? Guys who can afford Teslas, won't spoil them at TF. The comparisons should be done for 10xx, 16xx, and 20xx cards as most people play those.
I'm running three T4s right now...

But, OK... If you want to get into the analysis paralysis domain... It comes down to how many cards of the various Compute Versions are working at what. A Telsa P100 (CV 6.0) should only go to 76, while a GeForce GTX 1080 (CV 6.1) should go to 77, for example.

Would you like to take on the task of providing us with an inventory of the currently deployed kit?
chalsall is online now  
Old 2020-04-05, 16:30   #172
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

684310 Posts
Default

Quote:
Originally Posted by chalsall View Post
Thanks to James' analysis, we know that for the more modern cards it is "optimal" to TF to 78 bits before running the FC ***on the same card***. Older cards shouldn't go as high.
And even this is more complicated. James' chart assumes no P-1. Since P-1 will find some of the factors between 2^77 and 2^78, TF'ing from 2^77 to 2^78 is not as profitable as James' chart indicates. In other words, don't switch to 2^78 TF when the chart indicates it to be only marginally profitable.
Prime95 is offline  
Old 2020-04-05, 16:48   #173
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

1ABB16 Posts
Default

Quote:
Originally Posted by chalsall View Post
Further, the opposite argument to yours can be made. If we have TF'ing resources that aren't going to be redirected to FC'ing, should they optimally TF the ranges years ahead of the wavefronts? Or should they instead TF past the optional only a few months ahead?

I would argue the latter, where people are willing.
I agree 100% with this conclusion.

Arguing about the optimum bit level is a bit silly. 1) There are a wide variety of GPUs participating each with their own optimum, and 2) If you have an excess of TF resources available, put them to work TF'ing past the theoretical optimum bit level.

You have a short term problem. TF resources "fell behind" the first-time testers and Chris is now juggling these cool new TF resources to best feed the 4 wavefronts and the P-1'ers.
Your long term solution is easy. Guess where the cat 4 wavefront is a year from now and TF that range as much as the TF resources allow (depth-first, breadth-first, probably does not matter much).

At some point, we should also look at taking some of the excess TF resources and pointing it at the 100M digit range.
Prime95 is offline  
Old 2020-04-05, 16:53   #174
Uncwilly
6809 > 6502
 
Uncwilly's Avatar
 
"""""""""""""""""""
Aug 2003
101×103 Posts

1F6C16 Posts
Default

Quote:
Originally Posted by Prime95 View Post
At some point, we should also look at taking some of the excess TF resources and pointing it at the 100M digit range.
Thank you kind sir.
Uncwilly is offline  
Old 2020-04-05, 17:31   #175
chalsall
If I May
 
chalsall's Avatar
 
"Chris Halsall"
Sep 2002
Barbados

2·3·1,499 Posts
Default

Quote:
Originally Posted by Prime95 View Post
At some point, we should also look at taking some of the excess TF resources and pointing it at the 100M digit range.
Already modeled. In fact, the code already exists from years ago; I just need to reactivate it.

Also, the DC range, once the FC ranges are comfortable.
chalsall is online now  
Old 2020-04-05, 18:45   #176
KEP
Quasi Admin Thing
 
KEP's Avatar
 
May 2005

32·101 Posts
Default

Quote:
Originally Posted by Prime95 View Post
At some point, we should also look at taking some of the excess TF resources and pointing it at the 100M digit range.
Maybe the plan, should be to get n<=120M to 78bit, then we should be ahead of FC enough to spread the ressources between DC, 100M and n<120M to as high a bit as possible before the wavefronts catch up. Then take the next 10M n towards 79 bit before returning to DC, 100M and as high a bit as possible before the wavefront catches up.

Quote:
Originally Posted by chalsall View Post
Already modeled. In fact, the code already exists from years ago; I just need to reactivate it.

Also, the DC range, once the FC ranges are comfortable.
I know it is intriguing to go and throw some ressources at the 100M digit range. It sure is nice to see that some "ancient" code excist to do that job, but untill there is adequate room between the wavefront of TF and the various FC and P-1 wavefronts, I would sure appreciate if we wavered that part of TF for the next time being. But of course, as you and George mention, for the future, once the world gets back to normal and our ressources stabilies it sure is a great suggestion
KEP is offline  
Closed Thread

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Chess World Championship Match -- 2013, 2014, 2016 Raman Chess 34 2016-12-01 01:59
mprime ETA and primenet "days to go" do not match blip Software 1 2015-11-20 16:43
less v4 reservations being made tha PrimeNet 8 2008-08-14 08:26
LL test doesn't match benchmark drew Hardware 12 2008-07-26 03:50
WE MADE IT!!!!!!!!!!!!!!!!!!!!!! eric_v Twin Prime Search 89 2007-01-23 15:33

All times are UTC. The time now is 18:05.

Thu Jun 4 18:05:43 UTC 2020 up 71 days, 15:38, 1 user, load averages: 2.34, 2.09, 1.98

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, 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.