20200127, 02:06  #23  
Aug 2006
3·1,993 Posts 
Quote:
https://pari.math.ubordeaux.fr/ and we have a subforum here devoted to it (a good place to ask questions). You can use it online but it's designed to run on your computer in Windows, Mac, Linux, etc. 

20200128, 13:55  #24 
Feb 2017
Nowhere
4,583 Posts 

20200128, 15:43  #25 
"Curtis"
Feb 2005
Riverside, CA
2×3×5×7×23 Posts 

20200227, 18:12  #26  
Sep 2006
The Netherlands
3^{2}·79 Posts 
Quote:
That's why most try small k's for riesels. Riesel stands for k * 2^n  1 in itself https://en.wikipedia.org/wiki/Riesel_number Proth's being the +1 form. The smaller k is, the faster the LLR software with the library from Woltman inside, can calculate. It's about how fast you can run LLR on each exponent and the slowdown for larger k's you really notice if you try something there  even until 1M bits. 

20200228, 05:49  #27  
Random Account
Aug 2009
1,949 Posts 
Quote:
It has been my experience that the larger the n the longer LLR will spend on each. I didn't see k making much of a difference. There is some I imagine. 

20200228, 06:44  #28  
"Alexander"
Nov 2008
The Alamo City
653 Posts 
Quote:


20200303, 17:36  #29 
Random Account
Aug 2009
1,949 Posts 
Sieving
I am wandering if there is a ruleofthumb about how deep to sieve any particular group of n's. It seems everyone has their own way of sieving and none seem to match.
For the past few weeks, I have been working on k = 98475. I keep track of everything in a spreadsheet. I have been experimenting with a formula to determine how deep to sieve. It goes like this: n / 780 * 1e9.. Example: Let's say the lower end of a group is 700,000. So, 700,000 / 780 * 1e9 = 897,435,897,435. I do not mess with all these digits, so I would round it up to 898e9. I have been gradually lowering the divisor down to increase the sieve value. My goal is to sieve deeply as possible but not so far that the sieving time exceeds the time required to run the group through LLR. The current group I am running will take roughly 18 hours in LLR. The next group sieving will take about 10 hours to complete. There is a point where this becomes selfdefeating. The removal rate for the sieve is currently 216 seconds per n. LLR is completing each n in 71 seconds, on this hardware. I am using sr2sieve for the bulk of the process. It has the R switch which forces a stop when the removal rate exceeds the set value, in seconds. I have not used it, to date. My quandary is where to stop the sieve, or to simply let it run. 
20200303, 17:45  #30 
Sep 2002
Database er0rr
E70_{16} Posts 
I have found that for a variable n search the rule of thumb is to measure the time for LLR test at 80% of the maximum n and sieve until the elimination time is the same,
Also, it is better to sieve one big batch, since the time to sieve is proportional to the square root of the range. Last fiddled with by paulunderwood on 20200303 at 17:50 
20200303, 17:55  #31 
"Curtis"
Feb 2005
Riverside, CA
4830_{10} Posts 
How to calculate optimal sieve depth depends a bit on the range of exponents in the sieve.
If you're doing a small sieve, like n=700k to n=1M, picking an exponent around 7080% of the way through the file will do for matching LLR time to sieveremoval time. If you're doing a large sieve, like n=700k10M, then the removal time should be a bit over twice the LLR time for the lowest candidate. When you reach that time, cut off a piece of the sieve for LLR, and continue sieving the rest until the removal time again matches twice the time for the (new) lowest candidate. Doubling the LLR time is related to the marginal productivity of the sieve software; that is, sieve speed doesn't increase linearly when you cut off a chunk of candidates. Sieve speed scales with the square root of the nrange of the sieve, so when cutting off small chunks (say, 700k750k) doubling LLR time is a good rule of thumb. When the "large sieve" rule of thumb gives a result longer than the "small sieve" rule of thumb, you're now running a small sieve. Turns out this happens about when N = 2n; say, 1M to 2M. Edit: As Paul said, it's a massive waste to sieve small ranges. You should run one sieve for a range a bit bigger than you think you are likely to ever test for that k. You're wasting a ton of sieve time; it's typical to sieve for about 5% of the total time LLR takes, but this ratio changes when you sieve a tiny range. Last fiddled with by VBCurtis on 20200303 at 18:00 
20200303, 23:13  #32  
Random Account
Aug 2009
1,949 Posts 
Quote:
An option: Sieve much larger and break off pieces for each machine according to their capability. My i5 runs somewhere between 80% to 85% of what the i7 can do. It fluctuates considerably at times.Other times, not. I wrote a small binary to split the sieve results in such a way that the i7 gets proportionally more of the load. This can easily be modified as needed. Sieving and running LLR at the same time creates a bottleneck for either machine. Oddly enough, it is worse on the i7. So, I sieve on the i5. 

20200304, 03:55  #33 
"Alexander"
Nov 2008
The Alamo City
653 Posts 
Since you're only working with one k, you should use sr1sieve instead of sr2sieve. sr1sieve is significantly faster when working with one or two k values (run separately for two k's), while sr2sieve is better for three or more k values. sr1sieve also has the advantage of outputting (inplace) to an LLRformat file, so there's no need to work with srfile.

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Patterns in primes that are primitive roots / Gaps in fullreptend primes  mart_r  Prime Gap Searches  14  20200630 12:42 
A question about primes of a particular form  enzocreti  enzocreti  55  20190427 11:10 
Fascinating Lenovo memory configuration paper  tServo  Hardware  7  20181117 16:28 
Fascinating periodic sequence pairs  doctornash  Other Mathematical Topics  7  20180714 00:06 
question about a chain of primes  firejuggler  Math  31  20140108 18:28 