[QUOTE=sichase;157715]The simple, permanent solution to this problem is to add "./" to your path.[/QUOTE]

A better solution is probably just to put the sr2sieve executable into /usr/local/bin.

[QUOTE=henryzz;157599]a lot of core 2s have two parts of their L1 cache
[COLOR=black]Level 1 cache size
4 x 32 KB instruction caches
4 x 32 KB data caches[/COLOR][/QUOTE]
It is the L1 data cache size that is important to the choice of hashtable size.

[QUOTE]also sr1sieve(probably sr2sieve as well but i havent used it) detects my L2 cache size as 4MB even though that 4MB is divided between two cores[/QUOTE]

For typical sieve files, sr2sieve cycles between short intervals of high L2 cache usage and much longer intervals of lower L2 cache usage. It is possible for a number of processes to efficiently share the L2 cache in this way, so I think the total shared L2 cache size is the right measure in most cases.

For best performance upgrade to sr2sieve version 1.8.8: Versions 1.8.6 - 1.8.7 in particular will be slow with the latest sieve file unless the switch -Q720 is added to the command line.

With the sieve file reduced to 3 sequences, here are the times to complete a 1T range with sr2sieve version 1.8.8 on my machines:

2.66GHz Core 2 Duo:
(64 bit, 1 core): 2 days 8 hr
(32 bit, 1 core): 4 days 6 hr

2.9GHz Pentium 4 HT:
(32 bit, 1 thread): 8 days 7 hr
(32 bit, 2 threads): 6 days 2 hr

geoff,

Thanks for the update. I replaced the sr2sieve to 1.8.8 ver from 1.8.3 and saw an immediate 1mil p/sec increase on my q6600 running x64 ubuntu. Can't beat that with a stick.:bow wave:

From another thread:

[QUOTE=paleseptember]Do we have estimates, or ways to find estimates, on the expected improvement for sieving now that this sequence has been removed?[/QUOTE]

sr2sieve 1.8.8, p=85e12, C2D 2.66GHz (64-bit):

5 sequences (87 subsequences mod 720), 3.82M p/sec
4 sequences (69 subsequences mod 720), 4.41M p/sec (15.4% faster, expected sqrt(87/69)= 12.3%)
3 sequences (57 subsequences mod 720), 5.01M p/sec (13.6% faster, expected sqrt(69/57)= 10.0%)

The expected gain is just for the discrete logarithm part of the algorithm, which usually accounts for the vast majority of the time taken.

But now that the number of sequences is getting very small some other factors start to play a bigger part. One is that the chance of all the terms in the sieve simultaneously being quadratic non-residues is 1 in 2^x where x is the number of sequences*. When this happens, 12.5% of the time now, the algorithm short-circuits before the discrete logarithm code is even started. I think this is that main reason that it can sometimes be faster to sieve the sequences separately when there are only 2 left.

(*) sequences which have both odd and even terms count as two, but there are none of those in this project.

How do you compile the sr2sieve code for 64bit Windows, is that using MinGW as? I wasn`t aware they figured out a way to get gcc to compile 64bit Windows code yet, do you have any link to instructions on how to do that?

Thanks,
Jeff.

[QUOTE=Jeff Gilchrist;162368]How do you compile the sr2sieve code for 64bit Windows, is that using MinGW as? I wasn`t aware they figured out a way to get gcc to compile 64bit Windows code yet, do you have any link to instructions on how to do that?[/QUOTE]

I use the mingw-w64 compiler from [url]http://www.sourceforge.net/projects/mingw-w64/[/url], it has been working OK for over a year now. In general you use it just like any other version of gcc, but some unix-specific library functions are missing (like fork(), pipe(), etc.), and it doesn't understand C99 printf formats like printf("%lld",1LL), you need to use the macros in <inttypes.h>, e.g. printf("%"PRId64,INT64_C(1));

I cross compile sr2sieve from Linux using this command, but it should work the same in Windows provided you have GNU make installed:

make ARCH=x86-64-gcc430 CC=x86_64-pc-mingw32-gcc

Remember to change the definition of BASE to zero in sr5sieve.h, and rename the resulting sr5sieve executable to sr2sieve.

The version of the mingw-w64 compiler I use has some bugs (which I think all early gcc 4.3.0 versions had), and the ARCH=x86-64-gcc430 option works around them by reducing the optimisation level to -O1. If you have a later version the bugs might be fixed and you could instead use ARCH=x86-64.

[QUOTE=geoff;162420]I use the mingw-w64 compiler from [url]http://www.sourceforge.net/projects/mingw-w64/[/url], it has been working OK for over a year now. In general you use it just like any other version of gcc, but some unix-specific library functions are missing (like fork(), pipe(), etc.), and it doesn't understand C99 printf formats like printf("%lld",1LL), you need to use the macros in <inttypes.h>, e.g. printf("%"PRId64,INT64_C(1));
[/QUOTE]

Thanks for the info, that is very useful. I can understand it still missing some things like fork, but it can't even understand printf properly? Wow, that is probably one of the most commonly used C statement isn't it?

Hopefully cygwin will also get to 64bit support some day as well.

[QUOTE=Jeff Gilchrist;162444]Thanks for the info, that is very useful. I can understand it still missing some things like fork, but it can't even understand printf properly? Wow, that is probably one of the most commonly used C statement isn't it?[/QUOTE]

MinGW uses the printf/scanf etc. functions from the Windows system libraries (MSVCRT.DLL I think), so blame Bill for that one.

Can you believe this?

100691806065289 | 2^2969687+41693

and also:

111228322245563 | 2^2969687+41693

The first was reported by Geoff on the 12th, and I eliminated it from the work file. Then I received the second from Kent (Kman1293) on the 15th, the only factor of a number in the range 2.93 million to 3.20 million, out of the 2500 or so entries in the currently unclaimed workfiles. Struck me as rather improbable, but then again, primes can be a bit spooky.

With the sieving having received a significant boost recently (thanks Lennart! Continuing thanks to Kman, Zuzu and geoff for his excellent program too!) and with the removal of the 3rd sequence, are there some benchmark numbers on the speed increase seen?

There are ... 315557 candidates left in the sieve file (thank you line count in WinEdt!)