mersenneforum.org  

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

Reply
 
Thread Tools
Old 2018-11-24, 02:54   #1
snme2pm1
 
"Graham uses ISO 8601"
Mar 2014
AU, Sydney

3618 Posts
Default TF Level policy

I observe that GPU72 TF sponsored work is proceeding to a different target from the yellow marker at mersenne.ca.
What is the adopted policy?
For example, I have been happy to plough the 118M region, with little interference, and suspect that the 76 bit yellow mark will likely be superseded by GPU72 participants, but is 77 bits the likely target when the time comes after some months?
snme2pm1 is offline   Reply With Quote
Old 2018-11-24, 17:25   #2
chalsall
If I May
 
chalsall's Avatar
 
"Chris Halsall"
Sep 2002
Barbados

9,029 Posts
Default

Quote:
Originally Posted by snme2pm1 View Post
What is the adopted policy?
It's a little complicated, balancing what is "optimal" vs. what the project can sustain, taking into account the demand of the Primenet P-1'ers and LL'ers.

To start with, we are guided by James' TF vs. LL/DC cross-over analysis. This gets even more complicated because our participants have a mix of different cards with different compute ability. For example, a GTX 580 (compute v2.0) should TF lower than a GTX 1080 (v6.1) which in turn should TF lower than a RTX 2080 (v7.5).

Basically we try to go as high as is practical, and offer lower bit-level work for those with older generation cards and/or those who simply want to process more candidates per wall-clock time (and, thus, find more factors).

Quote:
Originally Posted by snme2pm1 View Post
For example, I have been happy to plough the 118M region, with little interference, and suspect that the 76 bit yellow mark will likely be superseded by GPU72 participants, but is 77 bits the likely target when the time comes after some months?
Depending on your card (and based on the above linked graphs), 77 is the lowest level we'll likely work to (when we get up there; several years away). More than likely we'll end up taking them up to 79, or possibly even higher as GPUs get ever more powerful.
chalsall is online now   Reply With Quote
Old 2018-11-25, 03:01   #3
snme2pm1
 
"Graham uses ISO 8601"
Mar 2014
AU, Sydney

24110 Posts
Default

Quote:
Originally Posted by chalsall View Post
Depending on your card (and based on the above linked graphs), 77 is the lowest level we'll likely work to (when we get up there; several years away). More than likely we'll end up taking them up to 79, or possibly even higher as GPUs get ever more powerful.
I am guessing that new lithography will lift the pool of CPU based contributions especially next year; bring on 7nm from AMD.
So perhaps there is an awkward nexus between the ratio of CPU derived versus GPU derived capacity that has been somewhat established by now.
snme2pm1 is offline   Reply With Quote
Old 2018-11-25, 03:31   #4
Mark Rose
 
Mark Rose's Avatar
 
"/X\(‘-‘)/X\"
Jan 2013
Ͳօɾօղէօ

2,789 Posts
Default

Quote:
Originally Posted by snme2pm1 View Post
I am guessing that new lithography will lift the pool of CPU based contributions especially next year; bring on 7nm from AMD.
So perhaps there is an awkward nexus between the ratio of CPU derived versus GPU derived capacity that has been somewhat established by now.
The biggest change lately was the major boost in TF performance of the RTX series. Maybe Navi GPUs will have the same.

With regards to Zen 2, the improved AVX2 performance won't make much difference because the chips are already memory bottlenecked. It will only help on the low core count parts. Their higher supported DDR4 frequencies will give a slight boost. It'll be Zen 3+ with DDR5 when we'll see the next big boost on the AMD CPU side.

It's possible that folks here will pick up used mining GPUs or entire rigs. A couple of those could have a big impact on TF throughput.

Either way, I think the balance will continue to shift towards more TF for the next couple of years, like it has the last couple of years.

I should probably shift those GTX 580's of mine to LL but I'm lazy.
Mark Rose is offline   Reply With Quote
Old 2018-11-27, 09:33   #5
snme2pm1
 
"Graham uses ISO 8601"
Mar 2014
AU, Sydney

241 Posts
Default

Quote:
Originally Posted by chalsall View Post
...More than likely we'll end up taking them up to 79, or possibly even higher as GPUs get ever more powerful.
Ok then, 79 bits it is then.... Hope I live long enough, though I recall the movie "Field of dreams", "Build it and they will come"!
snme2pm1 is offline   Reply With Quote
Old 2018-11-27, 13:04   #6
snme2pm1
 
"Graham uses ISO 8601"
Mar 2014
AU, Sydney

241 Posts
Default

Quote:
Originally Posted by Mark Rose View Post
The biggest change lately was the major boost in TF performance of the RTX series. Maybe Navi GPUs will have the same.

With regards to Zen 2, the improved AVX2 performance won't make much difference because the chips are already memory bottlenecked. It will only help on the low core count parts. Their higher supported DDR4 frequencies will give a slight boost. It'll be Zen 3+ with DDR5 when we'll see the next big boost on the AMD CPU side.
I'm guessing from comments I'm need to wait another year or two..
But that is almost always the condition of a potential buyer, always hoping for something a little better.

Trying to not run off topic, but fear it might be heading in that direction.
snme2pm1 is offline   Reply With Quote
Old 2018-11-27, 19:17   #7
chalsall
If I May
 
chalsall's Avatar
 
"Chris Halsall"
Sep 2002
Barbados

