What on earth are you programming?
Earth. He is programming the earth.
I'm asking because I read a lot of comments when it was released that it just doesn't need as much RAM because $REASONS. I wouldn't put my money on this, but I'm curious if this assumption holds water now that people have had time to try it out.
Edit: there are such comments further down the thread where it seems to still be a mystery: https://news.ycombinator.com/item?id=26913643
So I'd really like to know where this magic breaks down: if you're used to 128GB or RAM, will the M1 feel sluggish?
AAA gamedev might be the wrong demographic though, since it's mostly done on Windows (I think?).
128gb is likely overkill, but I can see a use case depending on what you're doing.
When the M1 first came out I was super super skeptical, seemed like an under powered chip compared to what's in the x86 world.
Now I'm convinced that it's got some magic inside it. Everyone I've talked to said it chews throw whatever they throw at it.
I'm consistently floored by Apple's ability to innovate.
Perhaps more than any other Apple innovation, we have the greatest visibility into the process with the M1.
Like Jobs said in his Stanford speech, “You can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.”
It seems like Apple uniquely combines open development of technology in known products with secrecy around new product development.
This allows people to be so surprised by the M1, when the late AX processors were obviously pointing toward massive capability.
I believe there are other examples of this happening--specifically with the Apple Watch.
On that product, the size limitations combined with increasing expectations of performance and functionality have allowed Apple learn and improve production-capability in many areas that will be in any forthcoming AR/VR products.
Apple collects a lot of metrics and I’m sure they know this well.
Flagship iPhones always have less ram than flagship androids, but match or exceed their performance.
Most business users were fine with 4GB 5-6 years ago. Electron apps like Teams and Slack pushed it up to 8. The next tier are folks with IDEs, docker, etc that are usually 16-32GB.
Getting some down votes, which I attribute to reasonable skepticism, so hopefully this will allay your concerns.
Such as?
I haven't seen a modern computer struggle with that kind of workload before.
With Firefox and auto tab suspend (addon), it's manageable.
My desktop is an ML container train/test machine. I also have ssh into two similar machines, and a 5 machine, 20GPU k8s cluster. I pretty much continuously have dozens of things building /running at once.
Maybe I'm an outlier though?
On my particular team we also run a dockerfile that includes elastic search, sql server, rabbitmq and consul—-I had to upgrade my work laptop from 16GB to 24GB to make it livable.
Though truth is that I use zram, which everyone should who is not fortunate enough to have plenty of RAM, but does have a decent CPU.
If you're on macOS, there's no such thing as a “lightweight Docker container”. The container itself might be small, but Docker itself is running a full Linux virtual machine. In no world is that “lightweight”.
I do most of my development in Chrome, bash, and sublime text and I'm still using 28GB of RAM.
10 klocs is huge for a student project but tiny for a real-world project.
The Apple stack is better optimized to take advantage of the hardware they have. Indeed, one of the reasons is because they have so few SKUs to worry about it focuses the engineering team (for example, in the past, internally engineers would complain about architectural design missteps that couldn’t be fixed because 32bit support wasn’t dropped yet and was pushed out yet another year). Now, obviously in a laptop use-case this is trickier since the source code is the same as the x86 version. It’s possible that the ARM code generation was much more space efficient (using -Oz instead of previously likely set at -O3). It’s also possible that they have migrated over to iOS frameworks in an even greater part than they were able to in the past, leveraging RAM optimizations that hadn’t been ported to macos). There could also be RAM usage optimizations baked around knowing you will always have a blazing fast NVME drive. Now you may not even need to keep data cached around and can just load straight from disk. Sure, not all workloads might fit (and if running x86 emulation the RAM hit might be worse). For a lot of use cases though, even many dev ones, it’s clearly enough. I wouldn’t be surprised if Apple used telemetry to make an intelligent bet around the amount of RAM they’d need.
I didn't claim it was all that matters, and I haven't seen anyone else do that either.
I do take the point of the rest of your comment though, and it may well be the case that Apple does some clever stuff. But realistically there is only so far that optimisations can take it - DDR4 is DDR4, and it's the workload that makes the most difference.
> I wouldn’t be surprised if Apple used telemetry to make an intelligent bet around the amount of RAM they’d need.
Your average Apple user is likely not a developer though (as others are very often pointing out on HN, whenever they make non-dev-friendly hardware choices). Furthermore, I would think such telemetry would be a self-fulfilling prophecy; if you have a pitiful 8GB of RAM, you're not going to punish yourself by trying to run workloads you know it wouldn't support.
Except the M1 is a novel UMA architecture where the GPU & CPU share RAM. There's all sorts of architectural improvements you get out of that where you can void memory transfers wholesale. There's no "texture upload" phase & reading back data from the GPU is just as fast as sending data to the GPU. Wouldn't surprise me if they leveraged that heavily to get improvements across the SW stack. The CPU cache architecture also plays a big role in the actual performance of your RAM. Although admittedly maybe the M1 doesn't have any special sauce here that I've seen, just responding to your claim that "DDR4 is DDR4" (relatedly, DDR4 comes in different speeds SKUs).
> Your average Apple user is likely not a developer though (as others are very often pointing out on HN, whenever they make non-dev-friendly hardware choices). Furthermore, I would think such telemetry would be a self-fulfilling prophecy; if you have a pitiful 8GB of RAM, you're not going to punish yourself by trying to run workloads you know it wouldn't support.
No one is going to model things as "well users aren't using that much yet". You're going to look at RAM usage growth in the past 12 years & blend that with known industry movements to get a prediction of where you'll need to target. It's also important to remember that RAM isn't free (not looking at the $). I don't know if it matters as much for laptop use-cases as much but for mobile phones you 100% care about having as little RAM as you can get away with on your system since it dominates your idle power. For laptop/iMac use-cases I would imagine they're more concerned with heat dissipation since this RAM is part of the CPU package. RAM size does matter for the iPad's battery life & I bet the limited number of configs has to do with making sure they only have to build a limited set of M1 SKUs that they can shove into almost all devices to really crank down the per-unit costs of these "accessory" product lines (accessory in the sense of their volumes are a fraction of what even AirPods ships).
I also shut down at the end of the day and make judicious use of browser history and bookmarks. If I were compiling binaries regularly I guess I could see the use in having more ram but as far as I’m concerned 8 is enough and so far people find what I put out perform at.
In my experience as a web dev, all the performance goes out the window as soon as the tracking scripts are added.
It may not be with fewer and less heavy dependencies!
It's still not comparable with your average developer tooling in terms of footprint, was my point.
PMs and executives are the ones you should give slow machines to if you want more focus on performance.
- 16GB MBP (Intel, not M1) - Running MacVim w/ coc.vim & coc-tsserver (so it's running partial TS compiles on save, much like VSCode)
- One image running in Docker
- Slack, Zoom (at idle), Safari (with a handful of tabs), and Mail.app running as well
Per Activity Monitor, 8.97GB of 16.00GB is used with 4.97GB marked as "Cached Files" and another 2.04GB of swap used.