3 ms·

> From first principles, you should always expect that regulation increases prices and the burden of proof is to argue why it would not. This reads like: From

• dmonitor 3y ago
  > From first principles, you should always expect that adding lines of code increases the time it takes to execute and the burden of proof is to argue why it would not. I would also argue this is true? Assuming more lines of code directly translates to more CPU instructions
  • metabagel 3y ago
    No, it’s not true. You can add lines of code which use a more efficient algorithm.
    • _gabe_ 3y ago
      > You can add lines of code which use a more efficient algorithm. Yes, so the burden of proof is on the algorithm. Adding more lines of code, by default, makes the code slower. If the algorithm is more efficient, it can make the code faster. But it must be more efficient. This logic seems to hold up to me, but maybe I’m missing something here?
      • michaelmrose 3y ago
        Having more lines of code doesn't even reliably map to having more machine instructions let alone time complexity of solution. Given 2 programs lines of code is a measure so worthless that no reasonable evaluator would start with the assumption that the smaller solution is faster and work from there. They would instead start with the actual code. The point of the analogy which is easily lost in comparing the mechanics of the actual thing is that you must in truth examine the regulation to discern if it on overall makes things more expensive rather than starting off by making the assumption that it does.
        • _gabe_ 3y ago
          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.
          • michaelmrose 3y ago
            > 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.
            • 3y ago
      • r_sreeram 3y ago
        Here's an excellent example of what GP said: https://www.youtube.com/watch?v=FJJTYQYB1JQ https://www.youtube.com/watch?v=FJJTYQYB1JQ (long video, skip to 26:00 if you are in a hurry) The key is that code isn't running in a vacuum. It's operating on data (or controlling systems, etc). A smaller amount of code may be operating on the data in an inefficient manner, whereas a larger amount may be doing it more efficiently. In the above talk, this contrast is very stark, because the "more code" version does some stuff and then does the exact thing the "less code" version does, yet is faster. This kind of thing is common enough (albeit less stark than in the above example), that "less code is faster" is not a great "default" assumption to make.
    • sahila 3y ago
      Of course it's not always true but I think there's an implicit assumption of "all things equal". The same efficient algorithm written in more lines of code vs less lines of code would be less cpu instructions in the latter.
      • nerdbert 3y ago
        I don't think that assumption is implicit in this argument, since it's specifically about whether complexity can lead to better optimization.
  • deleted 3y ago
    [deleted]