Riesel base 3 reservations/statuses/primes

[lalera]

Originally Posted by KEP

You could test from:

k=20,000,000,002 to
k=21,000,000,000

using the starting base script.

I've just begun testing the same range using rogues srbsieve. That way, we can establish a great doublecheck and see if the program works as should. Also we could have another 1G range doublechecked, wich is not entirely a bad idea to do once in a while

Can Gary/you accept this or do you have other suggestions?

i can do a range of 100M - 20,000,000,002 to 20,100,000,000 if you like

[KEP]

Originally Posted by lalera

i can do a range of 100M - 20,000,000,002 to 20,100,000,000 if you like

That could also be good, then we can compare from 20,000,000,002 to 20,100,000,000... Just let me know what you and Gary agrees on and then I can cut out the range from the final files ... such that we can compare the results.

[rogue]

Gary wants one run with new-base-txt and one with srbsieve. Those results should be compared.

For such a test, I suggest running the new-base script to n=100 and running srbsieve to n=100 for a large range (100M). I see no reason to run any higher. My reasoning is that going further would take a lot more time, but not provide reveal any bugs that wouldn't already have been revealed for a lower n. As part of the test, it would be important to ensure that srbsieve run through more than 1 phase in case there is some weird issue in transitioning between phases.

Gary, what are your thoughts on the matter? My personal opinion is that as long as pl_remain.txt is the same between the two runs, the primes that are generated are less important.

[lalera]

Originally Posted by rogue

Gary wants one run with new-base-txt and one with srbsieve. Those results should be compared.

For such a test, I suggest running the new-base script to n=100 and running srbsieve to n=100 for a large range (100M). I see no reason to run any higher. My reasoning is that going further would take a lot more time, but not provide reveal any bugs that wouldn't already have been revealed for a lower n. As part of the test, it would be important to ensure that srbsieve run through more than 1 phase in case there is some weird issue in transitioning between phases.

Gary, what are your thoughts on the matter?

ok, thank you!

[KEP]

Officially reserving for testing of srbsieve, k=20,000,000,002 to k=20,100,000,000 to n=25K

[gd_barnes]

Originally Posted by rogue

Gary wants one run with new-base-txt and one with srbsieve. Those results should be compared.

For such a test, I suggest running the new-base script to n=100 and running srbsieve to n=100 for a large range (100M). I see no reason to run any higher. My reasoning is that going further would take a lot more time, but not provide reveal any bugs that wouldn't already have been revealed for a lower n. As part of the test, it would be important to ensure that srbsieve run through more than 1 phase in case there is some weird issue in transitioning between phases.

Gary, what are your thoughts on the matter? My personal opinion is that as long as pl_remain.txt is the same between the two runs, the primes that are generated are less important.

Point taken on not running it very high but I would like to see it run to n=1000.

Although pl_remain.txt is the most important, primes are also important. If there is a difference in primes, then there could eventually be a k that should be remaining that is not or vice versa even if that does not happen for this particular test. In other words, all files must be identical.

Also important is the multiples of the base file, that is pl_MOB.txt. I have seen differences in this file where PFGW was not finding primes correctly.

[KEP]

Originally Posted by gd_barnes

Point taken on not running it very high but I would like to see it run to n=1000.

Although pl_remain.txt is the most important, primes are also important. If there is a difference in primes, then there could eventually be a k that should be remaining that is not or vice versa even if that does not happen for this particular test. In other words, all files must be identical.

Also important is the multiples of the base file, that is pl_MOB.txt. I have seen differences in this file where PFGW was not finding primes correctly.

No worries. I'm currently running srbsieve (version 1) for R3 to n=25K and it looks like it could complete the range for k=20,000,000,002 to k=20,100,000,000 to n=25K as early as today (48 hours total). After that run completes, I'm going to do the same range using the starting bases script, even though I doubt that I'll use the starting bases script higher than to n=24, simply because after n=24 the primes should be the same, since I'll be using the latest and same PFGW version for both tests. So far I have completed through several phases, without errors. Even though I run version 1, I don't see, if everything comes out as a match, that further testing is needed for base 3, since nothing that should affect an eventual output has been changed in version 2 of srbsieve. Well, hopefully in the weekend we will know more about my testings and the doability of srbsieve. For now it appears that srbsieve is somewhere between 3 and 4 times as fast as using the starting bases script and sieve approach, that I previously suggested

Nice work Rogue

Take care

Ps. Rogue, would it be to hard to enforce srbsieve to sort the k's in ascending order in all the .txt files created, before termination of srbsieve just after 100% completion of srbsieve final phase?

Pps. I'm running with the original phase settings in the srbsieve.ini file, wich means going to n=80, to n=300, to n=1000, to n=3000, to n=9000 and to n=25000

[rogue]

Originally Posted by KEP

Would it be to hard to enforce srbsieve to sort the k's in ascending order in all the .txt files created, before termination of srbsieve just after 100% completion of srbsieve final phase?

Yes. The program would have to hold everything in memory in order to do that. For a range of 1G that would require at least 8GB of memory. You can find tools to sort the files from the command line then use WinMerge to compare.

[KEP]

Originally Posted by rogue

Yes. The program would have to hold everything in memory in order to do that. For a range of 1G that would require at least 8GB of memory. You can find tools to sort the files from the command line then use WinMerge to compare.

Okay, yes that is a lot of memory, so I can see that it is not an option. I guess most of our users either way is familiar enough with DOS commandoes, to be able to sort using the cmd prompt and its sort function

This is really looking good. Even though I'm not complete yet, I expect my Hasswell to be able to complete 1G every 5 days. In other terms, it looks like I can expect on my Hasswell, if everything goes as I expect, to run for base 3, 73G a year on my Hasswell alone and on my Sandy Bridge it will be something like: 48G a year ... I'll have more accurate numbers (for my Sandy Bridge) tomorrow

[rogue]

Originally Posted by KEP

Okay, yes that is a lot of memory, so I can see that it is not an option. I guess most of our users either way is familiar enough with DOS commandoes, to be able to sort using the cmd prompt and its sort function

This is really looking good. Even though I'm not complete yet, I expect my Hasswell to be able to complete 1G every 5 days. In other terms, it looks like I can expect on my Hasswell, if everything goes as I expect, to run for base 3, 73G a year on my Hasswell alone and on my Sandy Bridge it will be something like: 48G a year ... I'll have more accurate numbers (for my Sandy Bridge) tomorrow

If the results match the new-base.txt script, then that is phenomenal. That would certainly put completion of R3 to 25K within reach.

[KEP]

Originally Posted by rogue

If the results match the new-base.txt script, then that is phenomenal. That would certainly put completion of R3 to 25K within reach.

Yes it will, because as soon as my R3 to n=100K (8G-13G) is complete, I'm going to put 8 cores on the effort if Gary feels reliable with srbsieve and can approve of the use of srbsieve. Now I just hope, that I can at least be allowed to reserve a 10G range, to n=25K, since it would make it easier to prepare the workfiles and completion will be in about 4-5 weeks... so please Gary, could you, if testing of srbsieve turns out as we all hope, accept a 10G reservation for me?

Guess it is now also time to consider starting up S3

Tomorrow, unless lalera is working on this, I'll use the starting bases script to test k=20,000,000,002 to k=20,100,000,000 to n=24 and then copy paste the primes with n>24 from the pl_primes.txt file created by srbsieve, and then see if the .txt files match each other. Hopefully within the weekend we will know if both ranges match ... can this btw be accepted as a correct way to test the reliability of srbsieve or what do you think Gary? Rogue?