Trial factoring with mfakto and gpuowl

I want to show you the history of an exponent, which has been factored but has been around for a while, look at the dates:


https://www.mersenne.org/report_expo...1697213&full=1

[preda]

Originally Posted by SELROC

I want to show you the history of an exponent, which has been factored but has been around for a while, look at the dates:


https://www.mersenne.org/report_expo...1697213&full=1

Congrats for finding the factor!
In 2016, I was probably doing some TF with mfaktc, thus no gpuowl involved yet :)

Originally Posted by preda

Congrats for finding the factor!
In 2016, I was probably doing some TF with mfaktc, thus no gpuowl involved yet :)

Thanks :-)


the point is 8 years to factor this exponent does look as far away from efficient.

[masser]

Originally Posted by SELROC

Thanks :-)


the point is 8 years to factor this exponent does look as far away from efficient.

The P-1 and LL testing wavefronts won't reach this exponent for another ten years. Some might argue it's inefficient to perform any trial-factoring on this exponent at this time.

[kriesel]

Originally Posted by masser

The P-1 and LL testing wavefronts won't reach this exponent for another ten years. Some might argue it's inefficient to perform any trial-factoring on this exponent at this time.

One could argue that anything other than a strictly monotonic search is wasteful. Or that a strictly monotonic search that leads to participant boredom and quitting is wasteful. Some people have more patience than others.

Much of my gpu power in recent months has been applied to TF and P-1 on scattered exponents spread widely through the 90 to 800 million span. P-1 to test CUDAPm1's limits, and find some possible issues, early, long enough before the wavefront arrives there, that something might be done to resolve issues ahead of the wavefront, and TF to ensure those P-1 tests are done on exponents not readily trial factored.


What I think an optimal monotonic search would look like is:
TF in ascending order, exponents to the TF-optimal-depth;
P-1 in ascending order, exponents that survived TF;
(there are some arguments for the last bit level of TF being postponed to after the P-1);
PRP3 in ascending order.
LL confirmation of anything that survives the preceding.

TF wavefront would be just enough ahead of the P-1 wavefront, and P-1 just enough ahead of the primality testing wavefront.
What's being optimized for is probability of finding a new Mersenne prime per unit computing effort.
Effort goes up at higher exponent, and probability of finding a new prime goes down.

[chalsall]

Originally Posted by kriesel

One could argue that anything other than a strictly monotonic search is wasteful.

The issue with trying to optimally achieve that here is GIMPS is a volunteer effort, with many disparate participants with differing interests, "kit" and agendas.

Some want to find the next MP. Some want to prove the order of the MPs (read: DC'ing). Some want to find lots of factors because they enjoy it. Some want to ensure the sanity of their kit and/or code.

To complicate matters, Primenet can't generally give participants work they didn't ask for. Well, it can actually, but invariably the participant asks "Why was I given X work when I asked for Y?!?!?" and then sometimes leaves. Other times someone new comes in with a great deal of firepower, tests their kit, and then leave without unreserving assignments.

Overall I think the GIMPS project has reached a reasonable equilibrium of optimal throughput and participant satisfaction. The "0 to 4 Category" assignment rules based on CPU heuristics have gone a long way in cleaning up the delays in the milestones.

And, further, no LL assignment has been made in the last several years which has not been "optionally" TF'ed nor P-1'ed (except for manual assignments, where people ask for LL work well ahead of the wavefront).

[LaurV]

Originally Posted by chalsall

The issue...

(actually, welcomed, after some bull stuff you posted in the last time )

[masser]

Originally Posted by chalsall

Overall I think the GIMPS project has reached a reasonable equilibrium of optimal throughput and participant satisfaction. The "0 to 4 Category" assignment rules based on CPU heuristics have gone a long way in cleaning up the delays in the milestones.

Agreed.

My only quibble is that I see all of the TF work that has been done in the 100M+ exponent range. I suspect that GPU72 would have an easier time staying in front of the P-1 wavefront if some of that 100M+ TF work was steered toward the LL wavefront, say 90M range exponents.

I understand that higher bit-level TF may not be efficient for CPUs. However, it appears that a lot of the manual TF work is done by GPUs. Could there be a non-trivial number of GPU owners that are using the standard manual request page for TF assignments, instead of the special GPU TF request page?

Thanks for chiming in, chalsall and kriesel!

Originally Posted by preda

Congrats for finding the factor!
In 2016, I was probably doing some TF with mfaktc, thus no gpuowl involved yet :)

Originally Posted by masser

Agreed.

My only quibble is that I see all of the TF work that has been done in the 100M+ exponent range. I suspect that GPU72 would have an easier time staying in front of the P-1 wavefront if some of that 100M+ TF work was steered toward the LL wavefront, say 90M range exponents.

I understand that higher bit-level TF may not be efficient for CPUs. However, it appears that a lot of the manual TF work is done by GPUs. Could there be a non-trivial number of GPU owners that are using the standard manual request page for TF assignments, instead of the special GPU TF request page?

Thanks for chiming in, chalsall and kriesel!

That is absolutely right, I am using the standard manual request page, as the special one is not being advertised in the site menus I didn't know of its existence.

[chalsall]

Originally Posted by masser

My only quibble is that I see all of the TF work that has been done in the 100M+ exponent range. I suspect that GPU72 would have an easier time staying in front of the P-1 wavefront if some of that 100M+ TF work was steered toward the LL wavefront, say 90M range exponents.

Sure. But we don't have control of them. They are self directing.

We can suggest, but we don't control.

It's a bit like a Buddhist position. Nemesia.

Originally Posted by masser

Agreed.

My only quibble is that I see all of the TF work that has been done in the 100M+ exponent range. I suspect that GPU72 would have an easier time staying in front of the P-1 wavefront if some of that 100M+ TF work was steered toward the LL wavefront, say 90M range exponents.

I understand that higher bit-level TF may not be efficient for CPUs. However, it appears that a lot of the manual TF work is done by GPUs. Could there be a non-trivial number of GPU owners that are using the standard manual request page for TF assignments, instead of the special GPU TF request page?

Thanks for chiming in, chalsall and kriesel!

I have tried to use the special page, every option gives the error no assignments available for gpu.