4 ms·
This seems wrong. I work on compilers, most CPU design advancements from the last several decades are aligned towards making bad code run fast. This is usual
by fooker 6y ago
This seems wrong.
I work on compilers, most CPU design advancements from the last several decades are aligned towards making bad code run fast.
This is usually a problem for people who write 'fast code', they have to hire a bunch of compiler devs to stop the compiler and CPU invalidating each other's optimizations, and to implement one-off domain specific optimizations.
This is how a vast majority of compiler people are employed nowadays.
- dfischer 6y agoHardware is hiding the rot and stink that is plaguing software. This will be coming to collect sooner than later.
- Arnt 6y agoI have no doubt that CPU development (like compiler development) aims to make bad code run fast. However, the result is what's intented modulated by what's possible. Thirty years ago a single misplaced read that goes all the way to main memory couldn't take as much time as a hundred well-conceived instructions, even in the worst case. Now it can. A badly chosen data structure that ends up causing a loop over a linked list ends up sucking. I don't think that's anyone's intention. Noone wanted to make choosing the right data structure become a bigger advantage. CPU frequencies outran main-memory frequencies, the number of instructions issued per cycle grew, but not because anyone wanted to punish linked-list iterators.
- Arnt 6y agoReplying to myself. This has bothered me today. I think what I really wanted to say was: CPU vendors try to improve. The things they try to improve don't add up to "make bad code run fast", even if much of their motivation may be that. "Increase the number of instructions issued per cycle" or "improve the branch predictor" bends the effect towards code which is written with some awareness of the CPU, ie. good code. Bad code is IMO almost synonymous with code written without awareness.