mersenneforum.org mfaktc: a CUDA program for Mersenne prefactoring
 Register FAQ Search Today's Posts Mark Forums Read

2020-10-19, 12:34   #3367
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

2×2,383 Posts

Quote:
 Originally Posted by LaurV Oh, you mean the other way around... Never tried that, because I always stop after class, but it should be easy to try, just take a factor line already reported and edit the asterisk. I will try when I reach home in about one hour (still at job).
A) what are you talking about? "edit the asterisk"?
B) shouldn't be necessary to manually intervene. What about people who use Misfit or mfloop etc.?
C) ... especially since completing the bit level is the mfaktc default configuration. (But not mfakto)
mfaktc ini file as distributed in zip file:
Code:
# Allow to split an assignment into multiple bit ranges.
# 0 = disabled
# 1 = enabled
# Enabled Stages make only sense when StopAfterFactor is 1 or 2.
# Do not change this in the middle of a run which spans over multiple
# bitlevels, in this case mfaktc will ignore the checkpoint file and
# restarts from the beginning.
#
# Default: Stages=1

Stages=1

# possible values for StopAfterFactor:
# 0: Do not stop the current assignment after a factor was found.
# 1: When a factor was found for the current assignment stop after the
#    current bitlevel. This makes only sense when Stages is enabled.
# 2: When a factor was found for the current assignment stop after the
#    current class.
#
# Default: StopAfterFactor=1

StopAfterFactor=1
mfakto ini file as distributed in zip file:
Code:
# Allows you to split an assignment into multiple bit ranges.
# Note that many mfakto-kernels can handle only one bit level at a time,
# i.e. in order to use them, Stages needs to be enabled.
# 0 = disabled
# 1 = enabled
# Enabled Stages make only sense when StopAfterFactor is 1 or 2.
#
# Default: Stages=1

Stages=1

# possible values for StopAfterFactor:
# 0: Do not stop the current assignment after a factor was found.
# 1: When a factor was found for the current assignment stop after the
#    current bitlevel. This makes only sense when Stages is enabled.
# 2: When a factor was found for the current assignment stop after the
#    current class.
#
# Default: StopAfterFactor=2

StopAfterFactor=2
D) Finishing the bit level makes more sense to me, because it leaves the database cleaner, with completed bit levels, not partially completed, so the folks that like to overfactor or completely factor Mersenne numbers don't need to either repeat trial factoring work already performed, or gamble by skipping part of a bit level.
E) The assignment is by bit level. Finish the assignment seems like the right thing to do.
F) The first factor found is not necessarily the smallest, since factoring on gpus is done class by class, not in ascending k order.
Attached Thumbnails

Last fiddled with by kriesel on 2020-10-19 at 13:27

2020-10-19, 12:39   #3368
James Heinrich

"James Heinrich"
May 2004
ex-Northern Ontario

2×1,601 Posts

Quote:
 Originally Posted by LaurV Oh, you mean the other way around... Never tried that, because I always stop after class, but it should be easy to try, just take a factor line already reported and edit the asterisk. I will try when I reach home in about one hour (still at job).
