[QUOTE=pepi37;507202]Still not working[/QUOTE]

Please PM me with more details.

My fix for many sequences is causing the issue. Stupid mistake on my part. Works great if you have more than 128 sequences, but not so well if less than that. D'oh!

I have attached a fixed version

sr2seive 2.0.0 is attached. This version supports k up to 2^64, which required a number of code changes. This version also does additional validation to prevent the building of invalid Legendre tables, which can happen in all older releases. That is likely to happen for k > 2^31, but can happen for k < 2^31.

I was going to call this 1.9.5, but I needed to leave room for the possibility of bugs or other small enhancements to 1.9.4.

This is a beta, so I would appreciate any help I can get WRT testing. The testing I have done focuses on k > 2^32 with thousands of sequences. The good news is that sr2sieve finds all of the same factors that srsieve finds. The better news is that sr2sieve (with -x) is about 30% faster than srsieve.

This means that I can use the discrete log logic from sr2sieve in srsieve2. This will effectively merge srsieve and sr2sieve into one program. In the process many of the switches to sr2sieve will go away. These include -g and -a (specific to sr5sieve (specific to BASE 5), -s and -r (specific to BASE 2), -u, --amd, --amd, --intel, --sse2, --no-sse2, -l, -L, -B -G -ladder -H, -Q, --scale-giant, --min-giant, -D, --log-factors, -R, -S, -z, -Z, -A, -j, -X, -d, -q, -v. Some of these switches are only enabled if one makes changes to sr2sieve.h or the makefile. I will likely add something akin to -R to the mtsieve framework.

If anyone relies on one of the switches that will not be supported in srsieve2, please let me know.

sr2sieve is limited to abs(c) = 1, unless doing a "dual" sieve. The "dual" sieve functionality won't be migrated to srsieve2, but it implies that I still need to support abs(c) != 1, which is only possible in srsieve. Ugh!

After a long hiatus, I finally started working on srsieve2 again. Based upon very limited testing srsieve2 is about 20% faster than srsieve. srsieve2 doesn't have all of the features of srsieve yet, but I will be adding the features I intend to add when I have time. BTW, srsieve2 will also incorporate the sr2sieve logic after I work out any bugs in the logic. There will be two code paths, one for abs(max(c)) = 1 (sr2sieve) and one for abs(max(c)) > 1 (srsieve). I don't know about sr1sieve yet, but I think it is basically sr2sieve but for a single sequence. If necessary I will create a third code path for that.

I'm looking at the options available to srsieve, sr1sieve, sr2sieve, and srfile and comparing to what I've done so far with srsieve2. You can see the comparison below. I'm looking for feedback from all users of these programs to tell me which command line features they use in those programs and want me to implement in srsieve2. The ones with '??' are ones that I intend to add, but haven't implemented. I'll open up the discussion for new features after I release this code.

[CODE]srsieve options: srsieve2 options:
-p --pmin P0 -p
-P --pmax P1 -P
-n --nmin N0 -n
-N --nmax N1 -N
-o --output FILE -o
-r --report X not configurable, always reports every 60 seconds
-s --save X not configurable, always saves every 60 minutes
-S --stop-rate X no corresponding option
-m --minimum X factors are only written to factor file if -O is specified
-B --babystep X no corresponding option
-H --hashtable X no corresponding option
-F --force-base X no corresponding option
-L --limit-base X no corresponding option
-M --mod M,a,b,.. no corresponding option
-f --factors -O
-g --newpgen no corresponding option
-G --prp no corresponding option
-w --pfgw -fA
-a --abcd -fD (default)
-c --check all factors are verified
--no-check cannot be disabled
-C --checkpoint always saves every 60 minutes
-d --duplicates no corresponding option
-y --no-filter no corresponding option
-z --idle always runs at idle priority
-Z --no-idle always runs at idle priority
-A --affinity N no corresponding option
-v --verbose no corresponding option
-q --quiet no corresponding option
-h --help -h
SEQUENCE ... -s can use multiple times, can specify a sequence of file of sequences
FILE ... -i

sr2sieve options:
-s --sierpinski no corresponding option
-r --riesel no corresponding option
-i --input FILE -i

-p --pmin P0 -p
-P --pmax P1 -P
-f --factors FILE -O
-u --uid STRING no corresponding option
-c --cache no corresponding option
-C --cache-file FILE no corresponding option
-l --L1-cache SIZE no corresponding option
-L --L2-cache SIZE no corresponding option
-B --baby METHOD no corresponding option
-G --giant METHOD no corresponding option
--ladder METHOD no corresponding option
-H --hashtable SIZE no corresponding option
-Q --subseq Q no corresponding option
--scale-giant X no corresponding option
--min-giant NUM no corresponding option
-D --duplicates FILE no corresponding option
--log-factors no corresponding option
-R --rate SECONDS no corresponding option
-S --save TIME always saves every 60 minutes
-z --lower-priority no corresponding option
-Z --raise-priority no corresponding option
-A --affinity N no corresponding option
-j --sobistrator no corresponding option
-X --skip-cubic no corresponding option
-x --no-lookup ??
-d --dual ??
-q --quiet factors are only written to factor file if -O is specified
-v --verbose no corresponding option
-h --help -h

sr1sieve options:
-p --pmin P0 -p
-P --pmax P1 -P
-i --input FILE -i
-o --output FILE -o
-f --factors FILE -O
-C --cache-file FILE no corresponding option
-s --save TIME always saves every 60 minutes
--sse2 no corresponding option
--no-sse2 no corresponding option
-l --L1-cache SIZE no corresponding option
-L --L2-cache SIZE no corresponding option
-B --baby METHOD no corresponding option
-G --giant METHOD no corresponding option
-H --hashtable SIZE no corresponding option
-Q --subseq Q no corresponding option
-F --format=f -fD (ABCD, default) and -fA (ABC)
-x --no-lookup ??
-z --lower-priority always runs at idle priority
-Z --raise-priority always runs at idle priority
-A --affinity N no corresponding option
-d --duplicates no corresponding option
-q --quiet factors are only written to factor file if -O is specified
-v --verbose no corresponding option
-h --help -h

srfile options:
-o --output FILE -o
-k --known-factors FILE -I
-d --delete SEQ ??
-g --newpgen no corresponding option
-G --prp no corresponding option
-w --pfgw -fA (ABC format)
-a --abcd -fD (ABCD format, default)
-Q --subseqs X no corresponding option
-B --newbase BASE no corresponding option
-E --extract KLIST no corresponding option
-c --congruence X no corresponding option
-p --pfactor X no corresponding option

-v --verbose no corresponding option
-q --quiet no corresponding option
-h --help -h
INFILE ... -i

other srsieve2 options:
-w number of primes per chunk per worker, default 1e6
-W number of worker threads
-A apply factors from -I and exit
[/CODE]

I use -m to suppress screen output when a sieve is first starting up; printing factors to screen can reduce sieve speed dramatically when the factors-found rate is in thousands per second.

On srsieve, this is important also because the status line scrolls off the screen along with factors; if one is finding hundreds of factors per second one is unable to ever see the status line on-screen. this isn't a problem with sr2sieve, as that status line stays at the bottom (and is printed with every factor found, not just every 60 seconds- perhaps that's why sieve speed suffers so much!)

