Skip to content

perf(von-mises): CDF dispatch thresholds were provisional since #51 — both Mac tiers measure parallel NEVER wins (memory-bound #111 batch CDF); Zen 4 row needs a sustained re-measure #144

Description

@OldCrow

The #51 Bessel-series CDF landed with provisional dispatch thresholds on every tier ("initial value, pending benchmark tuning"). The v2.4.0 calibration legs measured them:

  • kNeon (M1): sustained V→P crossover NEVER — BEST=VECTORIZED at 2M in all 3 runs (forced-parallel 0.20× at 2M). Encoded row dispatched parallel from 100000, a measured ~5× slowdown for every large batch. Bundle: data/profiles/dispatcher/2026-09-04T04-22-28Z_darwin-arm64_dev-v2.4.0_sha-5f27ee1/.
  • kAvx2 (Kaby Lake): sustained NEVER in all 3 runs (forced-parallel 0.27× at 2M). Encoded row dispatched parallel from 200000. Bundle: data/profiles/dispatcher/2026-09-04T02-36-22Z_darwin-x86_64_dev-v2.4.0_sha-5f27ee1/.

Mechanism is #111: the batch CDF is O(count × j_max) full-array sweeps with heap allocations — memory-bound, the same class as Beta PDF/LogPDF, so a real fork adds contention without adding bandwidth.

Fixed on dev for kNeon and kAvx2 (CDF → NEVER, cross-referenced to #111 for re-profiling once that lands).

Remaining: the kAvx512 row (CDF 25000) is equally provisional but there is no checked-in Zen 4 sustained data to justify changing it — the 12-thread Zen 4 may legitimately differ. Needs one sustained re-measure on the Zen 4 machine; the row comment now says so. Close this issue when the kAvx512 cell is either confirmed or corrected from measurement.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions