![]() |
[QUOTE=lavalamp;172194]From what I can see, that does appear to be the order.
What are the residue classes then? Also, how does em99010pepe's status.txt show he has passed 2^77 when his residue class is only 2? On my 73 - 74 run, the residue class got up to 7 before it finished, and the current k value resetting with each increase.[/QUOTE] Factoring uses a mod120 mechanism. There are only 16 classes out of 60 that can get a possible factor. Each class is worked by one thread, so 2 may indicate the class 3 on a single threaded machine, classes 5 and 6 on a two threads machine, classes 8,9,10,11 on a four thread machine. There is also a sliding rule mechanism to take advantage of the cache size: the first 4 million factors candidates (k values, actually) are divided into 16 classes and elaborated, then we take the next 4 million candidates. On Carlos assignment, you can get the bit-depth by taking the actual k value. Luigi |
Wouldn't em99010pepe be on classes 9, 10, 11, 12 and still have to go through 13, 14, 15 and 16 then?
6.1% to 76 bits for n=3321933893. |
M3321928381 to 78 bits progress (87.7 %)
[code] 3321928381 73 78 1421573839423 24057570903103 45490362861568 3 0 4 0 [/code] |
OK, well now it's over 77 for sure, 77.081 I make it.
|
[QUOTE=lavalamp;172306]Wouldn't em99010pepe be on classes 9, 10, 11, 12 and still have to go through 13, 14, 15 and 16 then?
[/QUOTE] No :smile: If memory serves, k is spread over all classes, and it's done in parallel. e.g. first 4 million k over 16 classes, second 4 million k over 16 classes and so on. Luigi |
I'll take 3321933679 from 72 to 78.
|
[QUOTE=ET_;172384]No :smile:
If memory serves, k is spread over all classes, and it's done in parallel. e.g. first 4 million k over 16 classes, second 4 million k over 16 classes and so on. Luigi[/QUOTE]Judging from em99010pepe's and my own output, that does not appear to be the case. If you look at the current k value in the three status files em99010pepe posted, you can see that the k went backwards by quite a lot. 26481227338303 at first, then 39367055173183, then 24057570903103. So in four days it went backwards by almost 2.5 trillion k values. It looks like it increased (presumably until it reached the end k), then reset (presumably to the start k) and is now progressing through the final four classes. If this is correct then the only time it's possible to judge bit-depth solely from current k value and n value is when there are 16 threads running. Additionally, I'll have only completely searched up to 75 bits when I'm 91.667% done. 19.4% to 76 bits for n=3321933893. |
[QUOTE=lavalamp;172581]Judging from em99010pepe's and my own output, that does not appear to be the case. If you look at the current k value in the three status files em99010pepe posted, you can see that the k went backwards by quite a lot.
[/QUOTE] That's why I *strongly* need to clear the mess in the source file and document it :blush: As well as adding a couple of features...:smile: I'm growing old and my memory has never been like once. Luigi |
So there are six candidates at 76 bits or higher, and three more will be soon. I guess I'll take 3321933661 up to 77 bits and make it an even 10 to round out this level.
I've just taken it to 73 bits as a speed test so I can calculate an eta. I'd say 77 bits by 7:30am on saturday (BST, UTC+1). |
I'll take 3321933613 from 72 to 75 bits.
|
3321933233 from 72 to 73 bits.
Luigi |
| All times are UTC. The time now is 22:06. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.