5 ms·

The big question is, why won't 64 bit catch on? Too new? I had a 64 bit chip 10 years ago and most of you probably did too. Too expensive? It's a good question

The big question is, why won't 64 bit catch on? Too new? I had a 64 bit chip 10 years ago and most of you probably did too. Too expensive? It's a good question and it probably comes down to programmers and habit. Multi core processing and async/multithreading are finally starting to take hold but optimizing for a 64 bit bus still seems like an afterthought. I am asking seriously because I don't have a definitive answer, but why is it just not catching on?

byuu 14y ago
Never underestimate human apathy. A super majority of the world does not care for progress, if it means having to change even the most nominal of habits. Not even for sometimes massive benefits. In fact, a great many individuals will become extremely vocal if you try and force something as tiny as "picking one file extension for a file type instead of using two like we have in the past." The only way things advance are when walls are finally hit. With 16-bit, this was trivial: the limitations were crippling. It'll get there with 32-bit, as applications begin to crash with the ~2GB per process memory limitations on Windows, and PCs continually appear with far more than 8GB of RAM available. But I'd say we are probably 5-10 years off from a point where we could consider deploying a 64-bit only application without losing users.
- bad_user 14y ago
  I do not agree with your pessimistic argument regarding human nature. A much bigger issue is that migrating a massive 32-bits application to 64-bits requires too much effort, because unfortunately the C and C++ specifications have left a ton of flexibility and room for platform-specific behavior. For instance it's beyond me why those specs haven't mentioned details like concrete sizes for really basic datatypes, like Ints and Chars, especially since development in C and C++ tends to get into really low-level details and optimizations, which means you end up relying on Ints being 4 bytes in size (how could you not do that?). The truth really is that even seemingly unimportant details such as the size of Ints can mean the difference between a rock-solid 32-bits app and a 64-bits app that's broken almost beyond hope of ever being fixed. If anything, this should be the number one reason for why we must stop using C and C++ for new application developments and even in systems/embedded programming we could do a lot better, as these languages are unsuitable for continued improvements due to Moore's law, impeding progress. Can you see how this creates a vicious circle btw? So we can have affordable consumer workstations with more than 10 GB of RAM right now with multiple cores and all that, which makes client-side development in garbage-collected functional programming languages feasible, but we can't really go there because the 32-bits legacy is holding us back. That's funny and goes to show that sometimes Worse is Not Better.
  - keeperofdakeys 14y ago
    It isn't about human apathy, it's about not fixing what isn't broken. You sometimes come across stories of a windows 3.1 machine controlling a critical piece of machinery for a business. As for C and C++, the bugs that prevent a program going from 32-bit to 64-bit is making assumptions about the sizes of datatypes, and these days is usually seen as bad programming. They are just tools though, and have their uses, even in a multi-threaded world.
    - bad_user 14y ago
      > these days is usually seen as bad programming I've seen this repeatedly told again and again, however people saying that don't really know what they are talking about - it's extremely easy to make assumptions without even realizing you're making one, even if you could recite the whole spec of C and C++. Even more, in C and C++ it is inevitable to make assumptions, even with eternal vigilance. I want you to point to a single reasonably big application that doesn't make such assumptions. And please don't point to one that works on both 32-bits and 64-bits, as in those cases the assumption about Ints simply evolved to: either 4 bytes or 8 bytes, with some awful code out in the wild that only works because of conditional compilation ... sometimes I wonder how software I rely upon works at all.
      - keeperofdakeys 14y ago
        Well the biggest thing you need to do is not use ints to store pointers, and use things like size_t, etc. This accounts for the majority of C programming bugs when moving from 32 bits to 64 bits. As for making assumptions, this is only natural, and programmers should be aware of the basic differences so they can correct their assumptions.
