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

Let machine-code generation in external back-ends run concurrently

Aperta
  • Qualcosa non va?
#1,014 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
10/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
cpp
Ambito
compilers

Direzione di ricerca

The relevant code is external_compile in src/utils.jl, which is a GC-unsafe ccall, and the back-end Compile paths in the bundled C++ files that take APILock and install ScopedFatalErrorHandler. The issue proposes two separate changes: making the ccall GC-safe, and moving the handler install out of each compile. It also asks for a new entry point after compile(:llvm). Nothing is settled yet, so the first step is to agree on the design with maintainers, not to write a patch.

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

Descrizione

gcn latency

JuliaGPU/CUDA.jl#3398 lets CUDA.jl run ptxas without holding its compile lock, so kernels requested from several tasks overlap their assembly. Looking at whether AMDGPU.jl should do the same showed that its expensive step is machine-code generation in the external LLVM back-end (mcgen → external_compile), not linking. That step can't currently overlap with anything, for three reasons:

  1. external_compile is a GC-unsafe ccall (src/utils.jl). Any thread that needs a collection waits for the back-end to finish. On a Radeon 610M, a GC.gc(false) on another thread took 834 ms while AMDGPUCompile ran, against 2.3 ms otherwise. The call could be a @gcsafe_ccall; the diagnostic callback is a @cfunction, which switches back to GC-unsafe when called.
  2. The back-end libraries serialize Compile on a process-wide APILock. That applies to libamdgpu, libnvptx and libspirv (Yggdrasil A/AMDGPU_LLVM_Backend, C/CUDA/NVPTX_LLVM_Backend, S/SPIRV_LLVM_Backend, bundled/*.cpp). Six concurrent AMDGPUCompile calls on 6 threads took 5.6 s, the same as running them one after another, though the outputs were identical. As far as I can tell, Compile only needs the lock because it installs LLVM's process-global fatal-error handler per call (ScopedFatalErrorHandler). Each compile has its own LLVMContext, TargetMachine and pass manager. The throwing handler is stateless, so installing it once during target initialization would let compiles run in parallel. AMDGPULink would keep the lock, since lld's global state needs it.
  3. There is no way for a back-end to run machine-code generation outside its own compile lock. GPUCompiler.compile(:obj/:asm, job) runs it as part of the pipeline. A back-end that keeps codegen under its lock (as the cached_results contract asks) would need an entry point that takes the optimized module, or its bitcode, after compile(:llvm). It could then release the lock around that step, as CUDA.jl does around ptxas.

How much this matters, per kernel (large unrolled kernel, warm compiler):

Julia → LLVM LLVM → machine code rest
AMDGPU (gfx1036) 0.82 s 1.0 s link 5 ms, module load 2 ms
CUDA (sm_120) 0.72 s 0.27 s ptxas 1.1 s (now outside the lock)

So for AMDGPU, about 55% of a kernel's compile time could overlap with other tasks' codegen, and 1 above is worth doing on its own. For CUDA the gain is smaller (about 13%). Releasing AMDGPU.jl's hipfunction_lock around linking and module loading alone isn't worthwhile, since those take milliseconds.

Lingua principale
Julia
Stelle
188
Fork
71
Merge medio
1g 13h
PR unite (30g)
68

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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 JuliaGPU/GPUCompiler.jl

Tutte le issue di JuliaGPU/GPUCompiler.jl

Issue simili

Altre issue su Julia

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.