A computation worthy of the name

[J.F.]

Unfortunately, 64-bit mode does not work for me:

FATAL: kernel too old
Segmentation fault

while uname -a says

Linux hpcibm1 2.6.8-11-amd64-k8-smp #1 SMP Sun Oct 2 20:03:22 UTC 2005 x86_64 GNU/Linux

Any other links?

[Batalov]

It should be relatively straightforward to build it.
The source is in src/experimental/lasieve4_64/ branch of ggnfs sourceforge and there's a readme with instructions. (Sorry, old kernel machines hard to find.)

[frmky]

Has anyone successfully compiled the 64-bit optimized version for Windows x64? If not, we should ask Brian Gladman if he's willing to port it.

[henryzz]

Originally Posted by frmky

Has anyone successfully compiled the 64-bit optimized version for Windows x64? If not, we should ask Brian Gladman if he's willing to port it.

whats wrong with mingw64?

[Jeff Gilchrist]

Originally Posted by henryzz

whats wrong with mingw64?

Nothing, does anyone have a link to a Windows x64 binary (native, mingw, whatever) of the 64bit experimental version for us to download and use?

[Batalov]

I figured that the deposition site is going to be the same fivemack.dyndns.org, M941/ directory.
...and there goes the first pancake.
R67-68M.bz2 2,122,258 relns (of which 3,659 are duplicates)
Sieved in 2.0Ms on Phenom940.

No problems with 16e found; there's no yield dip and there were no badscheds. Same for 67M-a which is almost finished.

fivemack: M941.67M-a.bz2 is truncated after line 990250 "-127824373,185539869:44a61f7,8f89333,5f22eb,61f489,15aea99,19a9,1f67,4057307:1d9b9ea1,21b7d45f,6e527,7b14f,ad41f,6bb997,7686d9"

[Brian Gladman]

Originally Posted by henryzz

whats wrong with mingw64?

Nothing, provided that you don't need the x64 assembler code. But it's highly likely that the performance of the x64 lattice siever depends on the x64 assembler and neither mingw64 nor Visual Studio can make any use of this until it is ported onto Windows.

Sadly, x64 on Linux and Windows use significantly different calling conventions, which means that porting assembler code requires a lot more work than simple format conversion. This is not too hard if the assembler has been written with this in mind (as in MPIR for example) but otherwise it can be a pretty daunting task.

I have looked at the assembler code in the GGNFS experimental directory and its volume and its poor structure from a porting point of view means that I won't be doing this. It is possible that the code was auto-generated and, if so, the generator might offer a better starting point.

It is worth noting that it is NOT hard to write x64 assembler code that can be easily moved between Linux and Windows provided that this is consciously considered when the code is first written. MPIR code is written in this way and, deliberately or not, it turns out that the x64 assembler code in GMP is also easy to convert.

[Andi47]

Is there an easy way to compile GGNFS for 64-bit-linux on a core 2 duo? If not - are there precompiled binaries for 64-bit linux on a C2D available?

fivemack: see http://www.mersenneforum.org/showpos...7&postcount=20
(or did you actually mean GGNFS, procrels and suchlike, in which case, why?)

[henryzz]

Originally Posted by Andi47

Is there an easy way to compile GGNFS for 64-bit-linux on a core 2 duo? If not - are there precompiled binaries for 64-bit linux on a C2D available?

http://mersenneforum.org/showpost.ph...1&postcount=28
they are optimized for amd cpus but someone says later on that that shouldn't make that much difference
they are what i use on a core 2 quad

[Joe O]

Originally Posted by Brian Gladman

Nothing, provided that you don't need the x64 assembler code. But it's highly likely that the performance of the x64 lattice siever depends on the x64 assembler and neither mingw64 nor Visual Studio can make any use of this until it is ported onto Windows.

Sadly, x64 on Linux and Windows use significantly different calling conventions, which means that porting assembler code requires a lot more work than simple format conversion. This is not too hard if the assembler has been written with this in mind (as in MPIR for example) but otherwise it can be a pretty daunting task.

I have looked at the assembler code in the GGNFS experimental directory and its volume and its poor structure from a porting point of view means that I won't be doing this. It is possible that the code was auto-generated and, if so, the generator might offer a better starting point.

It is worth noting that it is NOT hard to write x64 assembler code that can be easily moved between Linux and Windows provided that this is consciously considered when the code is first written. MPIR code is written in this way and, deliberately or not, it turns out that the x64 assembler code in GMP is also easy to convert.

Will this help?
10.1 Call stubs for 64-bit conversions

[Andi47]

Originally Posted by Andi47

fivemack: see http://www.mersenneforum.org/showpos...7&postcount=20
(or did you actually mean GGNFS, procrels and suchlike, in which case, why?)

The link posted there is 404.

Edit: And the link to which Henryzz's posting directs to, requires a password.

I have installed Ubuntu 9.04 (64 bit) this week on a C2D laptop which was running WinXP-32 until then, and I'm currently running the matrix of 2,1766M, which will finish around Monday morning. When it finishes, I want to install GGNFS (gnfs-lasieve4I1?e and such), I also plan to run a part of my range for M941 on this node.