gcwsieve - Page 3

Citrix · 2007-06-20, 02:13

Quote:

Originally Posted by hhh

Great news indeed.

Sieving the 5-25M range will be done up to 100G in a couple of days, and I think we can start a new sieve drive then. Is that OK for you, or do you suggest to reopen the late 1.5-5M range?

Yours H.

Since 1.5-5M has been p-1ed, it might be better if we start to sieve 5M to 25M.

Can the 1.5to 5M numbers be P+1ed? What is the command line for Prime95 to do this?

hhh · 2007-06-20, 13:05

P-1 has been done only to 3M. See the reservation thread.

I decided to stop the support of sieving mainly because the human overhead was just too big.
But I can look up the P+1 command, and publish some worktodo.ini's, for 3M upwards. Would there be some interest?

H.

geoff · 2007-06-21, 02:10

Quote:

Originally Posted by hhh

Sieving the 5-25M range will be done up to 100G in a couple of days, and I think we can start a new sieve drive then. Is that OK for you, or do you suggest to reopen the late 1.5-5M range?

I wouldn't mind sieving 2.5M < n < 5M, 4200T < p < 5000T on my P4/Celeron, it will be a little more producive than LLR testing, but if you don't want to reopen sieving for that range then that is OK, I will just continue with LLR.

hhh · 2007-06-21, 19:49

Go ahead. If it's a big chunk reservation it should be fine. I'll import it with the P-1 results very much later then.

The Sieving to 100 G finished today, I will do the necessary tomorrow. But I'll create a poll already. H.

geoff · 2007-07-15, 21:23

This version has a new main loop in x86-64 assembler. It should be a lot faster than previous versions for those running 64-bit Linux (is there anyone?), but the code has not been tested at all, so please check that the results match those produced by the 32-bit binary.

There is no need to upgrade if you are using the 32-bit binary.

jasong · 2007-07-18, 04:10

Quote:

Originally Posted by geoff

This version has a new main loop in x86-64 assembler. It should be a lot faster than previous versions for those running 64-bit Linux (is there anyone?), but the code has not been tested at all, so please check that the results match those produced by the 32-bit binary.

There is no need to upgrade if you are using the 32-bit binary.

I'd be willing to try it, but not until tomorrow afternoon. The soonest I can give a result, unless I have insomnia, is about 16 hours from now.

jasong · 2007-07-20, 03:33

Um, the sieve file seems to be screwed up. The lines have the n-value printed twice, but judging from the equation at the beginning, they should only be printed once per line.

geoff · 2007-07-20, 03:54

Quote:

Originally Posted by jasong

Um, the sieve file seems to be screwed up. The lines have the n-value printed twice, but judging from the equation at the beginning, they should only be printed once per line.

Yes it is :-(. You can delete the first column with the cut command:

$ cut -d\ -f 2,3,4 INFILE > OUTFILE

Note that there needs to be two spaces after the -d\

jasong · 2007-07-20, 04:41

64-bit Linux on AMD give a little over 620K a second.

geoff · 2007-07-20, 23:17

Quote:

Originally Posted by jasong

64-bit Linux on AMD give a little over 620K a second.

If possible could you send me a copy of the factors for a range of about 5G or so for double checking? Email address is in the README file.

Also, are you able to compare that with the 32-bit binary on the same machine? It is possible that the 32-bit SSE2 code is faster than the 64-bit code, and if that was the case then I could probably improve it using 32-bit SSE2 together with the extra SSE registers on the x86-64.

jasong · 2007-07-21, 20:53

The 64-bit code works perfectly. When I unzipped the 32-bit version to the same directory and tried to run it, the OS claimed the file didn't exist, even though the 'ls' command listed it as being there.

My command was ./gcwsieve I even verified that there were no invisible spaces in the filename.

2007-07-15, 21:23	#27
geoff Mar 2003 New Zealand 1157₁₀ Posts	gcwsieve 1.0.10 (x86-64) This version has a new main loop in x86-64 assembler. It should be a lot faster than previous versions for those running 64-bit Linux (is there anyone?), but the code has not been tested at all, so please check that the results match those produced by the 32-bit binary. There is no need to upgrade if you are using the 32-bit binary.

2007-06-20, 13:05	#24
hhh Jun 2005 373 Posts	P-1 has been done only to 3M. See the reservation thread. I decided to stop the support of sieving mainly because the human overhead was just too big. But I can look up the P+1 command, and publish some worktodo.ini's, for 3M upwards. Would there be some interest? H.

2007-06-21, 19:49	#26
hhh Jun 2005 373 Posts	Go ahead. If it's a big chunk reservation it should be fine. I'll import it with the P-1 results very much later then. The Sieving to 100 G finished today, I will do the necessary tomorrow. But I'll create a poll already. H.

2007-07-20, 03:33	#29
jasong "Jason Goatcher" Mar 2005 DB3₁₆ Posts	Um, the sieve file seems to be screwed up. The lines have the n-value printed twice, but judging from the equation at the beginning, they should only be printed once per line.

2007-07-20, 04:41	#31
jasong "Jason Goatcher" Mar 2005 3×7×167 Posts	64-bit Linux on AMD give a little over 620K a second.

2007-07-21, 20:53	#33
jasong "Jason Goatcher" Mar 2005 3×7×167 Posts	The 64-bit code works perfectly. When I unzipped the 32-bit version to the same directory and tried to run it, the OS claimed the file didn't exist, even though the 'ls' command listed it as being there. My command was ./gcwsieve I even verified that there were no invisible spaces in the filename.