- gurkendoktor 14y ago
  What you say is often true. Take Windows XP vs Windows 7; Windows 7 is miles ahead in the security department, that should be a killer reason for people to upgrade. Or IPv4 vs IPV6 for obvious reasons. But 64-bit has none of these big advantages in practice. Battery life on OS X was worse right after the switch.[1] I have downloaded Podcasts a year before iTunes ran in 64-bit mode and they stopped working with the switch (nothing obscure - early Railscasts episodes). Many perfectly fine machines have been marked obsolete by Apple because their processors or graphics drivers weren't 64bit. - Windows has been a mess for me too: the 64-bit ODBC control panel is in system32 and the 32-bit ODBC control panel is in WoW64.[2] Because there are no fat binaries, casual users suddenly need to know which version of a Windows program to download. - So there is a lot of friction that needs to be outweighed. For what? - If Firefox wants to escape the 2GB barrier, the wiser choice might be to use one process per tab, as other browsers do. If you look at the first and last sentence of your posting, you are basically accusing people of apathy because they keep using their 32-bit computers. [1] http://forums.appleinsider.com/t/104687/64-bit-safari-reduces-battery-life-by-45 http://forums.appleinsider.com/t/104687/64-bit-safari-reduce... (might also be caused by API changes that Apple has tied to the 64-bit platform) [2] http://robertoschiabel.wordpress.com/2008/02/28/windows-x64-32bit-odbc-vs-64bit-odbc/ http://robertoschiabel.wordpress.com/2008/02/28/windows-x64-...
  - byuu 14y ago
    64-bit binaries net me a 15% performance increase with my application. Obviously it can vary per application, and depends on where the bottlenecks are. It's been my experience that x86->amd64 is often beneficial: the x86 is so register starved that it makes up for the larger pointers, and most of the latter is mitigated through 32-bit relative instructions. Now PowerPC, sure. 32-bit PPC code does tend to run faster than 64-bit from my experience. The other advantage is being able to utilize more than 2GB of memory per process. The reason to favor pure 64-bit is to get rid of all that extra 32-bit compatibility code. WoW64, in this case, or ia32libs on Linux. Whether you're pragmatic about it or not, 32-bit will eventually go away. I'd prefer to see it sooner rather than for it to drag on for decades like IPv6. And yeah, WoW64 is a clusterfuck. Basically, Microsoft wanted to make porting 32-bit applications as easy as possible. Since some applications may have been hardcoded to System32, they stuck the 64-bit libraries there, and put the 32-bit ones in WoW64. They also cloned the registry so you actually have 32-bit and 64-bit keys (see KEY_WOW64_32KEY flag.) What can I say? Microsoft's always had a thing for rigid backward compatibility at the expense of common sense design. But they are still the market leader, so I guess they know a thing or two :/ I don't care for your Firefox example. What if one single tab needs >2GB, like say a really high-end WebGL game? What about other applications? People found similar tricks for getting more memory in 16-bit processes too (far pointers), but we aren't still using Win16. I'm accusing people of apathy because they resist change simply because it's change. I get being pragmatic, but at some point we have to cut ties with the past. Even Microsoft understands this, as you can no longer run 16-bit applications on the latest versions of Windows.
daeken 14y ago
> I had a 64 bit chip 10 years ago and most of you probably did too. Intel didn't put out an x86-64 chip until 2004, and their first desktop chip wasn't until early 2005 (IIRC). AMD's first 64-bit chip (Opteron) wasn't until 2003. Neither of these were mass market for quite a few years; it wasn't until 2006 that you really started seeing them in mass-market desktops. Now, there were exceptions of course, most notably the iMac and PowerMac G5, but 64-bit machines really weren't in the hands of general users until 2006-2007.
- rplnt 14y ago
  Athlon64, released in 2003, was quite popular. In the middle of the 2004 most of the AMD desktop processors (athlon, sempron) were 64-bit. So it wasn't "quite a few years" exactly. Only netbooks brought 32bit back to life somehow.
- JeremyMorgan 14y ago
  Now that I think about it, rplnt is right it was late 2003 I got an athlon64, so 9 years.
twoodfin 14y ago
This sounds like a chicken-and-egg problem somewhat specific to Mozilla. Their users depend on a large stable of independently developed plugins, which must be updated to support a 64-bit Windows browser. I can imagine that many of those plugin developers are much less motivated to do the requisite porting (or fix 64-bit bugs after they port) before Mozilla ships (or even commits to shipping) a 64-bit Windows browser. But when plugins used by 80%+ of your userbase are nonexistent or buggy, releasing a browser becomes difficult: Everyday users will assume it's buggy because they don't make the distinction between plugin authors and Mozilla.
- atesti 14y ago
  Why can't Firefox's plugincontainer marshall the calls between 32bit and 64bit?
