With new M1 Macs now available to everyone, one of the concerns I’ve seen floating around the internet is that the performance increase of the new M1 Macs is going to be offset by developers’ blatant disregard for performance in general.
I agree, in part, but I also think that it does not matter much. In part, that is because software is bloated and unoptimised at such a level we can hardly comprehend. This reminded me of a Jonathan Blow highlight I saw on YouTube:
But guys, it doesn’t matter. It doesn’t matter how fast CPUs are for almost anything in your life, because all that will happen is that the same programmers who are making CPUs orders of magnitude slower at doing actual computation than they should be, are just going to make them even slower. That is all that happens. And no, they are not trading that off for productivity, because again, they’re not productive. So why do you care that a new, faster CPU is coming out?
He then continues:
Your computer can be a hundred times faster than it is with slightly different software. A hundred— at least a hundred times. Probably a lot more than that. Oh no, the M1 is like 40% faster. You could be a hundred times faster. A hundred! That is what I think about Apple’s M1 processor. Computers are so fast, you have no idea. Most professional programmers have no idea— most “professional” programmers have no idea how fast computers are, they’re crazy. They’re insane supercomputers. (…) You could be a hundred times faster starting today, starting right now, right this second.
Hilariously, one commenter on the livestream responds and Blow notices:
“Where do you download the fast software?” Unfortunately, you have to write the fast software. It’s very sad. It’s a very sad state of affairs.
While I think the 100x improvement might apply in a perfect world (where all software is engineered to work perfectly all the time), we have to understand we do not live in a software development utopia. The truth is, though, that much software is unoptimised — software could benefit from multi-threading, for example, but the workload or the programmer might choose to keep the process on a single thread.
Most new developer devices feature 6 or 8 CPU cores, meaning you could parallelise much of the work your computer needs to do, but this isn’t the case if you’re building apps that are mostly single-threaded.
Our optimisations need to be so low-level, that we can get good performance on a much older device — not just a last year’s MacBook: you need a proper older device. For this, you should use very slow hardware, or throttle your program to see how it performs. If you’re deploying a web app, you can try running it on a Raspberry Pi, for example, and see how it performs. If you’re building a native app, test it on an older device.
For iOS apps, I keep an older iPod touch and entry level iPad around for this very purpose. If I can guarantee a good experience on this older hardware, I can be sure that the experience will be great on newer hardware as well.
Ideally, you should build your product on older devices as well. It exposes performance issues. The next best thing is performance throttling, but that isn’t always representative of the genuine, slower, article.