mersenneforum.org  

Go Back   mersenneforum.org > New To GIMPS? Start Here! > Information & Answers

Reply
 
Thread Tools
Old 2021-07-22, 02:27   #12
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

5,779 Posts
Default

Quote:
Originally Posted by Siegmund View Post
It does seem like the default ought to be 2 for LL testers and only 1 for PRP testers.
When standalone P-1 is performed, how is the server to predict whether the first primality test that will be assigned later and performed later will be LL, PRP without proof or with bad proof, or PRP with a good proof that verifies as correct?
kriesel is online now   Reply With Quote
Old 2021-07-22, 02:41   #13
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
Jun 2011
Thailand

24·13·47 Posts
Default

My two cents: the value should stay 2. Little bit more P-1 won't hurt anybody, and it may be beneficial on long term.
LaurV is offline   Reply With Quote
Old 2021-07-22, 04:27   #14
Zhangrc
 
"University student"
May 2021
Beijing, China

6416 Posts
Default

Quote:
Originally Posted by LaurV View Post
the value should stay 2.
If one is interested in P-1 factors, he or she of course could use 2-primarity-test-saved bounds. However, some people just want to test as much exponents as possible, using PRP with proof, the 1-test-saved bounds are OK. Of course, we could go into the middle, using 1.2-test-saved bounds, since there are some PRP tests with bad proof or stalling out.

Personally I suggest doing more TF work at current PRP wavefront. By adding the throughput of top 500 producers, we have done 64 million GHZDays on PRP tests in the last year, but over 147 million GHZDays on TF (over twice as much work!) . For this reason, we could TF a bit higher, say 2^77 (even 2^78), just like what we have done to 95M exponents.
Zhangrc is offline   Reply With Quote
Old 2021-07-22, 04:51   #15
Uncwilly
6809 > 6502
 
Uncwilly's Avatar
 
"""""""""""""""""""
Aug 2003
101×103 Posts

234158 Posts
Default

Quote:
Originally Posted by Zhangrc View Post
Personally I suggest doing more TF work at current PRP wavefront.
Quite a bit of the TF work is being done away from the area of FTC's. SRBase is moving through exponents bit level by bit level and not staying below 120M. Also user TJAOI is doing a lot of work on low exponents (well below the FTC rang and at lower bit levels). So these 2 should not be counted toward the TF total. Also, with PRP and certs there is less work being done on to test and confirm exponents. This changes the calculus of what makes sense WRT to TF vs primality testing. Those running GPU72 closely watch the front of the Cat 4 FTC wave front, the Cat 3 FTC wavefront, and the currently available TF firepower for working ahead of the FTC's and what sort of work the various users prefer.

Last fiddled with by Uncwilly on 2021-07-22 at 04:52
Uncwilly is offline   Reply With Quote
Old 2021-07-22, 05:26   #16
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
Jun 2011
Thailand

24×13×47 Posts
Default

Quote:
Originally Posted by Uncwilly View Post
Also... <snip>

Also... <snip>

Also... <snip>
Also... we are comparing apples with watermelons, the TF credit unit and PRP credit unit are a lot different. One good GPU can spit 3000-6000 GHzDays for every day it does TF, but only 300-800 GHzDays for every day it does LL/PRP/P-1. This is remnant from the time when CPUs were used to TF, and the credit values were calculated to be approximately equal per time unit spent by the CPU for each work type. GPUs joining the fight completely changed the equation: now you can get 5 to 10 times more "credit" if you use your GPU for TF than for PRP, and there are people still motivated by that, especially young gamers whose gaming cards are not good at FP64 flops (needed for PRP) but are excellent at FP32 flops (good for gaming and TF). Unfortunately (or more exactly, fortunately) this was never fixed, because the re-balancing is not easy, and it will upset some people. On the other hand, giving a lot more TF credit per unit of time may be beneficial because that's the ONLY incentive given for TF. Some people with gaming GPUs (which are anyhow better at TF, and worse at LL/PRP) will join and do TF to advance in tops fast - two average gaming cards can put you on the tops in few weeks - therefore helping the project, which is always in need of "more TF". The TF does not have other incentive (unlike PRP, where you can find a prime and take some money) beside altruism ("we want to help the project"), idiocy ("we want to find factors, or to get a lot of credits, albeit we know none of the both are of any use"), or entertainment ("yeah, it is fun! hihi" and make donkey face). So, let TF give more credit, that's ok. I personally will jump to grab some of it!

