I write algorithms that operate on predictable amounts of data. It's very easy to work out the maximum amount of things we need to have and then allocate it all in fixed size arrays. If you allocate all your memory at startup you can never OOM at runtime. Some containers need over 100GB but like the parent comment said we've already bought the RAM.

Caches are automatically released by the OS when demand for memory increases.

How often are ooms caused by lack of ram rather than programming?

I don't think MacOS OoMs as Linux

(and to be honest the way Linux does acts on OoMs are quite debatable)

It’s counterintuitive but I learned this best by playing RTS games. If you don’t spend money your opponent can outdo you on the map by simply spending their money. But the principle extends, everything you have doing nothing (buildings units etc) is losing. The most efficient process is to have all your resources working for you at all times.

Why he wouldn't say it about HDD space? You buy HDD to keep them empty?

And as for the money analogy, what's the idea there, that memory grows interest? Or that it's better to put your money in the bank and leave it there, as opposed to buy assets or stocks, and of course, pay for food, rent, and stuff you enjoy?

It's the same in all three cases: using HDD space, money and RAM for good purposes (disk cache) is useful, wasting it (Electron) is bad.

(Weird side question: are you by any chance the Jason Farnon who wrote IBFT?)

> about money in the bank?

Yes, generally. That's the entire idea behind the stock market.

> do you also say that about hdd space?

For slightly different reasons. My game drive is using about 900 GB out of 953 GB usable space - because while I have a fast connection, it's nicer to just have stuff available.

Same for some projects where we need to interface with cloud APIs to fetch data - even though the services are available and we could pull some of the data on demand, sometimes it's nicer to just have a 10 TB drive and to pull larger datasets (like satellite imagery) locally, just so that if you need to do something with it in a few weeks, you won't have to wait for an hour.

I am not following, isn't this just a graph that shows that how fast operations happen is largely dependent on the odds that it is in cache at various levels (CPU/Ram/Disk)?

The memory operation itself is O(1), around 100 ns, where at a certain point we are doing full ram fetches each time because the odds of it being in CPU cache are low?

Typically O notation is an upper bound, and it holds well there.

That said, due to cache hits, the lower bound is much lower than that.

You see similar performance degradation if you iterate in a double sided array the in the wrong index first.

The author of that post effectively re-defines "memory"/"RAM" as "data", and uses that to say "accessing data in the limit scales to N x sqrt(N) as N increases". Which, like, yeah? Duh, I can't fit 200PB of data into the physical RAM of my computer and the more data I have to access the slower it'll be to access any part of it without working harder at other abstraction layers to bring the time taken down. That's true. It's also unrelated to what people are talking about when they say "memory access is O(1)". When people say "memory access is O(1)" they are talking about cases where their data fits in memory (RAM).

Their experimental results would in fact be a flat line IF they could disable all the CPU caches, even though performance would be slow.

Memory access performance depends on the _maximum size of memory you need to address_. You can clearly see it in the graph of that article where L1, L2, L3 and RAM are no longer enough to fit the linked list. However while the working set fits in them the performance scales much better. So as long as you give priority to the working set, you can fill the rest of the biggest memory with whatever you want without affecting performance.

RAM is always storing something, it’s just sometimes zeros or garbage. Nothing in how DRAM timings work is sensitive to what bits are encoded in each cell.

> Every byte used makes the whole thing slower.

This is an incorrect conclusion to make from the link you posted in the context of this discussion. That post is a very long-winded way of saying that the average speed of addressing N elements depends on N and the size of the caches, which isn't news to anyone. Key word: addressing.

Huh? There is nothing called "empty memory". There is always something being stored in the memory, the important thing is whether you care about that specific bits or not.

And no, the articles you linked is about caching, not RAM access. Hardware-wise, it doesn't matter what you have in the cells, access latency is the same. There is gonna be some degradation with #read/write cycles, but that is besides the point.

why is it not O(1)? It has to service within a deadline time, so it is still constant.

