mersenneforum.org How to read the "Exponent Status Distribution"
 User Name Remember Me? Password
 Register FAQ Search Today's Posts Mark Forums Read

2020-07-21, 00:50   #12
jwnutter

Oct 2019
United States

32×7 Posts

Quote:
 Originally Posted by nemonusquam Those are "small" primes, fast to generate. Remember, the primes are from 111000007 to 111999997 and not from 2^111000007-1 to 2^111999997-1 which, if prime, is a Mersenne prime. nemonusquam
Thank you nemonusquam. This is exactly what I was not considering. Thank you.

Last fiddled with by jwnutter on 2020-07-21 at 00:51

2020-07-21, 01:23   #13
Uncwilly
6809 > 6502

"""""""""""""""""""
Aug 2003
101×103 Posts

26×33×5 Posts

Quote:
 Originally Posted by jwnutter From these links https://www.mersenne.org/various/mat...rial_factoring and https://www.mersenne.org/report_expo...2918073&full=1 I can see that TF'ing is completed in stages (though the factoring cost appears to have changed slightly since this table was published based on my testing interval of 73 to 74 on exponents in the 111M range) with each stage generally assigned out over the course of many years (Moore's Law at work I assume).
A lot of those assignments over the years were being done by old slow machines. Doing the lowest bit levels was something they could accomplish in short enough time and help a little. They went through all of the exponents at one bit level, then through to the next one. That task also does not stress the CPU as much as a primality check.

Quote:
 Back to my example question. How are the various bit levels captured in the Assigned and Available TF data fields? In other words, what are the units of Assigned/Available TF? Is 1 Assigned TF equal to 1 Range Count in terms of units, if that makes sense? Or, is 1 Assigned TF equal to 1 bit level of 1 Range Count? I'm sorry these questions might not make any sense at all, but I'm trying to understand what I'm looking at in the Exponent Status Distribution vs. what my CPUs/GPUs are actually telling me they are working on at the moment.
The range count is the total number of exponents that we need to test. (We normally use the term exponents when talking about them.) In your example you have 6000 exponents assigned to you. If you suddenly gave them up, there would be 6000 more in the available column. Depending on how they were reserved, you could have them for 1 or more bit levels. Still the count on the table is just for the number of exponents. The closer that the first time primality tests get to a bunch of exponents, the bigger the push to have them at the optimum TF bit level (effectively where investment of a single extra bit level would cost [overall] more than it is worth in saved tests). If you look here: https://www.mersenne.ca/status/tf/0/0/4/11100 you will see that level as the yellow column. (GPUs have changed where this is. They have moved the bit level up by 2 or 3 generally.

Search the forum for answers or ask questions.

2020-07-21, 15:18   #14
jwnutter

Oct 2019
United States

6310 Posts

Quote:
 Originally Posted by Uncwilly Still the count on the table is just for the number of exponents. The closer that the first time primality tests get to a bunch of exponents, the bigger the push to have them at the optimum TF bit level
This makes sense. Thank you for the clarification.

That said, it seems a bit misleading - to me anyway. As an example, if the current goal is to factor exponents in the 111M range to a bit level of 77 (let's make this assumption for this example) and the exponent 111,000,007 was factored to 77 with no factors (however, I realize this is a false statement) and 111,000,031 to a bit level of 75 with no factors wouldn't 111,000,007 need to appear in a list of available exponents to TF twice (once for a bit level of 76 and then again for a bit level of 77) to reach the desired end state of having all 111M exponents factored to a bit level of 77? However, based on my current understanding (which could be very inaccurate), both exponents (111,000,007 and 111,000,031) would appear in the Assigned TF field once when only one exponent (111,000,007) was "fully" factored to 77.

This is all really cool stuff. Once I have a quasi-complete understanding of the Exponent Status Distribution I'll work on developing my understanding of the data tables provided here: https://www.mersenne.ca/exponent/102918073.

Thanks again, Uncwilly. You seem to be answering a lot of my questions on a variety of topics. When would you like to have that beer?

2020-07-21, 15:47   #15
kriesel

"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest

4,457 Posts

Quote:
 Originally Posted by Uncwilly They have moved the bit level up by 2 or 3 generally..
The difference between PrimeNet goal (cpu trial factoring) and GPUto72 (gpu trial factoring) target levels is typically 4 bit levels, as in https://www.mersenne.ca/exponent/111000031
Arguments have been made that with the advent of RTX20xx and GTX16xx, the differential ought be increased to 5 bit levels. The bit level increment thought optimum for use of the same gpu, is log2(TF GhzD/day / primality testing GhzDday), or for RTX2080 Super, approx log2(3072/73.9) = log2(41.57) =5.38 bit levels. For Radeon VII it's log2( 1113.6 / 280.9) = 1.99 bit levels. A reasonable compromise when using each gpu type for what it's relatively best at is to do TF 4-5 bits additional on NVIDIA and P-1 and primality testing on Radeon VII. Benchmarks from https://www.mersenne.ca/mfaktc.php and https://www.mersenne.ca/cudalucas.php)

But in regard to jwnutter's question, why aren't each TF level of each exponent counted, in https://www.mersenne.org/primenet/ Word distribution map.

a) there's no way to predict that total, other than some statistically informed guesses.

