Sieving drive Riesel base 6 n=1M-2M

[gd_barnes]

This is a sieving drive for the final 2 k's remaining on Riesel base 6 for n=1M-2M. Lennart has kindly gotten us started. The k's remaining and their weights are:
k=1597; weight 272
k=36772; weight 583

This is a very exciting base where k's have fallen quickly. We now have a very good chance of proving it over the next 1-2 years.

The optimum sieve depth is probably in the P=170T-175T range. We will be using sr2sieve but because the 2 k's are so different weight, we will possibly eventually sieve them to different depths using sr1sieve. It is recommended that you run 64-bit sr2sieve on a 64-bit machine. Let us know if you need the executable or more detailed instructions on using it. Here is an example of the command to execute at the command prompt:

sr2sieve -p 50e12 -P 60e12 -i sieve-riesel-base6-1M-2M.txt

The above would be if you were sieving P=50T-60T. The file is listed after the "-i" command and is the actual file name that is attached below. Feel free to name it something shorter if you want or use the "srwork" older convention where you don't have to specify a file name.

When complete, you should have a factors.txt file. Just post the file here in this thread or if it is too big, please Email the file to me at:
gbarnes017 at gmail dot com

A P=1T range should take ~1-2 CPU days on one core of a modern 64-bit machine. Please reserve ranges in multiples of P=1T and plan to reserve no more than ~7 days of work at a time. When making reservations, please post your estimated completion date. This can be seen in sr2sieve about one minute after you start your sieve.

Attached is the latest sieve file. All factors up to P=100T have been removed. We will remove additional factors as the drive progresses to slightly speed up sieving.

Reservations:

 P-range      reserved by      status     est. completion date
   0T- 40T    Lennart         complete
  40T- 45T    Flatlander      complete
  45T- 70T    Lennart         complete
  70T- 80T    Dougal          complete
  80T-180T    gd_barnes       complete

The sieving drive is now complete.

All help is greatly appreciated!


Thank you,
Gary

[Lennart]

Originally Posted by gd_barnes

Would anyone like to get a sieving drive started for n=1M-2M? Although sieving the 2 k's together using sr2sieve should be about as fast as sieving them separately using sr1sieve, I think sieving them separately would be better because they will have much different optimum sieve depths. From the beginning of this drive, k=1597 has been by far the lowest weight k. The weight of the final 2 k's now remaining is:
k=1597: 272
k=36772: 583

I can start the sieve.

Lennart

[gd_barnes]

Originally Posted by Lennart

I can start the sieve.

Lennart

Great, after you have sieved to some nominal depth, perhaps P=1T or something like that, just send me the 2 files and I'll start a formal drive.

k=1597 would be higher priority right now. When the sieving for it is complete, we can start searching n>1M.

[Lennart]

Originally Posted by gd_barnes

Great, after you have sieved to some nominal depth, perhaps P=1T or something like that, just send me the 2 files and I'll start a formal drive.

k=1597 would be higher priority right now. When the sieving for it is complete, we can start searching n>1M.

I am soon done to 13T

I use sr2sieve 1.8.11 it is a little faster when you have a few sequences.

Lennart

[Lennart]

Her is the file in abcd format. Sieved to 13T

I reserve 13T-22T ( they are started )

Lennart

[mdettweiler]

I've split off the posts regarding n=1M-2M sieving to a new thread so they don't clutter up the main drive thread. Gary, I'll leave it up to you to set up a reservations table and whatnot since I don't know exactly at what point you were going to start that.

[philmoore]

I really don't understand the logic of sieving these two sequences separately. The optimum sieving depth for sieving together should be greater than the optimum depth for separate sieving, shouldn't it?

[gd_barnes]

Originally Posted by philmoore

I really don't understand the logic of sieving these two sequences separately. The optimum sieving depth for sieving together should be greater than the optimum depth for separate sieving, shouldn't it?

No. In theory it should be the same. With recent versions of sr2sieve, it has been shown that 2 instances of sr1sieve will give about the same total throughput as 2 instances of sr2sieve. Although here, Lennart is saying that he is getting slightly faster with sr2sieve. And that is only a recent phenomenon. In the past, 2 instances of sr1sieve far outpaced 2 instances of sr2sieve. It was only at 3 k's that 3 instances of sr2sieve became faster than 3 instances of sr1sieve.

I'd like to run a few tests myself because the calculations are quite complex with 2 extremely different weights. Since these remaining k's are so different in weight, one is nearly double the weight of the other, I was advocating sieving them separately.

