mtsieve

[pepi37]

Single sequence is only I need 😊

[pepi37]

e:\MTSIEVE\216>srsieve2cl -P 2e15 -H -D 1 -d 1 -i 92.txt -g 120 -o 92.txt -f B -l
srsieve2cl v1.5, a program to find factors of k*b^n+c numbers for fixed b and variable k and n
Sieving one sequence where abs(c) = 1 for p >= 1600012693787917
Split 1 base 10 sequence into 216 base 10^360 sequences.
709440 bytes used for congruence tables
CL_DEVICE_MAX_COMPUTE_UNITS = 22
CL_DEVICE_GLOBAL_MEM_SIZE = 2147483648
CL_DEVICE_LOCAL_MEM_SIZE = 49152
CL_KERNEL_WORK_GROUP_SIZE = 256
CL_KERNEL_PREFERRED_WORK_GROUP_SIZE_MULTIPLE = 32
CL_KERNEL_LOCAL_MEM_SIZE = 1
CL_KERNEL_PRIVATE_MEM_SIZE = 14752
GPU global bytes allocated = 36837532
GPU private bytes allocated = 4805632
GPU primes per worker is 675840
Sieve started: 1600012693787917 < p < 2e15 with 93883 terms (1400033 < n < 2999998, k*10^n+c) (expecting 595 factors)
p=1600014279249383, 742.3K p/sec, no factors found, 0.0% done. ETC 2021-08-02 01:12

CPU is Intel 9600K ( 5% utilization)
GPU is 1660 Super ( working only with this program)


I experiment with g , and if I go above 150 my gpu utilization spikes from 0 -100% but speed is same as I use g=120 so it is around 742.3K p/sec


I will kindly ask to explain -W and -w parameters since they clearly are not same as in rest of mtsieve package.

Test was done on sequence 92*10^n-1 from ( sieve is from 1M4 to 3M) with 93883 candidates

[rogue]

Originally Posted by pepi37

CPU is Intel 9600K ( 5% utilization)
GPU is 1660 Super ( working only with this program)


I experiment with g , and if I go above 150 my gpu utilization spikes from 0 -100% but speed is same as I use g=120 so it is around 742.3K p/sec


I will kindly ask to explain -W and -w parameters since they clearly are not same as in rest of mtsieve package.

Test was done on sequence 92*10^n-1 from ( sieve is from 1M4 to 3M) with 93883 candidates

How does that compare to the speed of sr1sieve?

-W is used to specify the number of CPU only workers.
-w is the number of primes per chunk per worker.

-G is used to specify the number of GPU only workers.
-g is a multiplier for the CL_DEVICE_MAX_COMPUTE_UNITS * CL_KERNEL_WORK_GROUP_SIZE to compute the number of primes per chunk per worker.

For CPU-only exes, -W defaults to 1 and -w to 1e6.
For GPU exes, -W defaults to 0 and -G default to 1 and -g defaults to 10.

For GPU-only exes, if p_min < a threshold determined at runtime, then a CPU worker is used even if -W is 0, but that CPU worker is only used until p_min > that threshold. IIRC, that threshold is min(1e6, k) for srsieve2cl. 1e6 is used because the factor density is fairly high for low p and I want to limit how much GPU memory is needed to pass factors back to the CPU. It is typically n_max or k_max for other GPU exes. -M is used to adjust the amount of memory needed for returning factors. If the default is not sufficient, then you will be told at runtime to adjust it if it detects too many factors for given -M.

You can use -W with a value > 0 for GPU exes, but that really depends upon the relative speed of your CPU to your GPU.
You cannot use -G with CPU-only exes.

I don't see a usage for -G > 1, but I suppose you can do that if -g isn't large enough to keep your GPU busy.

If -g is too large you could encounter screen lag.

I hope that answers your questions.

[pepi37]

I can compare speed of sieves only by finish date

[rogue]

Originally Posted by pepi37

I can compare speed of sieves only by finish date

There is an ETA output by both programs and a factors removal rate. You just need to run both them for 10 minutes, hit ^c, then compare the results to see which one sieved further during that time.

[MisterBitcoin]