Last fiddled with by LaurV on 2021-07-22 at 05:30
LaurV is offline   Reply With Quote
Old 2021-07-22, 05:39   #17
Zhangrc
 
"University student"
May 2021
Beijing, China

10010 Posts
Default

Quote:
Originally Posted by LaurV View Post
now you can get 5 to 10 times more "credit" if you use your GPU for TF than for PRP.
Sometimes it's 30 times more, depending on GPU model. My GPU (GTX1650) earn approximately 900 GHZDays per day doing TF but only less than 30 GHZDays doing PRP. As a result, I factor every exponent I test to at least 2^77, sometimes to 2^79.
Zhangrc is offline   Reply With Quote
Old 2021-07-22, 06:39   #18
Siegmund
 
Siegmund's Avatar
 
Mar 2014

22·13 Posts
Default

Quote:
Originally Posted by kriesel View Post
When standalone P-1 is performed, how is the server to predict whether the first primality test that will be assigned later and performed later will be LL, PRP without proof or with bad proof, or PRP with a good proof that verifies as correct?

Perhaps 2 is reasonable if a person requests a standalone P-1 assignment.


It seems less reasonable when one receives a PRP assignment for a number that has not yet had P-1 done on it. (I have been getting quite a few of these, for the past year or so.)


And is not the intention for all future world-record-sized testing to be PRP, not LL, no? So the expected number of tests saved is something like 1.03?


If extra factors are found, great - it just seems the default ought to be to minimize time needed to resolve each exponent.

Last fiddled with by Siegmund on 2021-07-22 at 06:40
Siegmund is offline   Reply With Quote
Old 2021-07-22, 06:47   #19
LaurV
Romulan Interpreter
 
LaurV's Avatar
 
Jun 2011
Thailand

100110001100002 Posts
Default

Quote:
Originally Posted by Zhangrc View Post
As a result, I factor every exponent I test to at least 2^77, sometimes to 2^79.
Yep, that's exactly what I mean. I do the same. But at the end, what should drive you (general you, not personal) should be the speed you eliminate exponent candidates. If you can run 150 TF assignments and find two factors per day, but it will take you more than half day to run a PRP test in the same hardware, and I mean, at the front level, not picking low hanging, large expos, low bitlevel TF assignments, than your hardware should do TF. You help the project more that way.

Last fiddled with by LaurV on 2021-07-22 at 06:52
LaurV is offline   Reply With Quote
Old 2021-07-22, 06:51   #20
kriesel
 
kriesel's Avatar
 
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

5,779 Posts
Default

Quote:
Originally Posted by LaurV View Post
you can get 5 to 10 times more "credit" if you use your GPU for TF than for PRP
Lowest I had on record from older GPU models is 12:1 (TF credit/day) / (PRP or LL or P-1 / day). https://www.mersenneforum.org/showpo...7&postcount=16 RTX20xx or GTX16xx are much higher; I think RTX30xx higher yet. (Mersenne.ca has rtx3090 at 4900 TF, ~98 PRP etc; 50:1; rtx2080 2623 TF, 62.5 PRP etc, 42:1)

Radeon VII mfakto v0.15pre6 was ~1300GHzD/day on Windows; there are benchmark results supporting up to 486/day in GpuOwl; that's 2.67:1. And noted for its incomparable PRP performance, at $700 original list, IIRC beat by a factor of 2, $2500 used Tesla P100. Some of the Teslas may have sufficiently strong DP to show low ratios also.

CPUs I've checked were 0.7 to 1.3.

Hence the general rule, TF on GPUs, PRP or P-1 or LL on CPUs.
Except on Radeon VII and other recent AMD GPUs, & maybe Teslas.

Last fiddled with by kriesel on 2021-07-22 at 07:02
kriesel is online now   Reply With Quote
Old 2021-07-23, 07:49   #21
drkirkby
 
"David Kirkby"
Jan 2021
Althorne, Essex, UK

3·149 Posts
Default

Quote:
Originally Posted by Siegmund View Post
Perhaps 2 is reasonable if a person requests a standalone P-1 assignment.
<snip>

