Half a million GHz-days?

[ramgeis]

I was just wondering if getting more than half a million GHz-days credit for one result makes sense or if something is completely broken here.

See attached screenshot:

[GP2]

I have been using GMP-ECM to do stage 2 for P−1 testing, with stage 1 done by Prime95/mprime. In a nutshell, GMP-ECM is much more efficient for stage 2 for very small exponents; on the other hand it is impractical for larger exponents and entirely unusable for the 80M range where we do most of the P−1 testing these days.

In the past few days I found additional factors for M3617 and M4957 recently. The factors are 40 digits and 48 digits, respectively. I used B2 = 10¹⁷, which is orders of magnitude higher than the B2 limits achievable with Prime95/mprime. Incidentally this requires large amounts of memory to do efficiently, I used 200 to 250 GB for these. I manually reported the results and PrimeNet assigned a ridiculously huge amount of credit.

This is similar to what happens when people use GPU-based programs for trial factoring: PrimeNet assigns credit as if Prime95/mprime had been used, instead of the actual more efficient program, leading to unrealistic values. This leads to the overall top producer rankings to be unfairly skewed in favor of users with a high percentage of TF relative to the other work types, but we tend to shrug and live with it.

I consider GHz-days to be pretty meaningless anyway, so a lot of the crunching I do these days is uncredited anyway (e.g., all unsuccessful P−1 testing of exponents with already-known factors, and PRP testing).

[retina]

Originally Posted by GP2

I consider GHz-days to be pretty meaningless anyway ...

This I agree with. I long ago abandoned my accounts on primenet and now just do "anonymous" work.

If someone gets 500000 GHzDays, or whatever GHzDays, then that is just fine with me. Give them more if it encourages them more. It's all just numbers in a database anyway.

[axn]

Originally Posted by GP2

This is similar to what happens when people use GPU-based programs for trial factoring: PrimeNet assigns credit as if Prime95/mprime had been used, instead of the actual more efficient program, leading to unrealistic values.

This is not at all similar to CPU TF/GPU TF situation. GPU TF has same algorithm as CPU TF -- in that sense, GPU TF is not more efficient than CPU TF. However, if we think of GPUs as faster CPUs, then the speedup we get from GPUs doing TF (over CPUs) is much higher than the speedup from GPUs doing LL.

There is nothing unrealistic about the GHz-Days values that GPUs get for TF.

[S485122]

Originally Posted by axn

...
There is nothing unrealistic about the GHz-Days values that GPUs get for TF.

Oh yes there is.If one goes for GHzdays electricity would be spent on TF on GPU's only. No LL testing or P-1 factoring would be done.

There will come a time where GPU's will have to be used on LL testing. (Just try to prove the 13th Mersenne prime by TF alone.)

Jacob

[chalsall]

Originally Posted by S485122

There will come a time where GPU's will have to be used on LL testing. (Just try to prove the 13th Mersenne prime by TF alone.)

At the end of the day, GPUs are currently best at TF'ing because of their *many* simple processors without a lot of precision, while CPUs are best at LL'ing because they have a much wider range of instructions and registers with DP. And while the TF'ing can be easily parallel, the LL test must be serial.

I don't think anyone really cares that much about the credits.

When the quantum computers become retail, the owners will laugh in our general direction....

[Batalov]

One might want to cap GHz-days credit at "GHz-days needed to eliminate this candidate by LL". The latter is certainly not a half a million GHz-days.

It is certainly fine to factor Mersenne numbers but this is more like also giving credits to people who do other Cunnigham list-type research. For GIMPS (as in "Great Internet Mersenne Prime Search"), factoring a factored candidate is arguably meaningless. Remember times when credit for doing useless LL was subtracted when a reasonably small factor was found? There was a logic behind that - in the paradigm that GHz-days were an attempt to objectively measure throughput. If GHz-days are no longer in this paradigm and the new paradigm is that GHz-days are "wages" for the work done, then there are corollaries: you could changes these wages to steer users to do a more wanted work (the wages are higher) or "pay" less for equal but less wanted work. (PrimeGrid clearly follows this line of thought, and gives arbitrary markups to the different classes of tasks. Sometimes these markups are added, sometimes removed.)
The two paradigms are not well compatible.

[GP2]

Originally Posted by Batalov

One might want to cap GHz-days credit at "GHz-days needed to eliminate this candidate by LL".

I wouldn't object to that, or some other form of cap, even a zero cap. It could be applied retroactively.

If a factor is found by P−1, I do want to report that it was found by P−1 and the bounds that were used, because that is useful information for posterity, so I format the manual results text accordingly. The wacky enormous credit is just a side effect of that. If the exact same factor was found by ECM instead, the credits would be very much smaller.

You are right that there is a certain Cunningham-project "factor philately" aspect to it which is tangential to the goal of finding new Mersenne primes, and credit should not be a motivation.

[LaurV]

The real problem here is that a factor found by ECM was reported as found by P-1. It has nothing to do with the credit system, or with the CPU, GPU, XPU or other hardware used.

It is NORMAL that people having better hardware get better credit. It is their money they spent to buy that hardware.

This problem occurred many times in the past, including when only the CPUs were the only ”actors” on the stage. When very small factors (like 70 bits or so) were found by TF in minutes, but they were reported as P-1 and get tons P-1 of credit, because they were not smooth (had a big k) and it would have taken P-1 years to find them; or vice-versa, a very smooth 85-bit factor was found by P-1 in minutes and reported as TF finding, giving tons of TF credit, because it would have taken TF ages to find a 85 bit factor (on CPU) for a mersenne with a small exponent. Nothing new under the sun, we had some guys doing this as a daily job. They got bored and left after a while, or learned to cope.

The real solution would be to allow people to report their findings in the right way.

Of course, capping the credit is not a bad idea either. I said repeatedly in the past, finding a factor is cool, but let's not forget we are trying to find PRIMES here. The main goal of the project is to find primes. Factoring numbers already known to be composite does not help the project at all, contrarily, it takes resources away from it, resources which could be used to do useful work. But again, everybody can do whatever work type he/she likes and whatever makes them happy. You can not force me to do other work type than the one I really want to do, even if that is futile, but it makes me feel important. My money, my hardware, my electricity, my time, my blah-blah-blah (I have a lot of this!)...

And to avoid further arguments, yes, I am the credit whore. No matter how altruistic some of you want to appear, half of you will pack their toys and go back home if the credits were removed. Don't tell me... Maybe not you personally, but we will lose half of the contributors for sure. Human nature...

[GP2]

Originally Posted by LaurV

The real problem here is that a factor found by ECM was reported as found by P-1.

No, the recent factors for M3617 and M4957 really were found by P−1. Or are you talking about some other past occurrence?

[retina]

Originally Posted by LaurV

... half of you will pack their toys and go back home if the credits were removed.

Another way to look at it is that some people prefer to join the "anonymous" team and become part of the computing awesomeness that is currently at the top of the list.