I encountered an bug while using srsieve2 on an large input file (around 100 MB). After two days of sieving it stopped at the given Pmax; but look at the screen output:

  p=19852801223, 178.6 p/sec, 4397895 factors found at 6.62 sec per factor (last
  p=19852801223, 180.6 p/sec, 4397919 factors found at 6.63 sec per factor (last
  p=19852801223, 176.3 p/sec, 4397936 factors found at 6.64 sec per factor (last
  p=19852801223, 180.7 p/sec, 4397951 factors found at 6.65 sec per factor (last
 517 min), 99.2% done. ETC 2021-02-05 12:14
2 workers didn't stop after 10 minutes

D:\sieve>

Which also means he didnt saved the file, last checkpoint was around 4 hours ago which is okay.
However i wonder why it did crash, is there a function that gives the app an timeout after a worker didnt reported the results back after reaching n-minutes?

[rogue]

Originally Posted by MisterBitcoin

I encountered an bug while using srsieve2 on an large input file (around 100 MB). After two days of sieving it stopped at the given Pmax; but look at the screen output:

  p=19852801223, 178.6 p/sec, 4397895 factors found at 6.62 sec per factor (last
  p=19852801223, 180.6 p/sec, 4397919 factors found at 6.63 sec per factor (last
  p=19852801223, 176.3 p/sec, 4397936 factors found at 6.64 sec per factor (last
  p=19852801223, 180.7 p/sec, 4397951 factors found at 6.65 sec per factor (last
 517 min), 99.2% done. ETC 2021-02-05 12:14
2 workers didn't stop after 10 minutes

D:\sieve>

Which also means he didnt saved the file, last checkpoint was around 4 hours ago which is okay.
However i wonder why it did crash, is there a function that gives the app an timeout after a worker didnt reported the results back after reaching n-minutes?

This occurs when the main thread suspects that one or more of the worker threads has become unresponsive, maybe stuck in a tight loop. In this case because p/sec is so low each worker thread needs more than 10 minutes to process a single chunk of primes. In this case the worker thread was likely still working. I can look into a change to not do that check under certain circumstances.

To get around the problem, I suggest that you use -w1e3 or -w1e4 (the default is -w1e6). This will give smaller chunks of work to each worker and thus they can process the chunk must faster. This will have a negligible affect on overall rate since so little time is spent in the prime sieve.

[Happy5214]

I ran into an issue starting a new Riesel sieve with multiple workers:

$ ./bin/srsieve2 -W 3 -n 125e3 -N 300e3 -P 1e9 -o t17_b2.prp -f B -s "14549535*2^n-1" 
srsieve2 v1.5, a program to find factors of k*b^n+c numbers for fixed b and variable k and n
Sieving with generic logic for p >= 3
Sieve started: 3 < p < 1e9 with 175001 terms (125000 < n < 300000, k*2^n+c) (expecting 165723 factors)
Sieving with generic logic for p >= 257
Split 1 base 2 sequence into 1 base 2^1 sequences.
Fatal Error:  Invalid factor: 14549535*2^128595-1 mod 34747 = 22443

-W 2 and -W 4 also failed with the same error at other small primes, but using only 1 worker seemed to get past that stage (I had another sieve running that I didn't want to interfere with, so I didn't complete this):

$ ./bin/srsieve2 -W 1 -n 125e3 -N 300e3 -P 1e9 -o t17_b2.prp -f B -s "14549535*2^n-1"
srsieve2 v1.5, a program to find factors of k*b^n+c numbers for fixed b and variable k and n
Sieving with generic logic for p >= 3
Sieve started: 3 < p < 1e9 with 175001 terms (125000 < n < 300000, k*2^n+c) (expecting 165723 factors)
Sieving with generic logic for p >= 257
Split 1 base 2 sequence into 1 base 2^1 sequences.
Sieving one sequence where abs(c) = 1 for p >= 15489191
Split 1 base 2 sequence into 171 base 2^180 sequences.
741796 bytes used for congruence tables
1617098 bytes used for Legendre tables
^CCTRL-C accepted.  Threads will stop after sieving to 32456407
Sieve interrupted at p=32456407.
CPU time: 16.72 sec. (0.03 sieving) (0.97 cores)
43690 terms written to t17_b2.prp
Primes tested: 1000000.  Factors found: 131311.  Remaining terms: 43690.  Time: 17.19 seconds.

[rogue]

Originally Posted by Happy5214

I ran into an issue starting a new Riesel sieve with multiple workers:

$ ./bin/srsieve2 -W 3 -n 125e3 -N 300e3 -P 1e9 -o t17_b2.prp -f B -s "14549535*2^n-1" 
srsieve2 v1.5, a program to find factors of k*b^n+c numbers for fixed b and variable k and n
Sieving with generic logic for p >= 3
Sieve started: 3 < p < 1e9 with 175001 terms (125000 < n < 300000, k*2^n+c) (expecting 165723 factors)
Sieving with generic logic for p >= 257
Split 1 base 2 sequence into 1 base 2^1 sequences.
Fatal Error:  Invalid factor: 14549535*2^128595-1 mod 34747 = 22443

-W 2 and -W 4 also failed with the same error at other small primes, but using only 1 worker seemed to get past that stage (I had another sieve running that I didn't want to interfere with, so I didn't complete this).]

Hmm. I'll take a look. This seems to have failed in the generic sieving logic, not the cisone logic.

[rogue]

Originally Posted by rogue

Hmm. I'll take a look. This seems to have failed in the generic sieving logic, not the cisone logic.

I see what I did wrong It was something I introduced in the most recent release. I'll fix in the next release. Since you are on linux or OS X, I have committed the files so you can build and try again.

[Happy5214]

Originally Posted by rogue

I see what I did wrong It was something I introduced in the most recent release. I'll fix in the next release. Since you are on linux or OS X, I have committed the files so you can build and try again.

It worked, though I actually didn't need it anymore. My workflow involves using srsieve2 to 1e9 and the faster sr1sieve or sr2sieve beyond that (this old box has no real GPU option), so I just burned the extra minute and ran it with one worker.