Sure, lines of code doesn’t correlate to how much actual code is produced, but I feel like that’s just being pedantic. The assumption that I’m stating here is: the more stuff a CPU has to do, generally the longer it’s going to take to do the stuff.
I’m not arguing that a more complex algorithm can do the same stuff quicker. Of course you can do that. There’s plenty of examples of that. But in the general case, doing more things takes longer.
Of course, the CPU can execute instructions in parallel, it can pipeline instructions and gain a higher throughput, it can predict branches, etc. But those are things you have to be intentional about enabling more often than not. Making small changes in the higher level code can ruin whatever performance gains you had gained because you accidentally trashed the throughput or something.
Generally, more instructions takes longer to process. Of course, a more complex algorithm can do the stuff quicker. But it’s not the default and depending on the problem, it can be very difficult to get it to go quicker with more instructions.
This isn’t even something that should be hard to conceptualize. Getting an element out of an array using an index is O(1). Getting an element out of a hashmap is also O(1) (when there’s no collisions). Even though these both perform the same in terms of complexity (“constant” time) the array will win every time if you already know the index. Why? Because the hashmap uses more instructions to figure out where the index is.
So I really don’t understand why the assumption that: generally, more code = slower is a bad one to make. Unless you explicitly try to make the code with more instructions faster, it will usually be slower than if you did it with less instructions.
> Sure, lines of code doesn’t correlate to how much actual code is produced, but I feel like that’s just being pedantic.
It is actually the core of the entire understanding. There is no mapping whatsoever lines of code and instructions executed. A finite program that doesn't halt will result in infinite instructions. 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.
Basically everything from function calls to loops ruins any mapping between brevity and execution time.
Normally I don’t continue with arguments like this haha. But I just want to point out that I keep saying generally more code means a slower algorithm. And when I say slower algorithm, that implies I’m comparing it to something. The thing I’m comparing it to is an equivalent algorithm with less lines of code. An infinite loop will run forever with just a few instructions. But I’m not comparing an infinite loop to anything here.
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.
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.
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.
I’m not arguing that a more complex algorithm can do the same stuff quicker. Of course you can do that. There’s plenty of examples of that. But in the general case, doing more things takes longer.
Of course, the CPU can execute instructions in parallel, it can pipeline instructions and gain a higher throughput, it can predict branches, etc. But those are things you have to be intentional about enabling more often than not. Making small changes in the higher level code can ruin whatever performance gains you had gained because you accidentally trashed the throughput or something.
Generally, more instructions takes longer to process. Of course, a more complex algorithm can do the stuff quicker. But it’s not the default and depending on the problem, it can be very difficult to get it to go quicker with more instructions.
This isn’t even something that should be hard to conceptualize. Getting an element out of an array using an index is O(1). Getting an element out of a hashmap is also O(1) (when there’s no collisions). Even though these both perform the same in terms of complexity (“constant” time) the array will win every time if you already know the index. Why? Because the hashmap uses more instructions to figure out where the index is.
So I really don’t understand why the assumption that: generally, more code = slower is a bad one to make. Unless you explicitly try to make the code with more instructions faster, it will usually be slower than if you did it with less instructions.