Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Array construction queries device properties on every allocation

Ouverte
  • Quelque chose ne va pas ?
#690 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@maleadt y travaille déjà.

Depuis le 16/10/2026.

  • #705 par @maleadt — ouverte

Évaluation

Difficulté
3/5
Temps estimé
Une demi-journée
Accessibilité débutants
65/100
Type d'issue
Refactorisation
Clarté
Clairement spécifiée
Activité
Active
Domaine
performance

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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)
Langage dominant
Julia
Étoiles
217
Forks
37
Merge moyen
1 j 5 h
PR mergées (30 j)
40

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de JuliaGPU/oneAPI.jl

Toutes les issues de JuliaGPU/oneAPI.jl

Issues similaires

Plus d'issues Julia

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.