I think you had in mind last night to explain why
@djjeff was right. He denied a basic claim at issue here, that "M1 Macs need less RAM to perform equivalently to, if not better than, their Intel-based counterparts." That's found in the article linked to below, which he dismissed without argument as nonsense. Do you disagree with the section of the article on M1 RAM usage or that claim?
To acknowledge how good the new M1 Macs are — and I am here to tell you they are *astonishingly* good — you must acknowledge that certain longstanding assumptions about how computers should be designed, about what makes a better computer *better*, are wrong.
daringfireball.net
I did have that in mind, yes. Unfortunately it takes a lot of time to write what I hope are good explainer posts, and it was late, so I didn't continue. I'll try to do so as I can.
I do disagree with John Gruber's article. It was disappointing to read. I don't read Daring Fireball a lot, but I have the impression that Gruber has an app software engineering background. He should know better, but then, he might not have great understanding of the stack at layers below where he works.
(For what it's worth, my position in the engineer ecosystem is that I write Verilog - the language used to design chips. This isn't as low a level as you can go, but it is the last one where there's anything resembling a high level language, and it's underneath all the software. I have significant low-level software background, too, so I'm pretty conversant with the internal architecture of operating systems, although I'm not a real domain expert there. And I'm definitely inexperienced at writing higher level code like a Mac application. Everyone has their specialty!)
So let's dissect Gruber's article.
* He starts off with the only quantitative data he's got - he links to an Apple engineer's tweet about the performance of retaining and releasing NSObject. The same one Azl just linked.
* Gruber goes on to clarify, in a way which might still be muddy to people without a technical background, that the numbers in that tweet aren't a measure of more efficient memory use, just a faster implementation of the mechanism used to
track memory use in Apple's software. (I wrote a post about this earlier in the thread.) Accelerating retain/release is important, and a really big clue as to why M1 is so fast, but does nothing to reduce the
amount of memory a program needs.
* Gruber starts segueing into our main topic of "You can get more done with less RAM" by saying that the NSObject retain/release performance shows that Apple co-designs hardware and software. And I agree, they do have a tight feedback loop between those two parts of their company.
So what we're now hoping for is that Gruber will go on to introduce some kind of evidence that this co-design has resulted in lower memory consumption. But that evidence never arrives. At best he just repeats anecdotes of people being excited that they replaced an Intel Mac with lots of memory with a M1 Mac that has less, and the M1 Mac was still faster.
But this doesn't show that M1 has memory-use-reducing magic! It just means that it's fast, and that in that particular load the penalty of not having a lot of RAM wasn't enough to overcome M1's performance advantage. (Note that the penalty can be nothing at all. A lot of people seem to have formed unrealistic ideas of how much RAM they need to do specific things.)
* He mentions that Android uses garbage collection and iOS uses reference counting, and that's one big reason why an iPhone needs less RAM than an Android phone. This is true! Of the two memory management techniques, GC tends to be more wasteful of RAM. But it's a non sequitur here. We're only concerned with macOS on Intel versus macOS on M1, and the frameworks aren't going to count references any harder on M1 than they do on Intel.
Apple has given us no reason to believe that memory management at this level is any different on M1.
* Gruber claims that because I/O is faster on M1 than Intel Macs, when you run out of memory and use swap, it's faster. The claim that I/O is faster seems to be true... as long as you're not looking at the upper end of the Intel Mac lineup. Apple has been shipping SSDs comparable to M1 SSD performance for years, just not in entry level models like the Air.
Furthermore, we're still looking at ~3.4 GB/s performance in the very biggest 2TB M1 SSDs (you won't get that with the baseline 256GB SSD, since SSD performance usually scales up as you add more flash memory). M1 can talk to DRAM at about 58 GB/s, according to the testing done by technical reviewers. (It's probably worse than these throughput numbers suggest, too. What really matters to a system under heavy swap load is disk access latency, and there's good reasons to expect that the ratio between DRAM and flash latency is even worse than the throughput ratio. But it's hard to find latency measurements of Mac SSDs, so I can't quantify this for y'all.)
So improved swapping performance isn't really a satisfactory answer. Disk speed is still way worse than DRAM speed, and equivalent disk speed is available on Intel models.
* Gruber mentions that he has a lot of stuff open on his 16GB review unit, and everything's smooth. But that's not an impossible result for Intel Macs either. In both cases, even if you've gone well past the limits of your available RAM, as long as what we low-level guys like to call the "working set" (the subset of virtual memory which is actually being read or written frequently enough to matter) fits into the physical RAM you have, you'll be doing just fine. You might notice the occasional minor delay here and there, such as when you switch to an app that hasn't been foregrounded in a long time, so it has to swap things in to begin responding quickly again, but overall the system can reach a stable state where it's not actively swapping all the time even though there's gigabytes of data in the swap file.
This is what the "Memory Pressure" graph is all about. It's Apple's attempt at measuring, in a rough sense, whether the system is under the kind of memory starvation and memory access pattern that produces high continuous swap activity, and therefore makes your computer feel slow.
A common feature of the screenshots people make where they try to prove that M1 needs less RAM is that, if Activity Monitor is visible and on the memory tab, sure they've got lots of swap used, but memory pressure is in the green. That means dynamic requirements are low, so the system isn't actively moving lots of data in and out of swap all the time.