Bases 501-1030 reservations/statuses/primes

[gd_barnes]

Thanks for the detailed status Kenneth. I'll change k=3677878 back to n=1M. I thought you might change your mind there.

I know you were doing a sieve for n=1M-1G. Did you work on that any? I wouldn't post such a huge sieve file on the pages but I would be willing to take part of it and post one for n=1M-10M or n=1M-5M depending on the size of the file. But if you only sieved it to a very low depth, don't worry about it. It wouldn't be worth posting.

As for base 955, I seriously doubt that you can get that to < 1000 k's remaining but I haven't done a detailed analysis. But to get rid of nearly 90% of k's after a test to n=2500 is extraordinarily difficult, especially for a high base. But that's OK. If you can at least get it up to n=10K, I'll gladly show the k's remaining on the pages.

[KEP]

Originally Posted by gd_barnes

Thanks for the detailed status Kenneth. I'll change k=3677878 back to n=1M. I thought you might change your mind there.

I know you were doing a sieve for n=1M-1G. Did you work on that any? I wouldn't post such a huge sieve file on the pages but I would be willing to take part of it and post one for n=1M-10M or n=1M-5M depending on the size of the file. But if you only sieved it to a very low depth, don't worry about it. It wouldn't be worth posting.

As for base 955, I seriously doubt that you can get that to < 1000 k's remaining but I haven't done a detailed analysis. But to get rid of nearly 90% of k's after a test to n=2500 is extraordinarily difficult, especially for a high base. But that's OK. If you can at least get it up to n=10K, I'll gladly show the k's remaining on the pages.

Regarding Riesel base 3, k=3677878, I did only very sporadic sieving in 4 different areas, for p<=1T, so it is not even fully sieved to 1 trillion, and since it was nearing <20M candidates, I decided to abandon it, to do some further testing on lower k's and find some k's that could eventually lead me to a Top5000 prime. Should btw notice, that I don't think I have the sieve file any more at all.

Regarding S955, I'm currently on 1 core, sieving to n=100K, and I think I'll break it off at optimal sievedepth for n=10K or n=25K, dependent on how far it has been sieved once all my non base 955 work completes. So sure I'll take it to at least n=10000, which should leave about 4651 k's remaining.

There is currently a sieve speed of ½ G for Sierp base 955, so I think by the time all my non base 955 work completes, that it should be sieved to somewhere around 40-50G. As tonight, local danish time, I expect the sieve file to go below 70M candidates for 8973 sequences going from n>2500 to n<=100K. S955 is btw reducing the number of k's with ~28% for every doubleing of the n, so I expect somewhere between 1500 and 1600 k's remaining at n=100K

Well this answer got a little long, thanks for changing my reservation back to n=1M for riesel base 3. Hope I got it all.

Does anyone know, if sr2sieve can handle a Multimillion sievefile, with 8973 candidate sequences going from n=2501 to n<=100000, for s955, such as I can sieve with 18000 p/s in stead of 6500 p/s ?

Regards

KEP

[gd_barnes]

Originally Posted by KEP

Does anyone know, if sr2sieve can handle a Multimillion sievefile, with 8973 candidate sequences going from n=2501 to n<=100000, for s955, such as I can sieve with 18000 p/s in stead of 6500 p/s ?

Regards

KEP

Yes, sr2sieve can handle as big of a file size as can fit in your computer's memory but no, I don't think there's any chance that you'll be able to use it. That's because the restriction usually comes in with the initial creation of the Lengendre symbols. IF the k's are quite small (< 10000), then those are not too much problem. You can do 1000's of k's. The problem comes in when the k's get large.

As an example, I could not run sr2sieve to sieve Sierp base 31 for n=10K-25K even though there were only about 1500-1600 k's remaining at n=10K. Very maddening because I couldn't optimally sieve nearly as far with much slower srsieve. The reason? The k's were simply too big (not too numerous) for the Lengendre symbol table to fit in my computer's memory because the conjecture is k=~6.3M. My guess is to do the Legendre symbols on base 31 with 1500 k's would take anywhere from 30G to 75G of memory or more. I remember letting it run as long as it could on a machine with 4G memory. Eventually it just gave a "memory alloc" error and saved nothing and I don't think it was much past k=1M yet. I think it took half a day or a little more before it finally filled up. (I didn't realize it was chewing up memory when I did this or I would have stopped it after an hour or so.)

Here is one thing you might attempt although I think it will be slower than simply running the already slow srsieve on all of your k's: Split your k's up into groups of 1000 k's and try running each one of those batches through sr2sieve individually. Hint: Do NOT put all of the large k's in one file. The symbols become much larger as the k's get larger. (From what I can tell, it's more than a linear increase.) I'm not sure of the best way to divide them up but something like (if you were doing 3 files), k=10, 20, & 30 in file #1, k=13, 23, & 33 in file #2, and k=16, 26, & 36 in file #3 would be a way to even out the memory that would be used for each. That would be your best chance.

Before embarking on anything like this, put all the k's in one file and watch the symbols progress on your screen. Also check your task manager for the memory being used to get a reasonable initial estimate of how much total memory might be needed. That way you'll know if the above is a possible option.

