JAjakobnissen·Sep 5, 2025
Im pretty sure Julia does JIT compilation of pure Julia to the GPU: https://github.com/JuliaGPU/GPUCompiler.jl
In ML needs a new programming language – Interview with Chris LattnerJuliaGPU
GPUCompiler.jl
Julia2020–2025
JuliaGPU / GPUCompiler.jl
GPUCompiler.jl
Reusable compiler infrastructure for Julia GPU backends.
8Distinct people
8Mentions
0Explicit recommenders
191GitHub stars
What to know before exploring
What it is
Reusable compiler infrastructure for Julia GPU backends.
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- julialang/packagecompiler.jl · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year8 dated mentions
Observed mentions: 2020-10-20 20:14:59 UTC to 2025-09-05 13:14:14 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
What Hacker News says
8 sourcesThanks!
> May I ask, is there any reason why one would focus themselfves on a single type of graphics card instead of relying on a library that works for other variants too?
AMDGPU.jl is actually one of the backends supported by Julia.
We do support CUDA, Metal, Intel, OpenCL as well to a varying degree: https://github.com/JuliaGPU
Each GPU backend implements a common array interface and a way to compile Julia code for low-level kernels relying on the GPUCompiler infrastructure: https://github.com/JuliaGPU/GPUCompiler.jl
Once that is done, users can write code and low-level kernels (using KernelAbstractions.jl) in a backend-agnostic manner.
Here're some examples of packages that target multiple GPU backends in this way:
- Real-time gaussian splatting supporting AMD GPU & Nvidia GPUs (probably others as well with minor work):
https://githu
Read the rest
b.com/JuliaNeuralGraphics/GaussianSplatting.jl
- AcceleratedKernels.jl which is like STD library:
https://github.com/JuliaGPU/AcceleratedKernels.jl
- NNop.jl implements Flash-Attention and other NN fused kernels:
https://github.com/pxl-th/NNop.jl
- Flux.jl a Deep-Learning library:
https://github.com/FluxML/Flux.jl
Revise.jl[1] is very helpful for development, as it allows for seamless recompilation without restarts. Cold start can also take a long time, so sometimes it helps to add options[2] such as -O0 when developing. Two paths forward for AOT compilation are PackageCompiler.jl[3] mentioned already in this thread (things like RelocatableFolders.jl[4] come in handy) and the possibility of GPUCompiler.jl[5] some day.
[1]: https://github.com/timholy/Revise.jl
[2]: https://docs.julialang.org/en/v1/manual/command-line-options...
[3]: https://github.com/JuliaLang/PackageCompiler.jl
[4]: https://github.com/JuliaPackaging/RelocatableFolders.jl
[5]: https://github.com/JuliaGPU/GPUCompiler.jl/issues/3
In GenieFramework – Build web applications with JuliaI don't think it's frowned upon to compile, many people want this capability as well. If you had a program that could be proven to use no dynamic dispatch it would probably be feasible to compile it as a static binary. But as long as you have a tiny bit of dynamic behavior, you need the Julia runtime so currently a binary will be very large, with lots of theoretically unnecessary libraries bundled into it. There are already efforts like GPUCompiler[1] that do fixed-type compilation, there will be more in this space in the future.
[1] https://github.com/JuliaGPU/GPUCompiler.jl
In Why We Use Julia, 10 Years LaterJulia's compiler is made to be extendable. GPUCompiler.jl which adds the .ptx compilation output for example is a package (https://github.com/JuliaGPU/GPUCompiler.jl). The package manager of Julia itself... is an external package (https://github.com/JuliaLang/Pkg.jl). The built in SuiteSparse usage? That's a package too (https://github.com/JuliaLang/SuiteSparse.jl). It's fairly arbitrary what is "external" and "internal" in a language that allows that kind of extendability. Literally the only thing that makes these packages a standard library is that they are built into and shipped with the standard system image. Do you want to make your own distribution of Julia that changes what the "internal" packages are? Here's a tutorial that shows how to add plotting to the system image (https://julialang.github.io/PackageCompiler.jl/dev/examples/.
Read the rest
..). You could setup a binary server for that and now the first time to plot is 0.4 seconds.
Julia's arrays system is built so that most arrays that are used are not the simple Base.Array. Instead Julia has an AbstractArray interface definition (https://docs.julialang.org/en/v1/manual/interfaces/#man-inte...) which the Base.Array conforms to, and many effectively standard library packages like StaticArrays.jl, OffsetArrays.jl, etc. conform to, and thus they can be used in any other Julia package, like the differential equation solvers, solving nonlinear systems, optimization libraries, etc. There is a higher chance that packages depend on these packages then that they do not. They are only not part of the Julia distribution because the core idea is to move everything possible out to packages. There's not only a plan to make SuiteSparse and sparse matrix support be a package in 2.0, but also ideas about making the rest of linear algebra and arrays themselves into packages where Julia just defines memory buffer intrinsic (with likely the Arrays.jl package still shipped with the default image). At that point, are arrays not built into the language? I can understand using such a narrow definition for systems like Fortran or C where the standard library is essentially a fixed concept, but that just does not make sense with Julia. It's inherently fuzzy.
A fun fact is that the GPUCompiler, which compiles the code to run in GPU's, is the current way to generate binaries without hiding the whole ~200mb of julia runtime in the binary.
https://github.com/JuliaGPU/GPUCompiler.jl/ https://github.com/tshort/StaticCompiler.jl/
In Cuda.jl v3.3: union types, debug info, graph APIsCurrently the best you can do is to build a somewhat unwieldy relocatable “bundle” with PackageCompiler.jl [1], but there are apparently plans for actual static compilation using an approach more similar to that used in GPUCompiler.jl [2], and the latter approach should as far as I understand allow for the creation of proper .so/.dlls.
[1] https://github.com/JuliaLang/PackageCompiler.jl
[2] https://github.com/JuliaGPU/GPUCompiler.jl
In Symbolics.jl: A Modern Computer Algebra System for a Modern LanguageMost of the julia GPU stuff is being made vendor agnostic via moving infrastructure from CUDA.jl to CPUCompiler.jl. The package AMDGPU.jl is coming along very well and will be plug-able with all this stuff.
https://github.com/JuliaGPU/GPUCompiler.jl
https://github.com/JuliaGPU/AMDGPU.jl
In Julia GPU