Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
You’re throwing around meaningless words of a bygone era. You need to explain why SoC architecture, fast SSD drives and large super fast caches for processing (on the chip!) can’t solve your problem?

A problem you fail to understand in the first place! There’s no such thing as low memory anymore. It’s the job of macOS to fill RAM to the max, no matter how much you have and make memory available if needed. That’s why Activity Monitor has a chart for Memory Pressure not Memory Usage.

Anyway, even if memory pressure on your system is high, the data is loaded from a fast SSD, not a spinning drive with a mechanical read-write head. This bottleneck has been eliminated. It’s a thing of the past like the Gigahertz race.

This is silly. If your working set is bigger than what fits in RAM, you need more RAM. SoC architecture, fast SSD drives, and fast caches can’t solve that. There are numerous examples of such working sets, including the ones he listed, as well as engineering and science applications. No matter how fast your SSD drive is, if you have to randomly access a data set that is bigger than RAM, each read will be at least two orders of magnitude slower than if it fits in RAM.

And as a guy who’s Ph.D dissertation had “memory hierarchies” in its title, I’ve spent a year or 25 thinking about this issue.
 
This is silly. If your working set is bigger than what fits in RAM, you need more RAM.
You need to give a definition of what need means!

Because there are plenty of videos on youtube which prove that an M1 MacBook Pro with 16GB beats it’s Intel counterpart equipped with up to 64GB memory even on the most demanding tasks. I’ve yet to see the edge case in which the bigger RAM triumphs over all the other improvements on the chip.

I don’t care about your dissertation and I’ve forgotten the title of my own. Show me a video proof or shut up!
 
  • Disagree
Reactions: KeithBN
Because there are plenty of videos on youtube which prove that an M1 MacBook Pro with 16GB beats it’s Intel counterpart equipped with up to 64GB memory even on the most demanding tasks. I’ve yet to see the edge case in which the bigger RAM triumphs over all the other improvements on the chip.
One example: a custom tool that reads a file containing genome sequences and their alignments and outputs a more space-efficient representation of the same data. In this case, the file is ~50 GB in size.

On an iMac with 128 GB memory, the tool uses ~50 GB memory in addition to the memory-mapped file and finishes in less than 3 hours.

On an M1 MBA with 16 GB memory, the first stage where the tool validates the input is slightly faster than on the iMac. The second stage, where the tool reads parts of the input into hash tables, is 3x slower than on the iMac. During this stage, memory usage of the process grows above 16 GB.

In the third stage, where the tool does the majority of the work, it slows down to a crawl. The tool is only using 20% of a single CPU core, because it's constantly waiting to access memory. Memory usage of the tool is steady at ~18 GB (and memory pressure at ~1/3), but the system is swapping in and out ~500 MB/s. After ~25 minutes of this, the tool has finally processed the first batch of the input and memory usage jumps to ~40 GB. I stop the execution at this point, because the tool has only finished the first ~1% of the work and I don't want to wear the SSD out prematurely.
 
Which application says, "sorry, I can't do that, there's no free RAM"?
I've had the out of ram force quit window appear when running Matlab, safari, music, teams, preview, sublime text, and mail. Mail is a memory hog when you have several huge mailboxes, Teams is as terrible as all Electron apps, and Mathworks likes to compete with Adobe for memory eating and pointless processing load (until recently they required the high performance GPU to load the documentation browser, for example). Admittedly I usually have a lot of tabs open in safari, but I do close documents when I'm not using them.
 
  • Like
Reactions: KeithBN
My body is ready for a 2TB SSD 32 GB 32" silver iMac. Bring it on and take my money.
 
You need to give a definition of what need means!

Because there are plenty of videos on youtube which prove that an M1 MacBook Pro with 16GB beats it’s Intel counterpart equipped with up to 64GB memory even on the most demanding tasks. I’ve yet to see the edge case in which the bigger RAM triumphs over all the other improvements on the chip.

I don’t care about your dissertation and I’ve forgotten the title of my own. Show me a video proof or shut up!

Dude, kindly explain how when I’m extracting parasitic resistance and capacitances from a database that takes up 128GB of RAM, I’m supposed to do that performantly with less than 128GB of RAM.

