20210823, 20:21  #287  
May 2007
Kansas; USA
24432_{8} Posts 
Quote:
I will attempt to sieve the file to P=1G using srsieve and see what point it starts removing factors. I see that you have been having difficulty sieving to P=1G with srsieve2 for the last several large files with nearly 100,000 k's remaining. It might be time to consider srsieve again. 

20210823, 20:27  #288  
Sep 2011
Germany
2×1,489 Posts 
Quote:


20210823, 20:54  #289  
May 2007
Kansas; USA
2·5,261 Posts 
Quote:
I get concerned about running buggy versions of software and using the files from those versions for future testing. Edit: It has stopped early before. Both R358 and S330 stopped before P=1G earlier this year. Last fiddled with by gd_barnes on 20210823 at 21:17 Reason: edit 

20210824, 01:08  #290  
May 2007
Kansas; USA
291A_{16} Posts 
Reb, below are the 3 times that you could not sieve where you needed to with srsieve2 when there was a large number of k's remaining. One of these is your recent post about R546.
Quote:
Quote:
Quote:
1. R358 is sieved to P=~964M like you stated in your post. But the file shows that it was sieved to P=694851893. Why is the file wrong? My sieves confirmed that P=~964M is correct. But the factor removal is faster than 1 per second. I don't know why you are showing one every 7000 secs. 2. S330 appears to be sieved to between P=300M and 350M somewhere. But you and the file show that it was sieved to P=32M. I'm getting ZERO factor removal at P=300M but many factors being removed per second at P=350M. 3. R546 appears to be sieved to P=1G. But you and the file show that it was sieved to P=715M. I'm getting no factor removal at various tests for P>715M including at P=990M. For additional verification I confirmed that factors were being removed at P>1G. So I'm confused what is happening. Below are my suggestions of what we should do. Please feel free to offer alternatives. 1. I can finish sieving R358 to P=1G. 2. For the S330 sieve depth, what you stated and what is in the file are very far off from the actual sieve depth. I feel like you should maybe start over the sieving of that one with a version of srsieve2 that you know is working properly. 3. As I stated above I will continue sieving R546 using srsieve for P=715M1G to see if there are any missing factors. That effort will be complete in ~4 hours from this post. I do not expect to find any factors. If none are found I will simply update the sieve depth in the file. I hope that future versions of srsieve2 are able to handle large numbers of k's remaining. Perhaps srsieve is better suited for such bases. Last fiddled with by gd_barnes on 20210824 at 01:12 

20210824, 05:22  #291 
May 2007
Kansas; USA
2·5,261 Posts 
Confirmed #3 in my last post: The file provided to me for R546 was already sieved to P=1G.

20210824, 06:04  #292  
Sep 2011
Germany
2978_{10} Posts 
Quote:
There could be 2 issues why its not working. The amount of k's or the multicore option W, in the past I ran without W and it was working but its a mess with 30 folders and merging every file. I always running 16cores + 14HT 

20210824, 06:38  #293  
May 2007
Kansas; USA
2×5,261 Posts 
Quote:
That would be a mess! I would like to do a comparison between srsieve and srsieve2: How many CPU hours did it take you to run that full sieve? Here is what I did: I sieved P=715M1G in ~8.5 hours on 4 cores. So that's ~34 CPU hours for a P=285M range. Extrapolating: If I sieved the entire range we'd have: 1000M totalrange / 285M range that I sieved * 34 CPU hours = ~120 CPU hours. To be fair, add about ~10% since the higher Pranges sieve faster. Therefore: I estimate using srsieve it would have taken me ~135 CPU hours to sieve S548 for n=2.5K10K to P=1G. How does that compare to how much CPU time that it took you running srsieve2? Last fiddled with by gd_barnes on 20210824 at 06:39 

20210824, 07:01  #294  
Sep 2011
Germany
2·1,489 Posts 
Quote:


20210824, 07:37  #295 
May 2007
Kansas; USA
10522_{10} Posts 
So...16 threads/cores * 20 hours = 320 CPU hours.
I estimated 135 CPU hours running srsieve with multiple instances. That's with an old (but very reliable) version of srsieve. Consider the following when sieving in the future: Split up the k's remaining into 8, 10, 12, or 16 pieces depending on the # of cores/threads you want to use. That's more efficient than splitting up Pranges while running multiple cores on all k's. Sieve them all at the same time with separate instances of srsieve (or try it with srsieve2). Then use srfile to combine all of the files at the end. I'm pretty sure you'll save CPU time that way. Of course that defeats the purpose of having a multithreaded program, which is its ease of use. But if its using that much more CPU time then you might consider the extra personal time worth it. My sieving machine is not real fast and not overclocked. It's an AMD Ryzen 16 core/32 thread running at 3.2 Ghz. 
20210824, 08:46  #296  
Sep 2011
Germany
2·1,489 Posts 
Quote:


20210824, 09:19  #297  
May 2007
Kansas; USA
10100100011010_{2} Posts 
Quote:
The benchmark that I gave you for the 4 cores running srsieve was with 20 instances of LLR running at the same time. So 24 threads were in operation at that time. That is generally the most that I will run on it at one time. Last fiddled with by gd_barnes on 20210824 at 09:23 

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Useless SSE instructions  __HRB__  Programming  41  20120707 17:43 
Questions about software licenses...  WraithX  GMPECM  37  20111028 01:04 
Software/instructions/questions  gd_barnes  No Prime Left Behind  48  20090731 01:44 
Instructions to manual LLR?  OmbooHankvald  PSearch  3  20050805 20:28 
Instructions please?  jasong  Sierpinski/Riesel Base 5  10  20050314 04:03 