mersenneforum.org GPU to 72 status...
 Register FAQ Search Today's Posts Mark Forums Read

2012-12-28, 20:54   #1640
chalsall
If I May

"Chris Halsall"
Sep 2002

22×23×103 Posts

Quote:
 Originally Posted by kracker
I'm experimenting with some GPU72 coordinated LMH. I need to apply a filter to not give the nominal amount of "GHz Saved" credit for such work.

Everything will be back to nominal in a few hours.

2012-12-28, 21:02   #1641
kracker
ἀβουλία

"Mr. Meeseeks"
Jan 2012
California, USA

32·241 Posts

Quote:
 Originally Posted by chalsall I'm experimenting with some GPU72 coordinated LMH. I need to apply a filter to not give the nominal amount of "GHz Saved" credit for such work. Everything will be back to nominal in a few hours.
Ahh, I see. That would be nice to have, btw

2012-12-29, 03:44   #1642
petrw1
1976 Toyota Corona years forever!

"Wayne"
Nov 2006

23·569 Posts

Quote:
 Originally Posted by chalsall I need to apply a filter to not give the nominal amount of "GHz Saved" credit for such work.
Why not?....I realize as displayed that the numbers would be huge so that could just mean a seperate chart from regular TF. NO?

 2012-12-29, 07:15 #1643 VictordeHolland     "Victor de Hollander" Aug 2011 the Netherlands 23·3·72 Posts How can you compare a factor found in lets say the 900M range with one in the LL range? Finding a factor in the 900M range is much easier and saves hundreds if not even thousands times the GHzdays if we finally get there in 100 years.
 2012-12-29, 14:37 #1644 c10ck3r     Aug 2010 Kansas 547 Posts Well, a 70 bit factor for a 900M is about equal (iirc) to a 66 bit factor for 56M. TF credit (should? does?) reflect this, but the simple truth is it does save so much time iff these exponents are ever LL tested. I picture it like this: a composite exponent also could have a "GHz saved" amount if anyone was stupid enough to run it without the known factor, but not stupid enough to run it with a known factor.
 2012-12-29, 15:03 #1645 James Heinrich     "James Heinrich" May 2004 ex-Northern Ontario 326710 Posts You need some kind of self-balancing metric, perhaps something along the lines of Code: worth = GHd_saved * (GHd_factor / GHd_LL) // examples: // 72-bit TF factor on 60M (TF to 273) value = (133.292 + 133.292 + 15.94) * (11.956 / 133.292) = 89.7 // 72-bit TF factor on 900M (TF to 284) value = (24825 + 24825 + 4352) * (0.5314 / 24825) = 1.2 // 83-bit TF factor on 900M (TF to 284) value = (24825 + 24825 + 2176) * (1088 / 24825) = 2271 // 93-bit P-1 factor on 900M (TF to 284) value = (24825 + 24825 + 0) * (684 / 24825) = 1368 This correctly shows that a 72-bit factor is worth a lot less on larger exponents than on smaller, despite "saving" a lot more LL effort. As can be seen above, it also works well with P-1 factors -- large factors can be found with relatively less effort than TF factors, but the above automatically scales it in what I think is an appropriate manner.
2012-12-31, 20:37   #1646
Graff

Jul 2006
USA (UT-5) via UK (UT)

22×59 Posts

Quote:
 Originally Posted by chalsall I'm experimenting with some GPU72 coordinated LMH. I need to apply a filter to not give the nominal amount of "GHz Saved" credit for such work. Everything will be back to nominal in a few hours.
Is this related in any way to the non-updating of the table of
LL trial factoring work (/reports/workers/lltf/)? The graphs
appear to be updated, but the table is outdated. And it
doesn't appear to be a cache problem at my end.

Gareth

 2013-01-08, 23:01 #1647 James Heinrich     "James Heinrich" May 2004 ex-Northern Ontario 33×112 Posts mfaktc v0.20's recent release brings GPU-sieving into the game. And much increased performance (in the order of 30-50%). TF levels for GPU72 may need to be reconsidered? http://mersenne.ca/cudalucas.php?model=13&granularity=2
2013-01-08, 23:23   #1648
swl551

Aug 2012
New Hampshire

23·101 Posts

Quote:
 Originally Posted by James Heinrich mfaktc v0.20's recent release brings GPU-sieving into the game. And much increased performance (in the order of 30-50%). TF levels for GPU72 may need to be reconsidered? http://mersenne.ca/cudalucas.php?model=13&granularity=2
74 is the new 72!

2013-01-08, 23:41   #1649
Prime95
P90 years forever!

Aug 2002
Yeehaw, FL

7,351 Posts

Quote:
 Originally Posted by James Heinrich TF levels for GPU72 may need to be reconsidered? http://mersenne.ca/cudalucas.php?model=13&granularity=2
Question: Look at row 47M, the cyan color indicates we should TF to 2^73, but the 2LL column indicates the TF breakeven is 72.3 bits. Am I missing something?

2013-01-08, 23:41   #1650
James Heinrich

"James Heinrich"
May 2004
ex-Northern Ontario

33·112 Posts

Quote:
 Originally Posted by swl551 74 is the new 72!
Starting at about 57M, I'd say that's true.

According to my chart:
46M-56M = 273
57M-72M = 274
73M-90?M = 275

Last fiddled with by James Heinrich on 2013-01-08 at 23:45 Reason: can't count

 Similar Threads Thread Thread Starter Forum Replies Last Post Primeinator Operation Billion Digits 5 2011-12-06 02:35 1997rj7 Lone Mersenne Hunters 27 2008-09-29 13:52 Uncwilly Operation Billion Digits 22 2005-10-25 14:05 paulunderwood 3*2^n-1 Search 2 2005-03-13 17:03 1997rj7 Lone Mersenne Hunters 25 2004-06-18 16:46

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

Sat Feb 27 22:43:37 UTC 2021 up 86 days, 18:54, 0 users, load averages: 2.93, 2.83, 2.45