Register FAQ Search Today's Posts Mark Forums Read

2009-01-11, 02:48   #34
geoff

Mar 2003
New Zealand

13×89 Posts

Quote:
 Originally Posted by sichase The simple, permanent solution to this problem is to add "./" to your path.
A better solution is probably just to put the sr2sieve executable into /usr/local/bin.

2009-01-11, 02:52   #35
geoff

Mar 2003
New Zealand

13·89 Posts

Quote:
 Originally Posted by henryzz a lot of core 2s have two parts of their L1 cache Level 1 cache size 4 x 32 KB instruction caches 4 x 32 KB data caches
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
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.

 2009-01-30, 21:29 #36 geoff     Mar 2003 New Zealand 13·89 Posts 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
 2009-01-31, 04:01 #37 engracio     May 2007 112 Posts 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.
2009-02-02, 04:57   #38
geoff

Mar 2003
New Zealand

115710 Posts

Quote:
 Originally Posted by paleseptember Do we have estimates, or ways to find estimates, on the expected improvement for sieving now that this sequence has been removed?
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.

 2009-02-10, 16:42 #39 Jeff Gilchrist     Jun 2003 Ottawa, Canada 100100101002 Posts How do you compile the sr2sieve code for 64bit Windows, is that using MinGW as? I wasnt 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.
2009-02-11, 03:33   #40
geoff

Mar 2003
New Zealand

13·89 Posts

Quote:
 Originally Posted by Jeff Gilchrist How do you compile the sr2sieve code for 64bit Windows, is that using MinGW as? I wasnt 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?
I use the mingw-w64 compiler from http://www.sourceforge.net/projects/mingw-w64/, 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.

2009-02-11, 10:31   #41
Jeff Gilchrist

Jun 2003

22·293 Posts

Quote:
 Originally Posted by geoff I use the mingw-w64 compiler from http://www.sourceforge.net/projects/mingw-w64/, 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 , e.g. printf("%"PRId64,INT64_C(1));
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.

2009-02-12, 02:10   #42
geoff

Mar 2003
New Zealand

13·89 Posts

Quote:
 Originally Posted by Jeff Gilchrist 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?
MinGW uses the printf/scanf etc. functions from the Windows system libraries (MSVCRT.DLL I think), so blame Bill for that one.

 2009-02-18, 00:30 #43 philmoore     "Phil" Sep 2002 Tracktown, U.S.A. 111910 Posts 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.
 2009-09-10, 00:23 #44 paleseptember     Jun 2008 Wollongong, .au 3×61 Posts 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!)

 Similar Threads Thread Thread Starter Forum Replies Last Post Lennart Conjectures 'R Us 31 2014-09-14 15:14 jasong Twin Prime Search 311 2010-10-22 18:41 ltd Prime Sierpinski Project 76 2008-07-25 11:44 ltd Prime Sierpinski Project 26 2005-11-01 07:45 R.D. Silverman Factoring 7 2005-09-30 12:57

All times are UTC. The time now is 11:35.

Sat Apr 10 11:35:48 UTC 2021 up 2 days, 6:16, 1 user, load averages: 2.44, 2.25, 1.90