M4+ Chip Generation - Speculation Megathread [MERGED]

[EugW]

I was querying the efficacy of 8gb or memory even for a basic user.

I ran an old 2014 i5-4278U 8 GB Mac mini for a year until recently, and it was fine. This was for my main work machine, and typical usage includes Safari (several tabs, including YouTube and forums), Citrix VPN client, Mail, Calendar, iMessage, Calculator, Numbers, Contacts, Photos, and sometimes Pages, Word, FaceTime, Chrome, and Activity Monitor. The main thing needed to make it function well was to install an NVMe SSD. I'm on my work machine 8-10 hours a day.

What I found is that I wouldn't notice any slowdowns until I did some heavier multitasking. Then I could occasionally see a mild lag, nothing major, but as someone who also had a 2017 24 GB iMac beside it, it could be noticed. When I ran Activity Monitor, memory pressure was always still in the green, but with the additional multitasking, the swap file had increased to >1 GB in size. I would not usually notice any slowdowns when the swap file was say 400 MB, but at 1-2 GB, I would sometimes notice it. But remember, I'm a geek at MacRumors and a moderate multitasker who had a 24 GB machine beside it I could compare against, and honestly I thought 8 GB was fine overall, just with occasional minor performance hiccups when doing heavier multitasking.

With much less geeky mainstream users who multitask less and who don't run anything super complex, 8 GB is even more fine. My wife has an 8 GB 2017 MacBook Air and my daughter has an 8 GB 2015 MacBook Pro, and their machines are totally fine for what they do. I am considering upgrading the 2017 Air though, mainly because it's not Retina, but also because it doesn't support hardware HEVC video playback. (Neither does the 2015 MBP but she doesn't play HEVC videos on it.)

For my wife I know 12 GB plus HEVC and AV1 hardware support would last her a very long time. Her usage pattern hasn't changed in the last 5 years, and I don't think they'll change much in the next five years either. But even 8 GB would probably be OK. For my daughter, I am less sure, because she is still a kid and things change quickly with kids.

I'm predicting the M4 MacBook Pro will get 12 GB base, and I'm hoping the M4 MacBook Air gets 12 GB base as well (assuming there is an M4 MBA), although I'm a bit less convinced about that. That 12 GB will be sufficient for the entry level for many years to come. I had considered getting my wife a cheap used 8 GB M1 MacBook Air, but decided to wait for a 12 GB MacBook Air instead. That thing could last her a decade.

tl;dr:

As a moderate multitasker who recently ran an 8 GB machine for 8-10 hours a day for a year, I thought the performance was fine, and it would be sufficient for most entry level users for several years.

OTOH, I do think a base memory upgrade is overdue given Mac pricing, and predict we'll see 12 GB base soon. 12 GB would last light users a very long time.

 

[LaterWolf]

I ran an old 2014 i5-4278U 8 GB Mac mini for a year until recently, and it was fine. This was for my main work machine, and typical usage includes Safari (several tabs, including YouTube and forums), Citrix VPN client, Mail, Calendar, iMessage, Calculator, Numbers, Contacts, Photos, and sometimes Pages, Word, FaceTime, Chrome, and Activity Monitor. The main thing needed to make it function well was to install an NVMe SSD. I'm on my work machine 8-10 hours a day.

What I found is that I wouldn't notice any slowdowns until I did some heavier multitasking. Then I could occasionally see a mild lag, nothing major, but as someone who also had a 2017 24 GB iMac beside it, it could be noticed. When I ran Activity Monitor, memory pressure was always still in the green, but with the additional multitasking, the swap file had increased to >1 GB in size. I would not usually notice any slowdowns when the swap file was say 400 MB, but at 1-2 GB, I would sometimes notice it. But remember, I'm a geek at MacRumors and a moderate multitasker who had a 24 GB machine beside it I could compare against, and honestly I thought 8 GB was fine overall, just with occasional minor performance hiccups when doing heavier multitasking.