b) think "a prime is a prime is a prime". Finding a factor early is good, saving a lot of further work, retiring the prime exponent from further consideration. Additional bit levels would not normally be trial factored in that case. P-1 not performed. Primality testing not performed. Primality test verification not performed. Completing a TF bit level with no factor found does not eliminate an exponent from further consideration. It only crosses off a small bit of work from the to do list.

c) not all TF levels are equal. In fact, they're approximately exponentially related. If doing 73 to 74 is one unit of effort, 74 to 75 is about twice as much, 75 to 76 about 4 times as much, 76 to 77 about 8 times as much, 77 to 78 about 16 times as much.
d) the report is about exponent status, not smallest-individual-assignment-possible status

There's much more about trial factoring at https://www.mersenneforum.org/showpo...23&postcount=6

Last fiddled with by kriesel on 2020-07-21 at 16:00

2020-07-21, 17:00   #16
chalsall
If I May

"Chris Halsall"
Sep 2002
Barbados

2×4,657 Posts

Quote:
 Originally Posted by kriesel Arguments have been made that with the advent of RTX20xx and GTX16xx, the differential ought be increased to 5 bit levels.
To add to the complexity is resource availability.

Before Ben entered the space, the TF'ing effort was actually comfortably ahead of the LL'ing (and P-1'ing) effort (at all four "wavefronts"), and pulling ever further ahead.

Now we're "surfing the waves" quite tightly. Literally "just in time" in some situations.

2020-07-21, 17:59   #17
jwnutter

Oct 2019
United States

1111112 Posts

Quote:
 Arguments have been made that with the advent of RTX20xx and GTX16xx, the differential ought be increased to 5 bit levels. The bit level increment thought optimum for use of the same gpu, is log2(TF GhzD/day / primality testing GhzDday), or for RTX2080 Super, approx log2(3072/73.9) = log2(41.57) =5.38 bit levels.
Very interesting. Though I've found the mfaktc benchmarks for GhzD/day to be 15% - 20% lower than my empirically derived actuals for the RTX2080 Super. On that note (and this is likely not the right place to ask this question), will the current slate of GPU tools (mfaktc, gpuOwl, CUDALucas, etc.) be available for the NVIDIA Ampere series of GPUs scheduled for release in mid-September? https://www.pcgamer.com/nvidia-amper...s-performance/

Quote:
 a) there's no way to predict that total, other than some statistically informed guesses.
Agree, I did not intend to imply that a bit level of 77 would be a constant. That said, it would seem as though this value would approach a constant as primality testing approached the traunch of exponents being TF'ed. To me anyway, a worst case scenario would be TF work bottlenecking primality testing. That said, I still have a lot to learn about this report: https://www.mersenne.ca/exponent/102918073. I'm simply trying to logic through the process with information acquired to date so many of my assumption may be entirely off-base.

Quote:
 b) think "a prime is a prime is a prime". Finding a factor early is good, saving a lot of further work, retiring the prime exponent from further consideration. Additional bit levels would not normally be trial factored in that case. P-1 not performed. Primality testing not performed. Primality test verification not performed. Completing a TF bit level with no factor found does not eliminate an exponent from further consideration. It only crosses off a small bit of work from the to do list.
Understood.

Quote:
 c) not all TF levels are equal. In fact, they're approximately exponentially related. If doing 73 to 74 is one unit of effort, 74 to 75 is about twice as much, 75 to 76 about 4 times as much, 76 to 77 about 8 times as much, 77 to 78 about 16 times as much.
