3 ms·
These machines are still insanely fast. If you actually notice anything get substantially slower, you are either running very specialized workloads or you can f
by _cenw 4y ago
These machines are still insanely fast. If you actually notice anything get substantially slower, you are either running very specialized workloads or you can forward the blame right to the developer of said application.
- hedgehog 4y agoIt seems pretty unlikely that many people have a workload that is highly sensitive to read throughput, has a disk footprint so small it fits on a 512GB SSD, and where the cost of slower disk outweighs a 20% faster CPU.
- hot_gril 4y agoIf I select 200 files and make a zip, that's probably an impacted workload.
- hedgehog 4y agoAs in 20% faster on the M2? At least for gzip defaults the per core throughput on my M1 is around 50MBps.
- hot_gril 4y agoAs in, possibly slower on the M2. Zipping a complex file tree can be disk-constrained, particularly if there are many small files.
- hedgehog 4y agoFor scale we're talking > 2TBps linear read and probably > 500MBps random 4k read in both cases, compared to on the order of 50-500MBps limit on the CPU side depending on threading etc. So still CPU limited. If there's any problem with big file trees it's probably macOS's relatively slow filesystem so again, advantage to the faster CPU. It sounds like LightRoom startup is a little slower but if you use it for editing you're going to get that back in faster workflow. In general modern NVMe has removed disk as a significant bottleneck for normal peoples' workflows, even on Mac. That includes backups, zipping up collections of files, git compaction, etc. What scenario are you imagining here?
- jyrkesh 4y agoThe Twitter OP elaborates further down the thread that they're seeing real-world impact on Lightroom. That would be a bummer for me...but I'd probably buy a build with a larger drive. Waiting for confirmation that this is only on the base model.