Why Modern Code is Slow

Because of the entire security nonsense, modern linkers do not support the classic statically linked executables, which were superfast. So all code is compiled the PIE bloatware. Of course that crap goes on top of already slow MMU and meltdown/spectre fixes (which are just an excuse to sell your new CPU). Remember these old COM files? They were ridiculously fast, compared to the modern ELF garbage, where just the header takes more space than the code itself.

Remember: security experts are the consumer's biggest enemies. Common people don't care about security, they care only about apps running fast, liek they used to run in C64.

>>11

The first few things (not comprehensive) that come to mind: pipelining, branch prediction, cache optimizations.

These are the minor architecture things, which require some work on part of programmer and compiler designer, not the true hardware frequency improvements. I.e. they wont ever make you computer work faster than the 10 GHz (still unobtainable speed even by the most hardcore overclockers). The only real improvement comes in the form of quantum computers, but these are applicable only to a limited set of problems, some of which are already solvable by throwing more GPUs, and wont give you back the cycles stolen by MMU, address space randomization, and other management layers. Many processes are inherently sequential, therefore can be improved with GPUs or quantum computers, only with faster clock rate.