A multiple k/c sieve for Sierpinski/Riesel problems - Page 38

geoff · 2007-12-05, 00:04

I have had two reports of the x86-64 executables crashing on Windows 64, one for sr1sieve and one for sr2sieve.

Has anyone else had problems with the x86-64 Windows version, especially an access violation soon after starting?

Conversely, has anyone successfully run the x86-64 executable on Vista 64?

tnerual · 2007-12-05, 00:36

Quote:

Originally Posted by geoff

Conversely, has anyone successfully run the x86-64 executable on Vista 64?

if nobody is running it, i will try it tomorrow (if vista accept to start)

geoff · 2007-12-06, 23:52

These versions have a new switch: `sr2sieve -An ...' will set affinity to CPU n.

This feature is probably not useful on Linux where you can just as easily run `taskset -cn sr2sieve ...', It hasn't been tested on Windows yet, please let me know if it doesn't work as expected.

AES · 2007-12-07, 02:21

Quote:

Originally Posted by geoff

I have had two reports of the x86-64 executables crashing on Windows 64, one for sr1sieve and one for sr2sieve.

Has anyone else had problems with the x86-64 Windows version, especially an access violation soon after starting?

Conversely, has anyone successfully run the x86-64 executable on Vista 64?

sr1sieve-1.2.4-windows-x86-64 runs great on 64-bit Vista. I have not had problems with any version of sr2sieve on 64-bit Vista.

Thanks Geoff.

geoff · 2007-12-08, 01:15

It appears that there is a bug in the cross compiler I use to build the Windows x86-64 executables that probably affected all prior sr1sieve versions. sr1sieve version 1.2.4 has a workaround for the bug, and I have also added the workaround to the stable branch in sr1sieve version 1.1.13. Thanks AES for helping track this down.

If anyone builds their own executables, please avoid using GCC version 4.3.0 if possible.

edit: This problem didn't affect the Linux or 32-bit precompiled executables, I use GCC 3.4 to compile them.

em99010pepe · 2007-12-08, 13:28

Hey Geoff,

You are doing a great job on the sieving side what about the LLRring side?

Carlos

geoff · 2007-12-09, 00:27

There are more reports of problems with the sr2sieve 64-bit Windows executables, the common thread is that the problems occur in the x87 FPU code path which is used for sieving p > 2^51 or when the --no-sse2 switch is used.

I don't have any solution yet, and without a 64-bit Windows machine it could take a while to locate the problem, so in the meantime please use the 32-bit executable on 64-bit Windows machines for sieving above p=2^51 (about 2250e12 or 2250T).

axn · 2007-12-09, 00:34

Hmmm... At first, I thought that maybe this was the problem, but then ...

Quote:

Originally Posted by the article

Early reports claimed that the operating system scheduler would not save and restore the x87 FPU machine state across thread context switches. Observed behavior shows that this is not the case: the x87 state is saved and restored, except for kernel-mode-only threads. The most recent documentation available from Microsoft states that the x87/MMX/3DNow! instructions may be used in long mode.

Oh well.

geoff · 2007-12-10, 23:59

I have found a place where the cross-compiler I use to build the x86-64 Windows executables generates incorrect code, causing an array overrun in the x87 FPU code path. This code path is only used when sieving deeper than 2^51 or when the --no-sse2 switch is given. The normal result is that the program crashes with an access violation soon after starting.

As a workaround I have lowered the compiler optimisation level to -O1 when building the sr1sieve version 1.2.5 and sr2sieve version 1.6.16 executables. This changes the part of the code which is obviously incorrect so that it is not obviously incorrect. It still needs to be tested. All earlier versions of the Windows x86-64 executables were affected by this bug and should not be used for sieving p > 2^51.

If compiling your own executable from source, avoid GCC 4.3.0 if possible, or else use the ARCH=x86-64-gcc430 Makefile option instead of ARCH=x86-64. This probably applies to the MacIntel executables too.

Cruelty · 2007-12-11, 08:55

Would it be possible to append to sr(x)sieve.log file version information every time sieve is started? Just to track which versions completed which ranges in case some error occurs.

geoff · 2007-12-12, 01:19

Quote:

Originally Posted by Cruelty

