GPU to 72 status...

[chalsall]

Originally Posted by kracker

The hell? ?

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.

[kracker]

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

[petrw1]

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?

[VictordeHolland]

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.

[c10ck3r]

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.

[James Heinrich]

You need some kind of self-balancing metric, perhaps something along the lines of

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.

[Graff]

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

[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

[swl551]

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!

[Prime95]

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?

[James Heinrich]

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 = 2⁷³
57M-72M = 2⁷⁴
73M-90?M = 2⁷⁵