[QUOTE=VBCurtis;515414]I use -m to suppress screen output when a sieve is first starting up; printing factors to screen can reduce sieve speed dramatically when the factors-found rate is in thousands per second.

On srsieve, this is important also because the status line scrolls off the screen along with factors; if one is finding hundreds of factors per second one is unable to ever see the status line on-screen. this isn't a problem with sr2sieve, as that status line stays at the bottom (and is printed with every factor found, not just every 60 seconds- perhaps that's why sieve speed suffers so much!)[/QUOTE]

Sorry that I wasn't clear in how factors are handled.

For all programs built on the mtsieve framework, no factors are written to the console. You can only write factors to a factor file and that can be done with the -O switch. The mtsieve programs will output a status update once every 60 seconds overwriting the previous status line. Once every 60 minutes the remaining candidates are written to an output file. For most of the mtsieve programs the name of that file is auto-generated. srsieve2 will auto-generate that file name.

There are two reasons to use the -O switch. The first is if you are sieving the same range across multiple computers and need to merge all of the factor files to generate a new candidate file. The second is if you want to independently verify that factors found are truly factors with pfgw. All of the mtsieve programs will verify factors and terminate if one is invalid, but there is always the possibility that the math used to verify factors is wrong. But considering how much time I spend in validating factors that are found with pfgw, that is a very slim possibility. I would rather that a the software misses a factor than reports an invalid one.

I'm looking at the sr2sieve code and what is driving me crazy is the number of optimizations that are driven by changing values in sr2sieve.h and recompiling. All of that is going away. I'm focusing on base case since that is how I've compiled and released sr2sieve. If there are any users/projects that need specific optimizations associated with their build, please let me know. Two specific optimizations are "dual sierpinski" and base 5 which is used to create sr5sieve.

Besides multi-threading, some features are only enabled if using the GNU compiler. Those restrictions will go away. I'm hoping that by the time I'm done that srsieve2 will be fast enough that there is no reason to continue using sr1sieve, sr2sieve, or sr5sieve. There might be opportunities to optimize very specific cases even further, but that is for the future and only upon request.

[QUOTE=rogue;515426]I'm hoping that by the time I'm done that srsieve2 will be fast enough that there is no reason to continue using sr1sieve, sr2sieve, or sr5sieve.[/QUOTE]

It would be amazing to maintain only one codebase. :smile:

-r is an option I frequently use when I use srsieve. Sometimes I want longer that the default and sometimes shorter while experimenting. Output should always be controllable.

I use the cache options -c/-C of sr2sieve almost all the time as it generally provides good speedups. I have also found -Q useful when building/testing my CUDA version of sr2sieve, and sometimes you can find greater speed in sr2sieve by using it to change the number of subsequences being sieved.

[QUOTE=rob147147;515649]I use the cache options -c/-C of sr2sieve almost all the time as it generally provides good speedups. I have also found -Q useful when building/testing my CUDA version of sr2sieve, and sometimes you can find greater speed in sr2sieve by using it to change the number of subsequences being sieved.[/QUOTE]

I do see value in -c/-C, but I'm not as familiar with -Q. I am not familiar with any CUDA version of sr2sieve.

[QUOTE=rogue;515659]I do see value in -c/-C, but I'm not as familiar with -Q. I am not familiar with any CUDA version of sr2sieve.[/QUOTE]
PPS sieva?
Running on GPU for base2

[QUOTE=rob147147;515649]I use the cache options -c/-C of sr2sieve almost all the time as it generally provides good speedups. I have also found -Q useful when building/testing my CUDA version of sr2sieve, [B]and sometimes you can find greater speed in sr2sieve by using it to change the number of subsequences being sieved.[/B][/QUOTE]


Can you give me some example?
Also, how much speed gain you can get? 10%, more?

I've been working on my own implementation of a CUDA version of sr2sieve for some time. Its still very much a work in progress (it only sieves the -1 side atm, so k*b^n-1, and only prints factors to the terminal). On a 2070 MaxQ it can sieve between 3x and 10x faster than a single cpu core on various test files I've tried, and finds all factors in my test cases, but I'm not claiming it is perfect. It could miss factors in other test cases though I hope not.

I push the code updates to my github occasionally but its a bit out of date currently. [url]https://github.com/rob147147/CUDA-Riesel-Sieve/tree/MX150BranchTesting[/url]

-Q varies the number of subsequences. sr2sieve will rewrite a sequence k*b^n-1 as (k*b^r) * b^(Qm) - 1, where n=Q*m + r. So you sieve a greater number of (sub)sequences, over a smaller range (m instead of n). Sometimes it can help to vary this, often not. I don't have any test cases to hand where I noticed a reasonable difference. Will try to dig some up at some point.

[QUOTE=pepi37;515660]PPS sieva?
Running on GPU for base2[/QUOTE]

I'm not touching ppsieve and srsieve2 will not replace it.

@rogue:
I have a bigger difference in tests left between srsieve 1.0.5 and srsieve 1.1.4:


with R627 up to 100M (2.5-10k range)

srsieve 1.0.5: 1137188 tests left
srsieve 1.1.4: 1339442 tests left

[QUOTE=rebirther;521457]@rogue:
I have a bigger difference in tests left between srsieve 1.0.5 and srsieve 1.1.4:

with R627 up to 100M (2.5-10k range)

srsieve 1.0.5: 1137188 tests left
srsieve 1.1.4: 1339442 tests left[/QUOTE]

I'll take a look. Are the sequences to be sieved on the CRUS site?

[QUOTE=rogue;521465]I'll take a look. Are the sequences to be sieved on the CRUS site?[/QUOTE]

If you need a file let me know. Its a new started base up to 2.5k for CRUS.

[QUOTE=rebirther;521467]If you need a file let me know. Its a new started base up to 2.5k for CRUS.[/QUOTE]

I will since I didn't see it on the CRUS page.

[QUOTE=rogue;521469]I will since I didn't see it on the CRUS page.[/QUOTE]


Email sent.

The old code is removing algebraic factors that are not removed by the newer code (which was heavily reworked). Although I won't fix srsieve, I will ensure that srsieve2 removes those algebraic factors correctly.

I am using s2sieve v2 as a drop in replacement for an in-progress 1.8.11 sieve.
The 1.8.11 has a 65 mil p/sec rate on 4 threads, s2sieve 2 has a 50mil p/sec rate with the exact same arguments.

