For all those people saying "RAM is RAM"
RAM is RAM, and it will not behave differently on the M1 vs Intel in how RAM is managed. However, since the M1 uses Unified Memory, it doesn't need to allocate 1.5 GB right off the top solely to the iGPU, and when it comes to swap on the storage drive its faster then the read/write of the Flash memory of the models it replaced
and "Data is Data"
Bear with me as I try and illustrate something with code.
Code:
typedef struct Point {
UInt32 x;
UInt32 y;
} Point;
int main(int argc, char** argv) {
Point *p = malloc(sizeof(Point)*100);
printf("How much space is heap allocated?");
return 0;
}
It does not matter if you compile and run that on x86, ARM or any other architecture, it will always be a minimum of 6.4Kb allocated. Two 32 bit unsigned integers in a Point, and 100 points. There is no way for the CPU architecture to change the laws of physics on that.
I would like to point out that a lot of what gets stored in memory is software, a.k.a. code, a.k.a. machine language instructions. And on this point, the binary code compiled for Intel CPUs (
amd64
) is
completely different from the binary code compiled for Apple's M-series chips (
arm64
).
The Intel CPUs are what are known as Complex Instruction Set Computers (CISC), while the M-series CPUs are what is known as Reduced Instruction Set Computers (RISC). CISC CPUs came first, RISC CPUs came later. When RISC computers were first introduced, the defining trade-off was:
- CISC CPUs could take a single "complex" instruction, but it might take multiple clock cycles to execute.
- RISC CPUs only implemented "simple" instructions, but each ran in a single clock cycle.
As a result, the first RISC programs, when compiled down to machine language (which are called "binaries"), were much bigger (
took up more memory, sometimes as much as 4 times the memory) than the same source code compiled for a CISC CPU.
So it is completely reasonable to ask if M-series software will use more memory than Intel-based software. I certainly expected that to be the case.
As it turns out, for
a lot of reasons, RISC programs got shorter (binaries got smaller) and CISC programs got longer (binaries got bigger) as both architectures (and the compilers supporting them) have matured over the years. Now, the real-world examples of Apple software I have looked at that ship dual-architecture binaries (one for Intel, one for M-series)
all have
smaller M-series binaries than Intel binaries (around 10% smaller).
So we can conclude that
Apple M-series computers actually use less memory than Intel-based computers, at least
when they are running native code (as opposed to emulating Intel code), because the software binaries are the only thing that changes between the two architectures. On the flip side, due to the overhead of emulation, we can expect that Apple M-series computers use more memory than Intel-based computers when running Intel code under emulation, because in that case the OS needs both the Intel code and extra memory for the Rosetta translated M-series code, plus Rosetta code itself. How much more memory I don't know, but I've seen well researched estimates of 60% more memory
for the code itself. Again, the data usage will be the same. However, it is very rare for me to find applications that are bigger than 100 MB of code, so compared to everything else, any extra memory usage from Rosetta is likely to be negligible.
Regarding GPU memory usage, that will definitely eat into your memory. On Intel Macs, the graphics cards have built-in dedicated memory. Mine has 8 GiB, which I think is the max for Intel MacBooks, and it routinely runs out of memory the way I use my machine (lots and lots of open browser windows, each with multiple tabs). That 8 GiB is now going to come out of the total system memory rather than being an add-on. For me, running several external displays, I expect the GPU to use up considerably more than 8 GiB on an M-series Mac, but for me that is a good thing, because swapping memory off a video card is brutally slow. For a lot of people, the GPU might only use up less than 1 GiB, but it will use up something.
On the whole, though, I conclude that if you are on an Intel Mac and add your current system RAM size to your current video card VRAM size and get that amount of memory, you will likely have the same or better performance on the new machine. The main exception would be if you are running compute-intensive Intel software that is not available in M-series native format.