> I've been absolutely mindblown at how fast my 3 8GB M1 Macbook Airs I just bought for ~$350 brand new

Wait what? How did you manage that?

The old mental model doesn't fit how any OS manages RAM. Every OS plays all sorts of fun guessing games about caching, predicting what resources your program will actually need etc. The OS does a lot of work to ensure that everything just hums along as best as possible.

I mean at that point (13 GB memory used), the "Swap used" is at several hundred megabytes.

And if I more apps (or browser tabs), the "Swap used" keeps increasing, and the "memory pressure" graph switches color from green to yellow.

The color of that graph is the indicator I'm using to know that I should close my browser tabs :p

I'd rather my ram go to my page cache, not have bloated apps hoarding it.

SpeedBoost was supported by vista through windows 10, and although windows 11 regognises a speed boost USB, I do not know it it uses it. When I put windows 11 on two i5 8gb machines and plugged in two speed boost drives, it did not swap a lot to them, whereas in windows 7, under memory load it would use them, at least until I found ChacheMem v2.1 it would manage memory much better than windows ever could.

Windows back to window 2.1 386 supported swapdisks, i.e fake ram.

It was my son’s laptop , he’s in high school. General Google Classroom / Google Docs / Gmail / web research stuff. He’s not technical at all. I bought him the 8GB machine thinking it would be fine, but it became a big problem for him.

I do think part of the problem was number of tabs open. It was a little better when I taught him how to manage tabs and I also turned up all the memory saving features in chrome.

But even with all of that, it would still slow down with what looked like a pretty minimal workload.

I spent a few hours with him on it, but he still had these kinds of issues.

It just seems like it requires a decent level of sophistication to work with a small RAM budget if you’re using Google software.

Depends of the usage. I just know that with 48GB I have a few TB or tens of TB written within a couple of hours when playing with homomorphic search.

Because 8GB is literally enough? There are multiple 8GB Macs in this house and they are fine. I wouldn't use them for development work but they're completely competent at the basics.

Tons of 8GB users out there who are happy. I'm on 16GB and its definitely enough for a power user - and running multiple coding environments, Docker, IDE's. MacOS is really good with caching.

> I wonder, why is it physically painful for some Apple owners

This wasn't necessary. I was just pointing out that 8GB hardware is not the full story. It's also true with windows, as you correctly point out. If you're coming from a slow SSD, or even Linux (it's a relatively new feature to have on by default) you might be pleasantly surprised.

Also, I'm an Apple owner and I have no problem saying it's not enough for anyone on this website. I tried it for a few years as my "second screen" computer, and would bump against it all the time, with glorious screeching as the audio skipped. But, I'm also a developer/power user.

The majority of people aren't power users.and that's the target audience for this. Clearly.

8GB has been completely fine for every non power user I know. Again, the majority of people do everything within a browser, maybe play some music/video at the same time, maybe open an office type app. It's completely acceptable for that, and that should not surprise you, as someone who has an understanding of memory usage and paging, and high bandwidth SSDs, in the slightest.

Perhaps because it's enough for a lot of things. I only came up against the 8GB limit when I ran a LLM locally using Ollama. It worked but wasn't workable.

8GB isn't ideal though and 16GB would've expanded its capacity to do more things. But soon as I want to do more things I shuffle over to my PC with it's dedicated GPU and 32GB o ram

I'm guessing Apple cuts capability to the lower end so as not to hurt sales of the higher end. Usage profile is often dependent on context. There are enough non-power users (when mobile) like me that 8GB isn't ideal but it's enough. And if it wasn't enough we could've paid more for the 16GB, but I personally decided it wasn't worth the ridiculous Apple ram price premium.

So these are my reasons for saying 8GB is enough. I'm also using an M1 MacBook Air, so the puniest of the lineup. Next laptop I'm considering is possibly a think pad with linux so I'm no macOS fanboi.

Same. I've been programming in Go on an M1 for years and perf is spectacular.