[CODE]sr2sieve 1.8.11 -- A sieve for multiple sequences k*b^n+/-1 or b^n+/-k.
Read 11367 terms for 1 sequence from ABCD format file `sr_2.abcd'.
Split 1 base 2 sequence into 32 base 2^36 subsequences.
Wrote 1 Legendre symbol lookup tables to version 1 cache file `cache'.
Loaded Legendre symbol lookup tables for 1 sequences from `cache'.
Resuming from checkpoint pmin=5499307326589 in `checkpoint.txt'.
Expecting to find factors for about 507.80 terms in this range.
sr2sieve 1.8.11 started: 2221074 <= n <= 2300000, 5499307326589 <= p <= 20000000000000
5509220732291 | 39547695*2^2269624-1
p=5513128324607, 65904269 p/sec, 34 factors, 2.8% done, ETA 28 Sep 14:27[/CODE][CODE]sr2sieve 2.0.0 -- A sieve for multiple sequences k*b^n+/-1 or b^n+/-k.
Read 11367 terms for 1 sequence from ABCD format file `sr_2.abcd'.
Split 1 base 2 sequence into 32 base 2^36 subsequences.
Loaded Legendre symbol lookup tables for 1 sequences from `cache'.
Resuming from checkpoint pmin=5484267013231 in `checkpoint.txt'.
Expecting to find factors for about 507.80 terms in this range.
sr2sieve 2.0.0 started: 2221074 <= n <= 2300000, 5484267013231 <= p <= 20000000000000
5496333170473, 50718759 p/sec, 33 factors, 2.7% done, 0 sec/factor, ETA 29 Sep 09:21[/CODE]IMPORTANT EDIT: sr2sieve v2 has niceness of 19, while 1.8 has 0, so that was the cause - my cpu was overburdened at the time of the testing.

But after giving ample cpu headroom I am still getting 85 mil p/sec vs 82 mil p/sec against v2

[QUOTE=rogue;507251]sr2seive 2.0.0 is attached. This version supports k up to 2^64, which required a number of code changes. This version also does additional validation to prevent the building of invalid Legendre tables, which can happen in all older releases. That is likely to happen for k > 2^31, but can happen for k < 2^31...
[/QUOTE]

I tried running this yesterday. There are some items missing, according to the readme file. [I]srsieve.exe[/I] and [I]srfile.exe. [/I]Other references suggest [I]sr1sieve.exe[/I]. I am looking for Windows builds! It would be nice to have all the pieces...

[QUOTE=storm5510;536570]I tried running this yesterday. There are some items missing, according to the readme file. [I]srsieve.exe[/I] and [I]srfile.exe. [/I]Other references suggest [I]sr1sieve.exe[/I]. I am looking for Windows builds! It would be nice to have all the pieces...[/QUOTE]

I suggest switching from srsieve to srsieve2 (part of the mtsieve distribution). srsieve and srfile are published in a separate post on this thread.

[QUOTE=rogue;536577]I suggest switching from srsieve to srsieve2 (part of the mtsieve distribution). srsieve and srfile are published in a separate post on this thread.[/QUOTE]

Thank you! I found all the different programs, including this one.

I have been using [I]NewPGen[/I] to produce my input files. Based on what I have seen, I should be able to bypass using it...

[QUOTE=storm5510;536579]Thank you! I found all the different programs, including this one.

I have been using [I]NewPGen[/I] to produce my input files. Based on what I have seen, I should be able to bypass using it...[/QUOTE]

Outside of some very specific forms not supported by other sieving software, newpgen is obsolete.

I am always open to improvements to the mtsieve framework and any of the sieving programs that are part of it. Any suggestions should be posted in that thread.

[QUOTE=rogue;536614]Outside of some very specific forms not supported by other sieving software, newpgen is obsolete.

I am always open to improvements to the mtsieve framework and any of the sieving programs that are part of it. Any suggestions should be posted in that thread.[/QUOTE]

I will have to experiment with [I]srsieve2[/I]. Its command line parameters are a bit different than [I]srsieve[/I], which I wrote a batch file to run it so I would not have to remember all the parameters.

[QUOTE]-B --baby METHOD Use METHOD for baby step mulmods.
-G --giant METHOD Use METHOD for giant step mulmods.
[/QUOTE] [QUOTE=henryzz;335574]Depending on various things like number of ks, range of n, number of candidates, etc the different methods can be faster or slower. By default it checks all of them to see which is fastest for that file on startup.[/QUOTE]

"METHOD" is not defined clearly in the documents. Could someone give an example of how this is used?

[QUOTE=storm5510;539016]"METHOD" is not defined clearly in the documents. Could someone give an example of how this is used?[/QUOTE]

You can override the loop it uses to unroll, but there isn't much value to that as the software tries to determine the optimal loop to use before sieving begins.

Where can I find the original sr1sieve source code. It is no longer available at the original site.
Thanks.

[QUOTE=Citrix;543165]Where can I find the original sr1sieve source code. It is no longer available at the original site.
Thanks.[/QUOTE]


[URL]https://www.bc-team.org/app.php/dlext/?cat=3[/URL]

[QUOTE=Citrix;543165]Where can I find the original sr1sieve source code. It is no longer available at the original site.
Thanks.[/QUOTE]

Is there something wrong with the current version?

[QUOTE=rogue;543178]Is there something wrong with the current version?[/QUOTE]

Srsieve2.exe is extremely slow for low weight numbers. I am trying to modify sr1sieve.exe for these. Looking at the source I only need to modify LIMIT_BASE (-Q flag).

[url]https://www.mersenneforum.org/showpost.php?p=529034&postcount=256[/url]
[url]https://www.mersenneforum.org/showthread.php?p=529034#post256[/url]

If Srsieve2.exe could have this then I do not use sr1sieve.exe

[QUOTE=Citrix;543189]Srsieve2.exe is extremely slow for low weight numbers. I am trying to modify sr1sieve.exe for these. Looking at the source I only need to modify LIMIT_BASE (-Q flag).

[url]https://www.mersenneforum.org/showpost.php?p=529034&postcount=256[/url]
[url]https://www.mersenneforum.org/showthread.php?p=529034#post256[/url]

If Srsieve2.exe could have this then I do not use sr1sieve.exe[/QUOTE]

The sources for all three are posted in this thread.

sr2sieve source is [URL="https://www.mersenneforum.org/showpost.php?p=507251&postcount=197"]here[/URL].

sr1sieve source is [URL="https://www.mersenneforum.org/showpost.php?p=507091&postcount=178"]here[/URL].

I use only [I]srsieve[/I] and [I]sr1sieve[/I]. Their parameters are similar. [I]Sr2sieve[/I] does a good job, but do not use it because I never work more than once sequence at a time. If [I]sr1sieve[/I] could read an ABC2 (PFGW) format, like the example below, then I would use it exclusively. I use [I]srsieve[/I] just long enough to create an input file for [I]sr1sieve[/I].

[CODE]ABC2 98475*2^$b-1
b: from 770000 to 1300000
[/CODE]

[QUOTE=storm5510;543248]I use only [I]srsieve[/I] and [I]sr1sieve[/I]. Their parameters are similar. [I]Sr2sieve[/I] does a good job, but do not use it because I never work more than once sequence at a time. If [I]sr1sieve[/I] could read an ABC2 (PFGW) format, like the example below, then I would use it exclusively. I use [I]srsieve[/I] just long enough to create an input file for [I]sr1sieve[/I].

[CODE]ABC2 98475*2^$b-1
b: from 770000 to 1300000
[/CODE][/QUOTE]

sr1sieve (by design) can only sieve for p > max k and possibly p > max n. I don't recall off the top of my head. This is one of drivers for its speed.

In some future state, srsieve2 will "do it all", but logic in sr1sieve and sr2sieve is incredibly convoluted so bringing it into srsieve2 is a massive undertaking. Each time I start I only get so far before I give up. This is mainly due to how I want to do the optimization, which is very different than the current logic being used.

[QUOTE=rogue;543249]sr1sieve (by design) can only sieve for p > max k and possibly p > max n. I don't recall off the top of my head. This is one of drivers for its speed.

In some future state, srsieve2 will "do it all", but logic in sr1sieve and sr2sieve is incredibly convoluted so bringing it into srsieve2 is a massive undertaking. Each time I start I only get so far before I give up. This is mainly due to how I want to do the optimization, which is very different than the current logic being used.[/QUOTE]

I am quite satisfied to use [I]srsieve[/I] and [I]sr1sieve[/I] as they are.

As I wrote before, [I]srsieve2[/I] needs to write a new line below the existing line, not replace it. Having a programming background of my own, this would seem a very minor modification.

[QUOTE=storm5510;543276]I am quite satisfied to use [I]srsieve[/I] and [I]sr1sieve[/I] as they are.

As I wrote before, [I]srsieve2[/I] needs to write a new line below the existing line, not replace it. Having a programming background of my own, this would seem a very minor modification.[/QUOTE]

I thought that I fixed that. Please check mtsieve framework 1.9.7. If I haven't please let me know.

[QUOTE=rogue;543286]I thought that I fixed that. Please check mtsieve framework 1.9.7. If I haven't please let me know.[/QUOTE]

I owe [B]rogue[/B] an apology. The behavior I noted was in [I]Windows PowerShell[/I]. [I]srsive2[/I] [U]does[/U] produce new lines in a Command Prompt console. I have had other programs that did not play well in [I]PowerShell[/I], [I]PFGW[/I] for one. If Microsoft wants to push [I]PowerShell [/I]as a replacement for Command Prompt, then any console program needs to behave the same as it does in Command Prompt.

[I]srsieve[/I] has an option to set a screen update interval, in seconds. As far as I can tell, [I]srsieve2[/I] does not have this. It would be nice if it did.

[QUOTE=storm5510;543358]I owe [B]rogue[/B] an apology. The behavior I noted was in [I]Windows PowerShell[/I]. [I]srsive2[/I] [U]does[/U] produce new lines in a Command Prompt console. I have had other programs that did not play well in [I]PowerShell[/I], [I]PFGW[/I] for one. If Microsoft wants to push [I]PowerShell [/I]as a replacement for Command Prompt, then any console program needs to behave the same as it does in Command Prompt.

[I]srsieve[/I] has an option to set a screen update interval, in seconds. As far as I can tell, [I]srsieve2[/I] does not have this. It would be nice if it did.[/QUOTE]

What does pfgw do in PowerShell differently than in the command prompt?

srsieve2 is set to 60 seconds between refreshes. I don't have a switch to change it because usage of that switch would be rare (as far as I know). I can't think of any cases where I have done sieving for less than 60 seconds outside of testing code changes. It would also impact the entire mtsieve framework. One of the things about mtsieve is that I want to keep usage of the framework (and its switches) simple and consistent.

[QUOTE=rogue;543359]What does pfgw do in PowerShell differently than in the command prompt?[/QUOTE]

It will overwrite an existing output line. This is in Windows 7's PowerShell. I have not tried it with Windows 10.

"The[I] mfsieve[/I] framework." This is part of [I]BOINC[/I]?


[U]Update[/U]: The behavior is the same in Windows 10 Powershell.

[QUOTE=storm5510;543361]It will overwrite an existing output line. This is in Windows 7's PowerShell. I have not tried it with Windows 10.

"The[I] mfsieve[/I] framework." This is part of [I]BOINC[/I]?


[U]Update[/U]: The behavior is the same in Windows 10 Powershell.[/QUOTE]

No. mtsieve has nothing to do with BOINC.

Can you explain what you mean by "overwrite and existing output line"? All of my sieves and pfgw can overwrite the current output line and is the default behavior. There are some cases where it will do a new line. I'm trying to understand your expectations.

[QUOTE=rogue;543366]...Can you explain what you mean by "overwrite and existing output line"? All of my sieves and pfgw can overwrite the current output line and is the default behavior. There are some cases where it will do a new line. I'm trying to understand your expectations.[/QUOTE]

Think of overwrite as "replaced by." Example: I have 1000 on the screen. 1000 changes to 1001 in the same location instead of dropping down to the next line below. [I]Prime95 [/I]does this. Each new item is placed below the existing one.

"Expectations." I do not have any. There is one item: Suppose I start a sieve with [I]srsieve2[/I] which will take 36 hours to complete. There is a power outage with only 4 hours left. As far as I can tell, everything would be lost because of no intermittent saving of the of the results. Is there an interval written into the code?

[QUOTE=storm5510;543372]Think of overwrite as "replaced by." Example: I have 1000 on the screen. 1000 changes to 1001 in the same location instead of dropping down to the next line below. [I]Prime95 [/I]does this. Each new item is placed below the existing one.

"Expectations." I do not have any. There is one item: Suppose I start a sieve with [I]srsieve2[/I] which will take 36 hours to complete. There is a power outage with only 4 hours left. As far as I can tell, everything would be lost because of no intermittent saving of the of the results. Is there an interval written into the code?[/QUOTE]

For pfgw, try -Cverbose. It will put the results of each PRP test on their own line. By default most users do not want to see intermediate outputs written to their own line as it just clutters the window with mostly useless information and one some systems will fill the command window buffer causing you to lose more important information. srsieve is one of few programs that does not work this way.

For all of the mtsieve programs, it will write to the output file once per hour. It is possible to lose up to just under 60 minutes of sieving time.

[QUOTE=rogue;543374]For pfgw, try -Cverbose. It will put the results of each PRP test on their own line. By default most users do not want to see intermediate outputs written to their own line as it just clutters the window with mostly useless information and one some systems will fill the command window buffer causing you to lose more important information. srsieve is one of few programs that does not work this way.

For all of the mtsieve programs, it will write to the output file once per hour. It is possible to lose up to just under 60 minutes of sieving time.[/QUOTE]

Look at the attached image. This is two instances of [I]LLR[/I] stacked on the screen. I suppose I am different because I do not consider everything there as useless. It is the same with [I]sr1sieve[/I]. I like to see what it has done and what it is doing at the same time. I started using computers in 1988 when there were few options about screen content. I became used to it.

I started out using [I]PFGW[/I] for Riesel searches. It was rapidly pointed out that I needed to be using [I]LLR[/I]. Probabilistic versus deterministic. I rarely use [I]PFGW[/I] now.

I solved my own problem with [I]srsieve2[/I] by not using [I]PowerShell[/I]. Writing to an output file every 60 minutes is good.

You refer to [I]mfsieve[/I] as a group of programs. Where can I find them?

[QUOTE=storm5510;543402]Look at the attached image. This is two instances of [I]LLR[/I] stacked on the screen. I suppose I am different because I do not consider everything there as useless. It is the same with [I]sr1sieve[/I]. I like to see what it has done and what it is doing at the same time. I started using computers in 1988 when there were few options about screen content. I became used to it.

I started out using [I]PFGW[/I] for Riesel searches. It was rapidly pointed out that I needed to be using [I]LLR[/I]. Probabilistic versus deterministic. I rarely use [I]PFGW[/I] now.

I solved my own problem with [I]srsieve2[/I] by not using [I]PowerShell[/I]. Writing to an output file every 60 minutes is good.

You refer to [I]mfsieve[/I] as a group of programs. Where can I find them?[/QUOTE]
Printing Carriage Return instead of the Newline symbol does that to a line.
Also I wouldn't say "Probabilistic vs Deterministic" is the reason we use the LLR test vs the Fermat test. The LLR test is more optimized for that problem - it needs fewer multiplications to reach a result. For a 100k digit number the Fermat test has 1.3*10[SUP]-10584[/SUP] chance of a false positive - it only gets more unrealistic from there [[URL]https://primes.utm.edu/notes/prp_prob.html][/URL].

I cannot speak for llr as I do not maintain it.

pfgw is best suited for whatever llr cannot do. It is also best suited to do primality testing on forms that other programs can only do a PRP test on, such as genefer/geneferocl.

The mtsieve framework is [URL="https://sourceforge.net/projects/mtsieve/"]here[/URL]. There are a nearly 20 sieving programs based upon it including srsieve2 (not to be confused with sr2sieve), which you can d/l from the aforementioned link.

[QUOTE=rogue;543427]I cannot speak for llr as I do not maintain it.

pfgw is best suited for whatever llr cannot do. It is also best suited to do primality testing on forms that other programs can only do a PRP test on, such as genefer/geneferocl.

The mtsieve framework is [URL="https://sourceforge.net/projects/mtsieve/"]here[/URL]. There are a nearly 20 sieving programs based upon it including srsieve2 (not to be confused with sr2sieve), which you can d/l from the aforementioned link.[/QUOTE]

Sophie Germain is one that [I]PFGW [/I]does quite well. There are other forms in it's documentation, which I cannot remember.

I found the [I]mfsieve[/I] collection late yesterday evening. I was amazed as to how many different programs are in the archive. Without any general description, it is difficult to determine what each does.

[QUOTE=storm5510;543361]"The[I] mfsieve[/I] framework." [/QUOTE]

[QUOTE=storm5510;543402]You refer to [I]mfsieve[/I] as a group of programs. [/QUOTE]

[QUOTE=storm5510;543437]I found the [I]mfsieve[/I] collection late yesterday evening.[/QUOTE]

mtsieve, not mfsieve.

[QUOTE=storm5510;543437]Sophie Germain is one that [I]PFGW [/I]does quite well. There are other forms in it's documentation, which I cannot remember.

I found the [I]mtsieve[/I] collection late yesterday evening. I was amazed as to how many different programs are in the archive. Without any general description, it is difficult to determine what each does.[/QUOTE]

Look at the [URL="https://mersenneforum.org/showthread.php?t=23042"]mtsieve thread[/URL]. Most of the individual programs are detailed [URL="https://mersenneforum.org/rogue/mtsieve.html"]here[/URL] although I know it isn't up to date.

I actually think that writing a sieve for Sophie-Germain primes would be fairly easy as it could use a lot of the same logic in twinsieve. What program do people use for sieving Sophie-Germain primes? I could easily see if building such a sieve in the mtsieve framework has value.

I used a fixed-n sieve in NewPGen. I haven't looked for SG primes in quite a few years, though.

[QUOTE=VBCurtis;543476]I used a fixed-n sieve in NewPGen. I haven't looked for SG primes in quite a few years, though.[/QUOTE]

fbncsieve (in the mtsieve framework) should be much faster than the fixed-n sieve of NewPGen.

[QUOTE=axn;543445]mtsieve, not mfsieve.[/QUOTE]

I stand corrected. I was unable to see the difference.

[QUOTE=rogue]Look at the [URL="https://mersenneforum.org/showthread.php?t=23042"]mtsieve thread[/URL]. Most of the individual programs are detailed [URL="https://mersenneforum.org/rogue/mtsieve.html"]here[/URL] although I know it isn't up to date.[/QUOTE]

An interesting document. Thank you.

[QUOTE=Citrix;543189]Srsieve2.exe is extremely slow for low weight numbers. I am trying to modify sr1sieve.exe for these. Looking at the source I only need to modify LIMIT_BASE (-Q flag).

[url]https://www.mersenneforum.org/showpost.php?p=529034&postcount=256[/url]
[url]https://www.mersenneforum.org/showthread.php?p=529034#post256[/url]

If Srsieve2.exe could have this then I do not use sr1sieve.exe[/QUOTE]

I was sieving a range of 10M for my extreme low weight k.
Using a Q value ~ 2500 this can be reduced to a range of around 4096.
I get a speed up of 2.5 times. Much lower than expected.

Looking through the source code of all 3 programs. Some suggestions:-
1. There is too much overhead in all 3 programs. Most of the specializations theoretically should make the program faster but I think they are making it slower. Simplifying the code might make it faster.

2. In Mtsieve there is a function GenericSubsequenceHelper::FindBestQ()
A better Q can be found using gcd. There are simpler ways of finding best Q. The best theoretical Q might not always be the fastest.

3. For the babystep and giantstep code, using a hashmap/bitmap instead of a hashtable can make the program much faster with no significant extra memory use.

4. The program (srsieve2) can be ported to a GPU in most cases (as long as the range is not too large or the weight is extremely low). For low weight sequences a GPU version will be very helpful as they cannot be sieved very far on the CPU.

Let me know if you are interested in implementing any of the above and need help.

Thanks.

[QUOTE=Citrix;543525]I was sieving a range of 10M for my extreme low weight k.
Using a Q value ~ 2500 this can be reduced to a range of around 4096.
I get a speed up of 2.5 times. Much lower than expected.

Looking through the source code of all 3 programs. Some suggestions:-
1. There is too much overhead in all 3 programs. Most of the specializations theoretically should make the program faster but I think they are making it slower. Simplifying the code might make it faster.

2. In Mtsieve there is a function GenericSubsequenceHelper::FindBestQ()
A better Q can be found using gcd. There are simpler ways of finding best Q. The best theoretical Q might not always be the fastest.

3. For the babystep and giantstep code, using a hashmap/bitmap instead of a hashtable can make the program much faster with no significant extra memory use.

4. The program (srsieve2) can be ported to a GPU in most cases (as long as the range is not too large or the weight is extremely low). For low weight sequences a GPU version will be very helpful as they cannot be sieved very far on the CPU.

Let me know if you are interested in implementing any of the above and need help.[/QUOTE]

I appreciate your feedback.

As for #1, I'm not certain if you are referring to srsieve2 or srsieve/sr1sieve/sr2sieve. If srsieve2, I'm open to suggestions. Note that I aim for easy of development/support over speed. Sacrificing up to 1 percent to achieve that is acceptable because I can typically make up for it in other areas. Also for srsieve2, it is still a work in progress. You have probably noticed that it is designed to switch the helper/worker if certain conditions are met as each helper/worker will have very different logic meant to optimize in certain ways.

As for #3, I did try to implement a hashmap, but the performance was worse. I didn't dig into determining why as the implementation I had was supposed to be one of the fastest.

As for #4, it is on my radar, but I haven't don anything yet. My focus has been on implementing the Legendre tables that sr1sieve and sr2sieve have, but bsgs code using those tables a hornet's nest.

I'm open to any suggestions. If you want to play around with the code and try your hand at some optimizations, I'm all for it.

To continue this, we can either move this discussion to the mtsieve thread, to a new thread, or take offline via PM or e-mail. If we keep it online then other participants of this forum can add their knowledge to the discussion or can learn from it.

[QUOTE=rogue;543533]If we keep it online then other participants of this forum can add their knowledge to the discussion or can learn from it.[/QUOTE]

And enjoy reading it :smile:

I created [URL="https://www.mersenneforum.org/showthread.php?p=543549#post543549"]this thread[/URL] for mtsieve improvemets.

I am running a fairly deep sieve, 4e12, on a [I]k[/I] that I want to pick back up and continue on with using [I]sr1sieve[/I]. The CPU utilization floats from 15% to 20% on an i7 CPU with 4 cores and 4 threads running at 4.15 GHz. I understand these are meant to be ran as background processes. [I]Prime95[/I] will run at 50% utilization, with no other processes running, at Priority 1. My sieve will take about four days to complete, if I do not have to stop it. It would cut a lot of time if the sieving utilization could be brought up to 35%, for example.

:two cents:

[QUOTE=storm5510;543557]I am running a fairly deep sieve, 4e12, on a [I]k[/I] that I want to pick back up and continue on with using [I]sr1sieve[/I]. The CPU utilization floats from 15% to 20% on an i7 CPU with 4 cores and 4 threads running at 4.15 GHz. I understand these are meant to be ran as background processes. [I]Prime95[/I] will run at 50% utilization, with no other processes running, at Priority 1. My sieve will take about four days to complete, if I do not have to stop it. It would cut a lot of time if the sieving utilization could be brought up to 35%, for example.[/QUOTE]

I can't say why it does that without doing some profiling. What inputs are you using?

[QUOTE=rogue;543558]I can't say why it does that without doing some profiling. What inputs are you using?[/QUOTE]

[U]Edit[/U]: The series is 98475*2^n-1.

[CODE]sr1sieve -P 4e12 -n 770e3 -N 1e6 -Z -s 3 -v -i sr1.npg -o work.abcd[/CODE]The above is for an example for first start. I have something shorter, below, for a restart of an existing sieve. All I have to do is use [I]srfile[/I] to convert the "abcd" file back to "npg" and rename it. The input file above comes from a short [I]srsieve[/I] run.

[CODE]sr1sieve -P 4e12 -Z -v -s 3 -i sr1.npg -o% work.abcd[/CODE]I do not run any of this by hand. I have two batch files I use where I put the parameters on the command line, in a specific order, and they are placed where the matching variables are in the batch. %1, %2, and so on.

[QUOTE=storm5510;543557]I am running a fairly deep sieve, 4e12, on a [I]k[/I] that I want to pick back up and continue on with using [I]sr1sieve[/I]. The CPU utilization floats from 15% to 20% on an i7 CPU with 4 cores and 4 threads running at 4.15 GHz. I understand these are meant to be ran as background processes. [I]Prime95[/I] will run at 50% utilization, with no other processes running, at Priority 1. My sieve will take about four days to complete, if I do not have to stop it. It would cut a lot of time if the sieving utilization could be brought up to 35%, for example.

:two cents:[/QUOTE]

You can split the prime range and run 2-3 sieve processes at the same time. Then use srfile to clean the main file.

On a 4 core i7 - I often run 8 processes in parallel to get maximum efficiency.

[QUOTE=Citrix;543601]You can split the prime range and run 2-3 sieve processes at the same time. Then use srfile to clean the main file.

On a 4 core i7 - I often run 8 processes in parallel to get maximum efficiency.[/QUOTE]

I have ran split sieve's before, but not on the same machine. I have ran multiple instances of [I]LLR[/I] on said CPU. It is sluggish. I do not think [I]Windows 10[/I] cooperates very well. A single instance can do more than two.

[QUOTE=Citrix;543525]I was sieving a range of 10M for my extreme low weight k.
Using a Q value ~ 2500 this can be reduced to a range of around 4096.
I get a speed up of 2.5 times. Much lower than expected.
[/QUOTE]

Do you have any benchmarks and a sieve file for this that I can test on my CUDA code? I've been wanting for some time to try to integrate my CUDA port of sr2sieve into mtsieve, but time has been my enemy. Maybe this year....

[QUOTE=rob147147;543665]Do you have any benchmarks and a sieve file for this that I can test on my CUDA code? I've been wanting for some time to try to integrate my CUDA port of sr2sieve into mtsieve, but time has been my enemy. Maybe this year....[/QUOTE]

You could create a similar sieve file yourself with searching a heavy weight k (say 15) from n=10M to N=10M+4096 for base 2.

Alternatively you could search
k=15
n=10M
N=20M
Use base as b=2^2048 i.e only choose n that are multiple of 2048.

On my AMD Radeon 5 (4 cores) I get between 8-10M p /sec per thread.
I can run 8 of these at a time for maximum efficiency.
So around 70-80M p/sec.

on an i7 4th generation (4 cores) I can clear around 300-320M p/sec.

I am using sr1sieve. I haven't tried srsieve2.exe.

I think the program is limited by the overhead and not the actual algorithm.

[QUOTE=Citrix;543829]...I think the program is limited by the overhead and not the actual algorithm.[/QUOTE]

In the [I]mtsieve[/I] document, there are references to "MyApp" towards the bottom. I believe this is [I]Microsoft .Net Framework[/I]. I experimented with the 2008 and 2010 versions. I found the applications to be rather sluggish. I stopped using each. It seemed Microsoft was moving away from programs which could do hard number-crunching into more database oriented applications where speed was not on the list of priorities. There are exceptions though. [I]Microsoft C++[/I] for example.

[QUOTE=storm5510;543836]In the [I]mtsieve[/I] document, there are references to "MyApp" towards the bottom. I believe this is [I]Microsoft .Net Framework[/I]. I experimented with the 2008 and 2010 versions. I found the applications to be rather sluggish. I stopped using each. It seemed Microsoft was moving away from programs which could do hard number-crunching into more database oriented applications where speed was not on the list of priorities. There are exceptions though. [I]Microsoft C++[/I] for example.[/QUOTE]

In that documentation, MyApp is just a placeholder for an actual App subclass name (such as SierpinskiRieselApp for srsieve2). It has nothing to do with .NET, and mtsieve doesn't use .NET. On Windows, it just uses the regular C++ Windows API interface.

.NET [i]is[/i] almost invariably slower than plain C or C++, for much the same reason that Java programs are slower (namely the virtual environment construct). IMHO no serious program in this field (high-performance mathematical computation) should ever use .NET or Java.

[QUOTE=Happy5214;543840]In that documentation, MyApp is just a placeholder for an actual App subclass name (such as SierpinskiRieselApp for srsieve2). It has nothing to do with .NET, and mtsieve doesn't use .NET. On Windows, it just uses the regular C++ Windows API interface.

.NET [I]is[/I] almost invariably slower than plain C or C++, for much the same reason that Java programs are slower (namely the virtual environment construct). [B]IMHO no serious program in this field (high-performance mathematical computation) should ever use .NET or Java.[/B][/QUOTE]

I agree completely. Some of the 32-bit antique languages from the 1990's would even be faster. Once upon a time, I used Visual Basic 6 as that was what I was taught in trade school. I could take virtually the same code and duplicate it in .Net 2008, with the required syntax variations. I would compile the .Net application as a 64-bit executable. The original 32-bit VB6 program would run circles around it .Net has too much baggage and too many dependencies.

[CODE]
static double expected_factors(uint32_t n, uint64_t p0, uint64_t p1)
{
/* TODO: Use a more accurate formula. This one is only reasonable when
p0/p1 is close to 1.
*/

return n*(1-log(p0)/log(p1));
}
[/code]

Looking at above code from sr1sieve. Can somebody point me to math behind this code. Thanks.

[QUOTE=Citrix;546059]Looking at above code from sr1sieve. Can somebody point me to math behind this code. Thanks.[/QUOTE]
It is a consequence of Merten's theorem ([url]https://en.wikipedia.org/wiki/Mertens%27_theorems[/url] - see third theorem)

I have had srsieve running on my laptop for the past few weeks.

I have 4 instances of it open in 4 seperate Windows PowerShells. All writing to seperate .out files every 10 minutes.

I also have a python script running which reads all 4 .out files every 10 minutes, counts how many entries are present in ALL 4 lists and records how many terms there are remaining.

The python script also outputs the average time taken, in minutes, for each term eliminated over the past 5 hours.

So here's the odd thing...

Every night I lock my computer and go to bed, leaving srsieve running. I wake up, unlock the computer and check the python shell output.

This morning shows that the srsieve had been eliminating 1 term every 27 minutes on average over the past 5 hours. Within 2.5 hours of actively using the laptop for work, this average has dropped to 18 minutes.

This is a recurring pattern... I wake up in the morning and srsieve has slowed down considerably overnight. Srsieve picks up again when I unlock the computer and start using it for other things. It has followed the same pattern every morning since I first noticed it a week ago.

This is possibly *not* an srsieve specific query - it might be more likely to do with how Windows runs while locked.

But does anyone know what's going on here?

[QUOTE=lukerichards;546082]But does anyone know what's going on here?[/QUOTE]

What are your Power options? Does Windows or your hard drive "go to sleep" if you are not actively using?

[QUOTE=rogue;546089]What are your Power options? Does Windows or your hard drive "go to sleep" if you are not actively using?[/QUOTE]

Nope... power settings attached in screenshot form. Nothing sleeps ever, not even while I'm sleeping.

When locked is a screen saver running? Can you take a look to see if something else is running that is stealing CPU cycles, e.g. malware?

Is the CPU clock lowering when locked?

[QUOTE=rogue;546103]When locked is a screen saver running? Can you take a look to see if something else is running that is stealing CPU cycles, e.g. malware?[/QUOTE]

It's a work computer (which our Ts and Cs do allow us to use for personal projects if they don't put any strain on the network infrastructure at work) so there are lots of things running which I wouldn't normally have running on my own computer.

Scanning down the active processes list, I notice a few things that might potentially update/sync/run at night/downtime or something similar not least various incarnations nof Sophos virus scanning/security services.

Tonight I'll have a look at disabling anything non-critical and see how it fares by the morning.

[QUOTE=henryzz;546105]Is the CPU clock lowering when locked?[/QUOTE]

How would I check?

[QUOTE=lukerichards;546108]How would I check?[/QUOTE]

You could run [URL="http://www.hwinfo.com"]HWInfo[/URL]. This program is able to log the current frequency of your processor over night. It can also log a ton of more things, maybe this is helpful in your case.

[QUOTE=rogue;546103]When locked is a screen saver running? [/QUOTE]

[B]George Woltman[/B], a.k.a. "Prime95", wrote something about screen savers. He indicated to never use one which would require mathematical calculations when running. The majority of them do. He recommends just a blank screen. Windows has had this for many years. I know Ubuntu Linux has it as well.

:smile:

The only change from 1.1.4 is to replace the error for "all terms divisible by 2" with a warning.

[QUOTE=storm5510;546487][B]George Woltman[/B], a.k.a. "Prime95", wrote something about screen savers. He indicated to never use one which would require mathematical calculations when running. The majority of them do. He recommends just a blank screen[/QUOTE]I know this is an older post, but a screen saver isn't required anymore. In the past it really did save the screen because on the old CRTs the constant bombardment by electrons could alter the screen if it showed the same image for hours. Though I never really got it how apparently the Word icons or start menu icon didn't matter...


With LCDs this doesn't happen anymore, since the LED backlight is on all the time. No matter if blank screen or not. It's different for OLEDs, since in that case the individual pixel is really switched on and off and to prevent uneven aging a blank screen could help.


But the easiest solution is not to use a screen saver, but just switch off the display after 10 minutes or so via energy saver settings. Doesn't use any CPU power and saves electrical power and you display won't age.

[QUOTE=bur;556355]I know this is an older post, but a screen saver isn't required anymore. In the past it really did save the screen because on the old CRTs the constant bombardment by electrons could alter the screen if it showed the same image for hours. Though I never really got it how apparently the Word icons or start menu icon didn't matter...

With LCDs this doesn't happen anymore, since the LED backlight is on all the time. No matter if blank screen or not. It's different for OLEDs, since in that case the individual pixel is really switched on and off and to prevent uneven aging a blank screen could help.

But the easiest solution is not to use a screen saver, but just switch off the display after 10 minutes or so via energy saver settings. Doesn't use any CPU power and saves electrical power and you display won't age.[/QUOTE]

I gradually stopped using screen savers when I began using LCD's. I have one here I came across which was made in 2003. It has one reversed pixel. Otherwise, it function fine. Another I bought new in 2008. It still works good. I have a recent new one which is 1920 x 1080. I was amazed at the clarity. If I leave, or am sleeping, I turn them off manually.

:smile:

It's likely that I'm very dense (as is standard), but I'm having whack-o issues attempting to run srsieve2 on sequences like 3^n+2 or 3^n-2. This might be along the lines of trying to use a screwdriver to open a can of tomatoes, but I was assuming that having k=1 would be sufficient to get things working and would be fine to use as a tool - even trying to sidestep things with some k = b^(small power) to avoid issues if necessary.

I was greeted with "Sequence 27*3^n+2 has 1000000 terms removed has they have the factor 5" in the +2 case, which definitely seems weird, as numbers like 3^14+2 are prime and are thusly [I]not[/I] divisible by 5, and as for -2 it comes down to "Fatal Error: Expected 18446744073709324636 terms when building sequences, but counted only 235736.", which, at the very least, strikes fear into my heart.

[QUOTE=Gelly;557189]It's likely that I'm very dense (as is standard), but I'm having whack-o issues attempting to run srsieve2 on sequences like 3^n+2 or 3^n-2. This might be along the lines of trying to use a screwdriver to open a can of tomatoes, but I was assuming that having k=1 would be sufficient to get things working and would be fine to use as a tool - even trying to sidestep things with some k = b^(small power) to avoid issues if necessary.

I was greeted with "Sequence 27*3^n+2 has 1000000 terms removed has they have the factor 5" in the +2 case, which definitely seems weird, as numbers like 3^14+2 are prime and are thusly [I]not[/I] divisible by 5, and as for -2 it comes down to "Fatal Error: Expected 18446744073709324636 terms when building sequences, but counted only 235736.", which, at the very least, strikes fear into my heart.[/QUOTE]

What did you use on the command lnie?

[QUOTE=rogue;557212]What did you use on the command lnie?[/QUOTE]

For 3^n+2, I did srsieve2 -n 1 -N 1000000 -s"27*3^n+2".
For 3^n-2, I did the same but with "27*3^n-2".

Similar results occur for -s"1*3^n+2" and fails to parse -s"3^n+2", as expected.

Edit: I suppose I should mention that the issue with the "removing 1000000 factors" bit isn't that it removes factors, but it removes the entire range, full stop.

[QUOTE=Gelly;557224]For 3^n+2, I did srsieve2 -n 1 -N 1000000 -s"27*3^n+2".
For 3^n-2, I did the same but with "27*3^n-2".

Similar results occur for -s"1*3^n+2" and fails to parse -s"3^n+2", as expected.

Edit: I suppose I should mention that the issue with the "removing 1000000 factors" bit isn't that it removes factors, but it removes the entire range, full stop.[/QUOTE]

The problem is a piece of algebraic factor code that is outputting the message should only be used if c = +1 or -1. I'll fix as soon as I can.

Windows? Did you double the hat?

Attached is sr1sieve 1.4.7. The major change is for non-x86 users. It will now work for p up tp 2^64 whereas it was limited to 2^52 previously. Based upon a few tests it is actually only about 5% slower than when running with the 64-bit ASM routines. There is a minor change in an attempt to get more accurate timestamp details so that the best baby steps method is chosen a runtime. This costs a second or two upon start up. If you use -vv you will see which baby steps method it chooses.

To compile for ARM or other non-x86 CPUs, use ASSEMBLER=no in the makefile and use # to comment all architectures in the makefile as well.

I compiled it on ARM 64 and make check reports an error

[CODE]
./srtest 1000000 0
Testing calculation of a^n (mod p) for random a,n < p < 2^62, seed=1610277202.
*** 5^0 (mod 13): expected 1, got 3.
*** 2746100997775259206^3224756103013107157 (mod 3821170955791617625):
expected 2787118976035927961, got 2537629473793175596.
Stopping after 2 errors.
make: *** [Makefile:329: check] Error 1
pi@raspberrypi2:~/sr1sieve/sr1sieve_1.4.7$
[/CODE]

[QUOTE=yoyo;568972]I compiled it on ARM 64 and make check reports an error

[CODE]
./srtest 1000000 0
Testing calculation of a^n (mod p) for random a,n < p < 2^62, seed=1610277202.
*** 5^0 (mod 13): expected 1, got 3.
*** 2746100997775259206^3224756103013107157 (mod 3821170955791617625):
expected 2787118976035927961, got 2537629473793175596.
Stopping after 2 errors.
make: *** [Makefile:329: check] Error 1
pi@raspberrypi2:~/sr1sieve/sr1sieve_1.4.7$
[/CODE][/QUOTE]

Use the attached srtest. You can see those when you look at the code. Extra steps are needed to use use the new generic mulmod correctly.

If I run sr1sieve version 1.4.5
sr1sieve_1.4.5-x86_64-linux -P 15257050000000000 -i in -o out -f factor1.txt)

I get an out file with this format:
[CODE]
15257500000000000:M:1:10:258
92 1400033
92 1400035
92 1400045
92 1400068
92 1400075
...
[/CODE]

If I run version 1.4.7
sr1sieve_1.4.7_aarch64 -P 15257050000000000 -i in -o out -f factor1.txt
I get an out file with this format:
[CODE]
ABCD 92*10^$a-1 [1400033] // Sieved to 15257500000000000
2
10
23
...
[/CODE]

How to get in 1.4.7 the same output format as in 1.4.5?
Background is that I run a task on different hosts and compare the results afterwards to ensure valid results.

You may have some options (was it -w or -G? I don't recall) to convert file formats, or you also can call srfile after the run, to convert to pfgw format, or newpgen format, or any format.

edit: I only have 1.4.5 here, you can call "srfile -g second_file" to get the "first_file" (i.e. convert from abc format to newpgen format). For details, see "srfile -h" and "sr1sieve -h".

Does sr1sieve support Riesel and Proth numbers in the same sieve? I combined two seperate sieves using srfile and sr1sieve threw the error [CODE]Cannot support multiple sequences in input file `sr_2.abcd'.[/CODE] I guess that means, no?


