4 ms·

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 ev

by 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.

by byuu 14y ago

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.