Skip to content

Performance Research A10 APU Opportunity Counters

github-actions[bot] edited this page Sep 15, 2026 · 1 revision

Peripheral opportunity counters

A10 — Implementation and validation notes

Field Value
Evidence state Diagnostic design; not a runtime optimization
Inspected source 322986f4c5502b3fa887a9605ac8cd88e9b2c579
First experiment Bounded per-thread counts with end-of-window aggregation
Scope Addendum dated September 15, 2026; not a current-main benchmark or implementation status

Unproven performance research · Performance research — common test protocol · Performance research — reproducible checks

Evidence and implementation reasoning

Purpose. Determine whether an idea has enough eligible work before building a broad fast path. Count DSP backend crossings, ordinary-memory versus peripheral accesses, transfer lengths, useful versus empty worker wakes, active HRTF voices, parameter changes, and actual control-value changes. Existing peripheral callbacks also implement halt, DMA, and interrupt behavior; repeated reads/writes cannot be presumed harmless. DSP callbacks, DMA.

Implementation. Prefer per-thread counters with bounded histograms, aggregated outside the timing window. For high-frequency regions, sample timing separately from exact event counting. Keep instrumentation disabled by default, and measure its cost against an uninstrumented binary.

In-the-wild relevance. JACK's real-time callback guidance prohibits operations that can block unpredictably, including I/O, allocation, and locking. xemu's APU thread is not identical to a JACK callback, but the same warning applies to injecting synchronous logs and allocations into deadline-sensitive measurements. JACK callbacks.

Expected gain. None by itself. This is research instrumentation and should not be promoted as a runtime optimization. The useful result is an opportunity fraction and a falsifiable hypothesis.

First patch boundary

Separate exact event counts from sampled duration measurement. Do not add synchronous file output or per-event allocation to the measured path.

hot-path event -> bounded local count -> off-path aggregation -> opportunity estimate

Locate the inspected seam before editing; names or ownership may have changed since the pinned review:

git grep -n -E 'read_peripheral|write_peripheral|dsp_dma_run|voice_worker_thread' -- hw/xbox/mcpx/apu

Proposed focused tests

These are implementation gates to add or exercise, not claims that production tests already exist or passed. Retained standalone checks are on the checks page.

Test ID Setup / deliberate control Required oracle
A10.01 Synthetic workload with a known number of scalar/bulk/peripheral operations. Exact counters agree with the constructed event count; sampled timers are labeled as sampled.
A10.02 Compare identical work with counters off and on; deliberately fill each histogram bucket. Overhead is measured; aggregation remains bounded and no samples silently disappear.
A10.03 Exercise halt/DMA/IRQ-related peripheral callbacks repeatedly. Instrumentation counts without coalescing, skipping or changing callback side effects.

Counters and rejection criteria

Collect: backend_calls, peripheral_calls, eligible_bytes, useful_wakes, active_hrtf_voices, counter_overhead_ns, log_bytes_in_window. Keep exact counts separate from sampled durations; use an uninstrumented build for performance qualification.

Reject or hold: Do not submit diagnostic counter removal as a discovered product speedup. Mark any timing with material observer overhead as diagnostic only.

Follow the common protocol for source identities, previous-main/fixed-baseline controls, raw results, confidence and retail/XISO qualification. No gain becomes proven from a model, cache hit, local operation count, or shifted wait label alone.

Clone this wiki locally