A rather large sector of software where you don't throw hardware at the problem is embedded software. Shipping hardware that is 25€ more expensive times a million is often much more expensive than optimizing the software.

I've also seen the opposite, quite often actually: Cheaping out on hardware that is going to ship maybe 1-10k (very expensive) units, then spending hundreds of thousands on optimizing software to make it not even good, just less painfully slow. The i.MX6 chip with its weak GPU and corresponding wonky drivers is an especially popular way to get user interfaces that can't keep 60 fps.

The i.MX6 is certainly a poor choice today but do you know of any good contemporary alternatives? Honest curiosity because personally I can't think of any medium-power (or at least thermal dissipation), (Mainline-) Linux capable, well (and openly) documented processor available long-term in low/medium quantities from a proven vendor.

I've recommended Toradex Tegra 2 modules to a customer (I got involved early enough to recommend hardware - a rare case) and they seem to be quite happy with it. Just a few euros more per module than i.MX6 from the same module vendor. The GPU is unsurprisingly (with nVidia making the whole SoC) pretty good. Most everything needed for software support except the user-space graphics driver is even open source. I am not an nVidia fan because of their desktop Linux driver shenanigans, but I strongly prefer Tegra 2 over i.MX6. By the way, i.MX6/6+/7 with the etnaviv driver might also be alright. I've just never used anything but the proprietary "gal3d" driver.

Regarding mainline Linux support, AFAIK you don't get mainline Linux support anyway with i.MX6 and the gal3d driver. You can only use mainline with etnaviv, which is semi-officially(?) supported by Pengutronix. I've heard others say good things about etnaviv.

It's easy to throw hardware at a problem that can be parallelized efficiently. It's very hard to throw hardware at inherently sequential solution.

It was easy to throw hardware at a sequential problem, a decade ago. CPUs were still improving their single-core performance year after year, and memory access and all kinds of IO devices kept getting faster and better. I'm guessing that time was where this idea originates from.

Today, things are different. Single-threaded performance isn't going to be improving much in foreseeable future; the effort shifted to improving parallel performance and, more recently, power consumption. So if you write slow code - perhaps by choosing a slow software stack - your code will remain slow.

It is also a bit less easy to throw hardware at a problem when your software is actually embedded firmware. Upgrading or adding hardware reduces your profit per unit.

But TBH in this particular field Moore's law still rules. Sometimes you are forced to upgrade to a better component for the same price because the component you chose five years ago has reached end-of-life.

Yet paying attention about optimization allows you to do more with what you have, or sometimes allows you to use less optimal but more convenient or simpler approaches.

In cases where you control the hardware and the problem is sufficiently parallelizable.

If you are releasing consumer applications either your program works smoothly on the device a consumer has or not, let alone has the ability to buy either financially or fundamentally (as in you don’t find a phone with desktop level performance anywhere, because they don’t simply exist).

This is partly what I was trying to convey with the "turning this aphorism into a question" fragment. Sometimes it is just not possible, or it is too expensive, to increase hardware performance.

Premature optimization, or at least one of its manifestations, is failing to consider the opposite.