With much less geeky mainstream users who multitask less and who don't run anything super complex, 8 GB is even more fine. My wife has an 8 GB 2017 MacBook Air and my daughter has an 8 GB 2015 MacBook Pro, and their machines are totally fine for what they do. I am considering upgrading the 2017 Air though, mainly because it's not Retina, but also because it doesn't support hardware HEVC video playback. (Neither does the 2015 MBP but she doesn't play HEVC videos on it.)

For my wife I know 12 GB plus HEVC and AV1 hardware support would last her a very long time. Her usage pattern hasn't changed in the last 5 years, and I don't think they'll change much in the next five years either. But even 8 GB would probably be OK. For my daughter, I am less sure, because she is still a kid and things change quickly with kids.

I'm predicting the M4 MacBook Pro will get 12 GB base, and I'm hoping the M4 MacBook Air gets 12 GB base as well (assuming there is an M4 MBA), although I'm a bit less convinced about that. That 12 GB will be sufficient for the entry level for many years to come. I had considered getting my wife a cheap used 8 GB M1 MacBook Air, but decided to wait for a 12 GB MacBook Air instead. That thing could last her a decade.

tl;dr:

As a moderate multitasker who recently ran an 8 GB machine for 8-10 hours a day for a year, I thought the performance was fine, and it would be sufficient for most entry level users for several years.

OTOH, I do think a base memory upgrade is overdue given Mac pricing, and predict we'll see 12 GB base soon. 12 GB would last light users a very long time.

With the way macrumors is going:
Once 12gb ram MacBook Air releases:
OH OH NO 12 GB RAM NOT ENOUGH TRASH APPLE BAD APPLE SHR IRJGF SIRI BAD APPLE BAD PLEASE STEVE COME BACK

 

[thenewperson]

With the way macrumors is going:
Once 12gb ram MacBook Air releases:
OH OH NO 12 GB RAM NOT ENOUGH TRASH APPLE BAD APPLE SHR IRJGF SIRI BAD APPLE BAD PLEASE STEVE COME BACK

I’d expect the same thing would happen with 16GB too.

 

[name99]

I’d expect the same thing would happen with 16GB too.

Noted as something rather more interesting than the endless bickerfest about Apple minimum RAM:

US20240095194A1 - Read Arbiter Circuit with Dual Memory Rank Support - Google Patents

A memory control circuit coupled to multiple memory ranks may receive read and write requests for a different ranks of the multiple memory ranks. The memory control may allocate write requests to different slots based on the write requests target memory rank, and may adjust the number of slots...

patents.google.com

US20240094917A1 - Write Arbiter Circuit with Per-Rank Allocation Override Mode - Google Patents

A memory control circuit coupled to multiple memory ranks may receive read and write requests for a different ranks of the multiple memory ranks. The memory control may allocate write requests to different slots based on the write requests target memory rank, and may adjust the number of slots...

patents.google.com

The magic word here, of course, is rank; everything else is familiar stuff. So...

My guess is this provides at least a plan B (maybe to be acted upon, maybe not) should there be a demand at the high end (Studio and Pro) for twice as much RAM.
In terms of physical mounting, the obvious and easy strategy is dual sided, that won't require too much of a rethink versus the current design, as opposed to the much more aggressive (and up-scalable) schemes like the memory spines.

 

[theorist9]

Noted as something rather more interesting than the endless bickerfest about Apple minimum RAM:

US20240095194A1 - Read Arbiter Circuit with Dual Memory Rank Support - Google Patents

A memory control circuit coupled to multiple memory ranks may receive read and write requests for a different ranks of the multiple memory ranks. The memory control may allocate write requests to different slots based on the write requests target memory rank, and may adjust the number of slots...

patents.google.com

US20240094917A1 - Write Arbiter Circuit with Per-Rank Allocation Override Mode - Google Patents

A memory control circuit coupled to multiple memory ranks may receive read and write requests for a different ranks of the multiple memory ranks. The memory control may allocate write requests to different slots based on the write requests target memory rank, and may adjust the number of slots...

