3 ms·

Your rule is much weaker to the point of being useless -- you are claiming that if it took me 1 hour to write high-level code, the compiler will generate better

by theamk 6y ago

Your rule is much weaker to the point of being useless -- you are claiming that if it took me 1 hour to write high-level code, the compiler will generate better assembly code than what I can write in 1 hour. This is obviously true in most cases -- if it takes me an hour to write task X in high-level language, it will probably take me a day or more to write it in assembly. After spending only one hour on assembly version the program will be nowhere close to completion, and likely completely non-functional. So whatever compiler produces will be much better -- it will at least work. I can believe that at some moment hand-rolled assembly will "beat" generated code (I am pretty sure that if someone spends a month optimizing assembly listing it will beat the best Rust program written in a hour), but I am not sure what the ratio is. I am sure it is not 1:1, and I suspect the ratio gets worse as program grows and there are more parts that one needs to keep track of.

adwn 6y ago
> Your rule is much weaker to the point of being useless Yes, it's much weaker, but it's not useless. The vast majority of code in a program does not need to be as fast as it could possibly be [1], so there's no point in manually implementing everything in assembly. That doesn't mean that it never makes sense to manually implement something in assembly for performance reasons. [1] And for many programs, all the code does not need to be as fast as it could possibly be.
- theamk 6y ago
  Right, but I called the rules "useless" because it does not tell you any actionable info -- and this is normally expected of rules. Here is a fixed version (note I added "times 20" at the end): "the compiler generates better assembly code than a human could within the time it takes to write high-level code times 20" See -- now I can make predictions. Let's say you have a function that you want to make fast, and you want to optimize it in assembly. The function took 30 minutes to write and debug. Do you have 10 hours to spare? Try assembly. No time? Leave as-is. Much more useful this way, no?
  - adwn 6y ago
    Now it's more accurate, but even less catchy ;-) How about: "don't blindly assume that the compiler is smarter than you"
    - Dylan16807 6y ago
      That sounds like a special case of "nothing is perfect" and even less actionable. Especially with how vague "blindly" is.

by theamk 6y ago

adwn 6y ago

> Your rule is much weaker to the point of being useless Yes, it's much weaker, but it's not useless. The vast majority of code in a program does not need to be as fast as it could possibly be [1], so there's no point in manually implementing everything in assembly. That doesn't mean that it never makes sense to manually implement something in assembly for performance reasons. [1] And for many programs, all the code does not need to be as fast as it could possibly be.

theamk 6y ago
Right, but I called the rules "useless" because it does not tell you any actionable info -- and this is normally expected of rules. Here is a fixed version (note I added "times 20" at the end): "the compiler generates better assembly code than a human could within the time it takes to write high-level code times 20" See -- now I can make predictions. Let's say you have a function that you want to make fast, and you want to optimize it in assembly. The function took 30 minutes to write and debug. Do you have 10 hours to spare? Try assembly. No time? Leave as-is. Much more useful this way, no?
- adwn 6y ago
  Now it's more accurate, but even less catchy ;-) How about: "don't blindly assume that the compiler is smarter than you"
  - Dylan16807 6y ago
    That sounds like a special case of "nothing is perfect" and even less actionable. Especially with how vague "blindly" is.