5 ms·

Except that 64 bits is still nothing but a marketing gimmick as far as the memory sizes in smart phones is concerned. All those companies are panicking, not be

Except that 64 bits is still nothing but a marketing gimmick as far as the memory sizes in smart phones is concerned. All those companies are panicking, not because they are being left behind technologically, but they are being left behind in the buzzword war.

AlexanderDhoore 13y ago
"The "64-bit" A7 is not just a marketing gimmic, but neither is it an amazing breakthrough that enables a new class of applications. The truth, as happens often, lies in between. The simple fact of moving to 64-bit does little. It makes for slightly faster computations in some cases, somewhat higher memory usage for most programs, and makes certain programming techniques more viable. Overall, it's not hugely significant. The ARM architecture changed a bunch of other things in its transition to 64-bit. An increased number of registers and a revised, streamlined instruction set make for a nice performance gain over 32-bit ARM. Apple took advantage of the transition to make some changes of their own. The biggest change is an inline retain count, which eliminates the need to perform a costly hash table lookup for retain and release operations in the common case. Since those operations are so common in most Objective-C code, this is a big win. Per-object resource cleanup flags make object deallocation quite a bit faster in certain cases. All in all, the cost of creating and destroying an object is roughly cut in half. Tagged pointers also make for a nice performance win as well as reduced memory use." [1] https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-an...
- makomk 13y ago
  So basically, it's only really a substantial performance win because of a quirk of how Apple's 32-bit code was written, a quirk that doesn't apply to competing platforms.
  - chaostheory 13y ago
    It will apply to competing platforms in about two years, when the first set of devices with 4 GB or more RAM start appearing.
  - acdha 13y ago
    If you look at the history of desktop/server operating systems, it followed the same pattern as clearly explained in the article: problems start before 4GB and affect programming decisions as soon as users start working with files which aren't trivially small. Once 64-bit became the default, many small optimizations or larger design changes became easy enough that they actually happened and produced small but meaningful improvements
  - wklauss 13y ago
    This specific case might only apply to Apple (I don't know, haven't read about it before) but the quirks of ARM's 32-bit instruction set surely apply to everyone else. The transition could have happen later, maybe, with not too much repercussion, but why not make the jump now, especially when you have a whole new OS engineered to take advantage of it?
deleted 13y ago
[deleted]
kubiiii 13y ago
Its been the same since the atari jaguar (didnt work for it though).
colanderman 13y ago
64 bits … memory sizes Processor word width has absolutely nothing to do with memory size. e.g. 8-bit processors regularly interface with 16-bit-wide memory buses, and 64-bit processors often allow use of 32-bit-wide pointers. What the word width does affect is how much data can be processed by each instruction. Certain algorithms benefit immensely from this (you can easily double throughput), but the code needs to be written to take advantage of this (or at least, not to squander the advantage), and needs to be compiled to use 64-bit-wide registers.
- deleted 13y ago
  [deleted]
  - plorkyeran 13y ago
    32-bit Windows Server 2003 supports up to 64 GB (although SQL Server is probably the only application which can actually do anything useful with that).
  - colanderman 13y ago
    By that logic, 8-bit computers would only access 256 bytes of memory (which is definitely not true). On processors where the hardware word size is less than the useful size of memory, there generally is another means of extending the addressing range (either per-page bank addressing, or special pointer registers).
- pmelendez 13y ago
  > "Processor word width has absolutely nothing to do with memory size." Huh? How would you address high positions on your 8Gb memory with a 32 bits pointer that will overflow after 4Gb?
  - plorkyeran 13y ago
    You don't have to have all of your memory mapped into your address space at once.
  - colanderman 13y ago
