New data page

[Cruelty]

OK, I will be hitting n=6999 (using PFGW) latest tomorrow, and I am planning to sieve 7000<n<20000 with sr2sieve (I have already created sieve file with srsieve @ pmax=1e6), and then finish it with LLR + Proth

[gd_barnes]

Originally Posted by Cruelty

OK, I will be hitting n=6999 (using PFGW) latest tomorrow, and I am planning to sieve 7000<n<20000 with sr2sieve (I have already created sieve file with srsieve @ pmax=1e6), and then finish it with LLR + Proth

Just to clarify to make sure I understand you correctly...Sometime late on Monday, you will have completed searching the range of 100K < k < 200K for n < 7000. Is that correct?

Suggestion...Having searched across large ranges of k quite a bit myself, I have found srsieve to be much faster than sr2sieve for a very large # of k's like you are doing here. You might run both over the same range of p for a small test and see which one is faster on your machine. I think srsieve will be much faster for the 50,000 k's that you're doing here (assuming that I understand you correctly).

My experience...when doing the double-checking for k <= 1001 up to n=50K, srsieve was faster in all cases, even when I reduced the range of k to just 300 < k < 1001. But when I did my 'large heavy-weight' k sieve for only 12 k's from k=19437 up to k=3428677395 from n=200K to 400K, sr2sieve was always faster. It probably has to do with actual factor removal as the program progresses on srsieve vs. just writing factors out and removing them later on sr2sieve. I think a large # of k's makes immediate removal by the program much faster vs. removing them at a few points along the way or all at the end using srfile.


Gary

[Cruelty]

You've got it right Gary
BTW: Thanks for the tip, I have another one: when running any sr(x)sieve program at the beginning stage of each sieve (when there are a lot of candidates to be found), minimize the prompt window as the output consumes a lot of CPU resources

[mdettweiler]

Originally Posted by Cruelty

You've got it right Gary
BTW: Thanks for the tip, I have another one: when running any sr(x)sieve program at the beginning stage of each sieve (when there are a lot of candidates to be found), minimize the prompt window as the output consumes a lot of CPU resources

Or, simply use runh.exe (Google runh.exe to find it) to run the application in the background--it's a very handy application for Windows that lets you run any command-line application in the background. You can then check on the progres by viewing checkpoint.txt in a text editor--it lists the % done in it. I use this method whenever I need to do sieving with either sr2sieve or gcwsieve (not for this project, as of yet, but for other projects), and it works great. To stop the application, simply terminate its process using Task Manager. You may lose a minute or two of work because it has to rely upon the autosaved checkpoint rather than an exact checkpoint that it would otherwise save when you press Control-C, but sr*sieve (or at least sr2sieve, which I've had experience with) checkpoints often enough so that this isn't a problem. (gcwsieve, on the other hand, checkpoints infrequently enough that it's good to set the -s option in the command line so that it will checkpoint more frequently. I use -s1 to checkpoint every minute, although others may prefer a longer time.)

[gd_barnes]

Originally Posted by Anonymous

Or, simply use runh.exe (Google runh.exe to find it) to run the application in the background--it's a very handy application for Windows that lets you run any command-line application in the background. You can then check on the progres by viewing checkpoint.txt in a text editor--it lists the % done in it. I use this method whenever I need to do sieving with either sr2sieve or gcwsieve (not for this project, as of yet, but for other projects), and it works great. To stop the application, simply terminate its process using Task Manager. You may lose a minute or two of work because it has to rely upon the autosaved checkpoint rather than an exact checkpoint that it would otherwise save when you press Control-C, but sr*sieve (or at least sr2sieve, which I've had experience with) checkpoints often enough so that this isn't a problem. (gcwsieve, on the other hand, checkpoints infrequently enough that it's good to set the -s option in the command line so that it will checkpoint more frequently. I use -s1 to checkpoint every minute, although others may prefer a longer time.)

Excellent! I'll look that up.

Typically, I wouldn't mind it running minimized but sometimes I'd prefer that others not know that it is running! That's what I'll use it for. LLR and NewPgen have easy ways to 'hide' them but I wasn't aware of a way to do that for the srsieve programs.


