Device steps are bound by kernel launches and buffer copies, not by arithmetic

Aperta
  • Qualcosa non va?
#357 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
8/100
Tipo di issue
Refactoring
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
cpp, python
Ambito
devtools, performance

Direzione di ricerca

The work is profiling-led and spans the Kokkos backend, the Adams trial paths and the GPU tests, so there is no single file to start from. Begin by reading the linked docs/dev/benchmarks.md and docs/dev/backends.md sections, then re-profile with rocprofv3 --kernel-trace on an MI325X or the CUDA equivalent on an H200. Done means a recorded profile in benchmarks.md, an A/B ratio per kept change, pytest -m gpu passing, and each unsupported lead listed as dropped.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area: gpu area: native performance priority: low
What happens

On data-centre GPUs a step is limited by launching kernels and copying buffers, not by arithmetic, which is why such a GPU gains little on a small problem. The records, each from its source and date:

Much has moved since. An elementwise Adams trial's source now replays as one device graph, saving about a microsecond a kernel, and small functors skip the constant-memory copy. The graph region covers only that source. Reductions, vendor GEMM, team launches with scratch and host copies disable it for the workspace's life, and Runge-Kutta and low-storage trials do not use it. So which of the figures above still hold is unknown: no later measurement of the coupled cases was found in benchmarks.md.

Why it matters

SEP 16 found a fixed cost per trial is what a cheap source cannot hide, leaving IP-DOPRI5 ahead on the canonical capillary and the coupled wall on devices. It sets the smallest problem worth running on a GPU, and is the reason for #356.

To do
  • Re-profile at the current tree before changing anything, with rocprofv3 --kernel-trace and the CUDA equivalent, on an MI325X and an H200: a fibre step at 2^16, a Cartesian Multistep trial, and the taper and wall.
  • For each remaining lead, fuse or drop it according to that profile: kernel fusion or graph capture beyond the Adams source, then the copies, then the two SEP 16 and SEP 25 fusions.
  • Record the profile in benchmarks.md.

What must not change: fields, beyond the rounding bound each pass already holds, and steps on a fixed schedule. Check a fused pass against #103's neighbouring changes, which touch the same trial paths. #78 has an entry saying this roadmap item should mention the graph capture, which this text does.

Done when

The profile is recorded with device and date. Each kept change's python -m benchmarks ab --device ratio on a data-centre GPU is in its pull request and shows a gain with the same steps, and pytest -m gpu passes on a CUDA and a HIP build. A lead the profile does not support is listed as dropped.

Checked against commit 8a9f764. Takes over the roadmap's entry "Launch and copy overhead on GPUs with full-rate binary64", and the clause on the coupled cases' launch and copy counts in "Execution autotuning beyond existing CPU controls", which belongs here rather than under autotuning (#115).

Lingua principale
Python
Stelle
3
Fork
3
Merge medio
8h 37m
PR unite (30g)
159

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di LupoLab/solprop

Tutte le issue di LupoLab/solprop

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.