Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Gluon all-gather reloads peer heap bases inside the tile loop

Aperta
  • Qualcosa non va?
#591 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@vishalshetagar ci sta già lavorando.

Dal 18/10/2026.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
hpc, python
Ambito
distributed-systems, performance

Direzione di ricerca

Start in iris/ccl/gluon/all_gather.py around lines 113-158, where the local heap base is already hoisted but peer bases are loaded per destination inside the tile loop. Hoist each destination's ptr_delta and the loop-invariant output_ptrs out of the loops, then check iris/ccl/gluon/all_to_all.py near line 130 for the same pattern. Done means correctness matches torch.distributed on 2, 4 and 8 ranks, and benchmark/ccl/bench_all_gather.py shows before and after numbers.

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

Descrizione

gluon good first issue help wanted iris python

Gluon all-gather reloads peer heap bases inside the tile loop

Follow-up to #585, where this was raised and deferred.

1. Hoist the peer heap bases

iris/ccl/gluon/all_gather.py:

113:  local_base = gl.load(ctx.heap_bases + iris_rank)      # hoisted, once
115:  for tile_id in range(pid, total_tiles, COMM_SMS):
147:      for rank_idx in range(world_size):
150:          output_ptrs = output_ptr + output_offsets      # loop-invariant
158:              target_base = gl.load(ctx.heap_bases + target_iris_rank)   # per dest, per tile

The comment at line 111 says the hoist "eliminates redundant gl.load(heap_bases)
calls in the inner store loop", but only the local base was hoisted. At 8 ranks
the loop still does 7 peer loads per tile. heap_bases, rank_start, rank_stride
and world_size are all tile-invariant, so each destination's ptr_delta can be
computed once before the tile loop — the same fix #585 applied to the TDM path in
d626261b. output_ptrs at line 150 is invariant across rank_idx too.

2. INLINE grouping, deferred from #585

From that review thread:

The grouping idea seems most useful for the register store path (gl.store),
where it bounds live values; I'd leave that to a later PR.

That is this file. These stores hold data live in registers across the whole
destination loop, and the docstring already warns the path is register-sensitive:
"Larger tiles cause register spilling and performance collapse."

Work

  • Hoist the per-destination ptr_delta out of the tile loop
  • Hoist output_ptrs out of the rank_idx loop
  • Confirm in the ISA whether range(world_size) at line 147 unrolls — it is
    range, not tl.static_range, and the grouping argument rests on it
  • Try INLINE grouping at 4 and 8; measure VGPR count and spill, not just time
  • Check iris/ccl/gluon/all_to_all.py:130 for the same pattern
  • Correctness vs torch.distributed on 2/4/8 ranks before timing
  • Before/after through benchmark/ccl/bench_all_gather.py

We expect a performance improvement here; it needs measuring.

Lingua principale
Python
Stelle
203
Fork
54
Merge medio
5g 4h
PR unite (30g)
27

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

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 ROCm/iris

Tutte le issue di ROCm/iris

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.