Davieddy's World

[davieddy]

Originally Posted by Aramis Wyler

All is not lost though, because we have at least 27 days of lead time to play with.

Why this brinkmanship?

I would argue that there is no slack at all, considering there are 3000 below 63M that are not yet TFed properly.
This is because Primenet dishes out ridiculously high exponents for TF to uselessly low bit levels. OTOH Chalsall prioritised taking 45M expos to 72 over 55M ones.

What about leaving some time to give P-1 at least a fighting chance of being done before expos are allocated for LL?

And what about my argument that TF to 74 isn't worthwhile till 72M, because the GPU and CPU core would be better employed doing LL?

D

[chalsall]

Originally Posted by davieddy

I would argue that there is no slack at all, considering there are 3000 below 63M that are not yet TFed properly.

Actually, 818. Only 90 of which we don't own.

Originally Posted by davieddy

This is because Primenet dishes out ridiculously high exponents fo to uselessly low bit levels.

Primenet assigns TF work to CPUs on bit-level at a time basis.

You yourself have said that CPUs shouldn't be doing TFing. So doesn't it make sense?

Originally Posted by davieddy

OTOH Chalsall prioritised taking 45M expos to 72 over 55M ones.

Not quite accurate.

I carefully balanced the demand vs. the resources vs. the candidates, as they became available.

Originally Posted by davieddy

What about leaving some time to give P-1 at least a fighting chance of being done before expos are allocated for LL?

I fail to understand how TFing to a higher level takes anything away from P-1. P-1 assignments are always available -- the fact they're not completing as fast as LL assignments are being made is not our problem.

Originally Posted by davieddy

And what about my argument that TF to 74 isn't worthwhile till 72M, because the GPU and CPU core would be better employed doing LL?

And, finally, we get to the core of the (emotional) argument...

David wants to tell everyone to devote everything to LLing...

Ground Control to Major Tom.....

[davieddy]

No problem is so difficult that, with the aid of a bit of sophistry and bullshit, it can't be rendered completely intractable.

Originally Posted by bcp19

Sadly, Chris, facts mean nothing to David... his fantasy world is far superior to our mundane life.

I personally think it funny how he removes the doubt 4x more often than I do.

I do have a couple of questions that you can probably easily answer which may help this nonsensical arguement.

In calculating out the following, use the assumption that there will be no increase or decrease in either CPUs or GPUs during the timeframes being calculated.

1) As of today, what is the approximate exponent handed out for a) LL and b) LL-TF?

2) At our current rate of LL-TF completions to 74 vs current rate of LL completions, on what date will we exhaust our 32 day lead?

3) On the date given in 2), what is the estimated exponent handed out for both a) LL's and b) LL-TF?

4) Using the 2 exponents garnered from 3). what is the approximate increase in LL runtime versus current runtime and the approximate decrease in LL-TF runtime versus current LL-TF runtime?

5) Using the results from 4), on the date found in 2), will the LL-TF completion rate increase from running higher exponents be enough to surpass the LL completion rate decrease from running higher exponents?

If the answer to 5) is yes, then simple logic would indicate David's arguement is moot and we should continue LL-TF to 74 bits. Conversely, if the answer is no, then we need to extend the current 32 day grace period.

Originally Posted by chalsall

