284
Apple exec defends 8GB $1,599 MacBook Pro, claims it's like 16GB on a PC
(www.theregister.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 09 Nov 2023
284 points (100.0% liked)
Technology
37720 readers
356 users here now
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
Subcommunities on Beehaw:
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
Do they store 32-bit integers as 16-bit internally or how does macOS magically only use half the RAM? Hint: it doesn't.
Even if macOS was more lightweight than Windows - which might well be true will all the bs processes running in Windows 11 especially - third party multiplatform apps will use similar amounts of memory no matter the platform they run on. Even for simple use cases, 8 GB is on the limit (though it'll likely still be fine) as Electron apps tend to eat RAM for breakfast. Love it or hate it Apple, people often (need to) use these memory-hogging apps like Teams or even Spotify, they are not native Swift apps.
I love my M1 Max MacBook Pro, but fuck right off with that bullshit, it's straight up lying.
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.