I wanted to use it since it was the fastest among sr1sieve, sr2sieve and srsieve2 for my fixed k.


Does it even make sense efficiency-wise to combine sieve files like that or would it be the same if I ran them seperately?

sr1sieve doesn't support multiple sequences period. It's optimized for a single sequence (i.e. [I]k[/I]). The traditional rule of thumb is to use sr2sieve for 3 or more [I]k[/I]'s, sr1sieve for 1 or 2 (two separate instances in the latter case), and srsieve/srsieve2 just to start (I go to 1e9 because my workflow is highly automated by e9, but that's probably not optimal), but I think srsieve2cl (GPU, not srsieve2 for CPU) is faster than even sr1sieve for a single [I]k[/I].

[QUOTE=bur;573361]Does sr1sieve support Riesel and Proth numbers in the same sieve? I combined two seperate sieves using srfile and sr1sieve threw the error [CODE]Cannot support multiple sequences in input file `sr_2.abcd'.[/CODE] I guess that means, no?


I wanted to use it since it was the fastest among sr1sieve, sr2sieve and srsieve2 for my fixed k.


Does it even make sense efficiency-wise to combine sieve files like that or would it be the same if I ran them seperately?[/QUOTE]

sr1sieve cannot be modified to sieve both +1 and -1 for the same k/b concurrently. The sign is important WRT how the Legendre tables are built and used.