Very interesting. As mentioned above, work is somewhat relative to hardware performance. Early reports of the Nvidia Ampere indicate sizable performance gains (+50% over the RTX2080Ti) and up to twice as efficient vs the Turing cards. That said, most of the information I've found is very speculative at this point. But here are some articles if you're interested:

https://www.techradar.com/news/nvidia-ampere

https://www.techradar.com/news/nvidi...ve-amd-worried

https://www.techradar.com/news/rtx-3080

https://www.pcgamer.com/nvidia-amper...ot-aging-well/

https://www.pcgamer.com/nvidia-amper...s-performance/

Quote:
 d) the report is about exponent status, not smallest-individual-assignment-possible status
Got it. I did not intend to imply the information contained in this report was inaccurate. My point was that two TF assignments in the same exponent may not be equal in terms of TF work complete to date. And maybe this isn't important, but it helps me better understand the data that's presented.

2020-07-21, 18:04   #18
jwnutter

Oct 2019
United States

32·7 Posts

Quote:
 Originally Posted by chalsall To add to the complexity is resource availability. Before Ben entered the space, the TF'ing effort was actually comfortably ahead of the LL'ing (and P-1'ing) effort (at all four "wavefronts"), and pulling ever further ahead. Now we're "surfing the waves" quite tightly. Literally "just in time" in some situations.
I was not aware of this, but you hit the nail on the head Chris. Thanks!

2020-07-21, 18:28   #19
Uncwilly
6809 > 6502

"""""""""""""""""""
Aug 2003
101×103 Posts

26·33·5 Posts

Quote:
 Originally Posted by jwnutter Agree, I did not intend to imply that a bit level of 77 would be a constant.
Another factoid to consider. As the size of the exponent goes up, the effort required to get to a given bit level goes down. Factors for numbers of the form 2p-1 must be in the form of 2*k*p +1
As the p goes up, the number of potential factors below a given size goes down. That is why we factor we can factor them to higher bit levels quicker. Add that to Ken's formula for how much effort to apply and the bit levels really zoom up. As seen here in the smooth curved lines: https://www.mersenne.ca/graphs/facto...M_20200721.png

2020-07-21, 19:39   #20
jwnutter

Oct 2019
United States

778 Posts

Quote:
 Originally Posted by Uncwilly Another factoid to consider. As the size of the exponent goes up, the effort required to get to a given bit level goes down. Factors for numbers of the form 2p-1 must be in the form of 2*k*p +1 As the p goes up, the number of potential factors below a given size goes down. That is why we factor we can factor them to higher bit levels quicker. Add that to Ken's formula for how much effort to apply and the bit levels really zoom up. As seen here in the smooth curved lines: https://www.mersenne.ca/graphs/facto...M_20200721.png
Learning about this stuff truly is like drinking from a fire hose. This is likely the only forum I've ever posted to in my life (this statement may not be 100% accurate, but it's very close). So, I appear to have quickly gone from zero participation to something significantly higher in just a few weeks. What I've learned during this process is that my historic lack of participation was likely a big plus to my social and financial well-being. I will likely be forced to limit my use of this forum very soon as I'm currently unable to stop asking questions and consuming the available content.

I think I understand part of this chart, but what do the lines represent (green, blue, red, and black scatter). Based on the sudden decline at 100M I'm assuming the black scatter represents known factor bit levels, which appears to match up with current TF assignments here https://www.mersenne.org/primenet/. But I still don't understand the other curves (green, blue, and red). And I guess I don't fully understand this comment: "That is why we factor we can factor them to higher bit levels quicker." Does this mean that as the exponent gets larger specific lower bit levels are ignored? (insert mind exploding emoji here).

