![]() |
|
|
#12 |
|
Oct 2006
vomit_frame_pointer
36010 Posts |
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. |
|
|
|
|
|
#13 |
|
Just call me Henry
"David"
Sep 2007
Cambridge (GMT/BST)
2·33·109 Posts |
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 |
|
|
|
|
|
#14 |
|
"Mark"
Apr 2003
Between here and the
22×7×227 Posts |
|
|
|
|
|
|
#15 |
|
Just call me Henry
"David"
Sep 2007
Cambridge (GMT/BST)
10110111111102 Posts |
windows
|
|
|
|
|
|
#16 |
|
Oct 2006
vomit_frame_pointer
23·32·5 Posts |
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:
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. |
|
|
|
|
|
#17 | |
|
Just call me Henry
"David"
Sep 2007
Cambridge (GMT/BST)
588610 Posts |
Quote:
|
|
|
|
|
|
|
#18 | |
|
Bamboozled!
"πΊππ·π·π"
May 2003
Down not across
2·5,393 Posts |
Quote:
Admittedly, my experience isn't primarliy with ggnfs, but ggnfs is (I believe) built around the Franke siever. Paul |
|
|
|
|
|
|
#19 | |
|
Oct 2006
vomit_frame_pointer
23·32·5 Posts |
Quote:
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. Last fiddled with by FactorEyes on 2008-02-19 at 21:01 |
|
|
|
|
|
|
#20 | |
|
Jul 2003
So Cal
22×32×59 Posts |
Quote:
Greg |
|
|
|
|
|
|
#21 |
|
Tribal Bullet
Oct 2004
3×1,181 Posts |
I vaguely remember Joppe Bos was working on integrating the 64-bit asm into the GGNFS lattice siever.
|
|
|
|
|
|
#22 |
|
Oct 2006
vomit_frame_pointer
16816 Posts |
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.
![]() ![]() 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. |
|
|
|