patents.google.com

The magic word here, of course, is rank; everything else is familiar stuff. So...

My guess is this provides at least a plan B (maybe to be acted upon, maybe not) should there be a demand at the high end (Studio and Pro) for twice as much RAM.
In terms of physical mounting, the obvious and easy strategy is dual sided, that won't require too much of a rethink versus the current design, as opposed to the much more aggressive (and up-scalable) schemes like the memory spines.

I've never really understood rank.

It sounds like going to dual-rank memory means that, for a given max module size, they can use two modules per memory controller rather than one, which would have the effect of doubling capacity, while keeping the "nominal" bandwidth the same. Is that right?

And what would be the effect on performance? In reading this article, it sounds like the answer is that it might either improve it or reduce it, depending on the task:

Memory rank - Wikipedia

en.wikipedia.org

 

[name99]

I've never really understood rank.

It sounds like going to dual-rank memory means that, for a given max module size, they can use two modules per memory controller rather than one, which would have the effect of doubling capacity, while keeping the "nominal" bandwidth the same. Is that right?

Memory rank - Wikipedia

en.wikipedia.org

Essentially, yes. Think of rank as two sides of a DIMM. *Same* wires route to *both* sets of DRAM chips, so switching from one side to the other results in some downtime.

Point of the patents is to limit the possible performance downsides. You lose performance whenever you switch rank, so don’t do that! More precisely, among other things:
- fill up near ranks first, then far, so hopefully most hot data is in a near rank
- so far as possible execute all operations to one rank before switching to the other rank.

 

[Confused-User]

Noted as something rather more interesting than the endless bickerfest about Apple minimum RAM:

US20240095194A1 - Read Arbiter Circuit with Dual Memory Rank Support - Google Patents

A memory control circuit coupled to multiple memory ranks may receive read and write requests for a different ranks of the multiple memory ranks. The memory control may allocate write requests to different slots based on the write requests target memory rank, and may adjust the number of slots...

patents.google.com

US20240094917A1 - Write Arbiter Circuit with Per-Rank Allocation Override Mode - Google Patents

A memory control circuit coupled to multiple memory ranks may receive read and write requests for a different ranks of the multiple memory ranks. The memory control may allocate write requests to different slots based on the write requests target memory rank, and may adjust the number of slots...

patents.google.com

The magic word here, of course, is rank; everything else is familiar stuff. So...

My guess is this provides at least a plan B (maybe to be acted upon, maybe not) should there be a demand at the high end (Studio and Pro) for twice as much RAM.
In terms of physical mounting, the obvious and easy strategy is dual sided, that won't require too much of a rethink versus the current design, as opposed to the much more aggressive (and up-scalable) schemes like the memory spines.

Cool find. I wonder if this sort of work is motivated by Apple's reported desire to use in-house gear for AI/cloud farms.

I read part of the patent, and... I have a couple questions. First, ISTM that this would be implemented in the SLCs. Is that right? I can sort of imagine an alternative, a memory controller block holding its own queues.

Also... This, from the patent:

One arrangement of memory circuits that is used in computing systems include multiple memory circuits connected to a common data bus and a common activation/control signal, with each of the memory circuits contributing to a portion of the overall width of the common data bus. Such an arrangement of memory circuits is referred to as a “rank.”

That seems wrong! Ranks are connected to a "common data bus", sure, but.. "contributing to a portion of the overall width of the common data bus"?? Like, 32 bits out of a 64-bit-wide bus? That isn't right, is it? My understanding was that a rank filled the entire width of the data bus. If that's wrong, can you point to a source I can read that describes this well? (Wikipedia has articles, but at least some are both antiquated and poorly written.)

 

[mr_roboto]

Noted as something rather more interesting than the endless bickerfest about Apple minimum RAM:

US20240095194A1 - Read Arbiter Circuit with Dual Memory Rank Support - Google Patents