This isn’t rocket science - if the working set is bigger than RAM, you swap, and swap is always slower than RAM access. This does not require “video proof” - some of us know how to read.
 
In the third stage, where the tool does the majority of the work, it slows down to a crawl. The tool is only using 20% of a single CPU core, because it's constantly waiting to access memory. Memory usage of the tool is steady at ~18 GB (and memory pressure at ~1/3), but the system is swapping in and out ~500 MB/s. After ~25 minutes of this, the tool has finally processed the first batch of the input and memory usage jumps to ~40 GB. I stop the execution at this point, because the tool has only finished the first ~1% of the work and I don't want to wear the SSD out prematurely.

Hard to say without knowing the details of how the file nor the output are structured, but at this point wouldn't it make more sense to preload parts of the original file to RAM using something like PyTables/HDF5 and modify the algorithm so it can work in chunks? I know this isn't always possible, but in the case of genomic data... I imagine the accesses follow an ordered pattern more than a random access one.

I mean, it seems like if the file had been 200GB instead of 50GB, it would have slowed to a crawl on both machines, and genomic data can get stupidly large.

(Not trying to be nitpicky here, just genuinely curious if/why there's no better solution than loading the entire dataset on RAM).
 
Hard to say without knowing the details of how the file nor the output are structured, but at this point wouldn't it make more sense to preload parts of the original file to RAM using something like PyTables/HDF5 and modify the algorithm so it can work in chunks? I know this isn't always possible, but in the case of genomic data... I imagine the accesses follow an ordered pattern more than a random access one.
I/O is the trivial part. It's basically just two sequential passes over the file, and memory mapping handles it just fine.

The memory usage comes from some hash tables and an in-memory graph. The ~40 GB when I stopped the execution is probably close to what a single human genome would need. The final ~50 GB is for ~45 genomes. With ~2500 genomes, memory usage is usually 150-200 GB, but with a different input format. Multi-terabyte text files are rather inconvenient, after all.
 
This isn’t rocket science - if the working set is bigger than RAM, you swap, and swap is always slower than RAM access. This does not require “video proof” - some of us know how to read.
If the only thing different was the size of RAM you would be right. But M1 and i5 differ in many more ways. System performance can only be tested by running the system, hence the idea of benchmarks. This isn’t rocket science.
 
  • Disagree
Reactions: KeithBN
Well, they already tested on the MacBook that for stuffs that really requires more than the system RAM they are of course slower compared to a system with the right amount of the required RAM. Of course, the penalty comes with stuff that really requires the RAM, which is less than what many people think, but on a Pro machine you expect to have that capability.
 
I'm curious to see the performance of the videocard compared to the discrete graphic offering available on the Intel iMacs. The last batch of iMacs finally had a very good videocard like the 5700XT
 
If the only thing different was the size of RAM you would be right. But M1 and i5 differ in many more ways. System performance can only be tested by running the system, hence the idea of benchmarks. This isn’t rocket science.

This is insanity. All I’ve said is that if your working set is bigger than available memory, performance suffers terribly regardless of architecture. This is indisputably true. The fact that anyone disagrees is ridiculous. Whether you are on an i5 or M1, swapping takes at least hundreds of times longer than DRAM access. If your working set is bigger than RAM, then you have to swap. Write vaguely about some unnamed feature that somehow makes RAM appear where there is none, but you’re wrong.
 
Last edited:
I/O is the trivial part. It's basically just two sequential passes over the file, and memory mapping handles it just fine.

The memory usage comes from some hash tables and an in-memory graph. The ~40 GB when I stopped the execution is probably close to what a single human genome would need. The final ~50 GB is for ~45 genomes. With ~2500 genomes, memory usage is usually 150-200 GB, but with a different input format. Multi-terabyte text files are rather inconvenient, after all.

Ah, that makes a lot of sense. Cool.
 
Whether you are on an i5 or M1, swapping takes at least hundreds of times longer than DRAM access.
But nobody cares how long swapping takes. It’s a system and only system performance is accessible to the user. Only if swapping is indeed the bottleneck that slows down the whole process, more RAM can actually have an effect.
 
  • Disagree
Reactions: KeithBN
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.