4 ms·
> the end of 32 bit computing. By itself hardly a bold prediction, but the top reply makes a caveat about mobile devices, which gets some nods about mobile tak
by mortenjorck 7y ago
> the end of 32 bit computing.
By itself hardly a bold prediction, but the top reply makes a caveat about mobile devices, which gets some nods about mobile taking much longer to transition to 64-bit.
Few might have imagined Apple would ship its first 64-bit phone only three years later, and a version of iOS before the decade was over that ended support for 32-bit phones!
- rsynnott 7y ago32bit died on phones much quicker than on the desktop, in fact (though of course it died on servers first). Arguably, this should have been predictable; legacy software was a much smaller problem on phones.
- jlokier 7y agoI find that a little surprising, because one of the side effects of 64-bit address spaces is a lot of redundancy in pointer representations stored in RAM. 64-bit pointer-based data structures have more redundant zeros. Much of the energy in a computer goes on communication between chips, so increased memory use means increased energy use. As well as more going on inside the CPU transferring all those redundant pointer bits around And phones are notably sensitive to energy use.
- zozbot234 7y agoYou don't have to use full 64-bit pointers for your "pointer-based data structures". You can store indexes into an arena allocation. This is common in languages such as C++ and Rust, and will become increasingly so as 32-bit is less and less used.
- rsynnott 7y agoI believe ObjC and Swift on 64bit machines use the upper section of the pointers to store reference counts. I'd guess that Android Java uses pointer compression like normal Java does, though I don't know for certain. The 64bit transition on ARM also allowed an arch overhaul, with extra registers etc. ARMv8 cores were usually a good bit faster than their immediate predecessors, but it wasn't much to do with 64bitness. This also happened with x86, of course.