902910 Posts
Default

Quote:
Originally Posted by snme2pm1 View Post
Ok then, 79 bits it is then....
Just wondering... Is there any reason you're not working though GPU72? You're free to do whatever you want, of course. It's your kit / time / electrons.

The advantage of GPU72 is it works closer to the "wavefronts", so the work is more immediately useful to the Great Internet Mersenne _Prime_ Search. Not to say your work up in the 118M range won't be useful; just not for several years.

Again, entirely up to you, of course.
chalsall is online now   Reply With Quote
Old 2018-11-28, 05:52   #8
snme2pm1
 
"Graham uses ISO 8601"
Mar 2014
AU, Sydney

3618 Posts
Default

Quote:
Originally Posted by chalsall View Post
Just wondering... Is there any reason you're not working though GPU72? You're free to do whatever you want, of course. It's your kit / time / electrons.
I don't like to extend my list of passwords for every this and that place that might want to own me.
I regard what George has established as very significant and would prefer to transact with the primary site that arose from his "Field of Dreams".
That is in no way intending any disrespect to what GPU72 has achieved; And evidently George is keen to compact resources so as to produce more prime results sooner rather than later.
I just would have preferred it if such were achieved from the main portal.
So it is that I like to operate, based on mersenne.org information, sometimes without allocated work, though when there is any hint of evidence of potential interaction I will take the reservation path, from mersenne.org.

Quote:
Originally Posted by chalsall View Post
The advantage of GPU72 is it works closer to the "wavefronts", so the work is more immediately useful to the Great Internet Mersenne _Prime_ Search. Not to say your work up in the 118M range won't be useful; just not for several years.
Thank you for your invitation.
Many months ago, prior to this thread, I had TF explored several exponents to 79 bits with only vague math analysis of the desirability of doing so.
I have reserved a couple for LL work myself, and the others were consumed for LL work by another member.
So I might argue that such work in 118M space, and other similar spaces, is relevant now for a smaller community that might like to engage with same.
snme2pm1 is offline   Reply With Quote
Old 2018-11-28, 15:02   #9
chalsall
If I May
 
chalsall's Avatar
 
"Chris Halsall"
Sep 2002
Barbados

9,029 Posts
Default

Quote:
Originally Posted by snme2pm1 View Post
I don't like to extend my list of passwords for every this and that place that might want to own me. ... So I might argue that such work in 118M space, and other similar spaces, is relevant now for a smaller community that might like to engage with same.
That's cool. This is a volunteer effort; everyone's allowed and encouraged to do whatever rocks their boat!
chalsall is online now   Reply With Quote
Old 2018-11-28, 15:42   #10
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

2·13·157 Posts
Default

Quote:
Originally Posted by chalsall View Post
It's a little complicated, balancing what is "optimal" vs. what the project can sustain, taking into account the demand of the Primenet P-1'ers and LL'ers.

To start with, we are guided by James' TF vs. LL/DC cross-over analysis. This gets even more complicated because our participants have a mix of different cards with different compute ability. For example, a GTX 580 (compute v2.0) should TF lower than a GTX 1080 (v6.1) which in turn should TF lower than a RTX 2080 (v7.5).
Does anyone know whether it's preferable to round those bit levels to nearest integer, round down to integer, or something else, for a given exponent size? (Mfaktx don't handle fractional bit levels AFAIK)

As I recall, prime95/mprime would apply additional TF before LL etc if appropriate, although that's based on the Cpu tradeoff, not the Gpu tradeoff. Gpu mersenne applications are mostly single computation type; gpuowl is the exception.
kriesel is online now   Reply With Quote
Old 2018-11-28, 15:55   #11
chalsall
If I May
 
chalsall's Avatar
 
"Chris Halsall"
Sep 2002
Barbados

9,029 Posts
Default

Quote:
Originally Posted by kriesel View Post
Does anyone know whether it's preferable to round those bit levels to nearest integer, round down to integer, or something else, for a given exponent size? (Mfaktx don't handle fractional bit levels AFAIK)
Again, it's a little complicated...

In an ideal world we would TF to the exact "economic cross-over" point (e.g. 76.253 "bits" for a GTX 580 at 90M). But mfaktX (and Prime95/mprime) only do integer depths. Further, mfaktX and Prime95/mprime do TF'ing differently (the former does lowest up; the latter uses "classes" spread over the entire bit range).

What we end up trying to do is what makes the most sense, based on the available compute.

Keep in mind also that James' analysis is based on the *same* hardware doing either TF'ing or LL'ing. In reality we have some who like to do TF'ing, and others who like to do LL/DC'ing. Thus, sometimes a participant/card will TF to a higher level than makes optimal sense (but rarely more than 0.5 of a bit level).
chalsall is online now   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
TF bit level davieddy Puzzles 71 2013-12-22 07:26
Probability of TF per bit level James Heinrich PrimeNet 11 2011-01-26 20:07
Expiring policy for V5 Server lycorn PrimeNet 16 2008-10-12 22:35
k=5 and policy on reservations gd_barnes Riesel Prime Search 33 2007-10-14 07:46
Reservation policy gd_barnes Riesel Prime Search 6 2007-10-01 18:52

All times are UTC. The time now is 02:39.

Mon Jul 13 02:39:27 UTC 2020 up 110 days, 12 mins, 0 users, load averages: 2.25, 1.98, 1.99

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.