Do they store 32-bit integers as 16-bit internally or how does macOS magically only use half the RAM? Hint: it doesn’t.
As a Mac programmer I can give you a real answer… there are three major differences… but before I go into those, almost all integers in native Mac apps are 64 bit. 128 bit is probably more common than 32.
First of all Mac software generally doesn’t use garbage collection. It uses “Automatic Reference Counting” which is far more efficient. Back when computers had kilobytes of RAM, reference counting was the standard with programmer painstakingly writing code to clear things from memory the moment it wasn’t needed anymore. The automatic version of that is the same, except the compiler writes the code for you… and it tends to do an even better job than a human, since it doesn’t get sloppy.
Garbage collection, the norm on modern Windows and Linux code, frankly sucks. Code that, for example, reads a bunch of files on disk might store all of those files in RAM for for ten seconds even if it only needs one of them in RAM at a time. That burn be 20GB of memory and push all of your other apps out into swap. Yuck.
Second, swap, while it’s used less (due to reference counting), still isn’t a “last resort” on Macs. Rather it’s a best practice to use swap deliberately for memory that you know doesn’t need to be super fast. A toolbar icon for example… you map the file into swap and then allow the kernel to decide if it should be copied into RAM or not. Chances are the toolbar doesn’t change for minutes at a time or it might not even be visible on the screen at all - so even if you have several gigabytes of RAM available there’s a good chance the kernel will kick that icon out of RAM.
And before you say “toolbar icons are tiny” - they’re not really. The tiny favicon for beehaw is 49kb as a compressed png… but to draw it quickly you might store it uncompressed in RAM. It’s 192px square and 32 bit color so 192 x 192 x 32 = 1.1MB of RAM for just one favicon. Multiply that by enough browser tabs and… Ouch. Which is why Mac software would commonly have the favicon as a png on disk, map the file into swap, and decompress the png every time it needs to be drawn (the window manager will keep a cache of the window in GPU memory anyway, so it won’t be redrawn often).
Third, modern Macs have really fast flash memory for swap. So fast it’s hard to actually measure it, talking single digit microseconds, which means you can read several thousand files off disk in the time it takes the LCD to refresh. If an app needs to read a hundred images off swap in order to draw to the screen… the user is not going to notice. It will be just as fast as if those images were in RAM.
Sure, we all run a few apps that are poorly written - e.g. Microsoft Teams - but that doesn’t matter if all your other software is efficient. Teams uses, what, 2GB? There will be plenty left for everything else.
Of course, some people need more than 8GB. But Apple does sell laptops with up to 128GB of RAM for those users.
Almost all programs use both 32bit and 64bit integers, sometimes even smaller ones, if possible. Being memory efficient is critical for performance, as L1 caches are still very small.
Garbage collection is a feature of programming languages, not an OS. Almost all native linux software is written in systems programming languages like C, Rust or C++, none of which have a garbage collector.
Swap is used the same way on both linux and windows, but kicking toolbar items out of ram is not actually a thing. It needs to be drawn to the screen every frame, so it (or a pixel buffer for the entire toolbar) will kick around in VRAM at the very least. A transfer from disk to VRAM can take hundreds of milliseconds, which would limit you to like 5 fps, no one retransfers images like that every frame.
Also your icon is 1.1Mbit not 1.1MB
I have a gentoo install that uses 50MB of ram for everything including its GUI. A webbrowser will still eat up gigabytes of ram, the OS has literally no say in this.
My 32/16 bit integer example was just that: an example where one was half the size as the other. Take 128/64 or whatever, doesn’t matter as it doesn’t work like that (which was my point).
Software written in non-GC based languages runs on other operating systems as well.
I used MS Teams as an example, but it’s hardly an exception when it comes to Electron/WebView/CEF apps. You have Spotify running, maybe a password manager (even 1Password uses Electron for its GUI nowadays), and don’t forget about all the web apps you have open in the browser, like maybe GMail and some Google Docs spreadsheet.
And sure, Macs have fast flash memory, but so do PC notebooks in this price range. A 990 Pro also doesn’t set you back $400 per terabyte, but more like … $80, if even that. A fifth. Not sure where you got that they are so fast it’s hard to measure.
There are tests out there that clearly show why 8 GB are a complete joke on a $1600 machine.
So no, I still don’t buy it. I use a desktop Windows/Linux machine and a MacBook Pro (M1 Max) and the same workflows tend to use very similar amounts of memory (what a surprise /s).
As a Mac programmer I can give you a real answer… there are three major differences… but before I go into those, almost all integers in native Mac apps are 64 bit. 128 bit is probably more common than 32.
First of all Mac software generally doesn’t use garbage collection. It uses “Automatic Reference Counting” which is far more efficient. Back when computers had kilobytes of RAM, reference counting was the standard with programmer painstakingly writing code to clear things from memory the moment it wasn’t needed anymore. The automatic version of that is the same, except the compiler writes the code for you… and it tends to do an even better job than a human, since it doesn’t get sloppy.
Garbage collection, the norm on modern Windows and Linux code, frankly sucks. Code that, for example, reads a bunch of files on disk might store all of those files in RAM for for ten seconds even if it only needs one of them in RAM at a time. That burn be 20GB of memory and push all of your other apps out into swap. Yuck.
Second, swap, while it’s used less (due to reference counting), still isn’t a “last resort” on Macs. Rather it’s a best practice to use swap deliberately for memory that you know doesn’t need to be super fast. A toolbar icon for example… you map the file into swap and then allow the kernel to decide if it should be copied into RAM or not. Chances are the toolbar doesn’t change for minutes at a time or it might not even be visible on the screen at all - so even if you have several gigabytes of RAM available there’s a good chance the kernel will kick that icon out of RAM.
And before you say “toolbar icons are tiny” - they’re not really. The tiny favicon for beehaw is 49kb as a compressed png… but to draw it quickly you might store it uncompressed in RAM. It’s 192px square and 32 bit color so 192 x 192 x 32 = 1.1MB of RAM for just one favicon. Multiply that by enough browser tabs and… Ouch. Which is why Mac software would commonly have the favicon as a png on disk, map the file into swap, and decompress the png every time it needs to be drawn (the window manager will keep a cache of the window in GPU memory anyway, so it won’t be redrawn often).
Third, modern Macs have really fast flash memory for swap. So fast it’s hard to actually measure it, talking single digit microseconds, which means you can read several thousand files off disk in the time it takes the LCD to refresh. If an app needs to read a hundred images off swap in order to draw to the screen… the user is not going to notice. It will be just as fast as if those images were in RAM.
Sure, we all run a few apps that are poorly written - e.g. Microsoft Teams - but that doesn’t matter if all your other software is efficient. Teams uses, what, 2GB? There will be plenty left for everything else.
Of course, some people need more than 8GB. But Apple does sell laptops with up to 128GB of RAM for those users.
Almost all programs use both 32bit and 64bit integers, sometimes even smaller ones, if possible. Being memory efficient is critical for performance, as L1 caches are still very small.
Garbage collection is a feature of programming languages, not an OS. Almost all native linux software is written in systems programming languages like C, Rust or C++, none of which have a garbage collector.
Swap is used the same way on both linux and windows, but kicking toolbar items out of ram is not actually a thing. It needs to be drawn to the screen every frame, so it (or a pixel buffer for the entire toolbar) will kick around in VRAM at the very least. A transfer from disk to VRAM can take hundreds of milliseconds, which would limit you to like 5 fps, no one retransfers images like that every frame.
Also your icon is 1.1Mbit not 1.1MB
I have a gentoo install that uses 50MB of ram for everything including its GUI. A webbrowser will still eat up gigabytes of ram, the OS has literally no say in this.
My 32/16 bit integer example was just that: an example where one was half the size as the other. Take 128/64 or whatever, doesn’t matter as it doesn’t work like that (which was my point).
Software written in non-GC based languages runs on other operating systems as well.
I used MS Teams as an example, but it’s hardly an exception when it comes to Electron/WebView/CEF apps. You have Spotify running, maybe a password manager (even 1Password uses Electron for its GUI nowadays), and don’t forget about all the web apps you have open in the browser, like maybe GMail and some Google Docs spreadsheet.
And sure, Macs have fast flash memory, but so do PC notebooks in this price range. A 990 Pro also doesn’t set you back $400 per terabyte, but more like … $80, if even that. A fifth. Not sure where you got that they are so fast it’s hard to measure.
There are tests out there that clearly show why 8 GB are a complete joke on a $1600 machine.
So no, I still don’t buy it. I use a desktop Windows/Linux machine and a MacBook Pro (M1 Max) and the same workflows tend to use very similar amounts of memory (what a surprise /s).