| |||||||||||||
|
| |||||||||||||
Desktops usually no; Servers yes.Desktops usually no; Servers yes.Posted Dec 9, 2004 16:43 UTC (Thu) by dwheeler (guest, #1216)Parent article: Fedora Core 3 on AMD64 The main advantage of 64bit systems is that more than 4G of memory is directly addressible. Whether or not that's a useful advantage depends on what you do with your system. Currently, most desktop users will be quite happy with 32bits. One exception is some high-end CAD systems, where you want in-memory simulations that take more than 3Gig of memory. But some large servers, especially large database servers, can really use this. Database systems work better if there's lots of memory, for example, and it's easier to address lots of memory given a 64-bit address space. The Wikipedia database currently runs on 32bits; they've considered switching to 64bits, but at the time the costs and leading-edge-ness convinced them to stay with 32bit systems. As these get addressed, they'll probably move to a 64-bit system for their main database. Many large commercial outfits run databases on 64bit systems, for this reason.
(Log in to post comments)
Desktops usually no; Servers yes. Posted Dec 9, 2004 19:02 UTC (Thu) by knobunc (subscriber, #4678) [Link] What about the extra registers available in 64-bit mode? That alone is enough to speed up some tasks regardless of memory needed.
More registers = less register spilling. Means less stack access when calling subroutines. Compilation is a good example of when this is useful.
-ben
Desktops usually no; Servers yes. Posted Dec 9, 2004 20:41 UTC (Thu) by evgeny (guest, #774) [Link] > The main advantage of 64bit systems is that more than 4G of memory is directly addressible.
Well, to me (and many others), it's also working at native CPU speeds with 64bit data types (doubles and long longs).
Desktops usually no; Servers yes. Posted Dec 10, 2004 0:27 UTC (Fri) by sbergman27 (subscriber, #10767) [Link] Does 64bit really help for doubles? I thought that FPU's on current 32bit processors handled 80 bits or so.
Desktops usually no; Servers yes. Posted Dec 10, 2004 12:17 UTC (Fri) by evgeny (guest, #774) [Link] > Does 64bit really help for doubles?
Well, at least for my codes it does. YMMV ;-)
> I thought that FPU's on current 32bit processors handled 80 bits or so.
P3 is not bad, and Centrino is even better (per GHz). But you can't get SMP boxes with Centrino, and CPU speed is not high. P4/Xeon4, on the other hand, is a complete disaster as far as doubles and longlongs are concerned - again, this is my experience. Try running md5sum on a large file (e.g. an iso image) on a P3, P4, and Opteron boxes (of course, with 64bit kernel and md5sum binary in the last case) - and compare the (user) times. I even tried the Intel's ICC compiler - all the same. Switching from x86 to amd64 got me a factor of ~2 (per GHz) comparing to P3 and ~4 (!) comparing to P4.
Desktops usually no; Servers yes. Posted Dec 10, 2004 21:08 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] What does md5sum have to do with floating point?
The speedup on md5sum probably comes from doubling the number of integer registers, and thereby reducing register spills to the stack.
At any rate, doubling the integer register file should have a minimal impact on floating point codes, since all floating point computation occurs in the floating point register file. One area floating point code will see speedups is in block copies. Non-computational manipulation of floating point data in the integer register file (stuff like memcpy(), structure assignment, array initialization) will speed up.
Desktops usually no; Servers yes. Posted Dec 10, 2004 22:31 UTC (Fri) by evgeny (guest, #774) [Link] > What does md5sum have to do with floating point?
Not with FP; with (64bit) long longs. Hmm, or, at least, that was my impression. I did some benchmarks a year ago and noticed that a couple of utilites worked much better on amd64 than on x86; and it seemed it was related to the use of 64bit variables/structs..
> The speedup on md5sum probably comes from doubling the number of integer registers, and thereby reducing register spills to the stack.
Probably you're right.
> One area floating point code will see speedups is in block copies.
That's definitely not the case with my numbercrunching codes. Furthermore, running 32bit exec under 64bit kernel takes exactly twice more CPU time than the 64bit executable.
Desktops usually no; Servers yes. Posted Dec 10, 2004 3:28 UTC (Fri) by mbp (guest, #2737) [Link] I find it very strange that most(?) AMD64 desktops currently available can accomodate less than 4G of RAM. Even if >4G is slightly expensive now, you'd think people switching would want at least the possibility of upgrading to say 8G in a year or so.
I don't really know what I'd do with 8G on a desktop though.
Desktops usually no; Servers yes. Posted Dec 10, 2004 5:42 UTC (Fri) by proski (subscriber, #104) [Link] Nothing strange. 4 Gb of memory is still too expensive for a desktop. Ability to address more memory is only one advantage of 64-bit architectures. There are other advantages, such as 64-bit arithmetic and (in case of AMD64) new registers.
|
|
||||||||||||