x86_64 ECM changes the weighting in this situation
 

On 64-bit machines, ECM runs over three times as fast it does in 32-bit, due to the GMP library's use of 64-bit*64-bit multiplication and 128-bit by 64-bit division (IIRC -- I haven't looked at the GMP assembler routines in a couple of years). This changes the weighting a bit, if you're lucky enough to have this problem.

So for x86_64-compiled ECM binaries, you can add 5 digits to your level of ECM cleanout.

what r the disadvantages of going to 64bit
i have a Athalon 64 3800+ running 32-bit Vista Ultimate(never bother getting Ultimate it is twice as slow as the home versions)
is it worth me upgrading to 64bit

[QUOTE=henryzz;126142]what r the disadvantages of going to 64bit
i have a Athalon 64 3800+ running 32-bit Vista Ultimate(never bother getting Ultimate it is twice as slow as the home versions)
is it worth me upgrading to 64bit[/QUOTE]

Are you referring to GMP-ECM or Windows?

windows

64-bit XP Pro has few advantages over 32-bit, and some disadvantages. Some applications will run faster, a few will run more slowly, and most will see no difference. You'll be able to see more than 3.6G of RAM with the 64-bit version.

64-bit versions of Windows lack antivirus software and certain other things, although I have heard that this situation is improving.

As for the sort of programs we on this forum love to heat our processors (and homes) with, it will only benefit those programs with configure/make options that take advantage of the double-wide registers and other goodies. I run 32-bit XP pro and 64-bit Centos 5.1 (Red-Hat Enterprise clone), and here are my observations:
[LIST][*]Pari-gp: No appreciable difference, but I don't use it for anything heavy[*]gnfs-lasieveXXXX (ggnfs): 15% slower on 64-bit, even when compiled for x86_64.[*]GMP-ECM: Around 3.2 times faster in 64-bit -- a huge advantage[*]msieve: No appreciable difference, but I haven't run any explicit tests, and I would bet that the square-root phase would run much faster in 64-bit.[/LIST]
This is a dual-boot situation, so processors, RAM, and motherboard are the same for both 32-bit XP and 64-bit Linux.

I might get 64-bit XP, but I prefer to do my compiling (and other, actual remunerative, non integer-obsessed work) in Linux, so there seems little point to it. You won't see the advantage unless you're prepared to recompile things for the 64-bit x86_64 instruction set, and things like lattice sievers are all about the cache and not about raw multiplication speed.

[quote=FactorEyes;126169]64-bit XP Pro has few advantages over 32-bit, and some disadvantages. Some applications will run faster, a few will run more slowly, and most will see no difference. You'll be able to see more than 3.6G of RAM with the 64-bit version.

64-bit versions of Windows lack antivirus software and certain other things, although I have heard that this situation is improving.

As for the sort of programs we on this forum love to heat our processors (and homes) with, it will only benefit those programs with configure/make options that take advantage of the double-wide registers and other goodies. I run 32-bit XP pro and 64-bit Centos 5.1 (Red-Hat Enterprise clone), and here are my observations:[LIST][*]Pari-gp: No appreciable difference, but I don't use it for anything heavy[*]gnfs-lasieveXXXX (ggnfs): 15% slower on 64-bit, even when compiled for x86_64.[*]GMP-ECM: Around 3.2 times faster in 64-bit -- a huge advantage[*]msieve: No appreciable difference, but I haven't run any explicit tests, and I would bet that the square-root phase would run much faster in 64-bit.[/LIST]This is a dual-boot situation, so processors, RAM, and motherboard are the same for both 32-bit XP and 64-bit Linux.

I might get 64-bit XP, but I prefer to do my compiling (and other, actual remunerative, non integer-obsessed work) in Linux, so there seems little point to it. You won't see the advantage unless you're prepared to recompile things for the 64-bit x86_64 instruction set, and things like lattice sievers are all about the cache and not about raw multiplication speed.[/quote]
thanks

[QUOTE=FactorEyes;126169]
gnfs-lasieveXXXX (ggnfs): 15% slower on 64-bit, even when compiled for x86_64.[/QUOTE]

I find that [i]very[/i] surprising. When I added the amd-64 assembler routines to the Franke lattice siever the speed increased markedly. I don't have measurements to hand but seem to remember it doubling or more.

Admittedly, my experience isn't primarliy with ggnfs, but ggnfs is (I believe) built around the Franke siever.

Paul

[QUOTE=xilman;126176]I find that [i]very[/i] surprising. When I added the amd-64 assembler routines to the Franke lattice siever the speed increased markedly. I don't have measurements to hand but seem to remember it doubling or more.

Admittedly, my experience isn't primarliy with ggnfs, but ggnfs is (I believe) built around the Franke siever.

Paul[/QUOTE]This is encouraging.

I compiled ggnfs a few days ago with the x86_64 target, but I have not dug into the code to see what the build process does with this information. It could be that my system lacks the right assembler executable, or something like that.

Is your source the CWI code?

This might be worth a new thread on what to expect from a 64-bit system, and how to ensure you're getting it.

[QUOTE=xilman;126176]I find that [i]very[/i] surprising. When I added the amd-64 assembler routines to the Franke lattice siever the speed increased markedly. [/QUOTE]

Are these AMD64 assembler routines publicly available? The version of the lattice sieve in GGNFS doesn't include them. As such, the 32-bit version, which has assembler routines, is about 15% faster than the 64-bit version without assembler support.

Greg

[QUOTE=frmky;126200]Are these AMD64 assembler routines publicly available? The version of the lattice sieve in GGNFS doesn't include them. As such, the 32-bit version, which has assembler routines, is about 15% faster than the 64-bit version without assembler support.
[/QUOTE]
I vaguely remember Joppe Bos was working on integrating the 64-bit asm into the GGNFS lattice siever.

Worth looking into
 

If this is easy or moderately difficult, someone would have done it already, but this might merit a trip through the 32-bit lattice siever code to see where the asm is called, and see if any means of souping it up comes to mind.

:ouch1::yucky:

I know enough about the Franke code to fear it, so I can only guess at the likelihood that this would be fruitful. Plus, you have to RTFM for the instructions that will do the best job, which, with these new jackrabbit processors, is not as clear as it used to be.