You bring up an interesting point that I was going to ask this group the other day but forgot (and now I'm getting a bit off topic - my apologies). Earlier this month when testing my GPU I noticed that I was able to get around 4,000 ghz-d/d when TF'ing exponents in the 333M range to a bit level of 75. This output is about 15% higher than what I'm seeing today while testing 111M exponents to 74. I'm not sure why, but for some reason this seemed very strange to me. Any thoughts?

2020-07-21, 20:35   #21
Uncwilly
6809 > 6502

"""""""""""""""""""
Aug 2003
101×103 Posts

100001110000002 Posts

Quote:
 Originally Posted by jwnutter I think I understand part of this chart, but what do the lines represent (green, blue, red, and black scatter). Based on the sudden decline at 100M I'm assuming the black scatter represents known factor bit levels, which appears to match up with current TF assignments here https://www.mersenne.org/primenet/. But I still don't understand the other curves (green, blue, and red). And I guess I don't fully understand this comment: "That is why we factor we can factor them to higher bit levels quicker." Does this mean that as the exponent gets larger specific lower bit levels are ignored? (insert mind exploding emoji here).
Here is the better view I was looking for earlier (the legend is easier to read).
https://www.mersenne.ca/graphs/facto...M_20200721.png
The lines represent different goal levels. The orangeish red line is the level that the Prime95 program would take and exponent to. The blue line is the 2-3 bits more than that that the average GPU should do. The green line is the 5 bits higher that Ken talked about. The black dots show where the exponents currently are. That drop off is the riding the wave that Chris (chalsall) was talking about. If we could not do all of them up to desired bit level to keep ahead of the wave, we could dump a bunch at 1 or 2 bits lower to keep the beast fed.

Let's look at some specific examples for the bit levels.
2^3321937-1 (The first exponent when expanded is 1,000,000 decimal digits)
2^33219283-1 (The first exponent when expanded is 10,000,000 decimal digits)
2^332192831-1 (The first exponent when expanded is 100,000,000 decimal digits)

The smallest possible factor for each is 2*1*p+1
That red 1 is the smallest 'k' value possible.
Doing the math that is (in binary)
110 0101 0110 0000 1010 0011 for the first number (23 bits)
11 1111 0101 1100 0101 1010 0111 (26 bits) for our second example.
10 0111 1001 1001 1011 1000 0111 1111 (30 bits) for our third example.
Those are our starting levels.
1111 0111 1000 0000 1100 0001 0001 0011 1001 (36 bits, 66,438,566,201 base 10) is the size of k=100 for our third number.

So, there is no point (and no way in the method being used) to check for 29 bit factors for our third number. So we are starting 7 bits higher than for the first example.
There are other math tricks to eliminate potential factors with out testing them too.

Quote:
 Earlier this month when testing my GPU I noticed that I was able to get around 4,000 ghz-d/d when TF'ing exponents in the 333M range to a bit level of 75. This output is about 15% higher than what I'm seeing today while testing 111M exponents to 74. I'm not sure why, but for some reason this seemed very strange to me. Any thoughts?
There are various reasons why different ranges have different efficiencies on different hardware. But what you are seeing is normal. There is overhead in starting a test. And since you are running at a higher range you could be running at a lower k range and get some extra speed from that.

And BTW, the really high factors are being found by P-1 which can find some crazy big factors.

2020-07-24, 09:10   #22
LaurV
Romulan Interpreter

Jun 2011
Thailand

19×461 Posts

Quote:
 Originally Posted by jwnutter Though I've found the mfaktc benchmarks for GhzD/day to be 15% - 20% lower than my empirically derived actuals for the....
That is true, and expected. The reason is that the most of the cards sold today are overclocked (factory, or by the user) compared with chip specs. So, when James receives those benchmark figures, they fill all the OC and UC spectrum (edit: yes, some people also UC, the reason is energy saving, better efficiency, less heat, less noises), therefore the has to "scale" them with clocking. So, the tables have to be read like "assuming your card runs at the clock specified in its datasheet". Most probably, your card is factory-OC by those 15%-20% (true for "super" cards). If you water-cool and OC (as in my case) then you can find differences up to 30% and even 50% compared with those tables (depending on the card, system, etc).

Last fiddled with by LaurV on 2020-07-24 at 09:17

 Thread Tools

 Similar Threads Thread Thread Starter Forum Replies Last Post heliosh Information & Answers 6 2020-07-20 19:27 pinhodecarlos NFS@Home 2 2015-07-04 11:18 James Heinrich Data 2 2012-02-01 21:14 ixfd64 Lounge 3 2004-05-27 00:51 ixfd64 Lounge 0 2003-10-14 23:04

All times are UTC. The time now is 16:57.

Wed Sep 30 16:57:43 UTC 2020 up 20 days, 14:08, 0 users, load averages: 1.74, 1.83, 1.77

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, 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.