Would it be possible to append to sr(x)sieve.log file version information every time sieve is started? Just to track which versions completed which ranges in case some error occurs.

That is a very good idea, I'll do it ASAP. Thanks.

2007-12-05, 00:04	#408
geoff Mar 2003 New Zealand 13·89 Posts	Problems with Windows x86-64 executable I have had two reports of the x86-64 executables crashing on Windows 64, one for sr1sieve and one for sr2sieve. Has anyone else had problems with the x86-64 Windows version, especially an access violation soon after starting? Conversely, has anyone successfully run the x86-64 executable on Vista 64?

2007-12-06, 23:52	#410
geoff Mar 2003 New Zealand 485₁₆ Posts	srsieve 0.6.9, sr1sieve 1.2.4, sr2sieve 1.6.15 These versions have a new switch: `sr2sieve -An ...' will set affinity to CPU n. This feature is probably not useful on Linux where you can just as easily run `taskset -cn sr2sieve ...', It hasn't been tested on Windows yet, please let me know if it doesn't work as expected.

2007-12-08, 01:15	#412
geoff Mar 2003 New Zealand 13·89 Posts	It appears that there is a bug in the cross compiler I use to build the Windows x86-64 executables that probably affected all prior sr1sieve versions. sr1sieve version 1.2.4 has a workaround for the bug, and I have also added the workaround to the stable branch in sr1sieve version 1.1.13. Thanks AES for helping track this down. If anyone builds their own executables, please avoid using GCC version 4.3.0 if possible. edit: This problem didn't affect the Linux or 32-bit precompiled executables, I use GCC 3.4 to compile them. Last fiddled with by geoff on 2007-12-08 at 01:20

2007-12-09, 00:27	#414
geoff Mar 2003 New Zealand 485₁₆ Posts	Don't use Windows x86-64 executables for p > 2^51 There are more reports of problems with the sr2sieve 64-bit Windows executables, the common thread is that the problems occur in the x87 FPU code path which is used for sieving p > 2^51 or when the --no-sse2 switch is used. I don't have any solution yet, and without a 64-bit Windows machine it could take a while to locate the problem, so in the meantime please use the 32-bit executable on 64-bit Windows machines for sieving above p=2^51 (about 2250e12 or 2250T).

2007-12-10, 23:59	#416
geoff Mar 2003 New Zealand 13·89 Posts	sr1sieve 1.2.5, sr2sieve 1.6.16 (Windows x86-64) I have found a place where the cross-compiler I use to build the x86-64 Windows executables generates incorrect code, causing an array overrun in the x87 FPU code path. This code path is only used when sieving deeper than 2^51 or when the --no-sse2 switch is given. The normal result is that the program crashes with an access violation soon after starting. As a workaround I have lowered the compiler optimisation level to -O1 when building the sr1sieve version 1.2.5 and sr2sieve version 1.6.16 executables. This changes the part of the code which is obviously incorrect so that it is not obviously incorrect. It still needs to be tested. All earlier versions of the Windows x86-64 executables were affected by this bug and should not be used for sieving p > 2^51. If compiling your own executable from source, avoid GCC 4.3.0 if possible, or else use the ARCH=x86-64-gcc430 Makefile option instead of ARCH=x86-64. This probably applies to the MacIntel executables too.

2007-12-08, 13:28	#413
em99010pepe Sep 2004 2×5×283 Posts	Hey Geoff, You are doing a great job on the sieving side what about the LLRring side? Carlos

2007-12-11, 08:55	#417
Cruelty May 2005 2³×7×29 Posts	Would it be possible to append to sr(x)sieve.log file version information every time sieve is started? Just to track which versions completed which ranges in case some error occurs.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Very Prime Riesel and Sierpinski k	robert44444uk	Open Projects	587	2016-11-13 15:26
Sierpinski/ Riesel bases 6 to 18	robert44444uk	Conjectures 'R Us	139	2007-12-17 05:17
Sierpinski/Riesel Base 10	rogue	Conjectures 'R Us	11	2007-12-17 05:08
Sierpinski / Riesel - Base 23	michaf	Conjectures 'R Us	2	2007-12-17 05:04
Sierpinski / Riesel - Base 22	michaf	Conjectures 'R Us	49	2007-12-17 05:03