View Single Post
Old 11-23-2022, 02:08 PM
Darryl Ramm Darryl Ramm is online now
Join Date: Nov 2010
Location: USA
Posts: 17,511
Default Re: m1 running HD for post, 32 or 64gb ram?

Originally Posted by its2loud View Post
Open up a large session on your Intel machine. Go into System Monitor and under Memory tab take a look at how much RAM Pro Tools and Pro Tools Video Engine are using.
While this is a start, unfortunately with modern demand paged operating systems like macOS this does not show you what applications actually need. A system with physically lots of memory will tend to use lots of memory because macOS is never under significant pressure to free up memory and running applications will tend to bloat. While this is actually a very good design and behavior it does tend to confuse memory need discussions. And macOS or other modern demand paged OSes free up memory comes in multiple flavors which confuses things more. Things are quite complicated under the surface, beside the demand paging complexity macOS (and other modern OSes) also use memory compression on Intel and Apple Silicon systems.

A user can easily tell they have enough memory when things are running well, and they can look at some memory usage stats and think they means something useful, but they can't easily tell how much more than enough memory they have... and it's often not important since memory is not expensive and heck things are working well. We get into a different risk area where folks start trying to justify how little memory can they get away with... esp. driven by things like low memory limits in early Apple Silicon Systems. And in that case you need more careful/technical testing to make strong assertions. Which in practice may mean running the system with decreasing amounts of memory and seeing where it hits the point where it really starts to run out of memory. If folks really want to make hard claims here I would expect to see testing done using Macs carefully placed under memory pressure (e.g. reconfigure memory at boot time via boot-args="maxmem=xx" or using tools like the memory_pressure utility shipped with macOS, and developers will often write their own things like that, memory balloons that pin themselves in memory and expand to put other apps under pressure/see how they do at decreasing real memory availability).

When looking at anything memory related the first metric you should be looking at there to start with is the macOS "memory pressure" shown in Activity Monitor, it's showing how much work macOS is doing to free/page out memory.

Assumption with Apple Silicon systems probably should be,

1. Memory works the same as on Intel systems, Pro Tools uses a significant amount of memory for data (as opposed to text/code), it does not matter if it's an intel processor or an Apple silicon processor allocating a variable or a buffer or whatever it's the same amount of memory.
2. Intel code on an Apple Silicon System is running via Rosetta 2 and the runtime environment consumes some extra memory. That will probably not be too significant for already large Pro Tools sessions, for smallest sessions it may be.
3. Apple silicon based systems being RISC might consume slightly more memory became of less binary code density, but this amount is maybe lost in the noise and highly dependent on compiler technology (on both Apple Silicon and Intel sides).
4. An impression that you need less memory on an Apple Silicon system may be coming from:
A. Improper measurement/not understanding how demand paging works when comparing systems.
B. Fast demand paging to the internal SSD on Apple Silicon systems. If you rely on that you may see Pro Tools stability issues well before other apps have problems, and you might induce wear on your expensive hard to repair/replace internal SSD. Yes in some cases this can mean less memory being needed, but there can be dragons lurking there. And nobody want dragons while you are trying to get real work done.

One trap in all this is if the system appears to be running OK to the user, but internally has been workin hard to free memory... and Apple Silicon Systems have very fast demand paging back to the SSD. That's where it's going to write modified data pages to SSD to free modified data pages in memory. If the pages are not modified and are just blank, macOS will just release them if it needs space, it can create a new blank page in future. If it's a text/executable code page then macOS just releases it, and reads back from the executable on disk in future. Think of a bloated web browsers like Chrome, most of it's memory use is modified data pages.... and the app is just bloated and likely to be significantly paged out if running on a small memory config Mac. The paging happens so fast on these new Macs that it might be unnoticed with users running normal apps. Folks won't noticed a few ms latency in the app every so often while scrolling a page, or an extra few 100ms when going to a new website... the website load is so slow anyhow. In days of HDD we'd notice this paging because it as so slow, and we'd hear the drives clicking away. It now happens much faster... but not fast enough...

So the dragons... Anybody know an app that uses a lot of memory and can't tolerate random latency being thrown at it? Yes, Pro Tools. If macOS on your system is pausing Pro Tools running, while it demand pages stuff for it, Pro Tools is eventually going to throw AAE CPU errors. yes even for relatively short pauses that never affect other apps and may never be noticed by users.

And more dragons... Some (non Pro Tools) users on the 8GB M1 MacBook Pros finally noticed that their system were paging a lot... and lots of modified data pages have been paged out to the SSD and as starting to affect the internal drive SSD expected life. And to be clear that's orders of magnitude more I/O that you would get to the internal SSD from say using Pro Tools... so while SSD drive wear with Pro tools is just not something I'd worry about, the sort of I/O possible from grossly under-configured memory is. Maybe to save us here Pro Tools users are maybe less likely than standard app users to do this to such and extreme, because if you push this hard enough Pro Tools will just crash with AAE CPU errors because it can't handle the latency. Pro Tools users with Apple Silicon Macs with small memory might want to keep an eye on memory pressure stats, and certainly if running in to CPU errors then look at this more/suspect it might be memory related.

So hopefully folks can see where it's possible some of the claims/"proof" of Apple Silicon needing less memory come from... somebody runs there sessions on an Intel mac, it's never under any significant memory pressure, expands to use what is there and users look at the memory that macOS claims is being used. They then run that on an Apple Silicon Mac, and it might face more memory pressure and macOS frees some of the memory that was never actually needed to be there in the first place. Now macOS reports Pro Tools is using less memory... except you would have likely seen the same had they tested in an Intel Mac with the same memory. Don't be a fool and blindly believe these frequently incorrectly done measurement approaches shows that you can use the same claimed memory saving ratio to size the Apple Silicon Mac memory you need.


But I really think the bottom line is start with at least what you have on your Intel Mac and if unsure get as much memory as you can, it does not hurt and memory use is only going to increase. Yes I know there are corner cases where it mean jumping up in cost to get to more memory. if you really need to work out how little memory you can get away with then do proper measurements by deconfiguring some of your Intel system's memory. For my own use I just could not get away with in < 32 GB and I want 64 GB to be comfortable, not just for Pro Tools. I expect my computers to last ~4 years and I have no idea what increasing memory needs will come in future. I just tend to always max the memory on them (or for PCs/computers with user upgradable DIMMs I upgrade them myself after purchase).

Last edited by Darryl Ramm; 12-06-2022 at 01:47 PM.
Reply With Quote