CJefferson 14y ago
While having a 64-bit OS is useful, the majority of apps I work on never use anywhere near 4GB. Firefox has distributed 64-bit builds, so it is not the case that they aren't willing to put the work in. However, there turns out to be basically no advantage to running a 64-bit web browser.
- gryph0n 14y ago
  If you're a heavy browser user, or if you simply never close your browser, you'll frequently run into the scenario where 32 bit Firefox reaches the 2GB virtual memory limit, whereupon it gets killed. Yep, it's 2GB, atleast on 32bit OS (I'm on Win 7 32bit). Just the convenience factor of not having to restart my browser frequently is enough to make me want to embrace x64. My blocker is that my corporate IT policy is to have 32 bit OS.
Chris_Newton 14y ago
The big question is, why won't 64 bit catch on? I suppose the obvious response is “Why should it?” It makes a lot of sense to have a 64-bit operating system if we have, for example, more than 4GB of memory to work with. However, unless a single process needs access to the same scale of resources all on its own, there isn’t necessarily any advantage to writing things like application code the same way. Moreover, moving to 64-bit pointers means more memory is required for data structures and for assembly level instructions that use indirection. In both cases, there is the potential for a significant performance hit, for example if less information fits into a cache. OK, what about using 64-bit instructions that let us calculate with larger values? Again, that might be useful in some contexts, but on PC processors we’ve had specialist instructions for things like double-precision floating point calculations or operating over multiple bundled values simultaneously for a long time, so there are only limited benefits to be had. Of course, set against all of these ambiguous benefits is the fact that porting to 64-bit can take a lot of work if the original code, data structures, file formats and so on were not designed with portability in mind. And once you’ve ported, if you’re also running a 32-bit version, now you have more testing to do, any related software might have to speak two protocols/APIs to remain compatible with both, etc. (This seems to be one of the main underlying points in the cited article.) Looking at the astronomical memory requirements for something like browsers opening multiple tabs these days, perhaps in the case of Firefox there really is an argument for supporting more than 4GB of RAM. On the other hand, even modern web pages full of large images and multimedia wizardry usually only come in at ~100kB or maybe ~1MB, so even with dozens of tabs open, you need to be doing an awful lot behind the scenes to be in any danger of hitting a 4GB limit. Presumably the Mozilla folks don’t expect this to be a problem.
- beatgammit 14y ago
  What about WebGL? It's catching on, and that means that we could see huge memory usage in a small number of tabs. I'm thinking we'll see 3d games become popular relatively quickly. Gamers tend to have tons of tabs in their browsers. Couple this with tons of game resources and we have a serious memory hog.

byuu 14y ago

Never underestimate human apathy. A super majority of the world does not care for progress, if it means having to change even the most nominal of habits. Not even for sometimes massive benefits. In fact, a great many individuals will become extremely vocal if you try and force something as tiny as "picking one file extension for a file type instead of using two like we have in the past." The only way things advance are when walls are finally hit. With 16-bit, this was trivial: the limitations were crippling. It'll get there with 32-bit, as applications begin to crash with the ~2GB per process memory limitations on Windows, and PCs continually appear with far more than 8GB of RAM available. But I'd say we are probably 5-10 years off from a point where we could consider deploying a 64-bit only application without losing users.