Please don't encourage submission of faked results. You really should know better than that.

 2020-10-19, 12:45 #3369 James Heinrich     "James Heinrich" May 2004 ex-Northern Ontario 320210 Posts In terms of GIMPS, stopping immediately after a factor is the efficient thing to do, (it's not prime, QED). Somebody might eventually extend factoring, but they're already "wasting time" (in terms of prime finding) so redoing a bit level is not unexpected. Primenet assignments are to TF from X to Y, or until a factor is found. Prime95 will not finish the bit level.
 2020-10-19, 13:34 #3370 kriesel     "TF79LL86GIMPS96gpu17" Mar 2017 US midwest 2·2,383 Posts Finding factors is frequent, more than daily in my case and no doubt for some others too. Here's another case of reduced credit for a factor found: processing: TF factor 24706114790941063870961 for M114010123 (274-275) CPU credit is 12.9969 GHz-days. processing: TF no-factor for M114010289 (274-275) CPU credit is 33.5587 GHz-days. Finding a factor is the exception, not the rule. And multiple factors in a bit level is an exception within that. Prime95 behavior is sorta moot now that almost all factoring is done on gpus, but it used to look for additional factors. Some excerpts from whatsnew.txt: Code: New features in Version 28.3 of prime95.exe ------------------------------------------- 4) Information added to result lines containing "has a factor". This information may be used by the server's manual web page to give proper TF / P-1 / ECM cpu credit at a future date. New features in Version 23.9 of prime95.exe ------------------------------------------- 2) A bug in continuing after finding a factor when using AdvancedFactor was fixed. New features in Version 20.3 of prime95.exe ------------------------------------------- 3) Prime95 no longer searches for a smaller factor when trial factoring discovers a factor. The reasons are two-fold. 1) Version 19 had a bug where stopping and restarting the program bypassed the search for smaller factors. Thus, my database may already be missing smaller factors. 2) As we factor larger exponents to a deeper depth it may no longer be a quick job to determine if there are smaller factors. Note, that version 20 will still look for smaller factors if you are looking for factors below 2^60 with the FactorOverride option in undoc.txt. The FactorOverride seems to be gone from undoc.txt. The prime95 undoc.txt seems not to have any control for behavior upon finding a factor, or say what is the default behavior, stop upon factor, or finish the class or bit level or worktodo uppermost level. ECM retains an explicit control for finding additional factors. Single or multiple factors may be found by a single P-1 GCD in either stage 1 or 2. Some excerpts from undoc.txt: Code: By default, ECM will stop when a new factor is found. You can have ECM always stop or always continue searching for factors by using a value of zero or one in prime.txt: ContinueECM=n You can force the program to skip the trial factoring step prior to running a Lucas-Lehmer or PRP primality test. In prime.txt add this line: SkipTrialFactoring=1 You can tune trial factoring performance with several prime.txt settings. Probably only the first parameter below is worth tuning: MaxTFSievePrime=x (default is 155000 on AVX512 CPUs, 145000 on FMA CPUs, 1000000 otherwise) The TF code uses a small prime sieve to eliminate composite trial factors. Set x to the maximum small prime used by this sieve. MaxTFSievePrime is limited to the range of 5,000 to 100,000,000. ThreadsPerTFPool=n (default is number of hyperthreads) When multithreading, set n to the number of threads to group together in a "pool". Pooling ensures that both sieving and trial factoring will be done by threads within the same pool. Thus, if the threads share a cache, locality is increased. For example, on Knights Landing the best setting is 8 because 2 cores with 4 hyperthreads each share an L2 cache. PercentTFSieverThreads=y (default is 50) When multithreading TF, set y to be the percentage of threads in each pool that can be running the small prime sieve. NOTE: If y is set to 100, then pooling is turned off. That is, each thread sieves and then immediately TFs. While this offers perfect locality, it gives slightly worse performance and I cannot explain why. My best theory is that pooling improves usage of the instruction cache. UseMaxSieverAllocs=0, 1, 2,or 3 (default is 3) If UseMaxSieverAllocs is 1 then at least 7 sievers will be allocated, resulting in a 14% reduction in single-threaded sieving. If UseMaxSieverAllocs is 2 then at least 60 sievers will be allocated, resulting in a further 9% reduction in sieving. If UseMaxSieverAllocs is 3 then at least 720 sievers will be allocated, resulting in a further reduction of 7%. The downside is more memory is required and initialization of each of the 16 factoring passes is slower. Allocating a lot of sievers can be detremental when factoring to low bit levels. AlternateTFSieveCount=z (default is 9) On AVX2 and AVX512 cpus, the code can sieve for small primes using either traditional x86 instructions or using AVX2/AVX512 instructions. As sieve primes get larger, the x86 code is faster than the AVX2/AVX512 code. Set z to the number of blocks of small primes to use the AVX2/AVX512 code path. On my AVX2 Skylake cpu the optimal block count is 9. Using too large a value here can result in memory corruption depending on the MaxTFSievePrime setting. Last fiddled with by kriesel on 2020-10-19 at 13:50
2020-10-19, 17:18   #3371
LaurV
Romulan Interpreter

Jun 2011
Thailand

