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

Array construction queries device properties on every allocation

Aperta
  • Qualcosa non va?
#690 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à
3/5
Tempo stimato
Mezza giornata
Idoneità per principianti
65/100
Tipo di issue
Refactoring
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Ambito
performance

Direzione di ricerca

Start in check_eltype and _device_supports_bfloat16 in src/array.jl, and reuse the device_limits cache in src/oneAPIKernels.jl as a pattern. Run the benchmark script in the issue to get a baseline, then check _device_supports_bfloat16 in compilation.jl too. Done when the fp16, fp64 and bf16 flags are cached per device, the capability bits come from module_properties(dev).flags, the benchmark drops well below 1 µs, and test/runtests.jl still passes.

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

Descrizione

check_eltype (src/array.jl), which runs on every oneArray construction, queries the driver each time it's called:

  • oneL0.module_properties(device()), twice (Float16 and Float64 checks);
  • _device_supports_bfloat16(), which on devices that don't advertise ZE_bfloat16_conversions (everything except PVC with recent drivers) falls through to oneL0.properties(dev). That builds the full device-properties NamedTuple, including the name String and UUID.

On an Iris Xe (TGL, NEO 26.18) with oneAPI.jl master (fa0f23a2):

call median allocs
oneAPI.check_eltype(Float32) 29.2 µs 67 (3.4 KiB)
oneL0.properties(dev) 20.9 µs 32
oneL0.module_properties(dev) 2.6 µs 15
check_eltype with cached capability flags 0.08 µs 1

Allocating and freeing a small array (unsafe_free!(oneArray{Float32}(undef, 16))) takes about 25 µs on an idle machine, so this check accounts for most of the cost of a small allocation. A profile shows most samples under check_eltype → _device_supports_bfloat16 → properties. Arrays allocated inside GPUArrays/AcceleratedKernels internals (reduction scratch space, similar) pay this cost as well.

Suggested fix: compute the per-device capability flags (fp16, fp64, bf16) once and cache them, like device_limits in src/oneAPIKernels.jl does (a Dict keyed by ZeDevice), or memoize properties/module_properties themselves, since they're static for a device. compilation.jl also calls _device_supports_bfloat16(dev), so it would benefit too.

While you're there: check_eltype (and test/runtests.jl) test fp16flags & ZE_DEVICE_MODULE_FLAG_FP16 and fp64flags & ZE_DEVICE_MODULE_FLAG_FP64. But fp16flags/fp64flags are ze_device_fp_flags_t (DENORM=1, INF_NAN=2, ...), not ze_device_module_flags_t, so these checks test the denorm/inf-nan bits. They give the right answer in practice (a device either reports no fp64 flags at all or reports the full set), but the capability bits are in module_properties(dev).flags, which is what device_limits already uses.

Benchmark script 
using oneAPI, BenchmarkTools
const L0 = oneAPI.oneL0
dev = device()
@benchmark oneAPI.check_eltype(Float32)
@benchmark L0.module_properties($dev)
@benchmark L0.properties($dev)

const cache = Dict{L0.ZeDevice,NTuple{3,Bool}}()
caps(d=device()) = get!(cache, d) do
    m = L0.module_properties(d)
    (m.flags & L0.ZE_DEVICE_MODULE_FLAG_FP16 != 0,
     m.flags & L0.ZE_DEVICE_MODULE_FLAG_FP64 != 0,
     oneAPI._device_supports_bfloat16(d))
end
function check_cached(T)
    Base.allocatedinline(T) || error()
    fp16, fp64, bf16 = caps()
    fp16 || (oneAPI.contains_eltype(T, Float16) && error())
    fp64 || (oneAPI.contains_eltype(T, Float64) && error())
    bf16 || (oneAPI.contains_eltype(T, Core.BFloat16) && error())
    nothing
end
@benchmark check_cached(Float32)
Lingua principale
Julia
Stelle
217
Fork
37
Merge medio
1g 7h
PR unite (30g)
38

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/oneAPI.jl

Tutte le issue di JuliaGPU/oneAPI.jl

Issue simili

Altre issue su Julia

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.