bad_user 14y ago
I do not agree with your pessimistic argument regarding human nature. A much bigger issue is that migrating a massive 32-bits application to 64-bits requires too much effort, because unfortunately the C and C++ specifications have left a ton of flexibility and room for platform-specific behavior. For instance it's beyond me why those specs haven't mentioned details like concrete sizes for really basic datatypes, like Ints and Chars, especially since development in C and C++ tends to get into really low-level details and optimizations, which means you end up relying on Ints being 4 bytes in size (how could you not do that?). The truth really is that even seemingly unimportant details such as the size of Ints can mean the difference between a rock-solid 32-bits app and a 64-bits app that's broken almost beyond hope of ever being fixed. If anything, this should be the number one reason for why we must stop using C and C++ for new application developments and even in systems/embedded programming we could do a lot better, as these languages are unsuitable for continued improvements due to Moore's law, impeding progress. Can you see how this creates a vicious circle btw? So we can have affordable consumer workstations with more than 10 GB of RAM right now with multiple cores and all that, which makes client-side development in garbage-collected functional programming languages feasible, but we can't really go there because the 32-bits legacy is holding us back. That's funny and goes to show that sometimes Worse is Not Better.
- keeperofdakeys 14y ago
  It isn't about human apathy, it's about not fixing what isn't broken. You sometimes come across stories of a windows 3.1 machine controlling a critical piece of machinery for a business. As for C and C++, the bugs that prevent a program going from 32-bit to 64-bit is making assumptions about the sizes of datatypes, and these days is usually seen as bad programming. They are just tools though, and have their uses, even in a multi-threaded world.
  - bad_user 14y ago
    > these days is usually seen as bad programming I've seen this repeatedly told again and again, however people saying that don't really know what they are talking about - it's extremely easy to make assumptions without even realizing you're making one, even if you could recite the whole spec of C and C++. Even more, in C and C++ it is inevitable to make assumptions, even with eternal vigilance. I want you to point to a single reasonably big application that doesn't make such assumptions. And please don't point to one that works on both 32-bits and 64-bits, as in those cases the assumption about Ints simply evolved to: either 4 bytes or 8 bytes, with some awful code out in the wild that only works because of conditional compilation ... sometimes I wonder how software I rely upon works at all.
    - keeperofdakeys 14y ago
      Well the biggest thing you need to do is not use ints to store pointers, and use things like size_t, etc. This accounts for the majority of C programming bugs when moving from 32 bits to 64 bits. As for making assumptions, this is only natural, and programmers should be aware of the basic differences so they can correct their assumptions.
gurkendoktor 14y ago
What you say is often true. Take Windows XP vs Windows 7; Windows 7 is miles ahead in the security department, that should be a killer reason for people to upgrade. Or IPv4 vs IPV6 for obvious reasons. But 64-bit has none of these big advantages in practice. Battery life on OS X was worse right after the switch.[1] I have downloaded Podcasts a year before iTunes ran in 64-bit mode and they stopped working with the switch (nothing obscure - early Railscasts episodes). Many perfectly fine machines have been marked obsolete by Apple because their processors or graphics drivers weren't 64bit. - Windows has been a mess for me too: the 64-bit ODBC control panel is in system32 and the 32-bit ODBC control panel is in WoW64.[2] Because there are no fat binaries, casual users suddenly need to know which version of a Windows program to download. - So there is a lot of friction that needs to be outweighed. For what? - If Firefox wants to escape the 2GB barrier, the wiser choice might be to use one process per tab, as other browsers do. If you look at the first and last sentence of your posting, you are basically accusing people of apathy because they keep using their 32-bit computers. [1] http://forums.appleinsider.com/t/104687/64-bit-safari-reduces-battery-life-by-45 http://forums.appleinsider.com/t/104687/64-bit-safari-reduce... (might also be caused by API changes that Apple has tied to the 64-bit platform) [2] http://robertoschiabel.wordpress.com/2008/02/28/windows-x64-32bit-odbc-vs-64bit-odbc/ http://robertoschiabel.wordpress.com/2008/02/28/windows-x64-...
- byuu 14y ago
  64-bit binaries net me a 15% performance increase with my application. Obviously it can vary per application, and depends on where the bottlenecks are. It's been my experience that x86->amd64 is often beneficial: the x86 is so register starved that it makes up for the larger pointers, and most of the latter is mitigated through 32-bit relative instructions. Now PowerPC, sure. 32-bit PPC code does tend to run faster than 64-bit from my experience. The other advantage is being able to utilize more than 2GB of memory per process. The reason to favor pure 64-bit is to get rid of all that extra 32-bit compatibility code. WoW64, in this case, or ia32libs on Linux. Whether you're pragmatic about it or not, 32-bit will eventually go away. I'd prefer to see it sooner rather than for it to drag on for decades like IPv6. And yeah, WoW64 is a clusterfuck. Basically, Microsoft wanted to make porting 32-bit applications as easy as possible. Since some applications may have been hardcoded to System32, they stuck the 64-bit libraries there, and put the 32-bit ones in WoW64. They also cloned the registry so you actually have 32-bit and 64-bit keys (see KEY_WOW64_32KEY flag.) What can I say? Microsoft's always had a thing for rigid backward compatibility at the expense of common sense design. But they are still the market leader, so I guess they know a thing or two :/ I don't care for your Firefox example. What if one single tab needs >2GB, like say a really high-end WebGL game? What about other applications? People found similar tricks for getting more memory in 16-bit processes too (far pointers), but we aren't still using Win16. I'm accusing people of apathy because they resist change simply because it's change. I get being pragmatic, but at some point we have to cut ties with the past. Even Microsoft understands this, as you can no longer run 16-bit applications on the latest versions of Windows.