A memory control circuit coupled to multiple memory ranks may receive read and write requests for a different ranks of the multiple memory ranks. The memory control may allocate write requests to different slots based on the write requests target memory rank, and may adjust the number of slots...

patents.google.com

US20240094917A1 - Write Arbiter Circuit with Per-Rank Allocation Override Mode - Google Patents

A memory control circuit coupled to multiple memory ranks may receive read and write requests for a different ranks of the multiple memory ranks. The memory control may allocate write requests to different slots based on the write requests target memory rank, and may adjust the number of slots...

patents.google.com

The magic word here, of course, is rank; everything else is familiar stuff. So...

My guess is this provides at least a plan B (maybe to be acted upon, maybe not) should there be a demand at the high end (Studio and Pro) for twice as much RAM.
In terms of physical mounting, the obvious and easy strategy is dual sided, that won't require too much of a rethink versus the current design, as opposed to the much more aggressive (and up-scalable) schemes like the memory spines.

This patent has nothing to do with capacity, it's about arbitration. As for physical mounting, Apple could easily do multiple ranks inside the package-on-package DRAM modules they use today - those things don't have single die inside, they have multiple.

Essentially, yes. Think of rank as two sides of a DIMM. *Same* wires route to *both* sets of DRAM chips, so switching from one side to the other results in some downtime.

Point of the patents is to limit the possible performance downsides. You lose performance whenever you switch rank, so don’t do that!

You've misunderstood the patent, imo.

It doesn't cost much to switch ranks. What does cost is bus turnaround - the data pins are bidirectional, and especially at modern DRAM clock frequencies, it costs some time to change which end of the link (memory or controller) is driving them.

That's what the language about "write turn" and "read turn" is about: the memory controller shouldn't turn the bus around at a whim, as that will destroy efficiency. So it reads for a while, then turns the bus around to write for a while, and so on. While reading, the memory controller's write request queue is backing up, and while writing, its read request queue is backing up.

What the patent describes is essentially that they want to build QoS awareness into a scheduler which governs the order of serving requests after each bus turnaround, and sometimes that interacts with rank. It doesn't imply that there's a huge penalty for rank switching (and, as far as I know, there isn't, certainly nothing of the same magnitude as the turnaround penalty).

I read part of the patent, and... I have a couple questions. First, ISTM that this would be implemented in the SLCs. Is that right? I can sort of imagine an alternative, a memory controller block holding its own queues.

It's not SLCs, memory controllers have complex queues and arbitration mechanisms built in.

Also... This, from the patent:

That seems wrong! Ranks are connected to a "common data bus", sure, but.. "contributing to a portion of the overall width of the common data bus"?? Like, 32 bits out of a 64-bit-wide bus? That isn't right, is it? My understanding was that a rank filled the entire width of the data bus. If that's wrong, can you point to a source I can read that describes this well? (Wikipedia has articles, but at least some are both antiquated and poorly written.)

It's just confusing patent-ese describing the fact that a rank filling the entire width of a data bus may be composed of multiple DRAM die which aren't full width.

 

[name99]

This patent has nothing to do with capacity, it's about arbitration. As for physical mounting, Apple could easily do multiple ranks inside the package-on-package DRAM modules they use today - those things don't have single die inside, they have multiple.


You've misunderstood the patent, imo.

It doesn't cost much to switch ranks. What does cost is bus turnaround - the data pins are bidirectional, and especially at modern DRAM clock frequencies, it costs some time to change which end of the link (memory or controller) is driving them.

That's what the language about "write turn" and "read turn" is about: the memory controller shouldn't turn the bus around at a whim, as that will destroy efficiency. So it reads for a while, then turns the bus around to write for a while, and so on. While reading, the memory controller's write request queue is backing up, and while writing, its read request queue is backing up.

What the patent describes is essentially that they want to build QoS awareness into a scheduler which governs the order of serving requests after each bus turnaround, and sometimes that interacts with rank. It doesn't imply that there's a huge penalty for rank switching (and, as far as I know, there isn't, certainly nothing of the same magnitude as the turnaround penalty).


It's not SLCs, memory controllers have complex queues and arbitration mechanisms built in.


It's just confusing patent-ese describing the fact that a rank filling the entire width of a data bus may be composed of multiple DRAM die which aren't full width.

Some points.
OF course read and write turns are an issue. But read and write turns have been part of Apple's (and everyone's) memory controller design since the A7 or earlier. They are not the point.

Likewise the basic QoS goal is not the point. Again, since forever, Apple's memory controller has taken in various signals in order to decide whether, for the next few cycles, to prioritize bandwidth vs latency. Boosting bandwidth is basically sticking with the current task (reading vs writing), boosting latency is essentially about terminating write runs early so that reads are not starved. This sounds trivial, but becomes complicated, built on a three-stage queueing system, once you add in every other desiderata (every request has particular QoS settings, you want to optimize repeatedly hitting the same page, you occasionally need to refresh the DRAM, etc etc).

OK, so that's all table stakes. Nothing new.
It's also the case (you're welcome to go back and check, if you think I made a mistake) that until these two patents I don't believe Apple's memory controllers ever mentioned rank.
Likewise I believe I am correct in saying that no current Apple product from watch to phone to Mac Pro uses rank.

