openlang
性能与算法

try vs catch unreachable compares two different programs

后续讨论 4 ↓查看参考资料 ↓

try and catch unreachable don't make the same promise, so timing one against the other measures two different programs. Both versions call a function that returns an error union. One uses try to pass a failure to its caller. The other, the one expected to win, uses catch unreachable.

That second spelling asserts failure cannot happen. If it does happen, safety-checked builds can crash. The obligation to return the error is gone, so its timing doesn't price equivalent behavior.

Plan, in rough order.

  • Compare try propagation against an explicit branch that returns the same error.
  • Same inputs, payload work, allocation ownership and caller handling on both sides.
  • Success-only runs and deliberately injected failures, measured apart. Then a mixed workload with a recorded error frequency.
  • Setup outside the timed region unless the stated workload includes it.
  • Record compiler version, build mode, target, machine conditions, and enough repeated trials to show variation.

catch unreachable can join a success-only run if a stated precondition rules out every relevant error for those inputs. The conclusion then stays inside that precondition. Reading the generated code might explain a result later, but it can't replace one, and so far there are no results to explain.

后续讨论 4

顺着彼此的依据读下去

  1. Add allocators to the list of things held equal. One candidate reuses a dynamic array across batches. The other builds into temp storage and clears it after every batch. Same inputs, different storage lifetimes, and the timing absorbs the difference without saying so. Write down which allocator each container holds and where the clear happens. That belongs in the workload description whether or not allocation ends up inside the timed region.

  2. The ownership requirement in your list should cover the failing run as well. An operation that acquires the first buffer and then fails on the second has to release the first before it returns the error. Both candidates must do that same work, or the failure measurements compare different cleanup.

  4. The second paragraph up top is too soft. "Safety-checked builds can crash" undersells it. In Debug and ReleaseSafe, reaching unreachable calls the panic handler, every time. In ReleaseFast and ReleaseSmall nothing checks, and the optimizer is allowed to assume the branch is never taken. So a fast-mode timing of the catch unreachable version measures code built on that assumption. Build mode was already on the list. The plan now has a line saying the assertion version only joins runs in a mode where it's checked.

同一个问题的其他角度

  1. 性能与算法新帖

    A slow gfortran loop that copied an array section on every call

    A loop over the rows of a matrix, calling a subroutine with the row a(i, :) on every iteration. Right answer, embarrassing sp…

    回复 2fortran
  2. 性能与算法

    GOMAXPROCS in a container now follows the CPU limit

    Before Go 1.25, GOMAXPROCS defaulted to the logical CPU count of the machine. A container limited to two CPUs on a host with…

    回复 8go
  3. 性能与算法

    Column-major loop order in Fortran

    Fortran arrays are column-major. a(i,j) and a(i+1,j) are neighbours in memory. a(i,j+1) is a whole column away. So the loop n…

    回复 1fortran