Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

whitedragon101

macrumors 65816
Original poster
Sep 11, 2008
1,349
339
At the moment I have an intel i7 Mac mini with 32GB ram. Before I had an intel 2011 i7 MBP with 16GB and I kept hitting the RAM limit and the system would bog down (from having multiple apps open not one big load like an 8k vid encode).
Do the apple silicone Macs deal better with 16GB with having lots open?

(I’m a developer. Running things like phpStorm, symfony server, docker, multiple browsers, loads of tabs, background processes etc)
 

ssmed

macrumors 6502a
Sep 28, 2009
885
423
UK
I would wait for the 2nd generation machines, should not be long now. Its certainly possible to overwhelm a M1 MBP with 16GB ram with heavy photoshop actions, whilst doing a few other things. It will depend how many of your applications are native I suppose.
 

ian87w

macrumors G3
Feb 22, 2020
8,704
12,638
Indonesia
At the moment I have an intel i7 Mac mini with 32GB ram. Before I had an intel 2011 i7 MBP with 16GB and I kept hitting the RAM limit and the system would bog down (from having multiple apps open not one big load like an 8k vid encode).
Do the apple silicone Macs deal better with 16GB with having lots open?

(I’m a developer. Running things like phpStorm, symfony server, docker, multiple browsers, loads of tabs, background processes etc)
If you are used to 32GB of RAM, don't buy now. Wait till Apple Silicon Macs offer 32GB of RAM as well. Do not believe those saying some magical equivalence of Apple Silicon needing less RAM. RAM is RAM, and the apps will need whatever amount of RAM they need.

So, wait.
 

Jorbanead

macrumors 65816
Aug 31, 2018
1,209
1,438
32Gb on intel does not equal 16Gb on apple silicon. My understanding is that Apple Silicon handles RAM more efficiently than intel (gaining some technology used in iPhones to efficiently swap out ram quickly). It does heavily depend on your workflow. Some applications will seemingly utilize less RAM on apple silicon, while others will still need the same amount. It really just depends on how that app uses RAM.

My suggestion, just like everyone else, is to wait for a 32Gb option, especially if you were hitting the RAM limit on 16Gb. You don't ever want to be in a situation where you run into limits and wish you would have gotten 32Gb.
 

radus

macrumors 6502a
Jan 12, 2009
720
447
Or just buy a M1 Mac Mini 16GB smallest SSD -may be used or refurbished- to test it using your workflow.
This should not be to expensive.
 

senttoschool

macrumors 68030
Nov 2, 2017
2,626
5,482
At the moment I have an intel i7 Mac mini with 32GB ram. Before I had an intel 2011 i7 MBP with 16GB and I kept hitting the RAM limit and the system would bog down (from having multiple apps open not one big load like an 8k vid encode).
Do the apple silicone Macs deal better with 16GB with having lots open?

(I’m a developer. Running things like phpStorm, symfony server, docker, multiple browsers, loads of tabs, background processes etc)
I run a similar load and my M1 8GB struggles sometimes but it's still very very usable. Ideally, I should have 16GB or even 32GB.

I also Electron/Browser-based apps like Whatsapp, Slack, Notion, Spotify, Figma, VSCode, and others.

I will say that my computer runs smoother than my old 2015 MBP with 16GB of RAM and I have had little issues running the same workload or more.

That said, I will be upgrading to the 16" MBP on day one and try to load it with as much RAM as possible.
 

leman

macrumors Core
Oct 14, 2008
19,522
19,679
Observations and tests suggest that Apple Silicon machines are somewhat better at juggling the memory around — that is, if you have multiple large applications running, but only use one at a time, there is a god change that you won't notice a slowdown. Of course, if all your large applications are doing something (e.g. you are encoding video while compiling a large application while running five database docker containers and a VM with an active web crawler), you will run out of RAM — although in that particular case you will probably run out of CPU resources earlier.
 

mr_roboto

macrumors 6502a
Sep 30, 2020
856
1,867
32Gb on intel does not equal 16Gb on apple silicon. My understanding is that Apple Silicon handles RAM more efficiently than intel (gaining some technology used in iPhones to efficiently swap out ram quickly). It does heavily depend on your workflow. Some applications will seemingly utilize less RAM on apple silicon, while others will still need the same amount. It really just depends on how that app uses RAM.
Apple Silicon doesn't handle RAM allocation at all. That's done by macOS, not hardware.

