SEARCH
diglloydTools™
Fastest SSD Yet in the MacBook Pro M1 Max, but Will Apps Run Things Faster Because of It?
Related: Apple, Apple MacBook Pro M1, Apple Silicon, data integrity, diglloydTools, IntegrityChecker, laptop, MacBook, MacBook Pro, memory, Other World Computing, SSD
To date, the fastest internal SSD in Macs has done real-world I/O of about 3.3 GB/sec. That’s really fast!
But the MacBook Pro M1 Max (and presumably M1 Pro too) are claimed by Apple to deliver about 7.4 GB/sec—more than double the speed.
Does that mean your Photoshop files will save twice as fast? Nope. Does it mean much of anything will run a lot faster? Nope—a little faster for some things, notably faster for a few things, and not much faster for most things.
To know for sure, you’d have to compare using a 3.3 GB/sec SSD, and there is no way to do that (no external can go that fast, and no other internal SSD is possible). The next closest thing next is a ~2.7 GB/sec Thunderbolt SSD, like the OWC Thunderblade or OWC Envoy Pro SX.
What is required for 2X faster I/O to matter
For starters, macOS has a performance bug that cuts ultra-fast SSD speed in half for the very jobs that could most use the speed. That 7.4 GB/sec quickly gets cut back by this bug, unless macOS Monterey has fixed it. How badly things are affected depends on the amount of memory; 64GB will be worse than 32GB memory. Once that cache is full, the overhead starts killing performance.
Next, a top speed of 7.4 GB/sec is *only* achieved for very large transfers. You need only glance at any of MPG’s test charts to see that transfer size matters hugely to speed. And since most apps use absurdly small buffers (1MB or smaller), they can never get full speed from the SSD.
Continues below...
Application behaviors
Several things have to be the case for 7.4 GB/sec SSD to outperform a 3.3 GB/sec SSD on real world tasks:
- Whatever application is reading or writing had to have special attention paid to maximizing disk I/O speeds, e.g. using very large transfer buffers, just for starters. Programs like IntegrityChecker. But very few apps are so-written. Apps that make stupidly small reads/writes might still benefit, but nothing like maximum I/O speed.
- Cutting the I/O time in half might might mean very little in the overall picture, where most of the time is computational overhead of other kinds: memory allocation, data structure setup, parsing, etc.
- Most disk I/O is intermixed with computation of some kind. A well-written app is already overlapping I/O and computation for an effective zero-time disk I/O (rarely could data be processed anywhere close to 3.3GB/sec, so the I/O time is effectively free). A poorly written app that reads then computes and repeats-until-done... that app is crude from a performance perspective. And that is what most apps do. And most such apps read in very small chunks.
- Adequate CPU processing power for the data stream. Very few tasks can process data at more than 3.3 GB/sec, so 7.4GB doesn’t mean things would go faster in any appreciable way.
When the faster SSD might help
The good news is that there are at least some cases where the faster speed will help:
- Exceptionally well-engineered programs like IntegrityChecker Java (icj), which utilize all CPU cores while overlapping I/O independently of computation (worker queues, multi-threaded file system scanning, multi-threaded parsing, etc).
- Virtual memory paging speed when memory gets low might improve. “Might” because paing is typically 32K writes and reads, and it’s possible that the faster SSD could be slower or no faster than the “slower” 3.3 GB/sec SSD for small reads and writes. This was already the case in some Mac iterations, so it is not idle speculation.
- File copy speed. Gated by the slowest of the to/from drives. But it won’t make your backups go faster reading at 7.4 GB/sec and writing to the same slow 200MB/sec hard drive.
- Programs that read or write very large files could benefit. In the past though, Photoshop took poor advantage of fast SSD speeds, well below what is possible. Still, the code was improved and it’s a lot faster than in the past—it might benefit.
IntegrityChecker Java (icj) can hash at over 12GB/sec on a 28-core Mac Pro. It can also max-out a 2019 iMac 5K Intel Core i9 8-core SSD ~3.3 GB/sec SSD (each core can hash at ~733 MB/sec). Just how much computing 'juice' those 8 performance cores on the MacBook Pro M1 Max have remains unknown to me until testing, but I’m guessing somewhere in the 1100MB/sec range for raw hashing speed. If so, icj will easily max-out the 7.4 GB/sec SSD I/O potential. Caveat: the JVM for M1 Macs has to have native hashing implemented, or performance will be far lower.
