Web Developer here. Wouldn't accept anything less than 32GB for a work machine.
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.
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.
With Firefox and auto tab suspend (addon), it's manageable.
- 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.
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.