2^925+1 sieving

[fivemack]

FactorEyes suggested that a nice chunky quartic would appeal for the next project. So: here's the polynomial

n: 5688016226807831064044758914315660452874822911732021084198059235416884717188698621609682118091029853096510590721423450325168014323277731989012600970545984976786513017985287740035850980703007762825496957935313661984801
c4: 1
c3: -1
c2: 1
c1: -1
c0: 1
Y1: -1
Y0: 49039857307708443467467104868809893875799651909875269632
type: snfs
skew: 1
rlambda: 2.6
alambda: 2.6
lpbr: 31
lpba: 29
mfbr: 62
mfba: 58
alim: 25000000
rlim: 150000000

Rational-side sieving only, -15e, 50M to 150M ought to suffice. Gentlemen, once you're finished with any contributions you have already committed to make to 3221-73, start your sieves! I'm somewhat snowed under with aliquot sequences at the moment, as well as finishing off 3221-73, and will not make a big reservation immediately.

You ought to get about 1.5M relations from a million-Q range near 150M and about 1.3M relations from one near 50M. 1MQ will take eight to nine days on a K8/2200, a bit less on a core2, so it's two to three CPU-years.

I do not trust the FTP server, or the terminal emulators I use, to handle umlauts, so this project's town is Fredrikstad, on the main road through Gothenburg from Malmo to Oslo.

Reservations (closed 30Dec):
andi47 50-53
FactorEyes 53-60 (done 02Jan)
fivemack 60-70 (done 25Dec)
fivemack 70-80 (done 01Jan)
fivemack 80-87 (done 05Jan)
J.F. 87-88 (done 31Dec)
bsquared 88-90 (done 04Jan)
Xyzzy 90-91 (done 22Dec)
fivemack 91-92 (done 02Jan)
bsquared 92-95 (done 19Dec)
Batalov 95-100 (done 12Dec)
J.F. 100-110 (done 15Dec)
J.F. 110-120 (done 21Dec)
J.F. 120-130 (done 21Dec!)
J.F. 130-135 (done 31Dec)
Batalov 135-140 (done 21Dec)
fivemack 140-150 (done 19Dec)

Pancake stock:
50-50.8, 53-150

Palatschinkenstapelanalyse:
15/12/2008 2244: 22973699 relations (22465778 unique), 42532642 large ideals
21/12/2008 1357: 64030198 relations (60720874 unique), 55771634 large ideals
26/12/2008 2017 (67MQ): 94956808 relations (87302551 unique), 60136963 large ideals
weight of 11147491 cycles is about 780489091 (70.01/cycle)
07/01/2009 1943 (97+MQ): 135302170 relations (121661494 unique), 65760664 large ideals
weight of 8600364 cycles is about 668840754 (77.77/cycle)
'matrix can improve, retrying'
weight of 8344139 cycles is about 584191277 (70.01/cycle)

[R.D. Silverman]

Originally Posted by fivemack

FactorEyes suggested that a nice chunky quartic would appeal for the next project. So: here's the polynomial

n: 5688016226807831064044758914315660452874822911732021084198059235416884717188698621609682118091029853096510590721423450325168014323277731989012600970545984976786513017985287740035850980703007762825496957935313661984801
c4: 1
c3: -1
c2: 1
c1: -1
c0: 1
Y1: -1
Y0: 49039857307708443467467104868809893875799651909875269632
type: snfs
skew: 1
rlambda: 2.6
alambda: 2.6
lpbr: 31
lpba: 29
mfbr: 62
mfba: 58
alim: 25000000
rlim: 150000000

Rational-side sieving only, -15e, 50M to 150M ought to suffice. Gentlemen, once you're finished with any contributions you have already committed to make to 3221-73, start your sieves! I'm somewhat snowed under with aliquot sequences at the moment, as well as finishing off 3221-73, and will not make a big reservation immediately.

You ought to get about 1.5M relations from a million-Q range near 150M and about 1.3M relations from one near 50M. 1MQ will take eight to nine days on a K8/2200, a bit less on a core2, so it's two to three CPU-years.

I haven't picked a city for uploads yet.

Food for thought.

Your group has little experience with a quartic. It might be better to
start with something a little smaller (say, 2,865+, 2,860+) to 'get a feel'
for proper parameter selection.....

[Batalov]

Växjö!
Let the people twist into pretzels trying to type that to
cd special/twomack-relations/växjö

[Xyzzy]

Please assign us whatever would make sense for (newbies) running a 2GHz C2D with 4GB memory. We'll (hopefully) be running some sort of 64-bit optimized binary, if there is one for Windows. (We're kind of stuck with 64-bit Vista on this particular machine for now.)

We've never been able to get Cygwin to install properly in Vista, despite numerous attempts and workarounds. Should we look into MinGW or MSYS? (We don't fully understand the difference between them.)

Thanks!

[Batalov]

Several last sieving excercises didn't have any instructions, so maybe they could be added to the fist post, Tom? Digested from several past threads, with links to binaries in one place?

A good starting point, I think, is a digest of http://www.mersenneforum.org/showthread.php?t=10003
It is actually invaluable for the link-outs to contributed binaries and a ton of benchmarks on different systems. I felt as if I was missing something there; another round of binary building happened in yet another thread, but I cannot find it now.

