I'll admit that I have a really old machine (~10 years), so it has 4 MB of L2 and no L3. Caching could definitely be a factor.

As noted, using 2 or more threads on srsieve2 yields better results than srsieve, and that would be the intended use in my circumstance anyway (probably 3 threads on my non-exclusive quad-core). But srsieve2 is not even in the same country as sr1sieve (with Legendre), which is hovering around 50M p/sec at later p's. Hopefully, the upcoming improvements will close, or even reverse, the gap.

On a side note, is there any particular reason why this code isn't in some sort of public VCS?

I have a sourceforge repository, but haven't put the code into it. I'll do that soon.

srsieve2 does not have the functionality of sr1sieve or sr2sieve yet. I started implementing the logic from sr2sieve, but have been too busy.

Is Happy5412's machine able to use the latest instructions srsieve2 is able to use(AVX?)? Could that be slowing it down?

[QUOTE=henryzz;525030]Is Happy5412's machine able to use the latest instructions srsieve2 is able to use(AVX?)? Could that be slowing it down?[/QUOTE]

There are no AVX instructions in srsieve2. I tried experimenting with AVX2 and got worse performance. This is due to a single loop which has a variable number of steps per prime.

I have finally put mtsieve into [URL="https://sourceforge.net/projects/mtsieve/"]sourceforge[/URL]. Going forward, releases will be placed in sourceforge. I'll eventually update my webpage to point to sourceforge.

If anyone wants to contribute, please let me know and I can give you access to commit code changes.

Thanks!

As an aside, why does everyone in this community love SVN so much? Every other coding community I'm part of uses Git or something similarly distributed. SVN just reminds me of a decade ago.

[QUOTE=Happy5214;525319]Thanks!

As an aside, why does everyone in this community love SVN so much? Every other coding community I'm part of uses Git or something similarly distributed. SVN just reminds me of a decade ago.[/QUOTE]

Having used both, svn is easier to use. git is better for projects with many contributors.

Last version of mtsieve , error can be eliminated if -K is [B]odd [/B]number


[QUOTE]e:\MTSIEVE\mtsieve1957>twinsieve -P2000000000 -w10000000 -W4 -k10001 -K1000000 -b2 -n5333333 -o BASE2.txt -fA -r -s
twinsieve v1.2, a program to find factors of k*b^n+1/-1 numbers for fixed b and n and variable k
Sieve started: 1 < p < 2e9 with 990000 terms (10001 < k < 1000000, k*2^5333333) (expecting 957958 factors)
Sieve completed at p=2000000011.
Processor time: 10.06 sec. (0.80 sieving) (2.41 cores)
[COLOR=Red][B]Fatal Error: Something is wrong. Counted terms (51638) != expected terms (51639)[/B][/COLOR][/QUOTE]

[QUOTE=pepi37;525668]Last version of mtsieve , error can be eliminated if -K is [B]odd [/B]number[/QUOTE]

I'll take a look. Thanks.

Last version of mtsieve , [B]gcwsieve[/B]

[QUOTE]gcwsieve -P 10000000 -w10000000 -W4 -O factors1.txt -b 196 -n 2 -N 800000 -s - [/QUOTE]

So first problem - when I start this I cannot get more then 26% on quad core CPu so it use only little more then one core.


[QUOTE]Processor time: 193.08 sec. (0.08 sieving) (0.98 cores)[/QUOTE]Second: if you tray to stop it it will write message



[QUOTE]CTRL-C accepted. Please wait for threads to complete.[/QUOTE]but will not stop the program, program continues to run. If you second time type CTRL+c then programs end but [B]there is no output file.[/B]


If you continue sieving with same parameters then GCWSIEVE will start to use 100% CPU

[QUOTE=pepi37;526086]Last version of mtsieve , [B]gcwsieve[/B]



So first problem - when I start this I cannot get more then 26% on quad core CPu so it use only little more then one core.


Second: if you tray to stop it it will write message



but will not stop the program, program continues to run. If you second time type CTRL+c then programs end but [B]there is no output file.[/B]


If you continue sieving with same parameters then GCWSIEVE will start to use 100% CPU[/QUOTE]

This is likely because -w is so large. The problem is that gcwsieve will use a single thread until the first 10000000 primes are tested, which can take a while. I should be able to change it to break out of that first chunk earlier so that it can start using multiple threads more quickly.

The other issue is that gcwsieve is a relatively slow sieve compared to srsieve2 and cksieve. It needs to finish the chunk of 10000000 primes before it terminates (when using ^C). I highly recommend setting -w to a lower value.