If extra factors are found, great - it just seems the default ought to be to minimize time needed to resolve each exponent.
Having done a quick test, with results obtained after a few beers,

https://www.mersenneforum.org/showpo...7&postcount=54

which I intend doing more thoroughly when 100% sober, I'm not convinced that any value of tests_saved can really be said to maximise the throughput unless you test the P-1 timing on your computer(s). I tested the run-time of the P-1 test on my Dell PC under the same circumstances
  • Using the exponent M105216541
  • 4 workers
  • 3 workers doing PRP tests with exponents around 104-105 million (13 cores each)
  • 1 worker doing a P-1 test (13 cores)
  • Dell 7920 tower workstation with 2 x Intel Xeon 8167M CPUs.
What I found on that quick test was.
  1. Based on saving 1 primality test. B1=434000, B2=21339000. Chance of finding a factor is an estimated 3.60%. Started 15:15. Finished 16:57. Runtime = 1 hour, 42 minutes = 102 minutes. Used 207872 MB (203 GB) RAM. 9.0812 GHz days credit.
  2. Based on saving 2 primality tests. B1=889000, B2=52784000. Chance of finding a factor is an estimated 4.66%. Started 1701. Finished 22:16. Runtime = 5 hours, 15 minutes = 315 minutes. Used 311330 MB (304 GB) RAM. 21.4559 GHz days credit.
The ratio of runtimes of the P-1 tests (315/102=3.08824:1) was a lot more than the ratio of GHz days credits (21.4559/9.0812=2.36267).

Given the optimal bounds for P-1 tested are based on the calculated computational effort (GHz days), the tests_saved will not be optimal if the actual run-time of the test (in minutes) does not reflect the credit in GHz days. It changes where the optimal point is. Clearly that optimal point could depend on things such as
  1. What else is running on the machine
  2. Cache
  3. RAM
  4. Whether a CPU or GPU are used, and what model.
  5. Number or cores devoted to the task.
  6. The actual exponent
  7. FFT size, which is a function of the exponent.
  8. Bounds, B1 and B2.
  9. Phase of the moon and direction of wind flow.
  10. Things I have not thought of.
As I said, I did not do this under ideal circumstances, and therefore the results need double-checking, but I intend testing assuming the tests saved are 0.9 (if mprime accepts <1.0) and 1.1, then measuring the actual run-time of the PRP test.

IMHO it is a shame so much effort (GHz days) is being put into testing exponents well away from the wavefront. They are not really helpful in finding primes.

Last fiddled with by drkirkby on 2021-07-23 at 08:20
drkirkby is offline   Reply With Quote
Old 2021-07-23, 08:42   #22
axn
 
axn's Avatar
 
Jun 2003

22×32×11×13 Posts
Default

Quote:
Originally Posted by drkirkby View Post
I'm not convinced that any value of tests_saved can really be said to maximise the throughput unless you test the P-1 timing on your computer(s). I tested the run-time of the P-1 test on my Dell PC under the same circumstances
<snip>
The ratio of runtimes of the P-1 tests (315/102=3.08824:1) was a lot more than the ratio of GHz days credits (21.4559/9.0812=2.36267).
I do not believe the server has been adjusted to give the correct GHzDay credit for the improved P-1 Stage 2 implemented from 30.4 onwards. I believe it still assumes that the P-1 has been done by the older algorithm and credits accordingly. Hence do not draw any hard and fast conclusions based on those numbers. Ideally, due to the improved stage 2, the credit should be suitably discounted.

However, the optimality calculations done by the program itself _do_ take in account the specifics of the new algo. TL;DR dont trust the GHzDay numbers.

Last fiddled with by axn on 2021-07-23 at 08:42
axn is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Determine squares fenderbender Math 14 2007-07-28 23:24
determine hyderman Homework Help 7 2007-06-17 06:01
Methods to determine integer multiples dsouza123 Math 6 2006-11-18 16:10
Help: trying to determine latency on movaps instructions on AthlonXP LoKI.GuZ Hardware 1 2004-01-26 20:05
How to determine the P-1 boundaries? Boulder Software 2 2003-08-20 11:55

All times are UTC. The time now is 13:04.


Mon Oct 18 13:04:56 UTC 2021 up 87 days, 7:33, 0 users, load averages: 1.96, 1.58, 1.62

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.