Are You Switching to 64-bit Processors?
chip_whisperer asks: "I used to be a big time custom desktop builder, making many working boxes per year, but I've been off the bandwagon for about four years now and am trying to get back into it now that Ars Technica has just released their recommendations. The standard seems to be heading towards 64-bit processors, but I'm wondering if it worth it to run a box on XP-64? I've heard that driver support for 64-bit processors can be a hassle. Also, for you fellow Linux geeks, how are current distros (like Suse, Ubuntu, Debian, and others) doing in supporting 64 bit processors?"
Make a list of what XP-64 will do for you that XP won't. If there's anything on that list that really entices you, consider XP-64. If not, forget it, and go along your merry way. XP-64 is guaranteed to give you more driver problems than XP, so if there are no added benefits in using it (which there probably aren't for you, unless you want to use over 2GB of memory), there's no reason for the headache.
Perhaps a more interesting question would be whether the Windows-users in the Slashdot community plan to run 64-bit Vista, considering its enhanced security (PatchGuard et al.) as well as its enhanced possibilities of restricting you from doing things on your own computer.
If you're building boxes for friends or customers, you'll want to consider the fact that Macromedia has not released a 64-bits version of Flash player, meaning users have to use a 32-bits browser to see flash animations. You don't start appreciating having flash around until you load the latest YouTube movie.
x86-64's main use is its address space. 32 bits places a 4 million word limitation on your addressing. systems like zfs that are heavily heavily transactional end up addressing a lot more objects than this. once you've breeched your 32bit addressing, the performance of native 64 bit addressing v. some kind of page extension mode is night and day. zfs's _need_ for x86-64 stems from this; it'll run on an "old" athlon, but in 64bit mode it flies.
my personal belief is that the future, the nebulous area Stroustroupe outlines as "better concurrency," is really going to be implemented at a platform level as this kind of deeply nested transactional data structuring, where instead of overwriting your object to change its state, you simply append the new state in a new part of memory. thus each object accumulates address space (referentiability) as it changes across time. i'll leave the full details implementation & ramifications of Copy on Update up to the user for now.
otoh, a lot of science people want double floats and 64 bit words, but look at the big boys, nvidia. it may bite them in the @#$@# someday, but for now they're sticking to a strong party line: 32bit floating point is sufficient. this works alright for video cards & games, since 4 channels of 32bit fp is an 128bit fp buffer. thats large, but still not entirely that accurate. i'd like to see a time when even game worlds are so massive they straight up require 64bit fp. i'd like to see nvidia release consumer cards with 64bit float performance sometime soon, but i dont think the odds of that happening are very big: its new technology with only a couple scientifc users making any use of it. just as it took the boys at Epic, Sweeny & CliffyB both stating the xbox needed more video ram, without vocal powreful demand we probably wont see it for a while.
hopefully we'll be doing more distributed dispatching with gpus in the future. 64 bit ints are going to be required there.
lordmyren
by 2012 -- the end of time
cos I always want to have that extra bit from my machines.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
All the new processors from AMD and Intel (and IBM, for that matter) are 64-bit. Therefore, if you get a new PC, you have no choice but to get a 64-bit processor in it. And since they're all backwards-compatible to 32-bit, there's no downside.
The only relevant issue here is whether you want to run 64-bit or 32-bit software on it.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
I just bought a Core 2 Duo board and processor. I immediately installed the native 64-bit Gentoo on it, but after two months, I decided to go back to running the x86 distribution. I've been using Linux since 1998, and Gentoo on x86 and PowerPC since before 1.4, and I wasn't very happy with amd64.
I'm a desktop user with 2GB RAM, the server is a PowerPC with 1.5GB RAM. I've never seen a system munch memory like this box when it was running 64-bit Linux. Running all those compatability libraries (for Firefox, OpenOffice, and several other apps) seemed to eat a ton of RAM.
Until every app and plugin I use is 64-bit native, I think I'll stay with 32-bit operating systems.
As for 64-bit hardware, you really don't have much choice if you want to buy new hardware. There's no reason NOT to buy 64-bit processors these days, you get the best bang for your buck with AMD64 or EMT64 CPUs. 32-bit operating systems benefit from the new processors almost as much as 64-bit systems do, so go ahead and 'go 32 on 64' if you want a modern computer.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
Your processing power won't improve at all by switching to x64. The only improvement is that you will be able to address more RAM and HD space, nothing else.
In fact, you will even lose out - 64 bit systems waste more memory than 32 bit systems. That's primarily because the 32-bit structures take up 64 bits on 64 bit system, while not carrying any more data. And all the pointers are suddenly 64 bit in length, etc.
In other words, it's worth switching only if you have and plan to use a reasonably larger amount of RAM/HD space than the 32 bit max limit. (in other words, if you want to switch to use 5gb, i'd recommend sticking with 32 bit system, but for 6gb or 8gb the pros start outweighing the cons)
Did you know that "FTW" ("for the win") is a direct translation of "Sieg Heil"?
Most programs run at about the same speed, but some programs gain a lot from running in 64 bit mode.
One example is that bit-board chess engines, including the current top engine Rybka, are much faster. Non bit-board engines gain little or are slower (The extra registers! They do nothing! Or at least not enough to do more than make up for the code bloat).
Large number arithmetic (e.g. encryption) gains even more because one 64 bit multiply does more that twice the work of a 32 bit multiply.
a,e,i,o,u and sometimes w and y (at be if of up cwm by)
I can't speak for x86-64 because I've never seen it, but I've played around with 64-bit PowerPC, and that's really not true. Or not necessarily, anyway. Note that in 64-bit PowerPC, there are no "modes"; all registers are 64 bits in width. However, that doesn't stop 32-bit code from running unmodified.
Basically what it comes down to is: it's not the size of your register; it's the size of your load/store. Having 64-bit registers doesn't stop you from doing a "store word" (32-bit store). It would even be somewhat natural to have 48-bit pointers if you wanted. What defines the size of data in your data structures is what conventions you (as an assembly programmer) decide for your loads and stores. As a C programmer, of course, it then comes down to your compiler implementation. On OS X, anyway, the convention is to use 32-bit pointers in 64-bit code.
So it's misleading to say everything is 64 bits in size. You get to play around with 64 bits when it's in your register, but that doesn't dictate how much memory you'll consume.
Perhaps a more interesting question would be whether the Windows-users in the Slashdot community plan to run 64-bit Vista, considering its enhanced security (PatchGuard et al.) as well as its enhanced possibilities of restricting you from doing things on your own computer.
/. community's resident Windows user and he is refusing to come out his closet unless you will personally guarantee that the hoard of torch and pitchfork wielding penguins outside won't tar and fether him.
I spoke to the
Only to idiots, are orders laws.
-- Henning von Tresckow
XP 64 is a workstation OS (and has always been marketed that way by Microsoft, FYI). Unless you're doing heavy stuff, or your hardware loves it (i.e Dual Opterons with NUMA), stay out. You can chuck all your older hardware while you're at it too. Personally I haven't had any real problems with it, apart from it being a massive I/O hog.
XP 64 is based on the WinServer 2003 x64 base, and IMO, Server 2003 x64 makes a better 64 bit workstation OS. I guess M$ frucked up big time when adding all the consumer end stuff to it. Pity 2003 x64 doesn't have the full multimedia support that its 32 bit version does.
Add me to the tally of folks running 64 bit Linux. For most purposes, the performance boost is unnoticable. However, I do get a few more FPS when transcoding video and I've noticed no other difficulties compared to 32bit Ubuntu. As others, I run 32 bit Firefox, but this is a breeze to install via automatix. About the only things that don't work for me are Google Earth and RealPlayer. I haven't bothered to look for others having similar troubles with Google Earth (app loads just fine, but imagery is all scrambled) and I don't care that much that RealPlayer barely runs (skips, audio out of sync, hangs inexplicably . . . but it did that on 32bits too).
As far as general day to day use goes, if you've got a 64 bit proc w/ a 32 bit OS, it's probably not worth the hassle to reinstall 64 bit builds. If you're starting over from scratch anyway, you might want to give it a shot.
Yes, but if he doesn't need an upgrade, then it is much cheaper to not buy any hardware at all. ;-)
*Rushes out to get a 64-bit processor, to be able to play games with bit-board chess AI faster!*
// MD_Update(&m,buf,j);