Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Array construction queries device properties on every allocation

オープン
  • 何か問題がありますか？
#690 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
半日
初心者へのやさしさ
65/100
issue の種類
リファクタリング
明瞭さ
明確に書かれている
活発さ
活発
領域
performance

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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)
主要言語
Julia
スター
217
フォーク
37
平均マージ
1日 7時間
マージ済み PR（30日）
33

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

JuliaGPU/oneAPI.jl のほかの issue

JuliaGPU/oneAPI.jl の issue をすべて見る

似ている issue

Julia の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。