mtsieve

[storm5510]

Originally Posted by rogue

Okay. I built on Windows 10. I do not have a Windows 7 machine to build on and I'm not certain how to build a Windows 7 compatible binary. If you want to try your own build, then you will need to install this:

D:\test\done>gcc --version
clang version 14.0.0 (https://github.com/llvm/llvm-project.git 329fda39c507e8740978d10458451dcdb21563be)
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: C:/llvm-mingw-20220323-ucrt-x86_64/bin

And an OpenCL SDK. I don't know if the AMD one I have used is still available online, but there are others.

No, I won't try to do a custom build. The older one you wrote in 2020 is working just fine. Using the -W switch to specify threads helps tremendously.

[storm5510]

@rogue

Look at the last line in the attached image. It may have something to do with the line after the invocation.

[Happy5214]

Originally Posted by storm5510

If will only display the first one it does not find. Below are some sample names I found.

api-ms-win-core-console-l1-1-0.dll
api-ms-win-core-console-l1-2-0.dll
api-ms-win-core-datetime-l1-1-0.dll

There are many more. I "think" these may be .Net Framework, but I am not sure.

From what I could gather on the Microsoft website, those are internal API DLLs for the operating system (the specific phrase used was "implementation detail"), and they're Windows version-specific. They will not work if copied from a newer version of Windows. To answer your question, they're not related to .Net.

[rogue]

Originally Posted by storm5510

@rogue

Look at the last line in the attached image. It may have something to do with the line after the invocation.

This is not a valid use case for srsieve2. You must pre-sieve all sequences to remove small terms before triggering the special logic which is used for larger p. You should never start sieving a new sequence at p > 1e6. In fact you should never specify -p when you start a new sequence.

I will add some validation to prevent this.

[storm5510]

Originally Posted by rogue

This is not a valid use case for srsieve2. You must pre-sieve all sequences to remove small terms before triggering the special logic which is used for larger p. You should never start sieving a new sequence at p > 1e6. In fact you should never specify -p when you start a new sequence.

I will add some validation to prevent this.

This is the 3rd of 3 batch files. The first two use lower p values.

Look at my last post in "Sieving for CRUS." If you change the program, I may not be able to do what I am doing now unless I stay with the current version, which I would have to.

[pepi37]

In srsieve2cl what is M switch?
I cannot find it in help menu...

srsieve2cl -g 512 -M 7500 -P 5e13 -f B -i b1732_n.boinc -o b17323_n.boinc -O fact173.txt

I do some testing on GPU ( 2070 SUPER) and find that -g must be 512 to get stable 95% gou utilization and speed same as 4 core ryzen 7 5700x at 4Ghz.
But switch M is still mystery. (and looks like speed is same with or without M switch)

[rogue]

Originally Posted by pepi37

In srsieve2cl what is M switch?
I cannot find it in help menu...

I do some testing on GPU ( 2070 SUPER) and find that -g must be 512 to get stable 95% gou utilization and speed same as 4 core ryzen 7 5700x at 4Ghz.
But switch M is still mystery. (and looks like speed is same with or without M switch)

-M sets the maxfactordensity, which indicates the number of expected factors per 1e6 terms. If the GPU cannot report all of the factors it will terminate the run and tell you to adjust it. At higher p you shouldn't need to adjust it. If you need to set it and set it too high, then it could impact performance due to how much more memory is required.

[rogue]

I have posted mtsieve 2.3.8. Here are the changes:

mfsieve/mfsievecl: version 2.1
   Build a list of terms with powers prior to sieving so that computing minn! is faster.
   For factorial, this improves the calculation of minn! by 30% with minn=1e6 when using
   the GPU and by 40% when using the CPU.
   Multi-factorials where minn < 1e6 will see less of a boost in performance.
   
srsieve2/srsieve2cl: version 1.6.6   
   Added -Q which will output estimated work for each possible q.
   Added -q which can be used to specify the q to use (if that q is possible),
   overriding the computed best q.
   
   To use -Q, first sieve your sequence(s) to at least 1e6.  This will ensure that
   subsequent runs are using the correct sieving subroutines.  Starting with the
   output file, run that output file with the -q flag then stop immediately after
   it outputs a group of lines looking like this:
   
   q =   45 with    162 subseq yields bs =   445, gs =     2, work =    793
   
   work is an estimated cost for that q with lower costs implying higher throughput.
   
   To use -q, take each of the q values output from -Q and run a range of at least
   1e9 to determine the actual amount of time it takes for that q.  Using the
   Run a range of at least 1e9 using -Q to specific which q to run with selecting
   the q output from using the -q flag.  Although you can run all q, you can limit
   to those q withing 20% of the lowest cost.  For each run observe the total time
   for that run to determine which q required the least amount of time.  You should
   then run the entire range with that q.  This will not necessrily be the q with
   the lowest cost.

[Happy5214]

Originally Posted by rogue

I have posted mtsieve 2.3.8. Here are the changes:

[...]
   
srsieve2/srsieve2cl: version 1.6.6   
   Added -Q which will output estimated work for each possible q.
   Added -q which can be used to specify the q to use (if that q is possible),
   overriding the computed best q.
   
   To use -Q, first sieve your sequence(s) to at least 1e6.  This will ensure that
   subsequent runs are using the correct sieving subroutines.  Starting with the
   output file, run that output file with the -q flag then stop immediately after
   it outputs a group of lines looking like this:
   
   q =   45 with    162 subseq yields bs =   445, gs =     2, work =    793
   
   work is an estimated cost for that q with lower costs implying higher throughput.
   
   To use -q, take each of the q values output from -Q and run a range of at least
   1e9 to determine the actual amount of time it takes for that q.  Using the
   Run a range of at least 1e9 using -Q to specific which q to run with selecting
   the q output from using the -q flag.  Although you can run all q, you can limit
   to those q withing 20% of the lowest cost.  For each run observe the total time
   for that run to determine which q required the least amount of time.  You should
   then run the entire range with that q.  This will not necessrily be the q with
   the lowest cost.

Your description of the -q and -Q flag usage seems to flip the flags around as it goes along. Can you please look over those again and clarify?

[rogue]

Sorry about that. How about this:

      Added -Q which will output estimated work for each possible q.
      Added -q which can be used to specify the q to use (if that q is possible),
      overriding the computed best q.
      
      To use -Q, first sieve your sequence(s) to at least 1e6.  This will ensure that
      subsequent runs are using the correct sieving subroutines.  Starting with the
      output file, run that output file with the -Q flag then stop immediately after
      it outputs a group of lines looking like this:
      
      q =   45 with    162 subseq yields bs =   445, gs =     2, work =    793
      
      work is an estimated cost for that q with lower costs implying higher throughput.
      
      To use -q, take each of the q values output from -Q and run a range of at least
      1e9 to determine the actual amount of time it takes for that q.  Using the
      Run a range of at least 1e9 using -q to specific which q to run with selecting
      the q output from using the -q flag.  Although you can run all q, you can limit
      to those q withing 20% of the lowest cost.  For each run observe the total time
      for that run to determine which q required the least amount of time.  You should
      then run the entire range with that q.  This will not necessrily be the q with
      the lowest cost.

[Happy5214]

Originally Posted by rogue

Sorry about that. How about this:

      Added -Q which will output estimated work for each possible q.
      Added -q which can be used to specify the q to use (if that q is possible),
      overriding the computed best q.
      
      To use -Q, first sieve your sequence(s) to at least 1e6.  This will ensure that
      subsequent runs are using the correct sieving subroutines.  Starting with the
      output file, run that output file with the -Q flag then stop immediately after
      it outputs a group of lines looking like this:
      
      q =   45 with    162 subseq yields bs =   445, gs =     2, work =    793
      
      work is an estimated cost for that q with lower costs implying higher throughput.
      
      To use -q, take each of the q values output from -Q and run a range of at least
      1e9 to determine the actual amount of time it takes for that q.  Using the [?]
      Run a range of at least 1e9 using -q to specific[specify] which q to run with[by] selecting
      the q output from using the -q[-Q] flag.  Although you can run all q, you can limit
      to those q withing 20% of the lowest cost.  For each run observe the total time
      for that run to determine which q required the least amount of time.  You should
      then run the entire range with that q.  This will not necessrily[necessarily] be the q with
      the lowest cost.

I just marked up the quote to show what I best understood it to mean.