> But if you take as “performance” the duty cycle of the machine’s various components, little will prevent you from ending up with a design in which the major part of your performance goal is reached by internal housekeeping activities of doubtful necessity
JITs have taken this to an even higher level — people don't just argue that the machine is fast enough to run their convoluted code with countless unnecessary layers, they argue that their code as they've written it won't be run at all: the JIT will reduce it to a simpler form that can be handled efficiently.
But they can't explain why their poor coworkers who have to read and maintain the code don't deserve the same consideration as the machine!
I don't understand your comment. A good JIT compiler can often make a program more efficient by taking advantage of runtime profiling. This allows developers to write simpler, more maintainable code without doing tricky things for efficiency.
That's the upside of JITs and a great way to take advantage of them. Unfortunately, not every programmer is motivated to produce simple code. Some programmers prefer to write more complex code, either because they enjoy building castles in their mind, or because they would rather not take the time to remove any of the dead ends and missteps they made while searching for a solution.
Highly optimized code being convoluted is an extreme case, for rare algorithms or exotic levels of instruction-level efficiency. The first 95% of optimization is simplifying the code, which benefits both the machine and the programmers.
JITs have taken this to an even higher level — people don't just argue that the machine is fast enough to run their convoluted code with countless unnecessary layers, they argue that their code as they've written it won't be run at all: the JIT will reduce it to a simpler form that can be handled efficiently.
But they can't explain why their poor coworkers who have to read and maintain the code don't deserve the same consideration as the machine!