terhechte 13y ago
Right.. "Adding it all together, it’s a pretty big win. My casual benchmarking indicates that basic object creation and destruction takes about 380ns on a 5S running in 32-bit mode, while it’s only about 200ns when running in 64-bit mode. If any instance of the class has ever had a weak reference and an associated object set, the 32-bit time rises to about 480ns, while the 64-bit time remains around 200ns for any instances that were not themselves the target. In short, the improvements to Apple’s runtime make it so that object allocation in 64-bit mode costs only 40-50% of what it does in 32-bit mode. If your app creates and destroys a lot of objects, that’s a big deal." https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-an...
deleted 13y ago
[deleted]
MBCook 13y ago
It may not be necessary today, but it's good to get it in the pipeline. In two years or so when top-end phones get >4GB of RAM Apple will be able to say 'iOS is 64-bit only, this is the line'. When they decide it's time to cut 32-bit support, the majority of their users will already be ready. That's what happened on the desktop. I think Apple only shipped one generation of 32-bit Intel processors. Apple was shipping 64-bit CPUs for years when many Wintel computers were still on 32. So when it came time to say 'We're going 64-bit only' with Mavericks Apple left almost no-one behind. On the other hand Microsoft still supports 32-bit Windows 8. Apple is preparing to make their lives easier in the future. For today's user, it's usefulness may not be too much higher than the level of a buzzword.
justin66 13y ago
> Except that 64 bits is still nothing but a marketing gimmick as far as the memory sizes in smart phones is concerned. We're less than one iteration of Moore's Law away from the 32-bit address space not being enough, even if you're just concerned about memory sizes of mobile devices. Getting this done doesn't seem particularly premature.
wyager 13y ago
When phones with >4GB are ubiquitous, any apps previously developed for 64 bit platforms will be ready to take advantage of increased RAM.
acdha 13y ago
I remember the same argument being employed against 64-bit server operating systems and later desktops, too: it'll waste pointer space, nobody can afford 1GB of RAM, etc. It quickly became obvious that they were underestimating the value of all of the little optimizations and bigger design reconsiderations[1] which this made possible – from little things like having more registers to larger boons like not having to play games either mapping memory around the operating system reserved block. All of that added up both in making things faster but also in making systems simpler in ways which allowed more ambitious improvements. 1. Think about designs like e.g. the Varnish cache versus squid where the latter team has poured an enormous amount of effort into features which allowed them to manage storage manually, work which is increasingly counterproductive when you can simply mmap() 4GB and let the kernel perform that complex, error-prone task for you while you focus on more interesting features.
mistercow 13y ago
64-bit addresses have a number of subtle advantages, even if you aren't addressing more than 4GB of memory. One is address space layout randomization (ASLR), which makes it harder for attackers to determine memory locations to use in exploits. ASLR works with 32-bit addresses, but it works far better with 64-bit addresses, where any given guess is overwhelmingly likely to point to absolutely nothing. This is pretty relevant to Apple, who are increasingly concerned about security on iOS.

AlexanderDhoore 13y ago

"The "64-bit" A7 is not just a marketing gimmic, but neither is it an amazing breakthrough that enables a new class of applications. The truth, as happens often, lies in between. The simple fact of moving to 64-bit does little. It makes for slightly faster computations in some cases, somewhat higher memory usage for most programs, and makes certain programming techniques more viable. Overall, it's not hugely significant. The ARM architecture changed a bunch of other things in its transition to 64-bit. An increased number of registers and a revised, streamlined instruction set make for a nice performance gain over 32-bit ARM. Apple took advantage of the transition to make some changes of their own. The biggest change is an inline retain count, which eliminates the need to perform a costly hash table lookup for retain and release operations in the common case. Since those operations are so common in most Objective-C code, this is a big win. Per-object resource cleanup flags make object deallocation quite a bit faster in certain cases. All in all, the cost of creating and destroying an object is roughly cut in half. Tagged pointers also make for a nice performance win as well as reduced memory use." [1] https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-an...

makomk 13y ago
So basically, it's only really a substantial performance win because of a quirk of how Apple's 32-bit code was written, a quirk that doesn't apply to competing platforms.
- chaostheory 13y ago
  It will apply to competing platforms in about two years, when the first set of devices with 4 GB or more RAM start appearing.
- acdha 13y ago
  If you look at the history of desktop/server operating systems, it followed the same pattern as clearly explained in the article: problems start before 4GB and affect programming decisions as soon as users start working with files which aren't trivially small. Once 64-bit became the default, many small optimizations or larger design changes became easy enough that they actually happened and produced small but meaningful improvements
- wklauss 13y ago
  This specific case might only apply to Apple (I don't know, haven't read about it before) but the quirks of ARM's 32-bit instruction set surely apply to everyone else. The transition could have happen later, maybe, with not too much repercussion, but why not make the jump now, especially when you have a whole new OS engineered to take advantage of it?

deleted 13y ago

[deleted]

