Skip Navigation
160 comments

  • Even if it was like 16GB on a PC still not worth $1.6k

    • Especially when 16g is something like $50.

      • At consumer prices. There's no way Apple doesn't pay wholesale rates for memory.

  • I felt getting ripped off by just reading the article. My recent PC build has 32 GB, is cheaper and the upgrade to 64 GB (meaning additional pair of 16 GB) only costs me around 100 Euros. It's nice that their devices are probably more effective and need less RAM, which the iPhones proved to be correct. But that does not mean the cost of the additional RAM units are more expensive. Apple chose to make them expensive.

  • 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.

    • Pied Piper middle out compression for your RAM

      But seriously it's so ridiculous especially since he said it in an interview with a machine learning guy. Exactly the type of guy who needs a lot of RAM for his own processes working on his own data using his own programs. Where the OS has no control over precision, access patterns or the data streaming architecture.

    • 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).

  • The best part is people complaining to them for pointing out that 8gb is laughable little. Ah, the sweet fanboys.

  • 🤖 I'm a bot that provides automatic summaries for articles: ::: spoiler Click here to see the summary With the launch of Apple's M3 MacBook Pros last month, a base 14-inch $1,599 model with an M3 chip still only gets you 8GB of unified DRAM that's shared between the CPU, GPU, and neural network accelerator.

    In a show of Apple's typical modesty, the tech giant's veep of worldwide product marketing Bob Borchers has argued, in an interview with machine learning engineer and content creator Lin YilYi, that the Arm-compatible, Apple-designed M-series silicon and software stack is so memory efficient that 8GB on a Mac may equal to 16GB on a PC – so we therefore ought to be happy with it.

    With that said, macOS does make use of several tricks to optimize memory utilization, including caching as much data as it can in free RAM to avoid running to and from slower storage for stuff (there's no point in having unused physical RAM in a machine) and compressing information in memory, all of which other operating systems, including Windows and Linux, do too in their own ways.

    Given a fast enough SSD, the degradation in performance associated with running low on RAM can be hidden to a degree, though it does come at the expense of additional wear on the NAND flash modules.

    We'd hate to say that Apple has designed its computers so that they perform stunningly in the shop for a few minutes, and work differently after a few months at home or in the office.

    His comment is also somewhat ironic in that much of the focus of YilYi's interview with Borchers centered around the use of Apple Silicon in machine-learning development, which you don't do in a store.

    Saved 71% of original text. :::

160 comments