100011000000112 Posts

Quote:
 Originally Posted by James Heinrich Please don't encourage submission of faked results. You really should know better than that.
Nope, sorry, that wasn't my intention. I only suggested it like a "fast test". Unfortunately (or fortunately?) I didn't do anything yet, in this direction (quite busy at job, then I forgot). In case I will do this test, I will still finish the bitlevel, just to be sure I don't let the garbage in the DB. Probably later. FWIW, reporting a known factor (i.e. removing the asterisk from a line already sent and sending it again without it) doesn't work (error: factor not needed). So it needs a "new" factor for a trial.

@kriesel: All you said was clear already. We KNOW than the credit is smaller when you find a factor, IF you stop after the factor is found. And this is normal, as you do less work. The question was what's the credit if you DON'T stop (and finish all the bitlevel). You should still get all the credit, factor or no factor, but this I didn't know if true. On the other hand (and this everybody knows for ages!), the difference between two lines that report respectively "i found one factor and I stopped after that class" and "I found one factor but I still continued the rest of the classes till the bitlevel ended", is just one asterisk (which you can edit with a text editor, if you want to test, or if you want to cheat the system and get more credit). That's what I (and James) am (are) talking about. Moreover, you just post some rubbish from some doc files, with no connection to the subject. Not P95 neither mfakt[c/o] gives you the credit, but the server... This has nothing to do with whatever you set in your ini files.

Last fiddled with by LaurV on 2020-10-19 at 17:35

2020-10-19, 18:09   #3372
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

2×2,383 Posts

Quote:
 Originally Posted by LaurV @kriesel: All you said was clear already. We KNOW than the credit is smaller when you find a factor, IF you stop after the factor is found. And this is normal, as you do less work. The question was what's the credit if you DON'T stop (and finish all the bitlevel). You should still get all the credit, factor or no factor, but this I didn't know if true. On the other hand (and this everybody knows for ages!), the difference between two lines that report respectively "i found one factor and I stopped after that class" and "I found one factor but I still continued the rest of the classes till the bitlevel ended", is just one asterisk (which you can edit with a text editor, if you want to test, or if you want to cheat the system and get more credit). That's what I (and James) am (are) talking about.
LaurV, you are pointlessly belaboring the other case, mfaktO default, stopafterfactor=2 (stop after current class) correctly getting lesser credit, which is not at issue here. What is at issue is mfaktC default stop after current bit level getting credit for only stop after current class, incorrectly reduced.

Mfaktc separately reports the factor(s) and the bit level completed.

I posted an excerpt from mfaktc.ini at https://mersenneforum.org/showpost.p...postcount=3359 showing I DO go to the full bit level regardless, as is mfaktc default configuration.
And examples in https://mersenneforum.org/showpost.p...postcount=3367 and https://mersenneforum.org/showpost.p...postcount=3370 where doing so and finding a factor results in REDUCED credit. Also note in the first attachment of 3367, the more than an hour delay between the factor and the completion of the bit level, on an RTX2080 Super (1 of 3 instances running together).
I can back that up with logging of all classes run after the one or more that contained a factor.
Code:
Starting trial factoring M114969319 from 2^75 to 2^76 (66.56 GHz-days)
k_min =  164300059317240
k_max =  328600118636496
Using GPU kernel "barrett76_mul32_gs"
Date    Time | class   Pct |   time     ETA | GHz-d/day    Sieve     Wait
Oct 18 14:58 |    0   0.1% |  5.967   1h35m |   1003.89    82485    n.a.%
Oct 18 14:58 |    5   0.2% |  5.620   1h29m |   1065.87    82485    n.a.%
...
Date    Time | class   Pct |   time     ETA | GHz-d/day    Sieve     Wait
Oct 18 15:35 | 1640  35.5% |  6.534   1h07m |    916.77    82485    n.a.%
Oct 18 15:35 | 1641  35.6% |  6.847   1h10m |    874.86    82485    n.a.%
M114969319 has a factor: 61735152791358058725319
Oct 18 15:36 | 1644  35.7% |  7.137   1h13m |    839.31    82485    n.a.%
Oct 18 15:36 | 1649  35.8% |  7.136   1h13m |    839.43    82485    n.a.%
...