Apple kept all the basic data types the same size, so data should occupy about the same amount of RAM.

There is no special swapping technology that was only possible in iPhones before Apple began transitioning the Mac. We know this because iPhones and iPads do not implement swapping at all! The iOS substitute for VM is to force backgrounded applications to quit whenever the foreground app needs more RAM. When it does this, it takes a screenshot of the app being asked to quit, and gives the app a short amount of time to write out a tiny data file which the app can use to resume its current UI state the next time it gets started up. The screenshot is used in Apple's app-switching UI. If the user tries to switch back to an app which looks like it's running, but isn't, the screenshot is also something to put up immediately so it looks like it's already running even though it's restarting.

The only reason M1 Macs have a rep for swapping faster than Intel Macs is that in many cases, the M1 SSD is much faster than what was in the outgoing x86 Mac models.
 

leman

macrumors Core
Oct 14, 2008
19,522
19,679
Apple Silicon doesn't handle RAM allocation at all. That's done by macOS, not hardware.

Apple kept all the basic data types the same size, so data should occupy about the same amount of RAM.

There is no special swapping technology that was only possible in iPhones before Apple began transitioning the Mac. We know this because iPhones and iPads do not implement swapping at all! The iOS substitute for VM is to force backgrounded applications to quit whenever the foreground app needs more RAM. When it does this, it takes a screenshot of the app being asked to quit, and gives the app a short amount of time to write out a tiny data file which the app can use to resume its current UI state the next time it gets started up. The screenshot is used in Apple's app-switching UI. If the user tries to switch back to an app which looks like it's running, but isn't, the screenshot is also something to put up immediately so it looks like it's already running even though it's restarting.

The only reason M1 Macs have a rep for swapping faster than Intel Macs is that in many cases, the M1 SSD is much faster than what was in the outgoing x86 Mac models.

I am not so sure about this. There are important differences between x86 and ARM macOS. For example, the ARM version uses 16KB memory pages, which alone will have significant impact on paging. Interrupts are faster on Apple Silicon. Also, do we know for sure that Apple is using the same paging algorithm on x86 and ARM? Given Apple's obsession with low-level optimizations I wouldn't be surprised if they have a fast path for it.

