> The software manufacturing industry could do with some more silicon sympathy. These are still orthogonal concepts. First of all, it's all about cost: if the

> The software manufacturing industry could do with some more silicon sympathy. These are still orthogonal concepts. First of all, it's all about cost: if the operational costs of running a piece software over the lifetime of said software are significantly lower than the cost of optimisation, there's nothing to be gained from doing the latter. Developer time is more expensive than a faster CPU, additional RAM or slightly higher power usage. Back in the day, the iron was expensive and developer time was cheap. Today it's the other way around, so saving on development time is more important than optimising for specific hardware. Hardware-level optimisation becomes especially bogus if your deployment target is data centres - you often don't even know the deployment target beforehand (could be an ARM CPU, could be an x86 CPU). With many modern SoCs (see the M1), it's even impossible to optimise at that level, since you don't even get the required hardware specs and simply using Apple's libraries will get the best results. So my argument still stands: there's litte benefit in general from going into such detail. Feel free to disagree, but developments like the Go language, SoCs, and GPGPU compute seem to point another direction. > It is to learn how to build a computer. And how does that translate to actual hardware then? Very poorly still. The fact is that unless you work with certain embedded systems, you never get close enough to the hardware to benefit from this. This is time better spent on learning how to use your tools and to learn how to benchmark and optimise based on algorithms and data structures instead, because that's where the inefficiencies start. Besides, most programming languages are so far removed from the hardware, that there's absolutely nothing you can do to optimise (JS, Python, Go, Java, C#, Haskell, LISP, etc.).