Many commentors are subscribing to the "more is better" school of thought without understanding the deeper realities.
Depending upon the application, a 64-bit platform can be *slower* than a 32-bit platform. The reason? More memory is being fetched. If you have a tight loop of memory dereferences, for instance, you may find that, on average, twice as much data needs to be moved to accomplish the same task. So, all else being equal (which is a pretty big caveat), in this case a 64-bit platform would perform more slowly than a 32-bit platform.
How do I know this? Simple. I worked on Visual Studio for the AMD64 several years ago. We saw consistent results with benchmarks (and for the skeptical, we also benchmarked gcc and Intel's compiler, so it wasn't just VS) for some algorithms where the performance bar was simply to *equal* the performance of the 32-bit platform. Not to exceed it or to beat it by a factor of 10000 (come on, people, have some realistic expectations!). Just to EQUAL the performance of 32 bits was a goal for some cases.
This is a basic fact of optimization: you cannot wave a magic wand over benchmarks. There's no "64-bit pixie dust" (just like there's no magic Linux pixie dust, or Mac pixie dust, or even PIC pixie dust or gcc pixie dust...). Optimization is a careful science, and quite often you have to trade a loss in one are for gains in another. As an optimizer, you have to focus not just on the best speeds, but on *what's a likely use-case* (this is why profile-guided optimization is such a big deal; it automatically takes usage data into account).
In reality, the primary gains of a 64-bit addressing bus are -- 64 bits of addressing. No surprises there. That means that more memory can be accessed. That means that instead of 4gb of RAM, ... lots can be accessed. For giant mega-servers this is great, but for the average user? When have you EVER used more than 4gb of RAM (or even the low-order 2gb imposed in Windows) for your word processing, or your game? Some high-end rendering and photo manipulation, maybe. But for normal daily tasks and gaming? Pshaw.
The other benefit of "64 bits" is that quite often you can improve floating point performance. Most multimedia-intensive tasks (think: gaming) perform at least 64-bit (if not 128-bit) floating point math. With wider registers comes fewer fetches and stores -- and that ALWAYS improves performance. But how much? That depends -- it all depends on how well written or ported the floating point code is. Some of the AMD fp code is very, very good, and some of it, frankly, sucks (when I left the VS team, parallelization was really crappy, but that's probably been fixed; it's been years). So in theory, you should be able to get better FP perf with wider FP registers, but how much? I think maybe a 20% gain would be reasonable to expect. Is that worth the cost and possible slowdown in other areas? Hmm.
The reality is simple: the average user simply has no use for this right now. Maybe in a year or three, when the drivers have matured, the cost of RAM has come down even more, and the FP picture is stabilized, maybe then I'll look at 64-bit platforms again. But right now, there's simply no killer app for people who aren't either running huge data farms or rendering feature-length movies.
When you say you were using a 64 bit Processor several years ago, theres some things that are unclear. 1. Were you using in in 64 bit mode ( ok, its probably a silly question, but you'd be surprised how many smart people fail to check the obvious "is it plugged in" problem ) 2. Were you using Windows or Linux to test the resultant product ( i presume windows, right? ) 3. In either case, were you using an Operating System developed FOR a 64 Bit Processor?, as I thought 64Bit XP was a realatively new concept.
I'm sorry, but i'm little confused by what you mean 64-bit means "More memory is being fetched". Please clarify this since I thought it means 64-bit address width per fetch. It's basically the same as 32-bit but it's wider, it doesn't mean you will fetch twice right?
on Fedora core. In that time, I've found that while it is faster for certain things (rendering), there are plenty of problems as well. Like, for example, most apps are still compiled and distributed for the 32 bit architecture. So, if you want native 64 bit apps, you have to compile them for yourself (like Mozilla, Firefox or Thunderbird). Worse, Macromedia simply will not create a 64 bit version of Flash. They just simply ignore this segment of the world.
... is best its worth with 64-bit software. Like 32-bit hardware booming with the boom of 32-bit software, 64-bit hardware is just waiting for the 64-bit software to boom.
Manage updates with the Download App
Depending upon the application, a 64-bit platform can be *slower* than a 32-bit platform. The reason? More memory is being fetched. If you have a tight loop of memory dereferences, for instance, you may find that, on average, twice as much data needs to be moved to accomplish the same task. So, all else being equal (which is a pretty big caveat), in this case a 64-bit platform would perform more slowly than a 32-bit platform.
How do I know this? Simple. I worked on Visual Studio for the AMD64 several years ago. We saw consistent results with benchmarks (and for the skeptical, we also benchmarked gcc and Intel's compiler, so it wasn't just VS) for some algorithms where the performance bar was simply to *equal* the performance of the 32-bit platform. Not to exceed it or to beat it by a factor of 10000 (come on, people, have some realistic expectations!). Just to EQUAL the performance of 32 bits was a goal for some cases.
This is a basic fact of optimization: you cannot wave a magic wand over benchmarks. There's no "64-bit pixie dust" (just like there's no magic Linux pixie dust, or Mac pixie dust, or even PIC pixie dust or gcc pixie dust...). Optimization is a careful science, and quite often you have to trade a loss in one are for gains in another. As an optimizer, you have to focus not just on the best speeds, but on *what's a likely use-case* (this is why profile-guided optimization is such a big deal; it automatically takes usage data into account).
In reality, the primary gains of a 64-bit addressing bus are -- 64 bits of addressing. No surprises there. That means that more memory can be accessed. That means that instead of 4gb of RAM, ... lots can be accessed. For giant mega-servers this is great, but for the average user? When have you EVER used more than 4gb of RAM (or even the low-order 2gb imposed in Windows) for your word processing, or your game? Some high-end rendering and photo manipulation, maybe. But for normal daily tasks and gaming? Pshaw.
The other benefit of "64 bits" is that quite often you can improve floating point performance. Most multimedia-intensive tasks (think: gaming) perform at least 64-bit (if not 128-bit) floating point math. With wider registers comes fewer fetches and stores -- and that ALWAYS improves performance. But how much? That depends -- it all depends on how well written or ported the floating point code is. Some of the AMD fp code is very, very good, and some of it, frankly, sucks (when I left the VS team, parallelization was really crappy, but that's probably been fixed; it's been years). So in theory, you should be able to get better FP perf with wider FP registers, but how much? I think maybe a 20% gain would be reasonable to expect. Is that worth the cost and possible slowdown in other areas? Hmm.
The reality is simple: the average user simply has no use for this right now. Maybe in a year or three, when the drivers have matured, the cost of RAM has come down even more, and the FP picture is stabilized, maybe then I'll look at 64-bit platforms again. But right now, there's simply no killer app for people who aren't either running huge data farms or rendering feature-length movies.
1. Were you using in in 64 bit mode ( ok, its probably a silly question, but you'd be surprised how many smart people fail to check the obvious "is it plugged in" problem )
2. Were you using Windows or Linux to test the resultant product ( i presume windows, right? )
3. In either case, were you using an Operating System developed FOR a 64 Bit Processor?, as I thought 64Bit XP was a realatively new concept.