Anyway, I will throw in here a couple of new links/ideas that may be important -
1. the GGNFS SVN source with version>=322 will not get stuck in infinite loop (however, this is rare, P~=1/10^8 relations; if no binary is found with this patch, fear not, proceed with any fast binary) - http://ggnfs.svn.sourceforge.net/viewvc/ggnfs/trunk/ Use the "Download GNU tarball" link at the bottom - this helps to avoid installing svn when you don't have it. You can build it. There are no 64-bit assembly enhancements in official GGNFS source...
2. Enhanced binaries with 64-bit assembly-optimized bottlenecks are available in the thread 10003 above, but AFAIR they are all linux-built (and they work for both AMD and C2D/Q). Maybe someone was successful in building a Win64 binary? Let's post it here!
3. I am NOT a Windows person (a reluctant user only at work), but I was always curious to hear an opinion from really good Windows programmers - is it possible to use/adapt that famous 64-bit assembly code in some wrapper (or whatever needed) and fuse it into a 32-bit Windows binary? The CPU is 64-bit, the OS is 32-bit (for a variety of reasons, laziness, work restrictions, right?) - but does the properly built program have access to the 64-bit capabilities of the CPU? EDIT: No. I am stumped here - not my cup of tea, those Windows... But we must have someone really good with this on the forum, heh? (I've also heard that there was a 32-bit assembly-optimization, too; not as dramatically faster as 64-bit, but still better than plain GGNFS code. Anyone? Build, contribute the binary?)

Lastly - here's my hit on SVN-322-with-64-bit-asm for Linux x86_64/k8 platform - http://snp.gnf.org/gnfs-lasieve4I15e.zip

--Serge

[jasonp]

No, if you use windows you need the 64-bit OS to access the extra registers, as well as the 64-bit versions of the 32-bit registers and the extra 8 SSE2 registers.

[bsquared]

Originally Posted by Batalov

A good starting point, I think, is a digest of http://www.mersenneforum.org/showthread.php?t=10003
It is actually invaluable for the link-outs to contributed binaries and a ton of benchmarks on different systems. I felt as if I was missing something there; another round of binary building happened in yet another thread, but I cannot find it now.

Maybe you were thinking of this one?
http://www.mersenneforum.org/showthread.php?t=10159

[henryzz]

Originally Posted by Xyzzy

Please assign us whatever would make sense for (newbies) running a 2GHz C2D with 4GB memory. We'll (hopefully) be running some sort of 64-bit optimized binary, if there is one for Windows. (We're kind of stuck with 64-bit Vista on this particular machine for now.)

We've never been able to get Cygwin to install properly in Vista, despite numerous attempts and workarounds. Should we look into MinGW or MSYS? (We don't fully understand the difference between them.)

Thanks!

what was the problem
i installed cygwin on 32-bit vista easily last time i installed
i have had problems with the PATH variable in the past though
i had to manually add the path of the cygwin bin directory to the PATH variable

[xilman]

Originally Posted by henryzz

what was the problem
i installed cygwin on 32-bit vista easily last time i installed
i have had problems with the PATH variable in the past though
i had to manually add the path of the cygwin bin directory to the PATH variable

Re-read what he posted: he's on 64-bit Windows.

There have been all sorts of problems getting Cygwin ported to W64. Finding more details is left as an exercise in using Google.


Paul

[henryzz]

Originally Posted by xilman

Re-read what he posted: he's on 64-bit Windows.

There have been all sorts of problems getting Cygwin ported to W64. Finding more details is left as an exercise in using Google.


Paul

i wondered whether it was 64-bit that was the problem but i then decided that vista was probably the greater evil

[Xyzzy]

Our first problem:

start "90,000,000-90,100,000" /low /affinity 1 gnfs-lasieve4I15e.exe -r "2,925+.pol" -f 90000000 -c 100000 -o 90,000,000-90,100,000
Special q lower bound 90000000 below FB bound 1.5e+008

We adjusted rlim in the polynomial file to 90000000. Was this a dumb move?

Our setup:

Right now we are not using any Cygwin/MinGW tools. Just a DOS window. (Of course, in Vista, DOS windows are more than just DOS windows, but they still kind of suck.)

The syntax is:

start "90,000,000-90,100,000" /low /affinity 1 gnfs-lasieve4I15e.exe -r "2,925+.pol" -f 90000000 -c 100000 -o 90,000,000-90,100,000

Where:

start → Invokes a command.
"90,000,000-90,100,000" → Sets the title of the invoked window.
/low → Run the program at low priority.
/affinity 1 → Set the CPU affinity to processor 0. Use "2" for processor 1.
gnfs-lasieve4I15e.exe → This is probably not the optimized binary for a C2D but we think it is at least 64-bit.
-r → Run the rational side only.
"2,925+.pol" → Our name for the polynomial file. Note it has to be quoted. Ugh!
-f 90000000 → Start processing at 90,000,000.
-c 100000 → Perform 100,000 incremented "tests" until the program reaches 90,100,000
-o 90,000,000-90,100,000 → Our name for the results file.

Our second CPU is running with

start "90,100,000-90,200,000" /low /affinity 2 gnfs-lasieve4I15e.exe -r "2,925+.pol" -f 90100000 -c 100000 -o 90,100,000-90,200,000

There is a file called ".last_spq0". Does running two instances of gnfs-lasieve4I15e.exe in the same directory cause a problem with this file? Perhaps both instances are using this file to track things?

We noticed nothing is written to the output files until we abort the process. We left it running a long time. Will the program eventually write to the files or will it try to cache all the data?

Here are some preliminary timings:

CPU0: total yield: 1021, q=90000767 (0.98395 sec/rel)
CPU1: total yield: 1101, q=90100837 (0.75965 sec/rel)

Translated, do we have this scenario?

Iterations per second × 100,000 / 3,600 = Hours to run 100,000 iterations?

CPU0: 27h19m55s
CPU1: 21h06m05s

Are the timings a cumulative average or just for the last set calculated? (They do seem to be drifting down a bit.)

Both processes are using roughly 245MB each.

Many thanks for any help!