iPhone 14 Pro Features 6GB of Faster LPDDR5 Memory

[extrachrispy]

Very nice! All we need is 10 more GB of ram for Apple to catch up to Android.

Sigh.

Swift vs. Java.

 

[tedtanner]

The reason why Android needs so much memory is that it lacks Apple's level of hardware and software integration and, like generic windows and other software that is required to run on a plethora of ambiguous hardware, is highly inefficient and needs twice as much to do pretty much the same as Apple does on its highly regulated hardware.

If iPhone ever moves over to M series with its unified memory architecture, this gap in performance and power usage will be literally LOLworthy.

I agree that iOS runs smoothly with much less RAM than Android, however I disagree on the reason you cite as the driver for that difference. There certainly is some advantage Apple's vertical integration provides in reducing RAM usage, but that difference is likely negligible.

The reason iOS runs smoothly with less RAM is because its behind-the-scenes system services and most of its apps use a different strategy for memory management than do Android apps and services. There are three main strategies programs (including apps and system services) can use to manage memory: manual management, Automatic Reference Counting (ARC), or a tracing garbage collector. Let me explain these strategies and then explain how that leads to Android using more RAM:

Automatic Reference Counting (which I'll now refer to as "ARC") involves keeping a count of how many pieces of code refer to (meaning they are using) a block of memory. When a piece of code obtains a pointer (a reference) to a block of memory, the reference count for that block in incremented. When a piece of code is done with that block of memory, the reference count is decremented. Once that count hits 0, meaning none of the code refers to that particular block of memory, that block is immediately returned to the operating system and can be used by other apps ("immediately" isn't always true; some of that memory can be retained and reused by the app for new pieces of data, but I think you get the point).

When an app uses tracing garbage collection, usually no reference counts are kept so there is no quick way for the program to determine which blocks of memory are still in use somewhere in the code and which no longer have references and can be recycled. So, the program uses a "garbage collector" that stops everything the app is doing (momentarily--often imperceptibly to the user) and then goes through each reference in the code and marks every block of memory that is referenced as being in use. Then the app knows that all of the other pieces of memory (the ones not marked as being in use) can be repurposed. Because the garbage collector only runs every once-in-a-while, there is a lot of "garbage" memory at any given moment that the app isn't using anymore but doesn't know is available to be reused. For this reason, apps will often request 2 to 4 times as much memory from the operating system than they would really need if they were cleaning up their memory immediately.

There are pros and cons to either method; ARC can cause memory fragmentation and poorer CPU cache performance in addition to the extra work needed to maintain reference counts. Garbage collection can have long latency spikes when the garbage collector kicks in and requires a LOT more RAM than ARC because of the memory needed to house garbage.

The vast majority of iOS apps use ARC (because Apple's Swift programming language uses ARC and Apple's runtime provides an ARC solution for Objective-C developers who choose to not manually manage their memory). The vast majority of Android apps use tracing garbage collection (because the majority of those apps are written in Java or Kotlin). Thus, the majority of Android apps (and many system services as well) request 2 to 4 times as much memory from the OS as they really need whereas iOS apps don't really do that (though may suffer from minor slowdowns due to the aforementioned negative effects of using ARC).

Essentially, the main reason iOS runs smoothly on less RAM is because its apps are much lighter on RAM than their Android counterparts, even when those apps do the same thing. There is some extra optimization that happens because of Apple's vertical integration, but I would guess that the impact of those optimizations on RAM usage is small compared to the enormous impact of using ARC rather than tracing garbage collection.

 

[tedtanner]

Sigh.

Swift vs. Java.

This is correct. More correct than the posts claiming that Apple's magical optimizations are the main contributor to lower RAM usage. More specifically, it is automatic reference counting vs tracing garbage collection

 

[caribbeanblue]

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

 

[name99]

I agree that iOS runs smoothly with much less RAM than Android, however I disagree on the reason you cite as the driver for that difference. There certainly is some advantage Apple's vertical integration provides in reducing RAM usage, but that difference is likely negligible.

Essentially, the main reason iOS runs smoothly on less RAM is because its apps are much lighter on RAM than their Android counterparts, even when those apps do the same thing. There is some extra optimization that happens because of Apple's vertical integration, but I would guess that the impact of those optimizations on RAM usage is small compared to the enormous impact of using ARC rather than tracing garbage collection.

This is part of the solution, it's not all.

Another part of the solution is that Apple has paid immense attention to priority issues throughout the HW and somewhat in the SW. To give just one example, all the various different devices (CPU, GPU, ISP, NPU, etc) can all simultaneously be sending requests to the Memory Controller. Which request gets handled first? Apple has machinery in place (which has grown over the years and has been completely revised at least three times) to ensure that the "highest priority" request gets serviced first, where "highest priority" again has grown to incorporate many different aspects (will data be lost [eg camera], is there UI involved [audio], balancing latency vs bandwidth, etc).
This prioritization machinery extends across every aspect of the HW.

At the OS level we see something similar in the attempts to categorize code by the type of task it is trying to perform, and running it on either an E or a P core. The E/P distinction is most obvious, but there are many other aspects to this, like which tasks are scheduled to run simultaneously on a cluster. Much of the OS machinery to do this is non-obvious (eg the Voucher technology introduced a few years ago), and it's interesting to see how utterly clueless supposedly tech Win or Linux people are about this, insisting that Vouchers are nothing new (which clearly shows they don't understand the problems vouchers are solving.)

Halfway between these OS features and the HW features is IO prioritization which has existed (as an API that didn't do much) for years, seems to have finally been hooked up to an implementation (badly) in Monterey, though the implementation did get better through various releases, and finally seems to be working correctly in Ventura.

 

[djphat2000]

Been using my 14 Pro 256GB for about a day. It took about 50 minutes to do a full transfer from my old 12 Pro.
Not as fast as I would like, but I didn't have any issues doing it. This was the side by side (close contact) method of transfer. I agree it would be nice to have USB 3/4/thunderbolt for stuff like this. Unless we get 10Gb WiFi in the next iPhone.

After signing into my apps again, enabling FaceID on everything (still don't know why that just isn't enabled by default). Everything seems to be working just fine. I'm not missing anything, and my home screen mapped exactly as it had been before.

It's noticeably faster than my 12. Screen is VERY fluid and responsive.
I'm still getting used to the always on display. I'm used to it just being "off" when I click the power button. It's weird to me it's "on".

Performance improvements are noticeable, everything pops open (snappy). I really like the speed improvements and refresh rate of the screen. VERY nice.
It feels a little heavier than the 12. Like at the top. Camera bump is much larger, most likely the reason. Have not taken any pictures worth mentioning yet. Or videos. That will come later. Have to get to erasing the old phone and getting it ready to ship back to Apple.

So far, for me. So good!

Just to update, that I had/have an odd issue with my company email via the built in Mail App. Been using it for many years without issue. But, the 14 Pro is showing a battery drain issue with it. I was able to pin point it to that email account and once removed. My issue resolved. Thought it was maybe the MDM or something. But, it was taking about 10% of my battery power per hour.

As far as I know, I'm the only one with the issue at my office. Figures!
Now that it's been resolved. The battery life on this is fantastic.