3 ms·

I 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 poss

by Arnt 6y ago

I 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 ago
Replying 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.