T34 — fused pipeline: close the sm_89 gap

Closed
  • Is something wrong?
#156 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

A pull request for this has already been merged.

  • #178 by @michel2323 — merged

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
julia
Domain
backend, performance

Research direction

Start with the T33 Report in TASKS.md and the tuning gates in bench/ARCH-TUNING.md; reproduce the sm_89 measurements with bench/e2e/fused_probe.jl. The proposal lists six ordered optimization steps, with earlier work tracked in #154 and #155. Done means measuring the fused refactorization and solve on sm_89 against the stated baselines and evaluating the proposed steps, but the issue does not define a single bounded completion criterion.

Written by the indexing model from the issue text.

Description

found-by-agent fused performance task

Found while working on: T33 (PR #153)

What: on the RTX 4080 (sm_89) the fused pipeline that FusedSolver and the MadNLP extension's SDSSolver run is well behind cuDSS 0.8.0. On the 78k-bus condensed KKT (idle GPU, bench/e2e/fused_probe.jl) a refactorization takes 28.2 ms against 16.2 ms (1.74×) and a solve 3.9 ms against 1.8 ms (2.2×); on the harness matrices the refactorization ratio is 1.6× (case118) to 3.3× (bcsstk38). One refactorization is 34 launches: the dependency-counter mega-kernel 23.0 ms, the subtree kernel 3.5 ms, invert_l11_kernel! 2.4 ms, 28 scatter_A! launches 0.14 ms, statistics and zeroing 0.6 ms. The solve is 4 launches, fwd2 2.3 ms and bwd2 2.1 ms. The launch count is not the problem; the time is inside the two counter kernels. The full numbers are in the T33 Report in TASKS.md.

Why it is out of scope: T33 was a pure refactor with no kernel change. No task in TASKS.md owns the performance of the fused kernels on sm_89; T24–T26 integrate them under execute!. This issue tracks the T34 proposal of the T33 Report, added to TASKS.md as T34 to run before T24.

Suggested fix or plan change: the T34 steps, in order of measured payoff on the 78k, each gated as in bench/ARCH-TUNING.md:

  1. the L₁₁ inverse written by the panel roles, dropping the invert_l11_kernel! launch (#155, −2.4 ms);
  2. a gpu-scope device_fence() hook in the fused kernels (#154, −3.5% on the 78k, −8% on lap3d_40);
  3. the subtree bucket and the fixed launches re-measured after 1–2;
  4. the fused solve on 76-SM parts (fwd2/bwd2 occupancy, the chain_* kernels);
  5. a per-front wide strategy in merged mode, for lap3d-class roots;
  6. CUDA-graph replay of refactorize + inverse and of the solve for n ≲ 1e5.
Dominant language
Julia
Stars
7
Forks
0
Avg merge
12h 41m
Merged PRs (30d)
46

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from exanauts/SparseDirectSolver.jl

All issues in exanauts/SparseDirectSolver.jl

Similar issues

More Julia issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.