kubiiii 13y ago

Its been the same since the atari jaguar (didnt work for it though).

colanderman 13y ago

64 bits … memory sizes Processor word width has absolutely nothing to do with memory size. e.g. 8-bit processors regularly interface with 16-bit-wide memory buses, and 64-bit processors often allow use of 32-bit-wide pointers. What the word width does affect is how much data can be processed by each instruction. Certain algorithms benefit immensely from this (you can easily double throughput), but the code needs to be written to take advantage of this (or at least, not to squander the advantage), and needs to be compiled to use 64-bit-wide registers.

deleted 13y ago
[deleted]
- plorkyeran 13y ago
  32-bit Windows Server 2003 supports up to 64 GB (although SQL Server is probably the only application which can actually do anything useful with that).
- colanderman 13y ago
  By that logic, 8-bit computers would only access 256 bytes of memory (which is definitely not true). On processors where the hardware word size is less than the useful size of memory, there generally is another means of extending the addressing range (either per-page bank addressing, or special pointer registers).
pmelendez 13y ago
> "Processor word width has absolutely nothing to do with memory size." Huh? How would you address high positions on your 8Gb memory with a 32 bits pointer that will overflow after 4Gb?
- plorkyeran 13y ago
  You don't have to have all of your memory mapped into your address space at once.
- colanderman 13y ago

terhechte 13y ago

Right.. "Adding it all together, it’s a pretty big win. My casual benchmarking indicates that basic object creation and destruction takes about 380ns on a 5S running in 32-bit mode, while it’s only about 200ns when running in 64-bit mode. If any instance of the class has ever had a weak reference and an associated object set, the 32-bit time rises to about 480ns, while the 64-bit time remains around 200ns for any instances that were not themselves the target. In short, the improvements to Apple’s runtime make it so that object allocation in 64-bit mode costs only 40-50% of what it does in 32-bit mode. If your app creates and destroys a lot of objects, that’s a big deal." https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-an...

deleted 13y ago

[deleted]

MBCook 13y ago

It may not be necessary today, but it's good to get it in the pipeline. In two years or so when top-end phones get >4GB of RAM Apple will be able to say 'iOS is 64-bit only, this is the line'. When they decide it's time to cut 32-bit support, the majority of their users will already be ready. That's what happened on the desktop. I think Apple only shipped one generation of 32-bit Intel processors. Apple was shipping 64-bit CPUs for years when many Wintel computers were still on 32. So when it came time to say 'We're going 64-bit only' with Mavericks Apple left almost no-one behind. On the other hand Microsoft still supports 32-bit Windows 8. Apple is preparing to make their lives easier in the future. For today's user, it's usefulness may not be too much higher than the level of a buzzword.

justin66 13y ago

> Except that 64 bits is still nothing but a marketing gimmick as far as the memory sizes in smart phones is concerned. We're less than one iteration of Moore's Law away from the 32-bit address space not being enough, even if you're just concerned about memory sizes of mobile devices. Getting this done doesn't seem particularly premature.

wyager 13y ago

When phones with >4GB are ubiquitous, any apps previously developed for 64 bit platforms will be ready to take advantage of increased RAM.

acdha 13y ago

I remember the same argument being employed against 64-bit server operating systems and later desktops, too: it'll waste pointer space, nobody can afford 1GB of RAM, etc. It quickly became obvious that they were underestimating the value of all of the little optimizations and bigger design reconsiderations[1] which this made possible – from little things like having more registers to larger boons like not having to play games either mapping memory around the operating system reserved block. All of that added up both in making things faster but also in making systems simpler in ways which allowed more ambitious improvements. 1. Think about designs like e.g. the Varnish cache versus squid where the latter team has poured an enormous amount of effort into features which allowed them to manage storage manually, work which is increasingly counterproductive when you can simply mmap() 4GB and let the kernel perform that complex, error-prone task for you while you focus on more interesting features.

mistercow 13y ago

64-bit addresses have a number of subtle advantages, even if you aren't addressing more than 4GB of memory. One is address space layout randomization (ASLR), which makes it harder for attackers to determine memory locations to use in exploits. ASLR works with 32-bit addresses, but it works far better with 64-bit addresses, where any given guess is overwhelmingly likely to point to absolutely nothing. This is pretty relevant to Apple, who are increasingly concerned about security on iOS.