One more suggestion: On the conjectures, I don't advise sieving an n-range where the high n-value divided by the low n-value is so large, especially at the low n-ranges. That's because many k's will be eliminated and much of your sieving will be wasted. My suggestion is that the high n-value be no more than 10 times the low n-value. In your case, in the future, consider two sieves of n=2500-25K & n=25K-100K (or n=2500-10K & 10K-100K). The point being that a lot of k's will be eliminated by n=10K or 25K. Although large n-ranges are highly efficient in srxsieve if you are going to test the entire n-range, there is a limit when you stop testing when a prime is found and that limit is based on the percentage of k's that should be eliminated in the range. As a wild guess, I'd estimate that if you expect that > ~65%-75% of your k's will be eliminated in the range you are sieving that you probably should sieve a somewhat smaller range. For example, I thought your sieving n=100K-1M on k=3677878 was a good range to sieve. But n=1M-1G would be way too much. If going higher, I'd suggest sieving either n=1M-5M or n=1M-10M. Iirc, you had a ~60% chance of prime for n=100K-1M so technically on avg, you should be eliminating 60% of your k's in that range (even though it's only one k, the analogy still applies); hence a good choice for the sieve range. That being the case, you should also have a ~60% chance for a prime in n=1M-10M so that's likely close to the largest range that you could efficiently sieve.

Now...if all that you have is a single or a couple of extremely low weight k's such that their combined percentage chance of prime in an n-range is < 50%, then by all means sieve an n-range with a ratio of a top to bottom n-value that is > 10 if you think that testing can complete in 1-2 years or less. If testing takes longer than that, than frequently future software/hardware improvements still make it better to sieve a smaller range. I mean, look at what happened with PFGW in the past 3 months and with 64-bit srxsieve in the last 2-3 years. One increased in speed by > 5 times and the other doubled in speed (from 32 bit) and that doesn't even take into account hardware improvements. The moral of the story: Don't use too many of today's resources to do too high of a percentage of tomorrow's work. Let a large portion of tomorrow's work be done by tomorrow's resources.

BTW, on your percentage drop in k's remaining with each doubling of the n-range, remember that the percentage drops somewhat as the n-ranges grow larger because the remaining k's are lower average weight. (If they were the same avg. weight then theoretically, it should remain the same.) If it's a 28% drop at n=2500, you'd probably be down to ~20% at n=100K. If it was a straight percentage drop, we'd prove these things a lot more easily.

...and you thought your answer was long. :-)


Gary

[kar_bon]

Originally Posted by gd_barnes

The reason? The k's were simply too big (not too numerous) for the Lengendre symbol table to fit in my computer's memory because the conjecture is k=~6.3M. My guess is to do the Legendre symbols on base 31 with 1500 k's would take anywhere from 30G to 75G of memory or more.

have you tried to use sr2sieve with option "-x" (or "--no-lookup")?

[gd_barnes]

Originally Posted by kar_bon

have you tried to use sr2sieve with option "-x" (or "--no-lookup")?

No. I wasn't aware of what that meant. So does that not do the Legendre symbols? If it doesn't, I wonder how much faster than srsieve it will be.

[KEP]

Thanks Gary for your answer. I think I'll take a look at my 24h sieved file, and then convert the srsieve.out to a sr_955.abcd file, and then try using "-x" as Karsten suggested (ONLY if memory use becomes too big for my computer with legendre symbol lookup tables).

I actually thought that using the even and odd legendre symbol tables, was what actually made sr2sieve so much faster than srsieve. Apparently I was wrong on that one. On a side note, did a time test on testing the highest k for sierp base 955 at n=100K, it took about 3670 seconds to complete 1 test

But to sum up, yes your answer was longer, but it contained a lot of great ideas and I may consider to do a smaller n-high range for sieving, but nothing has been decided yet, even though your morale of the story is good, and somehow follows what i feel and think, however I also longs for a Top5000 prime, so sieving a high n may make sence in that way

Again thanks for your inputs and I'm sure looking forward to follow them as of tonight.

Regards

KEP

[KEP]

Riesel base 633 is complete to n=25K, with 5 k's remaining

Regarding S955, I tried reducing the max-n to n=10K, and of course for both n=100K aswell for n=10K, using sr2sieve was impossible, with the legendre symbols. At k=10000, it took up already about 500MB. But using sr2sieve, with the -x flag, could maybe be a solution to sieve the high k's. I must say, that the RAM use was only a bit more than 360MB for 8973 k's, for both n=100K aswell for n=10K. HOWEVER, once I got to the line where sr2sieve claimed that it has started, I got an "the program has stopped working and is terminating" or something like that message, whereafter (hope thats the right word ) the program shuts down. These termination happens for both n=10K and n=100K, using the -x flag. Havent investigated it further, but maybe there is something Geoff needs to look a bit further into.

Regards

KEP

[gd_barnes]

R999 is at n=10K; 87 k's remaining; continuing to n=25K. Details on the pages.

These high bases take a LONG time, even if few k's are remaining, which this one does not!

[rogue]

Originally Posted by gd_barnes

R999 is at n=10K; 87 k's remaining; continuing to n=25K. Details on the pages.

These high bases take a LONG time, even if few k's are remaining, which this one does not!

You've got that right. Riesel base 928 still has over 1000 k left at n=5000. With a conjectured k at just over 32000, k are not getting removed very quickly.

[gd_barnes]

Originally Posted by rogue

You've got that right. Riesel base 928 still has over 1000 k left at n=5000. With a conjectured k at just over 32000, k are not getting removed very quickly.

And then they seem to frequently go into these huge "prime holes" like you found with S811 & S961, which makes them even worse.

[gd_barnes]

Dougal released R1017. Therefore I searched it to n=25K. 15 k's are remaining. Details on the pages. No further work.