3 ms·

Great find! One comment on what the article says: > If this were actual code review the correct comment would be something like “this [piece] hasn’t been used

by anyfoo 2y ago

Great find! One comment on what the article says: > If this were actual code review the correct comment would be something like “this [piece] hasn’t been used for years, it should be deleted”. But this is something in physical space, and there would be arguments that removing it (them) means the route has changed, thus times are no longer comparable. Hmm, I think the correct analogy is rather a benchmark. Like code in a benchmarking tool or test, the whole climbing course does not serve any purpose, any actual goal, except to be completed as fast as possible. You wouldn't say "these instructions should be deleted because branch prediction and speculative execution in recent years have made it so that total cycle count is the same without them", for the reason stated ultimately after in the article already: That may not have been true in the past, and may change again in the future.

bigiain 2y ago
> "these instructions should be deleted because branch prediction and speculative execution in recent years have made it so that total cycle count is the same without them" Then a new CPU architecture becomes popular, and spiders start winning every speed climbing event
masklinn 2y ago
> You wouldn't say "these instructions should be deleted because branch prediction and speculative execution in recent years have made it so that total cycle count is the same without them" This is a very different statement than the original, and furthermore the original might actually trigger performance issues e.g. while the operation might not be used anymore it can have side effects (like triggering a prefetch) which end up affecting downstream code.
- yccs27 2y ago
  Yep, and even if the hold is not used anymore it can have side effects (like being in the way) which can end up affecting the climbing movements ;)
yccs27 2y ago
In the benchmark analogy, that piece would be a line of code that can be optimized away by the compiler. It could still matter if the code (course) is recompiled (rerouted) for a different architecture (climber).
canucker2016 2y ago
My analogy is that "The bug is in the error-handling portion of the common fast-path speed traversal of the climb." The fast path that the speed climbers commonly use doesn't involve the slower path involving the buggy portion. But if the climber can't get up/further using the fast path then the climber may be forced to take the slower path. Since the slower path is standardized, the climber knows how much effort/time is needed on the slower path. Except on the righthand side, the climber's typical effort along the slower "buggy" path is different from the typical slower path and will result in an even slower time aka the execution time in the error-handling path is larger than usual...

by anyfoo 2y ago

bigiain 2y ago

> "these instructions should be deleted because branch prediction and speculative execution in recent years have made it so that total cycle count is the same without them" Then a new CPU architecture becomes popular, and spiders start winning every speed climbing event

masklinn 2y ago

> You wouldn't say "these instructions should be deleted because branch prediction and speculative execution in recent years have made it so that total cycle count is the same without them" This is a very different statement than the original, and furthermore the original might actually trigger performance issues e.g. while the operation might not be used anymore it can have side effects (like triggering a prefetch) which end up affecting downstream code.

yccs27 2y ago
Yep, and even if the hold is not used anymore it can have side effects (like being in the way) which can end up affecting the climbing movements ;)

yccs27 2y ago

In the benchmark analogy, that piece would be a line of code that can be optimized away by the compiler. It could still matter if the code (course) is recompiled (rerouted) for a different architecture (climber).

canucker2016 2y ago

My analogy is that "The bug is in the error-handling portion of the common fast-path speed traversal of the climb." The fast path that the speed climbers commonly use doesn't involve the slower path involving the buggy portion. But if the climber can't get up/further using the fast path then the climber may be forced to take the slower path. Since the slower path is standardized, the climber knows how much effort/time is needed on the slower path. Except on the righthand side, the climber's typical effort along the slower "buggy" path is different from the typical slower path and will result in an even slower time aka the execution time in the error-handling path is larger than usual...