Skip to content

Native CPU: a stage's forward transforms as one batched region (#560 item 4) #584

Closed

Description

@jtravs

What

#560 item 4, on the CPU: a source's forward transforms as one batched region, each row of each transform a task for one team, in place of one threaded call per transform.

Why it may pay

On a host each forward transform of a stage (the state's, the plasma current's and its edge term's; the quadrature alarm's three) runs as its own threaded call over that transform's columns. With four modes, four of 16 threads have work.

The Julia backend experiment (#559) ran them as one pool's work, each block of each transform a task. On an Intel Xeon Gold 6240 at 16 threads it took rdw's commits from 12.3 ms to 5.8 ms and its source transforms from 8.7 ms to 3.8 ms (#560). After #576, Julia's remaining lead on an Apple M5 Max includes this idea, still untried in native.

SEP 46's calibration (#582) points the same way. On 16 cores of a Google Axion, a team of 8 ran the few-mode tracking cases 9–20 % faster (argon_blueshift_envelope 0.80, h2_raman_averaged 0.90, rdw 0.91) and the large ones up to 1.8 times slower. A process-wide narrower team cannot serve both; filling the team with more work per region can.

What native already has

The device path stacks a stage's forward rows into one buffer and one plan: packs_forward() and transform_forward_pack() in native/src/general.cpp, carrying the in-stage absorber's rows, the projection's (fine and coarse) and the held currents'. On a host packs_forward() returns false behind a compile-time #if. A CPU version can reuse the buffer layout and differ only in how the batch runs:

  • one FFTW plan over all rows (howmany = the batch), threaded by FFTW; or
  • blocks of single-threaded plans as tasks of one OpenMP region, as Julia does.

Plan

  1. Probe (free hardware): enable the pack on a host behind a build switch; A/B rdw, ctc, line, h2_raman_averaged and argon_blueshift_envelope against the current build on one socket of an Intel Xeon Gold 6240, at 1 and 16 threads. Fields must agree to rounding.
  2. If it pays, a PR stacked on SEP 46: calibrating the native backend to its machine #582: the batched region's width becomes an operation class of SEP 46's CpuExecution (a built-in threshold and calibrated candidates), qualified with the tracking set on the machines of SEP 46 section 7 item 1.

Done when

The probe's ratios are recorded with hardware and date. Then either the host batch lands with its grain calibrated, or this issue closes on the numbers.

Activity

  1. added a commit that references this issue on Nov 9, 2026
  2. jtravs commented on Nov 9, 2026

    @jtravs
    ContributorAuthor

    John Travers has asked for this experiment and any resulting implementation to be included directly in SEP 47, tracked by #588 and proposed in #589 (scope revision 2a66238). SEP 46 / #582 is already merged; no separate prerequisite PR is needed.

    Probe the host batched FFTW/OpenMP alternatives early, including the proposed short Xeon Gold 6240 cases at one and sixteen threads. Qualify numerical agreement, planning/storage cost and interaction with SEP 46's CpuExecution policy. Integrate a measured winner in phase 3; retain the issue's option to conclude with documented negative results. An unhelpful transform experiment does not block the session architecture or require a broader FFT redesign.

    Keep the transform improvement separately attributable: compare the original baseline, focused optimizations on the old ownership model, and the session using those same optimizations (or a documented ablation). A kernel gain must not conceal a session regression.

    The SEP remains Draft pending the maintainer's reading and explicit acceptance. This records scope and sequencing; the experiment has not been run by this documentation update.

  3. added 2 commits that reference this issue on Nov 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions