JuliaGPU / JuliaGPU/KernelAbstractions.jl

How to query a backend's native/recommended groupsize?

Open
#740 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Julia
Stars
523
Forks
88
Avg merge
1d 11h
Merged PRs (30d)
25

Description

My use cases evolve around sparse linear algebra. As always, there are big differences in performance between CPU and GPU (-like). As a naive solution, I used isgpu(backend) to choose a groupsize. However, isgpu is no longer around, and I have (once) observed the PoCL backend on the CPU to be fastest for a groupsize of 1, whereas the CPU performed better for ~4 and CUDABackend much better for 32 (or 64). I've used smth like this, which I specialized using package extensions:

clamp_groupsize(groupsize::Int, backend)::Int

Technically, one can probably only recommend prod(@groupsize) but not @groupsize directly. It would be nice if KA would provide an abstraction that, in the long term, could make use of CUDA's occupancy API. Therefore, I would recommend smth like

recommended_groupsize(backend, kernel)::Int

where the user then has to recover the actual groupsize for N > 1 dimensional kernels.

  • If CUDA, use the occupancy API
  • If old CPU backend, use number of cores
  • If new PoCL CPU backend, use one (more research needed!)

I'm sometimes confused on whether I should focus on groupsize or the hardware's vector width. Please let me know what you think. 🙂

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files or tests are named. Start by surveying the existing groupsize handling and backend interfaces, then compare the proposed behavior across CPU, PoCL, and CUDA backends, including CUDA occupancy considerations. Done would require an agreed API and documented, validated recommendations for the listed backend cases.

Written by the indexing model from the issue text.

Assessment

Tech stack
julia
Domain
backend-api-design, performance
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.