The author mentioned that,
It boils down to what you want for yourself. Do you prefer your apps to run speedily and smoothly? Then go for more cores. Or do you want to run so many apps simultaneously without freeze? Then you need plenty plenty of RAM.
He is correct, obviously.. but I was looking for an answer that describes performance with like.. a sliding-scale between # of cores vs amount of ram (or ram per core ratio). I am in the group of people that only needs 16GB of ram to feel comfortable with my purchase, but from a standpoint of curiosity.. I can’t help but wonder.
Whoever the author of that article is, either their understanding of technical aspects is fundamentally flawed, or they are deliberately oversimplifying things.What they write sounds so obvious, and yet is not obvious at all... The problem lies with the understanding of what "run many apps simultaneously" means.
Say you have a browser with 40 tabs open, an email app and a note-taking app in the background, you are listening to music in iTunes and currently have Word in foreground, working on a document. How many apps are you running simultaneously? Correct answer is "two, probably". Because the only apps that are active and perform useful work atm are iTunes and Word. The rest is sleeping, waiting to get activated — and ideally use neither CPU time nor need to be resident in memory. One might say now, sure, but what if you need to switch between the apps? If its not loaded into RAM, you'll have to wait. Very true, but you also need to consider that with modern SSDs and memory compression, that Safari tab etc. will load faster then your brain's visual processing latency. And such delay can be hidden by app switch animation.
Of course, this is all highly idealistic — in real world we have background apps which still need to perform work (e.g. fetch emails in the background) and quite often they are written in an inefficient way. But in a nutshell, this is how stuff works. Even when heavily multitasking (in user's terms — what we understand as "simultaneous" execution is years spent in waiting in the CPU's world), what you need is a certain minimal RAM threshold, as well as a speedy backing storage in order to achieve smooth operation.
What about true simultaneous execution? Well, that would be server work — where its not uncommon to have hundreds or more of active, demanding tasks. And you do need tons of RAM to run it. You also need tons of CPUs and a lot of cache, and ideally — multiple memory controllers. Because there is not much point in having a lot of RAM if you don't have the computational resources to actually use it...
When we look at the contexts where people ask for more RAM, its always the same. Its either people running multiple virtual machines (where memory access patterns are more complicated and paging can incur very complex costs), working with large datasets (often using suboptimal algorithms — but hardware is cheaper than programmer's time), or running large suites that require a lot of data or infrastructure to be loaded simultaneously (pro audio apps come to mind).