Or -- and I know this is crazy -- slottable RAM on a device that is designed for things other than portability. Wild, I know.
Or -- and I know this is crazy -- slottable RAM on a device that is designed for things other than portability. Wild, I know.
It goes by many names, the "microeconomic pricing strategy where identical or largely similar goods or services are sold at different prices by the same provider to different buyers based on which market segment they are perceived to be part of",
I mean, that's basically it. The difference between part costs of 8GB/16GB/32GB RAM chips is nearly a rounding error, and they're probably eating a bunch more costs stocking and adding assembly for different RAM SKUs.
I think people here forget that Apple is targeting a certain profit margin. Currently, their gross profit margin is about 45%.
If you're rolling this out on the Mac line, it's okay to have a profit margin closer to 35% on the base model; but maybe with 55%-65% margins on the higher-tier professional equipment, to "balance" it out. It also turns out, professionals have money, and will pay despite the grumbling. The RAM prices are basically a progressive tax.
It's nice to see more RAM and Apple was being very stingy about it, but the real-world is totally overblown.
I'm also doing Rust dev, but I can't work with less than ~24GB.
On my headless rackmount dev box that I use for my remote development environment, the box sits around 17GB of memory in use + 8GB of cache. I've got an M3 with 36GB running a few Visual Studios Code (plus browser/Docker/Dropbox) with about 30GB used (8GB of that is cache).
16GB would not have been enough for me for my work at Deno. My current job involves both Rust and Python work and I'd quickly hit the limits of 16GB if I'm running my code while developing it, let alone running a browser or keeping my email client open.
That was fine when Intel was sitting on their ass, raking in the cash, and nearly everything else (storage, especially external drives, RAM, and even batteries weren't too bad) is upgradeable. This is less great when you can no longer upgrade the component most likely to be the first bottleneck.
Apple pays people to be smarter than me about this, but I still think it's a stupid long-term play to damage one of your biggest selling points
Whenever switching company I went from a 64 gb ram computer to a 16 gb ram. Yes, it worked, but only because I had to adapt to it. But one might not see it if one's never tried.
With usb-c/thunderbolt, it is hard to be a pro user AND be interested in the iMac form factor when you can have a mobile device that you can easily dock to a large screen and have the conveniency and comfort of both a laptop and a desktop.
Outside of companies that wants fixed, kensington locked desktops for their employees, I don't see who would choose an imac over anything else.
(WebStorm, Rider, Android Studio, Chrome, Discord & Slack), not currently running an Android Emulator, LLM or Docker
At some point it becomes impossible for the OS to keep everything it wants in RAM at the same time, and then you get an orgy of disk thrashing and a potential lock-up.
This is not theoretical. I've had it happen on both Macs and Windows machines, sometimes with just a single main app running.
At best you'll get obvious delays if you switch apps, as pages get dumped to disk while other pages are loaded.
Some RAM is used for file caching and other optional stuff, so not all of the additional usage will translate into swap if RAM is reduced.
MacOS also makes use of RAM compression, which increases the amount of memory pressure that can be sustained before swapping is necessary.
All in all, it's pretty complicated, and the only way to know if a workload will perform acceptably on a machine with less RAM is to try it.
Source?
For transfer speeds, look at the data sheets for the M series. Much faster than DDR4 or DDR5 RAM. In the ballpark of GPU memory.
I bet that the extreme lag when you run out of memory because you have an Electron app or two, several browser tabs and something like Excel is way more noticeable.
Hardly anyone is using Macs for gaming these days and almost anybody who does something GPU intense would need more than 16GB anyway.
See: https://www.theregister.com/2020/11/19/apple_m1_high_bandwid...
> The SoC has access to 16GB of unified memory. This uses 4266 MT/s LPDDR4X SDRAM (synchronous DRAM) and is mounted with the SoC using a system-in-package (SiP) design. A SoC is built from a single semiconductor die whereas a SiP connects two or more semiconductor dies.
LPCAMM solutions mentioned upthread resolve some of this by making the problem more "three dimensional" from what I can tell. They reduce the length of the traces by making the pinout more "square" (as opposed to thin and rectangular) and stacking them closer to the actual dies they connect to. This allows you to cram swappable memory into the same form factor, while retaining the same clock speeds/size/bus width, and without as many design complexities that come from complex socket traces.
In Apple's case they connect their GPU to the same pool of memory that their CPU uses. This is a key piece of the puzzle for their design, because even if the CPU doesn't need 200GB/s of bandwidth, GPUs are a very different story. If you want them to do work, you have to feed them with something, so you need lots of memory bandwidth to do that. Note that Samsung's LPCAMM solutions are only 128-bits wide and reported around 120GB/s. Apple's gone as high as 1024-bit busses with hundreds of GB/s of bandwidth; the M1 Max was released years ago and does 400GB/s. LPCAMM is still useful and a good improvement over the status quo, of course, but I don't think you're even going to see 256-bit or 512-bit versions just so soon.
And if your problem can be parallelized, then the higher your bus width, the lower your clock speeds can go, so you can get lower power while retaining the same level of performance. This same dynamic is how an A100 (1024-bit bus) can smoke a 3090 (384-bit) despite a far lower clock speed and power usage.
There is no magical secret or magical trick. You will always get better performance, less noise, at lower power by directly integrating these components together. It's a matter of if it makes sense given the rest of your design decisions -- like whether your GPU shares the memory pool or not.
There are alternative memory solutions like IBM using serial interfaces for disaggregating RAM and driving the clock speeds higher in the Power10 series, allowing you to kind of "socket-ify" GDDR. But these are mostly unobtainium and nobody is doing them in consumer stuff.
Two of those modules working in parallel would hit "M Pro" speeds as well. I doubt Apple will be adopting them though, for the same reason they don't offer standard M.2 SSD slots even on systems that could obviously support them with minimal design compromises.
Just be patient, the EU will take a large stick and force Apple to allow users to replace their RAM soon too.
The difference there is that slotted GPU memory is demonstrably impactical, but the memory on the M4 isn't demonstrably better than the LPCAMM2 module above. It's literally the exact same spec. Not that I expect the EU to do anything either when they didn't act on Apples soldered-in SSDs, which definitely aren't any better than standardized M.2 drives.
Easy heuristic: if your memory transfer rate is more than 1.5x the standard, you can solder RAM. If not, you must use the standard.
For most people 32gb is not going to hold them back.
On the other hand, the MacBook Air ships with 8GiB RAM standard, and it's robustly popular. One could suppose that all those customers are suffering from the lack of RAM, or one could suppose that for many use cases, it's an adequate amount.
The latter is more likely. macOS manages memory well, and a fast SSD means that swapping is fast enough that it often results in no visible delays to the user.
That they sell a lot of stock MacBook Airs? They do. I don't find the topic interesting enough to find a link, but I'm pretty confident on this one.
> a lot of people use their Macs as they would an iPad
A lot of people have pretty undemanding requirements in a laptop, yes. 8GiB is more than enough for some web browsing and light document editing, a bit of photo retouching, that kind of thing. There are many Chromebooks on the market right now with 4 GiB and they sell in numbers.
The HN tilt trends toward systematically overestimating system requirements because development is fairly demanding of them.
I just doubt there is actual meaningful data available (at least that's publicly accessible). We'd need to measure the proportion of base config MBA users who regularly get OOM warnings?
> many Chromebooks
Yes. People just have different use cases. I mean almost nobody who does anything that might require > 16-32 GB of memory would likely buy this iMac (even if Apple sold such configs).
It's an entirely different product than the 27 inch "Pro" iMacs with Xeons from back in the day.
Hardly anybody "needs" a desktop PC these days (outside of gaming and some niche applications). So this is just basically a generic office / front desk PC for people who don't need laptops.
Ah, yes that was why I asked what I did. I'm quite confident they sell a lot of stock MBAs, is what I said, as a guess at what we were trying to 'tell'.
As for "low on application memory" warnings, macOS doesn't really do that unless the user is also out of swap. Offer may not be valid for XCode. My wild-ass guess is that users who need lots of RAM tend to know that when they buy computers, and that percentage wise, there are more over-provisioned Mac users than under-provisioned. But who knows.
> So this is just basically a generic office / front desk PC for people who don't need laptops.
Right. Apple market-segments their products pretty carefully, and the post-Pro iMac line is for receptionists, desktop publishing, light-duty visual/creative, the occasional desk-oriented email job, and so on. 16 GiB is a generous baseline for those tasks, and 8 GiB was probably adequate for most customers.
What are you doing? I'm still doing web development with Chrome, JetBrains, and Docker on a 16GB M1 Pro and it isn't a problem. For the average Chrome-using citizen, 16GB should be fine.