And Apple (who, I'm afraid, I trust rather more than you, disagree that changing rank costs time. Quoting from one of the patents:
"
During a read or write turn, different ranks of the multiple ranks may be accessed based on how accesses are distributed into the available slots. When switching from accessing one rank to another within a write turn, there is a period of time during the switch when no writes are being performed, which limits the number of writes that can be performed during the write turn (referred to as “efficiency”).
"

So if you think my analysis is wrong, you need to explain why bring up rank now – when no products use it?
And why talk about rank turnaround time if it doesn't matter?

One of the reasons Apple have reached the performance they have, as is very clear if you study the design from the earliest days, is that they care about every little .1% here, .1% there. Things that other companies consider unimportant are pounded on mercilessly. And it turns out that if you add together one hundred .1% improvements you do indeed get a 10% improvement. Repeat annually and amazing things can happen.

I refer you to volume 3, where I discuss in what many probably consider mind-numbing over-detail the evolution of the Memory Controller (in tandem with the NoC and the SLC controller) since the earliest days of the A4 and A5:

GitHub - name99-org/AArch64-Explore

Contribute to name99-org/AArch64-Explore development by creating an account on GitHub.

github.com

 

[name99]

Cool find. I wonder if this sort of work is motivated by Apple's reported desire to use in-house gear for AI/cloud farms.

I read part of the patent, and... I have a couple questions. First, ISTM that this would be implemented in the SLCs. Is that right? I can sort of imagine an alternative, a memory controller block holding its own queues.

Also... This, from the patent:

That seems wrong! Ranks are connected to a "common data bus", sure, but.. "contributing to a portion of the overall width of the common data bus"?? Like, 32 bits out of a 64-bit-wide bus? That isn't right, is it? My understanding was that a rank filled the entire width of the data bus. If that's wrong, can you point to a source I can read that describes this well? (Wikipedia has articles, but at least some are both antiquated and poorly written.)

Like I said, volume 3 describes the whole complicated interaction between SLC and memory controller. Remember that SLC is a Memory-side Cache (Apple has started referring to it more as Memory Cache than SLC), so the two have to be intimately tied – every request has to go through the SLC, and if it doesn't hit in SLC is passed on to the Memory Controller.

Language in patents is frequently sub-optimal as a negotiation between the engineer (who writes the first draft) and the lawyer (who fixes subsequent drafts, but by the end both are exhausted and tend to skip over stuff that looks like uninteresting verbiage).

There is a pathology of small minds (which are the main population of the tech internet) which thinks that real life is like debate club – you have somehow achieved something important and useful by noting trivial legalistic issues in someone else's presentation, a patent, a contract, or whatever. That's not how real world making works! Real engineers view these things as imperfect sources of information, not as tools for virtue and smartness signaling. Trivial details are unimportant relative to the big picture.
BUT most real engineers are off doing something important, not wasting time with the smooth brains. Every few months I encounter what looks like an intelligent thread populated by intelligent people, and assume there may be value in participting.
And every time, within a week, I'm reminded what an utter waste of time that is, how the river of crap from the small brains drowns anything and everyone with moronic objections.

OK, I'm out for now. Maybe I'll forget the lesson in a year, maybe not; but I can't take another round of this.

 

[Confused-User]

Like I said, volume 3 describes the whole complicated interaction between SLC and memory controller. Remember that SLC is a Memory-side Cache (Apple has started referring to it more as Memory Cache than SLC), so the two have to be intimately tied – every request has to go through the SLC, and if it doesn't hit in SLC is passed on to the Memory Controller.

I will look back at that. I definitely didn't read it as thoroughly as I did the last two sections.

There is a pathology of small minds (which are the main population of the tech internet) which thinks that real life is like debate club – you have somehow achieved something important and useful by noting trivial legalistic issues in someone else's presentation, a patent, a contract, or whatever. That's not how real world making works! Real engineers view these things as imperfect sources of information, not as tools for virtue and smartness signaling. Trivial details are unimportant relative to the big picture.
BUT most real engineers are off doing something important, not wasting time with the smooth brains. Every few months I encounter what looks like an intelligent thread populated by intelligent people, and assume there may be value in participting.
And every time, within a week, I'm reminded what an utter waste of time that is, how the river of crap from the small brains drowns anything and everyone with moronic objections.

OK, I'm out for now. Maybe I'll forget the lesson in a year, maybe not; but I can't take another round of this.

Um, what?

Are you mixing up this conversation with one in RWT, maybe? I do not understand what could have prompted that reaction.

 

[Confused-User]

It's not SLCs, memory controllers have complex queues and arbitration mechanisms built in.

I should have remembered that, sigh.

It's just confusing patent-ese describing the fact that a rank filling the entire width of a data bus may be composed of multiple DRAM die which aren't full width.

I'm not sure I buy that, but regardless (assuming I'm reading you correctly) I am at least not confused on rank widths, so that's nice...

 

