jit: cache resolved kernel name beside cubin to fix slow warm-cache loads#43
Conversation
There was a problem hiding this comment.
Code Review
This pull request introduces a caching mechanism for resolving kernel names in cubin files (find_kernel_name_in_cubin_cached) to avoid slow, GIL-holding ELF symbol iteration on subsequent runs. Feedback on these changes highlights a potential multi-threading race condition and temporary file leak when writing the cache file, suggesting the use of thread identifiers in the temp filename and cleanup on failure. Additionally, it is recommended to use re.match instead of re.findall for more efficient pattern matching.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
… made warm-cache load slower than cold compile)
51fe91b to
c9f62cc
Compare
|
Adopted both suggestions: thread ident in the temp filename + cleanup on failed replace, and re.match instead of re.findall. Amended into the single commit. |
Problem
Loading a cached cubin calls
find_kernel_name_in_cubin, which iterates the ELF symbol table in pure Python (pyelftools) while holding the GIL. Each call takes seconds for large template-instantiated kernels, and concurrent loads serialize on the GIL. With a few hundred cached kernels (e.g. after a tuning sweep), a fully warm cache loads slower than cold compilation — NVRTC releases the GIL, the ELF reparse does not.Fix
Resolve the kernel name once and persist it in a
<cubin>.namesidecar; later loads read one line of text. ~200x faster warm-cache loading measured on H20 with a few hundred cached kernels.Safety:
^_Z\d+<keyword>); mismatch falls back to ELF parsing and rewrites the sidecaros.replace), safe under concurrent processes