Oct 18 16:47 | 4616  99.9% |  6.290   0m06s |    952.33    82485    n.a.%
Oct 18 16:47 | 4617 100.0% |  6.689   0m00s |    895.53    82485    n.a.%
found 1 factor for M114969319 from 2^75 to 2^76 [mfaktc 0.21 barrett76_mul32_gs]
tf(): total time spent:  1h 49m 23.377s
In that case it gave neither 100% bitlevel credit, nor 35.6% current-class credit, but 47.1568 / 66.56 = 70.85% instead of the 100% due.

In both example cases I am also using the standard default mfaktc output format.
James has offered to look into the reduced-credit-for-full-bit-level situation which I've also emailed to him.

It ought work correctly for a default mfaktc ini file, and does not, and that is both documented, and independently confirmed.

What is not documented is the asterisk you refer to; where does it go, what does such output look like, how does it differ from mfaktc default output, what custom mfaktc format would generate it, if it's necessary for proper credit why isn't it part of the default mfaktc output format, etc. EXACTLY.

Last fiddled with by kriesel on 2020-10-19 at 18:54

 2020-10-19, 18:10 #3373 James Heinrich     "James Heinrich" May 2004 ex-Northern Ontario 2×1,601 Posts If you can hold off the urge to test things for 12h I can look at the code and see what it's doing.
 2020-10-19, 18:14 #3374 James Heinrich     "James Heinrich" May 2004 ex-Northern Ontario 2×1,601 Posts Asterisk is documented. I asked for it maybe 5 years ago. Search way back in this thread somewhere. edit: You already participated in a discussion on the asterisk and bitrange completion 2.5 years ago Last fiddled with by James Heinrich on 2020-10-20 at 01:12
2020-10-20, 00:51   #3375
James Heinrich

"James Heinrich"
May 2004
ex-Northern Ontario

2·1,601 Posts

Quote:
 Originally Posted by kriesel James has offered to look into the reduced-credit-for-full-bit-level situation which I've also emailed to him.
So I've looked at the manual_results code and you are indeed correct: TF credit is only given as far as where Prime95 would have found the factor. The TF-credit calculating code is somewhat buried and I'm not sure I want to mess with it, however the manual form was already detecting whether the range was completed or not so it was easy to patch in a full-credit override when a factor is found the but bitrange finished anyways.

So, somebody please find a new TF factor (while finishing the bit level) and let me know if you get appropriate full-level credit or not now.

2020-10-20, 01:12   #3376
James Heinrich

"James Heinrich"
May 2004
ex-Northern Ontario

2×1,601 Posts

Quote:
 Originally Posted by James Heinrich Asterisk is documented. I asked for it maybe 5 years ago. Search way back in this thread somewhere.
After some digging I found the original suggestion, on page 113 of this (currently 306-page) thread, from 2011-Sep-27:
It was soon-after included in mfaktc v0.18 and mfakto v0.10

Last fiddled with by James Heinrich on 2020-10-20 at 01:13

2020-10-20, 12:20   #3377
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

112368 Posts

Quote:
 Originally Posted by James Heinrich So, somebody please find a new TF factor (while finishing the bit level) and let me know if you get appropriate full-level credit or not now.
Not. Credit still reduced. Emailing details. Thanks for your efforts, as always.

edit: But interestingly, https://www.mersenne.org/results/?ex..._hi=&limit=100 shows full credit, for the same factor-found line as shows reduced credit in the manual submission form results output.

Last fiddled with by kriesel on 2020-10-20 at 12:46

 Similar Threads Thread Thread Starter Forum Replies Last Post MrRepunit GPU Computing 32 2020-11-11 19:56 Bdot GPU Computing 1657 2020-10-27 01:23 firejuggler GPU Computing 752 2020-09-08 16:15 keisentraut Software 2 2020-08-18 07:03 fivemack Programming 112 2015-02-12 22:51

All times are UTC. The time now is 06:45.

Sat Dec 5 06:45:47 UTC 2020 up 2 days, 2:57, 0 users, load averages: 1.50, 1.36, 1.42