[mr_roboto]

And Apple (who, I'm afraid, I trust rather more than you, disagree that changing rank costs time. Quoting from one of the patents:

I said that changing ranks costs much less time than changing direction, not that it costs no time.

So if you think my analysis is wrong, you need to explain why bring up rank now – when no products use it?
And why talk about rank turnaround time if it doesn't matter?

Because it does matter, but not as much as you seem to think.

You read all these Apple patents but you process them with a ton of motivated reasoning. You're always on the lookout for things which you can use to present yourself as someone with unique insight into what Apple's doing. So in this case, you've gleaned a little bit of truth, but you're trying to spin it as something a lot bigger than it probably is.

As for the first question: How can you tell that no Apple Silicon products use more than one rank today? Hint: virtually all RAM "chips" today actually have many die inside one package. Hint #2: Apple's system design philosophy seems to favor lots of open DRAM pages, which is natural as their SoCs have a ton of different agents generating memory transactions. Multi-rank memory helps with that, even if it makes command scheduling a little more difficult.

(for the record: no, I'm not saying I know that Apple is using multi-rank memory today. Only that as far as I know, they easily could be, and there are already potential reasons for them to be doing so. Just providing a counterpoint to the kind of unwarranted conclusion you love to leap to.)

I refer you to volume 3, where I discuss in what many probably consider mind-numbing over-detail the evolution of the Memory Controller (in tandem with the NoC and the SLC controller) since the earliest days of the A4 and A5:

GitHub - name99-org/AArch64-Explore

Contribute to name99-org/AArch64-Explore development by creating an account on GitHub.

github.com

Nah, I'll pass.

Um, what?

Are you mixing up this conversation with one in RWT, maybe? I do not understand what could have prompted that reaction.

Those of us who've been watching Maynard Handley interact with people online for a long time have seen this many times before. He searches for conversations about Apple all over the internet, or discovers conversations he thinks should be about Apple but aren't yet, and tries to kramer in and dominate the discussion. Any amount of non-sycophantic response, no matter how mild, makes him angry. Eventually he'll throw a big temper tantrum, declare that he's better than everyone, and stomp out.

Later, he'll come back and do it all over again. He never actually makes good on his threats to leave forever.

 

[Frantisekj]

Is that possible?

Scalable Matrix Extension for the Armv9-A Architecture

In this blog, read the details for Scalable Matrix Extension (SME). This is a new extension from the latest Arm Vision day announcement for Armv9-A.

community.arm.com

I do not have knowledge so I at least share two interesting deep M4 reviews

Here you need to turn subtitles on.

 

[altaic]

I do not have knowledge so I at least share two interesting deep M4 reviews

Here you need to turn subtitles on.

Do you have any particular thoughts about those videos (or timestamps)? Not about to spend 45 minutes watching rando reviews.

 

[Frantisekj]

Do you have any particular thoughts about those videos (or timestamps)? Not about to spend 45 minutes watching rando reviews.

I do not know any other guys who would be able to do deep analyses like those two. I discovered that Chinese guy before already. And Gary is know well enough.

 

[LaterWolf]

This whole ram puzzle was started by a joke post about macrumors negativity.

 

[MrGunny94]

I ran an old 2014 i5-4278U 8 GB Mac mini for a year until recently, and it was fine. This was for my main work machine, and typical usage includes Safari (several tabs, including YouTube and forums), Citrix VPN client, Mail, Calendar, iMessage, Calculator, Numbers, Contacts, Photos, and sometimes Pages, Word, FaceTime, Chrome, and Activity Monitor. The main thing needed to make it function well was to install an NVMe SSD. I'm on my work machine 8-10 hours a day.

What I found is that I wouldn't notice any slowdowns until I did some heavier multitasking. Then I could occasionally see a mild lag, nothing major, but as someone who also had a 2017 24 GB iMac beside it, it could be noticed. When I ran Activity Monitor, memory pressure was always still in the green, but with the additional multitasking, the swap file had increased to >1 GB in size. I would not usually notice any slowdowns when the swap file was say 400 MB, but at 1-2 GB, I would sometimes notice it. But remember, I'm a geek at MacRumors and a moderate multitasker who had a 24 GB machine beside it I could compare against, and honestly I thought 8 GB was fine overall, just with occasional minor performance hiccups when doing heavier multitasking.

With much less geeky mainstream users who multitask less and who don't run anything super complex, 8 GB is even more fine. My wife has an 8 GB 2017 MacBook Air and my daughter has an 8 GB 2015 MacBook Pro, and their machines are totally fine for what they do. I am considering upgrading the 2017 Air though, mainly because it's not Retina, but also because it doesn't support hardware HEVC video playback. (Neither does the 2015 MBP but she doesn't play HEVC videos on it.)

For my wife I know 12 GB plus HEVC and AV1 hardware support would last her a very long time. Her usage pattern hasn't changed in the last 5 years, and I don't think they'll change much in the next five years either. But even 8 GB would probably be OK. For my daughter, I am less sure, because she is still a kid and things change quickly with kids.

I'm predicting the M4 MacBook Pro will get 12 GB base, and I'm hoping the M4 MacBook Air gets 12 GB base as well (assuming there is an M4 MBA), although I'm a bit less convinced about that. That 12 GB will be sufficient for the entry level for many years to come. I had considered getting my wife a cheap used 8 GB M1 MacBook Air, but decided to wait for a 12 GB MacBook Air instead. That thing could last her a decade.

tl;dr:

As a moderate multitasker who recently ran an 8 GB machine for 8-10 hours a day for a year, I thought the performance was fine, and it would be sufficient for most entry level users for several years.

OTOH, I do think a base memory upgrade is overdue given Mac pricing, and predict we'll see 12 GB base soon. 12 GB would last light users a very long time.

There's a lot of people waiting on the 12GB Air at this point, however it does look like this will be Spring 2025 at this stage...

I'm one of these people waiting for the 12GB version as base model, so I can easily get 24GB on an upgrade

 

[leman]

I do not have knowledge so I at least share two interesting deep M4 reviews

Here you need to turn subtitles on.

The first video is already compromised by calling M4 a “armv9” CPU. It’s not.

 

[DrWojtek]

Lol I am already past M4. Eagerly waiting for M5 now. What if it brings great boost to GPU as leman has fortold? Would be an incredibly future-proof allrounder. CPU is already phenomenal and will probably increase another 10% for M5.

 

[tenthousandthings]

Lol I am already past M4. Eagerly waiting for M5 now. What if it brings great boost to GPU as leman has fortold? Would be an incredibly future-proof allrounder. CPU is already phenomenal and will probably increase another 10% for M5.

M2 launched for MacBook Air.
M3 launched for MacBook Pro.
M4 launched for iPad Pro.

M5 will launch for Vision Pro, 1H 2025.

 

[Xiao_Xi]

The first video is already compromised by calling M4 a “armv9” CPU. It’s not.

I can't imagine what you would think of M4's Wikipedia page.

It is rumored the Apple M4 is Apple's first SoC which uses the ARMv9 architecture for its CPU cores, ARMv9.4 to be specific.[7][8] It also could support Arm's SME2 extension,[9] which was announced in 2022[10] and is a superset of SME and SVE2,[11] to accelerate matrix operations. This is likely the cause of the majority of the estimated 7.6% Instructions Per Cycle (IPC) uplift from M3 Max, which would only be 3.0% without the new matrix extensions.[12]

Apple M4 - Wikipedia

en.wikipedia.org

 

[tenthousandthings]

M2 launched for MacBook Air.
M3 launched for MacBook Pro.
M4 launched for iPad Pro.

M5 will launch for Vision Pro, 1H 2025.

I wrote that tongue-in-cheek, but I also think it’s the best way to understand Apple’s “cadence” for M-series silicon. It’s product-driven.

M2 was all about power/performance efficiency in the MacBook Air. Just ask Qualcomm and Intel (Lunar Lake) about whether this was important.

M3 was all about realigning the MacBook Pro to have a consistent good-better-best structure, instead of inconsistent design and chopped-down “Pro” graphics.

M4 is all about display engines and addressing machine learning throughout the CPU/GPU/NPU. At least, I’m going to guess that will be the focus next week. “AI” isn’t just about the NPU. With regard to display engines, really hoping M4 in the Mini, Studio, and Pro means new Studio and Pro displays…

[Edit to add that I think Activity Monitor is due for a rebuild. Perhaps I’m wrong, but it doesn’t look to me that the utility has been updated to account for Unified Memory and SoC silicon. It looks the same as I remember from years ago when trying to determine if I needed to add more RAM.]

 

[altaic]

I can't imagine what you would think of M4's Wikipedia page.

Apple M4 - Wikipedia

en.wikipedia.org

He probably thinks it’s incorrect, like me. I don’t find that hard to imagine at all. Did you check the citations? Vadim from Max Tech responding to TwistedAndy on twitter, and an article from The Register entitled “You OK, Apple? Seriously, your silicon lineup is … a mess.” 🫠

 

[thenewperson]

He probably thinks it’s incorrect, like me. I don’t find that hard to imagine at all. Did you check the citations? Vadim from Max Tech responding to TwistedAndy on twitter, and an article from The Register entitled “You OK, Apple? Seriously, your silicon lineup is … a mess.” 🫠

…they used MaxTech as a source?? That’s low.