[us-commits] [ehb54/ultrascan3] 0c57fb: somo/grpy: rate-limit progress calls; they cost mo...

[emre brookes]

  Branch: refs/heads/ehb54-issue-984
  Home:   https://github.com/ehb54/ultrascan3
  Commit: 0c57fbfc96e735c40ff26c82c9a1b31bfeeb0916
      https://github.com/ehb54/ultrascan3/commit/0c57fbfc96e735c40ff26c82c9a1b31bfeeb0916
  Author: ehb54 <brookes at uthscsa.edu>
  Date:   2026-08-07 (Fri, 07 Aug 2026)

  Changed paths:
    M us_somo/develop/grpy/grpy_core.hpp
    M us_somo/develop/grpy/linalg.hpp

  Log Message:
  -----------
  somo/grpy: rate-limit progress calls; they cost more than the work they report

A run whose ladder stopped at the same rungs as an earlier one took 8m20s
against 4m09s. Requiring intrinsic viscosity adds no computation -- it only
changes when the ladder stops -- so the doubling was the progress reporting
added in 4e14d5f3.

Progress has two independent problems and one knob cannot solve both:

  FREEZE LENGTH -- the calling thread is a compute worker, so the event loop
  cannot turn until the current slice ends. Fixed by sizing the slice.

  CALL RATE -- the callback itself costs something, paid per call however
  short the slices are. In SOMO it is qApp->processEvents() against an editor
  buffer that grows all session, which is why this hurt a long run and not a
  short one. Nothing controlled this at all: solve() ticked once per tile,
  up to 2*nt calls -- hundreds on a large model -- against an operation that
  is cheap next to the factor.

tune_chunk now times only the work, never the callback. Timing them together
made an expensive callback SHRINK the chunk, which raises the call rate and
makes the overhead worse -- the opposite correction. That defect was real but
was not the main cost: fixing it alone moved 80 calls to 73.

ProgressGate is the actual fix. It rate-limits emissions against what the
callback measurably costs: emit after ~10x the last callback's duration, and
never more often than every ~80 ms. A cheap callback is essentially
unthrottled; an expensive one throttles itself to ~10% overhead instead of
dominating. Applied to assembly, factor and solve.

Measured, 512-bead model with a 20 ms callback: 80 calls and 2.79x the whole
solve before, 11 calls and 1.03x after. A trivial callback is 0.98x, i.e. the
chunking machinery itself costs nothing.

The tradeoff is deliberate: frequent repaints and low overhead are not both
achievable when a repaint is expensive. This favours throughput, so the bar
updates less often exactly where updating is costly.

Fixes ehb54/ultrascan-tickets#984

Co-Authored-By: Claude Opus 5 <noreply at anthropic.com>



To unsubscribe from these emails, change your notification settings at https://github.com/ehb54/ultrascan3/settings/notifications