GPU performance: tracking the open leads on the CUDA and HIP builds

Aperta
#367 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
12/100
Tipo di issue
Refactoring
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
python
Ambito
performance

Direzione di ricerca

This is a tracking list, not a single change, so start by reading the ledger sections in docs/dev/benchmarks.md and the measurement steps in docs/dev/benchmarking.md. Pick one linked issue whose "Done when" you can meet on the named hardware, and run python -m benchmarks ab --device with three rounds. Done means that issue closes or this list gets a note explaining why the lead was dropped.

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

Descrizione

area: gpu area: native performance priority: low

This issue tracks every open lead on the speed of the native backend's GPU builds (CUDA and HIP), so that someone can pick up the next one without reading the history first. Each lead with an issue carries its own detail and "Done when". Tick a box here when its issue closes, and add new leads here as well as opening an issue for them.

Where things stand

PR #59 was the last GPU performance campaign. The ledger's device sections hold the measurements: transfers and the Kerr stage, launches and the Adams passes, graph replay, the four-mode and radial transforms and split real rows. In short, a data-centre GPU's trial is limited by launching 2 to 4 µs kernels from the host, while an NVIDIA A40 is limited by binary64 arithmetic. GPU comes after accuracy and CPU performance in the project's priorities, so this list has no deadline.

Leads, in a suggested order

The order is a suggestion: what makes other measurements trustworthy, then what is cheap, then what is large. Nothing here has been re-measured for this issue.

First, so that the rest can be measured

  • #151: no CI lane builds a device target, so device builds break unnoticed.
  • #366: some device runs take one of two speeds from process to process, which blurs any A/B ratio.

Host work, which needs little or no GPU time to change

  • #346: a saved plane of a large Cartesian field costs about 3 s of host work per plane, mostly copies. It is the only host cost that repeats.
  • #347: the fixed host cost of a run, about 6 s on kerr_beam_384.

Launches and copies

Kernels

  • #352: fusing the band column's kernels, and coalescing the split's transposes.
  • #364: the far-field pass's accumulators in global memory.
  • #359: the on_axis_* statistics copy the whole state to the host.
  • #341: forming fewer propagators where binary64 is slow.

Larger work, each likely its own design

  • #356: a batch axis for lockstep batches of small runs. The roadmap expected its own SEP.
  • #362: an Adams controller held on the device.
  • #355: the carrier frame on devices, refused until it has parity tests and timings.
Related, not speed itself

#353 (the next device qualification), #354 (a scheduled device test lane), #360 (the stepper gallery's device rows), #363 (z tables on GPU builds), #310 (device memory in the run record), #303 (GPU geometries in execution tuning) and SEP 4.

Already tried: do not repeat without new evidence

#59's rejected list and the ledger record these as measured and dropped:

#59 also names "FP32 device paths (findings only)" as a lead, but I found no such finding in the ledger. The nearest record is SEP 36's mixed precision, measured and withdrawn, and #342 holds what single precision still refuses. So it has no box here.

How to measure
  • Compare two builds with python -m benchmarks ab --device, three rounds, as the ledger's tables do. Record a run with python -m benchmarks track --device.
  • Time on the hardware an item names, since the limits differ: an NVIDIA A40 (compute capability 8.6, slow binary64), an H200 or H100, and an AMD MI325X (HIP).
  • Keep the same steps and fields within the floating-point rules of SEP 25, run the gpu-marked tests, and add the result to the ledger.
Done when

Every box is ticked, each by a closed issue or a note here saying why the lead was dropped, with its measurement in the ledger.


Checked against commit 8a9f764. Read, not run: this issue only gathers what the records say.

Lingua principale
Python
Stelle
3
Fork
3
Merge medio
6h 29m
PR unite (30g)
119

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.