![]() |
[QUOTE=Rodrigo;223564]How about 190M? [URL]http://www.mersenne.info/?s=100000000&d=1&t=1[/URL][/QUOTE]
That range is about to start being handed out by the server to those who have selected "LMH - TF" on the client. So, to answer your question in the negative, why don't you do what we've been advising you do for some time, and simply select "LMH - TF" on your client and let the system do what it was designed to do? [QUOTE=Rodrigo;223564]Which leads me to something I'd been meaning to ask. After all these years and with so many people participating, why is there (apparently) still so much work left undone in the very low ranges? (I.e., [URL]http://www.mersenne.info/?s=0&d=2&t=1[/URL] ) No doubt there is a good reason.[/QUOTE] Indeed there is... Remember we told you earlier that the smaller the exponent, the longer TFing takes. Besides, all those low numbers have already been LLed and DCed, so from the project's main objective (finding primes) there is no point in doing additional work on them. Not to say that you can't, however; and some do and are. But keep in mind it would take your slow machines months to move a single low exponent up by one factor depth, with *very* little chance of finding a factor (because of the PM-1 and possibly EMC factoring attempts done on them). |
chalsall,
Thanks for the explanation. I suspected it might have something to do with it taking longer to TF a smaller exponent; just wanted to make sure my suspicion was warranted. :smile: Yes, LMH-TF does look more and more like the place to go. Things were up in the air for a bit because we were considering OBD, but that's looking less likely now for the P75. I've signed up the first of my computers to do work, and will be adding each of the others in turn as I get better acquainted with the process. In fact I'll be starting a new thread shortly with a couple of questions about the program settings. But it's already churning away! Gratefully, Rodrigo |
[quote=Primeinator;223525]I think all of those exponents have been factored past 62 bits (which, if I remember correctly, was the limit of what your oldest machine is capable of).[/quote]
Primeinator, How can I look up what that limit is? Thanks! Rodrigo |
There is a little table on here:
[url]http://www.mersenne.org/various/math.php[/url] I'll reproduce it here slightly edited:[code] Exponents Bit up to depth --------- ----- 3960000 60 5160000 61 6515000 62 8250000 63 13380000 64 23390000 65 29690000 66 37800000 67 47450000 68 58520000 69 75670000 70 96830000 71[/code]This relationship between log(exponent) and bit depth is roughly linear, with a bit of a kink around 64 and 65 bits. If you plot the log of the exponent against the bit depth (log to base 2 of the trial factor to depth), you get a nice straight line from a bit depth of 65 onwards. I added a trend line to that and the equation was this: ln(E) = 0.2346*D + 1.7171 Where E is the exponent and D is the bit depth. So using this, it's tentatively possible to extend the table, but whether or not this linear relationship should continue I don't know. Assuming it does, here's what the numbers would be:[code] Exponents Bit up to depth --------- ----- 23390000 65 29690000 66 37800000 67 47450000 68 58520000 69 75670000 70 96830000 71[color=red] 120640000 72 152530000 73 192860000 74 243860000 75 308340000 76 389860000 77 492940000 78 623280000 79 788070000 80 996440000 81 1259900000 82 1593020000 83 2014220000 84 2546790000 85 3220170000 86 4071590000 87[/color][/code]So it seems as though Operation Billion Digits should be taking numbers to 87 bits, and currently there are 10 (soon to be 13) exponents that are at 81 bits. Also, the first lot of 100 million digit candidates should be trial factored to 77 bits. Once again, I do not know if this linear relationship between exponent and trial factor depth should continue. So take it with a pinch of salt until someone who actually knows something about it makes a comment. |
[QUOTE=lavalamp;223641]I added a trend line to that and the equation was this:
ln(E) = 0.2346*D + 1.7171 Where E is the exponent and D is the bit depth. So using this, it's tentatively possible to extend the table, but whether or not this linear relationship should continue I don't know. Assuming it does, here's what the numbers would be:[code] Exponents Bit up to depth --------- ----- 23390000 65 29690000 66 37800000 67 47450000 68 58520000 69 75670000 70 96830000 71[color=red] 120640000 72 152530000 73 192860000 74 243860000 75 308340000 76 389860000 77 492940000 78 623280000 79 788070000 80 996440000 81 1259900000 82 1593020000 83 2014220000 84 2546790000 85 3220170000 86 4071590000 87[/color][/code]So it seems as though Operation Billion Digits should be taking numbers to 87 bits, and currently there are 10 (soon to be 13) exponents that are at 81 bits. Also, the first lot of 100 million digit candidates should be trial factored to 77 bits. Once again, I do not know if this linear relationship between exponent and trial factor depth should continue. So take it with a pinch of salt until someone who actually knows something about it makes a comment.[/QUOTE] Close enough. The rule of thumb is, doubling of exponent = 3 more bits. If you make it so that the bit depth changes are aligned to FFT size changes, that should be good enough. But since we're looking at only the OBD exponents, the figure 87 bits should be within +/- 1 bit of optimal. Since P-1 is not yet practical on these size exponents, maybe that number can be increased. |
[QUOTE=lavalamp;223641]Also, the first lot of 100 million digit candidates should be trial factored to 77 bits.[/QUOTE]That is what George says.:geek:
|
[QUOTE=axn;223642]If you make it so that the bit depth changes are aligned to FFT size changes, that should be good enough.[/QUOTE]I don't suppose there's a list of these somewhere, or some method to work out what size exponents fit into what size FFT? The benchmark page on mersenne.org only gives exponent ranges for FFT sizes up to 4M, but I know that Prime95 runs to at least 32M.
I wasn't only looking at OBD exponenets by the way, I just gave them a special mention, along with the 100 million digit candidates. |
1 Attachment(s)
[QUOTE=lavalamp;223654]I don't suppose there's a list of these somewhere, or some method to work out what size exponents fit into what size FFT?[/QUOTE]You will find the FFT size for all exponent ranges up to 596M in the source code. I attach an zipped excel file for those to lazy to look it up.
Jacob |
[quote=axn;223642]The rule of thumb is, doubling of exponent = 3 more bits.[/quote]
This can be understood simply: Doubling the exponent quadruples the time for an LL test, and halves the number of trial divisors 2kp + 1. Note also that doubling the exponent multiplies the computing required to find a Mersenne prime by 8: the time is 4 times longer and the probability of it being prime is halved. If doubling the digits every 3.8 years is to be maintained, I would guess that GIMPS needs India and/or China to catch the bug! David |
[QUOTE=S485122;223659]You will find the FFT size for all exponent ranges up to 596M in the source code. I attach an zipped excel file for those to lazy to look it up.[/QUOTE]I downloaded your excel file, so I am clearly lazy.
I also downloaded the source code for Prime95 and looked through the files, none of which are named in such a way as to appear a likely place to contain such information, not that I saw at least. Upon searching the contents of many (MANY) of them, I still have not found it. Since you seem to know where the needle sized array is located in this haystack of 431 files, could you please drop a name? |
[QUOTE=lavalamp;223712]I downloaded your excel file, so I am clearly lazy.
I also downloaded the source code for Prime95 and looked through the files, none of which are named in such a way as to appear a likely place to contain such information, not that I saw at least. Upon searching the contents of many (MANY) of them, I still have not found it. Since you seem to know where the needle sized array is located in this haystack of 431 files, could you please drop a name?[/QUOTE]You will find the table in mult.asm But you could also search the forum : the subject has been treated already. Jacob |
| All times are UTC. The time now is 20:52. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.