Actually, because of the way Primenet assigns work (and the way the participants complete it (or not)) your above analysis is almost impossible to do in the manner you describe. (As an aside, I don't really think the assignment methodology could be greatly altered given that this is a volunteer effort, with the possible exception of assigning "Anonymous" work at the wavefront -- and expiring candidates which are over a year old.)

However, your questions got me thinking about how best to settle this "debate" once and for all, using quantitative data rather than hysterical ranting. Thank you for that.

Over the last 30 days Primenet's workers have completed approximately 9,100 LL assignments, or 303.4 a day. (The exact number is hard to determine for various reasons, but this is certainly accurate to within 1%.)

The average completion is somewhere in the 58M range. So going by James' calculator, each one took on average 122.93 GHz days, or a Primenet average of ~37,297 LL GHz Days / day.

I took this average, and extended the Estimated Completion report to show both the number of days GPU72 is reasonably expected to take to TF, vs. how many days Primenet is reasonably expected to take to LL.

The numbers speak volumes: ~191 days to TF everything below 66M appropriately; ~706 days to LL everything below 66M.

Now, then, based on this, the only real question is how much of a lead time does GPU72 have over the LL wavefront... Based on the data available last night at 0010 UTC (just before Primenet started recycling abandoned candidates), there were approximately 16,330 available for assignment for LLing or P-1'ing, or already assigned for P-1'ing (by both Primenet and GPU72) below 65M.

Taking into account the work available, and assigned for P-1'ing (read: already appropriately TFed -- reasonably expected to complete or be recycled) we are actually ~53.8 days ahead.

Or, executive summary: I remain comfortable we can complete the goal of TFing >63M to 74 bits without hindering LL assignments in any way. And, in fact, we may be able to start going to 75 in a few months.

P.S. For clarity, while the Primenet LL average is only an approximation at the moment, the calculated estimate for both TFing and LLing is based on the actual number of GHz days required for each individual candidate.

P.P.S. I will be able to make the calculated 30 average of Primenet's LL performance more accurate (it will be lower) and updated daily by adding a data-tap to Mersenne.info. As in, it will remain accurate over time.

[chalsall]

Originally Posted by davieddy

No problem is so difficult that, with the aid of a bit of sophistry and bullshit, it can't be rendered completely intractable.

Have you found a fault in my analysis?

[Aramis Wyler]

Originally Posted by davieddy

I am aware that I lost you here last time, but the bitlevel should be upped by one everytime the exponent increases by a factor of 1.26.
1.26*57M ~ 72M.
1.26³ = 2. When the exponent is doubled the time for an LL increases 4 fold. The same goes for TFing three bits higher with the exponent doubled.

I wrote a fairly lengthy post in response to this, with a page of carefully written calculations where I tried to duplicate your 1.26 number without unknowns, and could not. So I'm going make up the following, and you can prove it is or is not true, same as I tried to do with your quote above. Surely the missing variable will pop right out:

Originally Posted by fakeddy

I am aware that I lost you here last time, but the bitlevel should be upped by one everytime the exponent increases by a factor of 1.12.
1.12*57M ~ 64M.
1.12⁶ = 2. When the exponent is doubled the time for an LL increases 4 fold. The same goes for TFing three bits higher with the exponent doubled.

Now that math is all correct, as is yours, and the word bits are also correct. Unfortunately those two things are not trribly relevant to each other. The first question one might ask is why you used a cube root. 2 squares isn't a cube, it's a 4th. Adding 2 squares isn't a cube either. the second question one might ask is what is the whole point anyway. What is the goal here, to keep the amount of time required the same? Because that would be 2, as in we would increment the bitdepth by 1 every time the P doubled, not when it went up to 126%.

I think the whole thing is bunk in the end, because it seems to assume that gpu72's throughput stays the same as it was when we hit 57M, and between new arrivals (like me) and the .20 release of mfactc that's certainly not true. But if you want to force a number, fine. Prove your number. But I do not think that, in the end, it is relevant.

As an addendum, I'm going to put some math about why what you say about the 4 fold bit is true.

For Factoring Time aT(Exponent bP, Bitdepth D+c)
Given T(P,D+1)=T(P/2,D)=2T(P,D) one could say that 
a = 2c * 1/b and sure enough 
4 = 23*1/2 so that last part of the quote pans out.

[kladner]

Originally Posted by davieddy

No problem is so difficult that, with the aid of a bit of sophistry and bullshit, it can't be rendered completely intractable.

How does the above differ from the "stupid" which caused such a kerfuffle recently. Use of words with more syllables does not negate the inherent, and needless nastiness.

And what about my argument that TF to 74 isn't worthwhile till 72M, because the GPU and CPU core would be better employed doing LL? And, finally, we get to the core of the (emotional) argument...

David wants to tell everyone to devote everything to LLing...

I thought his point is that LL is chomping at our heels, as well as being handed out with improper levels of factoring. How is it that we should divert resources to more LL work?

[chalsall]

Originally Posted by kladner

I thought his point is that LL is chomping at our heels, as well as being handed out with improper levels of factoring.

That is his unsupported claim. And what he would like everyone to believe.

It's not true.

Originally Posted by kladner

How is it that we should divert resources to more LL work?

We shouldn't. Although that is what he would like us to do.

Actually, David's distractionary work is possibly a High School (or an "A" level) Student's Honors Theseus to analyse.

[davieddy]

Originally Posted by kladner

How does the above differ from the "stupid" which caused such a kerfuffle recently. Use of words with more syllables does not negate the inherent, and needless nastiness.





I thought his point is that LL is chomping at our heels, as well as being handed out with improper levels of factoring. How is it that we should divert resources to more LL work?

What (if anything) DO you understand?

[Batalov]

Originally Posted by davieddy

No problem is so difficult that, with the aid of a bit of sophistry and bullshit, it can't be rendered completely intractable.

Originally Posted by davieddy

What (if anything) DO you understand?

Originally Posted by davieddy

Cut the BS.

David

This manner of conversation (and complete avoidance of answering other people's reasonable questions) strongly reeks of Don-Blazy-ness. I used to regard you a bit higher than that.

Originally Posted by Mark Twain

The more I know people, the more I love my dog.

[davieddy]

Originally Posted by Batalov

This manner of conversation (and complete avoidance of answering other people's reasonable questions) strongly reeks of Don-Blazy-ness. I used to regard you a bit higher than that.

No more Mr Nice Guy.

I have spent 24 hours explaining patiently and clearly that area = pi r² to a frenzied lynch mob who insist that this is merely my opinion, to which I am not entitled anyway through inadequate hardware ownership, and not subscribing to their club.

I have tried to find points of concensus:
1) 74 bits is unsustainable at the moment.
2) If 74 bits is worthwhile, this is at best marginal.
3) Setting the default to 73 in no way precludes folk going to 74 if the mood takes them. The point is to avoid allocating anything <73 for LL.

I'll set out the way GIMPs is tomorrow.
I think I need a break.


D

[c10ck3r]

Originally Posted by davieddy

No more Mr Nice Guy.

I have spent 24 hours explaining patiently and clearly that area = pi r² to a frenzied lynch mob who insist that this is merely my opinion, to which I am not entitled anyway through inadequate hardware ownership, and not subscribing to their club.
D

Area of a square= L²