Gary

[mdettweiler]

Originally Posted by gd_barnes

Excellent! I'll look that up.

Typically, I wouldn't mind it running minimized but sometimes I'd prefer that others not know that it is running! That's what I'll use it for. LLR and NewPgen have easy ways to 'hide' them but I wasn't aware of a way to do that for the srsieve programs.


Gary

Don't credit me. Actually, the suggestion came from Bryan at the Riesel Sieve forums. :-) I had mentioned there when I was first getting started with the whole concept of manual sieving, that I needed a way to run the application either in the background or in the system tray, and he suggested runh.exe. One thing I can say is, it works! And as long as I can still check the progress of the range from checkpoint.txt, the only thing I'm missing out on is the p/second information that I'm told the full display will give you. There might be some more information that the regular display gives you, but I can't imagine that any of it is absolutely necessary (or that, in most cases, is even useful).

Another option for hiding a command line application (or any application, for that matter) is to use hideit.exe--a handy little program that is a bit more full-featured than runh.exe, and simply puts an icon in the system tray, which you can right-click on to display a list of all the open windows--and you can hide any of them with a click of its name. I personally prefer runh.exe for manual sieving and other apps of that sort, but hideit.exe is useful for other applications, such as mail programs or stuff like that, that you'd like to get out of your hair. I think I heard of it on the message boards at Riesel Sieve too (though it might have been elsewhere). I can't remember where to download it, though, and a Google search doesn't seem to be as fruitful as with runh.exe, so I'm attaching hideit.exe to this post for convenience.

[Cruelty]

Originally Posted by gd_barnes

I think srsieve will be much faster for the 50,000 k's that you're doing here (assuming that I understand you correctly)

You were right... sort of, because running 50000-k sieve using sr2sieve is simply not feasible, as sr2sieve computes Legendre symbol tables which is extremely memory intensive task, e.g. 1GB RAM + 2.9GB SWAP is not enough to even complete this process, not to mention starting actual sieve...

[mdettweiler]

Originally Posted by Cruelty

You were right... sort of, because running 50000-k sieve using sr2sieve is simply not feasible, as sr2sieve computes Legendre symbol tables which is extremely memory intensive task, e.g. 1GB RAM + 2.9GB SWAP is not enough to even complete this process, not to mention starting actual sieve...

What's the difference between srsieve and sr2sieve? Is one faster than the other, and are they interchangeable in any way? I've heard both mentioned a bunch of times all over this board, and I'm quite confused.

[VBCurtis]

srsieve is a very general program for sieving many different categories of prime searches. It can sieve many k's at once.

sr1sieve is a single-k sieve for k*2^n+-c. It's fast.

sr2sieve is a multi-k version of sr1sieve. It only sieves files in abcd or rieselsieve formats, and only of the form mentioned for sr1. It is heavily optimized and on the order of 5x faster than srsieve for the searches I've tried (between 3 and 20 k's, over a large range of n). However, it uses more memory to achieve the speed increases, so unusual sieves may not be faster (or may run out of memory, as in cruelty's post).

-Curtis

[mdettweiler]

Originally Posted by VBCurtis

srsieve is a very general program for sieving many different categories of prime searches. It can sieve many k's at once.

sr1sieve is a single-k sieve for k*2^n+-c. It's fast.

sr2sieve is a multi-k version of sr1sieve. It only sieves files in abcd or rieselsieve formats, and only of the form mentioned for sr1. It is heavily optimized and on the order of 5x faster than srsieve for the searches I've tried (between 3 and 20 k's, over a large range of n). However, it uses more memory to achieve the speed increases, so unusual sieves may not be faster (or may run out of memory, as in cruelty's post).

-Curtis

I see now. You mentioned that sr2sieve sieves files in abcd or rieselsieve formats; do you mean that Riesel Sieve uses a proprietary format for its sieve files? I would have thought that they would use a standardized format for them--and I never heard anything over there about a proprietary sieve file format.

[VBCurtis]

I don't remember precisely, but I think SOB and rieselsieve use a format slightly different from abcd. if I'm incorrect, both use ABCD and I'm simply mistaken.

-Curtis