If you mean to say that on average, if you sample from a distribution of randomly-assembled instructions, then code with more lines will run longer, then that's fair. However, I don't think that most code is randomly-assembled, so sampling from that distribution doesn't make realistic sense to me.
Basically,
> You can speed up an algorithm by using more instructions, but you have to be intentional about it.
I feel like most code is written with some intention. It depends on whether or not you believe that most code is written competently, I guess.
Re:Airlines Are Just Banks Now
by michaelmrose on Friday September 22, 2023 @09:49PM
(#37619939)
It doesn't matter whether it's written competently. The original debate was about lines of code. There is no mapping between lines of code and instructions executed because loops and conditionals are a thing. EG even if 20 lines of code results in twice as many instructions as 10 it tells you absolutely nothing about how many times each instruction will be executed and ergo nothing about the clock time required to execute the program.
And just to be clear, I do agree with everything you’re saying here, but I do think you’re still being overly pedantic.
> Less pedantically a sorting function that is far more efficient will result in the instructions corresponding to individual operations being called thousands of times less.
Exactly. The goal is to spend fewer instructions to achieve the same outcome. As soon as you start thinking about how different instructions take different amounts of cycles and you can speed up an algorithm by using more instructions that are cheaper, that kind of proves my whole point. You can speed up an algorithm by using more instructions, but you have to be intentional about it. The default will never be: more instructions = faster.