Personally, I would like to run them separately at some point but for the time being, we'll go ahead and run them together. Perhaps once we reach P=~50T or so, we should do a detailed analysis of what works best. In other words, we may find that THIS:

low-weight k sieved to P=300T
high-weight k sieved to P=500T

Is more effective as for total sieving and testing CPU time than this:

Both k's sieved to P=400T.

It will be a tricky calculation but one that I feel is worth it at such a high n-level.

One other big reason that I was thinking we would like to sieve them separately is that the high weight k is only tested to n=600K right now whereas the low weight k is already at n=1M. We may not need the high weight k sieve file at all.

Lennart, because we don't have k=36772 searched to n=1M yet, what do you think about separating them at about P=50T and only sieve k=1597 for a while using sr1sieve?

Based on the circumstances, what do others think?

[Lennart]

Reserving 22T-40T


I shall start a test on the low k and compare p/sec.

at 13T 1M-2M I have

k 1597 5921 candidates left
k 36772 12229 left.

I will now start a test on sr1sieve on each k and give you p/sec and one with both on sr2sieve

I will use one computer and use -t8

Lennart

[gd_barnes]

I have done a calculation running sr1sieve vs. sr2sieve:

Set up: Intel I7 @ 2.94 Ghz. 3 other LLR/PFGW processes running in background so as to not affect the throughput in any way.

Test 1:
Sr2sieve on both k's for P=1G-5G. Time: 349 secs.

Test 2:
Sr1sieve on k=1597 for P=1G-5G. Time: 155 secs.
Sr1sieve on k=36772 for P=1G-5G. Time: 202 secs.
Total time: 357 secs.

Sr2sieve is 357 / 349 - 1 = ~2.3% faster.

Sr1sieve tests were run in batch so as to avoid any extra CPU time from manually starting each of them.

One could conclude this intuitively if one knew that sr1sieve and sr2sieve use the exact same types of calculations, which they apparently do now. Why? Because the further apart the weights are, the greater difference in time taken between the 2 and the less efficient it becomes to sieve the lower weight k. That is, if there were only 10 terms remaining on k=1597 and all remaining terms were on k=36772, it would be highly inefficient to sieve only the 10 terms. BUT...it was not clear to me if the 2 programs were using the exact same processes. I am now convinced of such. Therefore: It always makes sense to run sr2sieve to at least the optimal depth of the lower weight k, if that depth is calculated while running sr1sieve -and then- run sr1sieve on the higher weight k until it is at optimal using that program.

Conclusion: We should definitely use sr2sieve up to some, as of yet, unknown depth. That depth should be based on 3 things:

1. The optimal depth of k=1597 run only by itself using sr1sieve.
2. The chance of k=36772 having a prime for n=600K-1M.
3. Can we have and will we be ready to start testing k=1597 for n>1M before testing of k=36772 is complete to n=1M?

#'s 1 and 2 can be calculated, although deciding how the chance in #2 should reduce the optimal depth of running both k's together is not very clear. #3 is very tough to decide upon.

This seems unlikely to happen but:
If we cannot have k=1597 fully sieved for n=1M-2M before k=36772 testing is done to n=1M, it makes sense to just sieve both k's using sr2sieve to nearly the optimal depth of k=1597 (computing it's optimum using sr1sieve), and then run k=36772 to it's optimal depth running sr1sieve. That's the way I would approach it if k=36772 was already tested to n=1M.

Lennart, as of yet, I haven't turned it into a formal sieving drive. When I do, I'll edit the 1st posting for reserved ranges and the such and sticky the thread. If you would just like to keep on running both k's with sr2sieve up to P=50T or 100T as your resources allow, I think that is quite reasonable. We don't have any huge demand for testing k=1597 for n>1M at this moment.

One more thing: Because max n / min n = 2, as demonstrated by VBCurtis at RPS, no ranges should be broken off. We'll sieve the entire n-range to the same depth (for each k, although different depths for the 2 k's) and it should be sievied until the removal rate equals the test time of a candidate at approximately 55-60% of the n-range, i.e. n=1.55M-1.6M. I have an exact calculation on that from some work I've done on some of my personal efforts that I can demonstrate later on.


Gary

[Lennart]

Here are my timings.

sr1sieve 1.41
1597 sr1sieve 133514792 p/sec
36772 sr1sieve 111216565 p/sec

Both k using sr2sieve 1.8.11

71742478 p/sec

Lennart