3 ms·

I don't think I entirely agree with the premise here. Yes, it is extremely difficult to engineer performance in after the fact; but assuming you've got an archi

I don't think I entirely agree with the premise here. Yes, it is extremely difficult to engineer performance in after the fact; but assuming you've got an architecture that's basically fit for purpose (from the performance perspective), then improving by targeting hotspots is sound, isn't it? That's literally Amdahl's law.

Sesse__ 3y ago
Amdahl’s law is specifically about the futility of optimizing by removing hotspots... (Or rather, that it can only take you so far.)
- taneq 3y ago
  No, it's about the limitations of optimizing individual parts of a program. A corollary would be the futility of optimizing non-hotspots if you want any significant gain. If your code spends 80% of its time in a given function you can't speed up the overall task by more than 500% by optimizing that function alone. If it spends 1% of its time in a given function then you can't speed it up by more than 1.1% by optimizing that function.
  - astrange 3y ago
    Performance isn't all first order wallclock time stuff. If you rarely enter one part of the program but that part accidentally deletes all your caches, everything else is going to get slower afterward.
taneq 3y ago
Yeah, I'm with you. The 80/20 rule isn't about "write code slow then speed up the inner loops", it's about "don't waste time optimizing the slow bits, which means don't waste time optimizing anything until you know which bits are the slow bits." It's explicitly about micro-optimizations, not architecture. And it's about helping devs avoid bogging down doing pointless work making micro-optimizations that will never affect the performance metrics that you care about.
- anonymoushn 3y ago
  You can't wait until the program is working correctly and you've benchmarked it to start optimizing. By then it is too late, you've already committed to data layouts that cannot possibly be fast.
  - taneq 3y ago
    Again, micro-optimisations. You still want to think about your architecture, data representations etc. right from the start. Just don’t start hand-coding asm to speed up your config file parser from day 1.
    - elvis10ten 3y ago
      > Just don’t start hand-coding asm to speed up your config file parser from day 1. The comment you reply to is talking about thinking about performance even during initial design. Based on your last sentence, you seem to be the only one thinking of micro-optimizations.

Sesse__ 3y ago

Amdahl’s law is specifically about the futility of optimizing by removing hotspots... (Or rather, that it can only take you so far.)

taneq 3y ago
No, it's about the limitations of optimizing individual parts of a program. A corollary would be the futility of optimizing non-hotspots if you want any significant gain. If your code spends 80% of its time in a given function you can't speed up the overall task by more than 500% by optimizing that function alone. If it spends 1% of its time in a given function then you can't speed it up by more than 1.1% by optimizing that function.
- astrange 3y ago
  Performance isn't all first order wallclock time stuff. If you rarely enter one part of the program but that part accidentally deletes all your caches, everything else is going to get slower afterward.

taneq 3y ago

Yeah, I'm with you. The 80/20 rule isn't about "write code slow then speed up the inner loops", it's about "don't waste time optimizing the slow bits, which means don't waste time optimizing anything until you know which bits are the slow bits." It's explicitly about micro-optimizations, not architecture. And it's about helping devs avoid bogging down doing pointless work making micro-optimizations that will never affect the performance metrics that you care about.

anonymoushn 3y ago
You can't wait until the program is working correctly and you've benchmarked it to start optimizing. By then it is too late, you've already committed to data layouts that cannot possibly be fast.
- taneq 3y ago
  Again, micro-optimisations. You still want to think about your architecture, data representations etc. right from the start. Just don’t start hand-coding asm to speed up your config file parser from day 1.
  - elvis10ten 3y ago
    > Just don’t start hand-coding asm to speed up your config file parser from day 1. The comment you reply to is talking about thinking about performance even during initial design. Based on your last sentence, you seem to be the only one thinking of micro-optimizations.