JuliaGPU / JuliaGPU/KernelAbstractions.jl
How to query a backend's native/recommended groupsize?
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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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