Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
It's not just about addressable memory. While you are correct that pointers will generally take double the memory when moving from 32 to 64 bit, storage of pointers is usually a tiny fraction of an applications memory footprint. It *may* impact how much you can fit in a cacheline if you have containers with a lot of pointers (assuming the cacheline does not double with this move, too - I'm only going by the article and it doesn't mention it). So, overall, a fairly negligible downside. Note that there should not be a difference in speed of access of a 32 bit pointer vs a 64 bit pointer (although alternate pointers in a consecutive range may see a difference, depending on how that mapping is implemented).

The upside is, at the very least: more registers (if the article is correct) - which is often even more important than the capacity of the cacheline! There is some handwaving in the article about things like "more system resources" 🤷🏻‍♂️ Could mean memory (but we don't seem to be close to the limit there, as you say), so there may be other benefits.

But based on access to more registers alone I'd say this is likely to be a net performance advantage for most (if not all) apps.

Of course none of this is straightforward and the reality may look quite different to my speculation, above.

What an excellent post! Thank you. Informative, and on point.
 
  • Like
Reactions: Starfia
Going to be interesting where they can now take the AW in 2-3 years. Certainly this means more RAM is coming sooner than later with the AW 11 and eventually, much better battery life.
 
Apple has really pushed the bounds of 64 bit computing for sure... but I absolutely do not see any benefit to going all in on 64 bit pointers on apple watch. The latest models have ~1 GB of RAM. They could quadruple that amount and still be fine with 32 bit pointers. I'd be interested to see what they are doing under the hood that truly makes going to 64 bit pointers all that great at this memory footprint that justifies this change - otherwise this feels like a slick way of combinging a 64 bit marketing win with forced obsolesce.

"Look!!! 64 bit stuff... oh by the way, the pointers take double the memory, so older devices will run even slower... time to upgrade!"
There are benefits to 64-bit pointers even if you don't have enough RAM to require them. Perhaps the biggest is that they dramatically increase the effectiveness of ASLR (Address Space Layout Randomization) -- more simply, they improve security.

Also, it's not unusual for operating system kernels to split the address space between user space and kernel space in such a way that things start getting weird when you need nearly all of the address bits for actual RAM. For instance, back in the day (late 1990's-early 2000's), if you had 1GB+ of RAM on a 32-bit Linux system, you could only use 896MB. (This was back before both Itanium and AMD64.)


While writing this post, I got curious and looked back at how much RAM the iPhone and iPad had when Apple decided to make those 64-bit. As it turns out, the iPhone 5 (32-bit) and 5s (64-bit) both had 1GB of RAM, as did the iPad 4th gen (32-bit) and iPad Air (64-bit). Also, Apple moved to 2GB of RAM for the iPad one year later with the iPad Air 2, and two years later for the iPhone with the iPhone 6s & 6s Plus.

It makes sense that Apple would handle the watch similarly: Move to full 64-bit while keeping the RAM at 1GB, then (in all likelihood) increase the RAM again in the future.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.