daeken 14y ago

> I had a 64 bit chip 10 years ago and most of you probably did too. Intel didn't put out an x86-64 chip until 2004, and their first desktop chip wasn't until early 2005 (IIRC). AMD's first 64-bit chip (Opteron) wasn't until 2003. Neither of these were mass market for quite a few years; it wasn't until 2006 that you really started seeing them in mass-market desktops. Now, there were exceptions of course, most notably the iMac and PowerMac G5, but 64-bit machines really weren't in the hands of general users until 2006-2007.

rplnt 14y ago
Athlon64, released in 2003, was quite popular. In the middle of the 2004 most of the AMD desktop processors (athlon, sempron) were 64-bit. So it wasn't "quite a few years" exactly. Only netbooks brought 32bit back to life somehow.
JeremyMorgan 14y ago
Now that I think about it, rplnt is right it was late 2003 I got an athlon64, so 9 years.

twoodfin 14y ago

This sounds like a chicken-and-egg problem somewhat specific to Mozilla. Their users depend on a large stable of independently developed plugins, which must be updated to support a 64-bit Windows browser. I can imagine that many of those plugin developers are much less motivated to do the requisite porting (or fix 64-bit bugs after they port) before Mozilla ships (or even commits to shipping) a 64-bit Windows browser. But when plugins used by 80%+ of your userbase are nonexistent or buggy, releasing a browser becomes difficult: Everyday users will assume it's buggy because they don't make the distinction between plugin authors and Mozilla.

atesti 14y ago
Why can't Firefox's plugincontainer marshall the calls between 32bit and 64bit?

CJefferson 14y ago

While having a 64-bit OS is useful, the majority of apps I work on never use anywhere near 4GB. Firefox has distributed 64-bit builds, so it is not the case that they aren't willing to put the work in. However, there turns out to be basically no advantage to running a 64-bit web browser.

gryph0n 14y ago
If you're a heavy browser user, or if you simply never close your browser, you'll frequently run into the scenario where 32 bit Firefox reaches the 2GB virtual memory limit, whereupon it gets killed. Yep, it's 2GB, atleast on 32bit OS (I'm on Win 7 32bit). Just the convenience factor of not having to restart my browser frequently is enough to make me want to embrace x64. My blocker is that my corporate IT policy is to have 32 bit OS.

Chris_Newton 14y ago

The big question is, why won't 64 bit catch on? I suppose the obvious response is “Why should it?” It makes a lot of sense to have a 64-bit operating system if we have, for example, more than 4GB of memory to work with. However, unless a single process needs access to the same scale of resources all on its own, there isn’t necessarily any advantage to writing things like application code the same way. Moreover, moving to 64-bit pointers means more memory is required for data structures and for assembly level instructions that use indirection. In both cases, there is the potential for a significant performance hit, for example if less information fits into a cache. OK, what about using 64-bit instructions that let us calculate with larger values? Again, that might be useful in some contexts, but on PC processors we’ve had specialist instructions for things like double-precision floating point calculations or operating over multiple bundled values simultaneously for a long time, so there are only limited benefits to be had. Of course, set against all of these ambiguous benefits is the fact that porting to 64-bit can take a lot of work if the original code, data structures, file formats and so on were not designed with portability in mind. And once you’ve ported, if you’re also running a 32-bit version, now you have more testing to do, any related software might have to speak two protocols/APIs to remain compatible with both, etc. (This seems to be one of the main underlying points in the cited article.) Looking at the astronomical memory requirements for something like browsers opening multiple tabs these days, perhaps in the case of Firefox there really is an argument for supporting more than 4GB of RAM. On the other hand, even modern web pages full of large images and multimedia wizardry usually only come in at ~100kB or maybe ~1MB, so even with dozens of tabs open, you need to be doing an awful lot behind the scenes to be in any danger of hitting a 4GB limit. Presumably the Mozilla folks don’t expect this to be a problem.

beatgammit 14y ago
What about WebGL? It's catching on, and that means that we could see huge memory usage in a small number of tabs. I'm thinking we'll see 3d games become popular relatively quickly. Gamers tend to have tons of tabs in their browsers. Couple this with tons of game resources and we have a serious memory hog.