There is a paper I quoted a while ago that analyses swap performance on major implementation and they conclude that OS-overhead is non-trivial in most cases. The swap-incurred delays had a long tail, with some page swaps reaching into milliseconds. It is therefore no surprise that paging can result in noticeable lag. Simply making the latency more predictable (something that is definitely technically possible with Apple's custom hardware) would mean a major usability improvement.
 
  • Like
Reactions: Jorbanead

senttoschool

macrumors 68030
Nov 2, 2017
2,626
5,482
The only reason M1 Macs have a rep for swapping faster than Intel Macs is that in many cases, the M1 SSD is much faster than what was in the outgoing x86 Mac models.
Interesting thing is, high-end PCI-E 4.0 SSDs are now up to 7,000 Mb/s while the M1 Macs only go up to 2,600 Mb/s.

So MacOS swapping can improve a lot in the future.
 

leman

macrumors Core
Oct 14, 2008
19,522
19,679
Interesting thing is, high-end PCI-E 4.0 SSDs are now up to 7,000 Mb/s while the M1 Macs only go up to 2,600 Mb/s.

So MacOS swapping can improve a lot in the future.

I think swapping is much more reliant on latency and not bandwidth. You are not going to be swapping GBs of data (and if you are, how have a major problem). You will be swapping KBs, maybe MBs at a time, and you want it to be done as quickly as possible. High throughput SSD won’t help you. Low latency protocols and low-overhead swapping algorithms are much more important.
 
  • Like
Reactions: senttoschool

mr_roboto

macrumors 6502a
Sep 30, 2020
856
1,867
I am not so sure about this. There are important differences between x86 and ARM macOS. For example, the ARM version uses 16KB memory pages, which alone will have significant impact on paging.Interrupts are faster on Apple Silicon. Also, do we know for sure that Apple is using the same paging algorithm on x86 and ARM? Given Apple's obsession with low-level optimizations I wouldn't be surprised if they have a fast path for it.

There is a paper I quoted a while ago that analyses swap performance on major implementation and they conclude that OS-overhead is non-trivial in most cases. The swap-incurred delays had a long tail, with some page swaps reaching into milliseconds. It is therefore no surprise that paging can result in noticeable lag. Simply making the latency more predictable (something that is definitely technically possible with Apple's custom hardware) would mean a major usability improvement.
Call me skeptical. The main thing which might take a while is the search for pages to evict from RAM. This can get complex because you'd like to evict pages which aren't likely to be needed until long in the future. There's no way to actually predict that with 100% accuracy, but the closer you get to perfect accuracy, the higher performance you'll maintain when swapping. Operating systems use a wide variety of techniques for estimating which pages are best to evict, and some of them have relatively high overhead.

But that kind of thing isn't a great candidate for HW acceleration. A lot of the work is going to be pointer-chasing through page tables, which isn't helped a ton by HW. And if you decide you want to change your algorithm in a future OS release, will the existing HW accel still work? Not obvious it would, unless it's really just a helper CPU.

I did remember while writing this that we do know of one custom extension. It helps with the intermediate tier of swapping they introduced several OS releases ago. Under low memory pressure, they avoid swapping to disk by compressing pages and keeping the compressed data in RAM.

On Intel Macs, the "codec" is implemented in software. M1 Macs don't change the compression algorithm at all, but they do have a HW codec invoked by running a couple Apple-custom Arm instructions. Presumably it's faster and more power-efficient than the SW codec.

But for what we traditionally think of as swapping - sending it all the way out to a disk - I tend to doubt there's any meaningful way to add HW accel.
 

PsykX

macrumors 68030
Sep 16, 2006
2,747
3,926
If you are used to 32GB of RAM, don't buy now. Wait till Apple Silicon Macs offer 32GB of RAM as well. Do not believe those saying some magical equivalence of Apple Silicon needing less RAM. RAM is RAM, and the apps will need whatever amount of RAM they need.

So, wait.
I had a 32GB iMac in 2013. I've gotta say, I'm a very intense computer guy, with a bunch of creative apps opened, barely used the 32GB.

I bought an 8GB M1 iMac while waiting for the real thing, because my 2013 iMac was starting to have a few unsupported things.

Sometimes I have a popup that appears, which I've NEVER had before, that suggests me to close an app to free up memory. It looks like the Force quit popup. Memory pressure is in the yellow. Really disappointed.

(In all honesty, it's mainly because M$ Teams is taking up like 5GB for itself. Unoptimized Electron crap.)
 
  • Like
Reactions: Alex_Mac and ian87w

ian87w

macrumors G3
Feb 22, 2020
8,704
12,638
Indonesia
I had a 32GB iMac in 2013. I've gotta say, I'm a very intense computer guy, with a bunch of creative apps opened, barely used the 32GB.

I bought an 8GB M1 iMac while waiting for the real thing, because my 2013 iMac was starting to have a few unsupported things.

Sometimes I have a popup that appears, which I've NEVER had before, that suggests me to close an app to free up memory. It looks like the Force quit popup. Memory pressure is in the yellow. Really disappointed.

(In all honesty, it's mainly because M$ Teams is taking up like 5GB for itself. Unoptimized Electron crap.)
Your experience reflects the real world situations. Not all apps will be highly optimized native Apple Silicon apps. Expecting Apple Silicon to magically use less FAM is naive at best.

And I'm really disappointed that Apple don't have a default config of current AS macs with 16GB RAM. In my country, there's no BTO option. So all we have are highly marked up expensive Macs with paltry 8GB RAM.
 
  • Like
Reactions: PsykX and Ruftzooi

Krevnik

macrumors 601
Sep 8, 2003
4,101
1,312
But for what we traditionally think of as swapping - sending it all the way out to a disk - I tend to doubt there's any meaningful way to add HW accel.

That’s actually related to why the page size change matters, though.

The throughput of SSDs when doing small transactions is more bound by the number of IO operations per second. So doing them in larger chunks helps a lot here. But even then, 16KB throughput to the M1 SSD is more than 4x that of the 4KB throughput. So there’s some additional perf gain on top. A 16KB transaction is simply less expensive than a 4KB one, despite providing 4x the data.

That means it takes slightly less time to evict or fault in a 16KB page on M1, than a 4KB page on Intel. And evicting one of these larger pages means you free up more memory in one go, so you are evicting pages less frequently when faced with the same usage pattern. Good data locality amplifies this further. But at the end of the day, it still means that the M1 effectively spends around 1/4th the time an Intel machine would handling swapping in the same usage.

So the M1 has a few tricks up it’s sleeve that does make page handling a little less expensive, which can help make swap use feel less punishing, leading to a smoother experience. It doesn’t mean you need less RAM than on Intel though, and with writes being a finite resource on an SSD, I wouldn’t be wanting to lean on the swap file to avoid having the extra RAM.

We know this because iPhones and iPads do not implement swapping at all! The iOS substitute for VM is to force backgrounded applications to quit whenever the foreground app needs more RAM.

As a developer that worked on a large iOS project, this is quite imprecise. The only difference between iOS and macOS’s VM implementation is that iOS disables the swap file. So while you are technically right, it misses the fact that memory compression and page eviction are still tools in the iOS box for RAM management.

Code locality made it easier on the system to evict code pages for features that weren’t frequently used, freeing up memory without forcing other apps to be quit. And we definitely saw iOS’ behavior that killing an app was last resort. Page evictions were the first thing iOS did before it would start doing that. Especially on the iPad.

Memory mapped files that were read-only (fonts) are also easy to evict and read again later.

Fixed/empty pages are cheap. Always evict them first. :)
 
Last edited:

PsykX

macrumors 68030
Sep 16, 2006
2,747
3,926
Your experience reflects the real world situations. Not all apps will be highly optimized native Apple Silicon apps. Expecting Apple Silicon to magically use less FAM is naive at best.

And I'm really disappointed that Apple don't have a default config of current AS macs with 16GB RAM. In my country, there's no BTO option. So all we have are highly marked up expensive Macs with paltry 8GB RAM.
Exactly.

I mean, for the casual guy who just surfs the web, uses email, takes notes... 8GB should be OK. I've seen a few capsules from WWDC and they did convince me that 8 GB with a SOC is worth more than 8 GB in a traditional PC.

But if you're doing some real work with Office apps, or creative work (FCPX, Adobe stuff, Sketch, etc.)... 16GB is the bare minimum anyone should consider.

And I think the PC world is more and more oriented towards 16GB as the base configuration.

I'm glad I already knew my setup was to be temporary.
I would be extremely deceived if it were my computer for the next 3 years.
 
  • Like
Reactions: Alex_Mac

pshufd

macrumors G4
Oct 24, 2013
10,151
14,574
New Hampshire
I have an M1 mini with 16 GB of RAM and max swap of 200 MB. I run my office stuff on this system and it's fine. I also have a Windows desktop with 128 GB of RAM and a CPU/GPU that's a little more powerful than the M1. I run my production on that system. If you are worried about RAM, you could use your Intel mini and your M1 mini together. And run some things on the Intel and some on the Apple Silicon.

I was considering buying a second M1 mini - that way I'd get an M1X - though in two systems. I can partition my workload easily though.
 

dogslobber

macrumors 601
Oct 19, 2014
4,670
7,809
Apple Campus, Cupertino CA
At the moment I have an intel i7 Mac mini with 32GB ram. Before I had an intel 2011 i7 MBP with 16GB and I kept hitting the RAM limit and the system would bog down (from having multiple apps open not one big load like an 8k vid encode).
Do the apple silicone Macs deal better with 16GB with having lots open?
There will be at least a 600$ markup for a 32GB M1 Mini.
 

ADGrant

macrumors 68000
Mar 26, 2018
1,689
1,059
On Intel Macs, the "codec" is implemented in software. M1 Macs don't change the compression algorithm at all, but they do have a HW codec invoked by running a couple Apple-custom Arm instructions. Presumably it's faster and more power-efficient than the SW codec.

But for what we traditionally think of as swapping - sending it all the way out to a disk - I tend to doubt there's any meaningful way to add HW accel.
I am not sure what you mean by codec. However all the current Intel Macs have a T2 coprocessor which manages the SSD. The T2 is based on the A10, an Apple designed ARM64 SoC. I doubt the M1 is significantly better at HW accelerated compression.
 

senttoschool

macrumors 68030
Nov 2, 2017
2,626
5,482
I think swapping is much more reliant on latency and not bandwidth. You are not going to be swapping GBs of data (and if you are, how have a major problem). You will be swapping KBs, maybe MBs at a time, and you want it to be done as quickly as possible. High throughput SSD won’t help you. Low latency protocols and low-overhead swapping algorithms are much more important.
Yea you're right.

This is where something like Intel's Optane, which has much faster latency than normal SSDs, could boost quite a bit for those who are RAM starved.
 

senttoschool

macrumors 68030
Nov 2, 2017
2,626
5,482
And I think the PC world is more and more oriented towards 16GB as the base configuration.
Not really.

I looked around and found that most Windows laptops in the class of the Macbook Air start at 8GB as well. I'm talking about quality thin and light laptops.

For example, the new Dell 13" XPS starts at 8GB/256GB with a price of $1050.

Sure, the cheapo PCs that use low-quality components and screens and has poor battery life might start at 16GB.
 
  • Like
Reactions: pshufd

PsykX

macrumors 68030
Sep 16, 2006
2,747
3,926
Not really.

I looked around and found that most Windows laptops in the class of the Macbook Air start at 8GB as well. I'm talking about quality thin and light laptops.

For example, the new Dell 13" XPS starts at 8GB/256GB with a price of $1050.

Sure, the cheapo PCs that use low-quality components and screens and has poor battery life might start at 16GB.
MacBook Air is supposed to be a low-end laptop.
I was talking about low-to-mid-end desktop PCs and mid-to-high end laptops.

Do you think it's normal to start only at 8GB in an iMac or a MBP? Baseline should be 16GB.
MBA I'm OK with 8.
 

pshufd

macrumors G4
Oct 24, 2013
10,151
14,574
New Hampshire
MacBook Air is supposed to be a low-end laptop.
I was talking about low-to-mid-end desktop PCs and mid-to-high end laptops.

Do you think it's normal to start only at 8GB in an iMac or a MBP? Baseline should be 16GB.
MBA I'm OK with 8.

The iMac 27 has been 8 GB base for a very long time. I see these used locally with people stating that they run a little slow. They don't realize that popping in another 8 GB or more will improve performance.considerably, particularly if they have a Fusion drive. This morning I went to run a program already started and it took about ten seconds to come up. I checked my RAM usage and swap was at 1 GB. I have never seen it that high before. I killed Firefox and it dropped in half. This is an old system though and it's probably been left on for a few months.

It's nice having 128 GB on a system - you literally never worry about swapping and a good chunk of your SSD is cached.
 

mr_roboto

macrumors 6502a
Sep 30, 2020
856
1,867
I am not sure what you mean by codec. However all the current Intel Macs have a T2 coprocessor which manages the SSD. The T2 is based on the A10, an Apple designed ARM64 SoC. I doubt the M1 is significantly better at HW accelerated compression.
Codec is shorthand for an encoder/decoder pair. Most use it to describe lossy video or audio codecs, like MP3, but it can also be used for lossless compression like this.

I don't think I described what Apple did in M1 well enough. It's a pair of CPU instructions which compress or decompress pages. There is no round-trip through the M1's SSD controller, these are RAM-to-RAM operations. That makes sense - one of the main reasons to implement compression as an intermediate alternative to actual swapping to disk is to avoid any I/O operations, since I/O is always costly (even if it's to a very fast NVMe device).

On Intel Macs, it is well known that this codec was implemented in software. You can find the source code for it in public Darwin kernel sources. Even if T2's Hurricane and Zephyr application processor cores already have the special instruction pair, they wouldn't be involved, because just like on Arm Macs, you don't want to perform an I/O operation, and all communications with T2 are a form of I/O.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.