# Compilation behavior in the multi-threading context
**URL:** https://discourse.julialang.org/t/compilation-behavior-in-the-multi-threading-context/136632
**Category:** General Usage
**Tags:** question, multithreading
**Created:** [April 9, 2026, 2:24am UTC](https://discourse.julialang.org/t/compilation-behavior-in-the-multi-threading-context/136632 "2026-04-09T02:24:36Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@WalterMadelim](https://discourse.julialang.org/u/WalterMadelim)
#### Post date: [April 9, 2026, 2:24am UTC](https://discourse.julialang.org/t/compilation-behavior-in-the-multi-threading-context/136632/1 "2026-04-09T02:24:36Z")
Oftentimes compilation takes some time before running the main code.
Given the following code
```julia-auto
function fn(x, y, z)
# some heavy work that needs to be compiled
end
spawn_fn(a...) = Threads.@spawn(fn(a...))
function multi_th(tks, a...)
for i=eachindex(tks)
tks[i] = spawn_fn(a...)
end
foreach(wait, tks)
end
const tks = Vector{Task}(undef, 100)
multi_th(tks, x, y, z)
```
, I wonder: when I run `multi_th` for the first time, will `fn` be compiled only once (and all threads waiting for it to be finished) or once per thread?
And another question is: can I compile multiple functions in different threads simultaneously to expedite my code execution?
```julia-auto
function fn1(x, y)
# some heavy work
end
function fn2(x, y)
# some heavy work
end
Threads.@spawn(fn1(x, y))
fn2(x, y)
```
Are there some subtleties here? e.g. function dependency.
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [April 9, 2026, 4:14am UTC](https://discourse.julialang.org/t/compilation-behavior-in-the-multi-threading-context/136632/2 "2026-04-09T04:14:50Z")
Threads share working memory, thus compiled method code. Distributed computing is where you’d have to separately compile a method per process.
> [@WalterMadelim](#):
>
> can I compile multiple functions in different threads simultaneously to expedite my code execution?
Now this is an interesting question. The [JIT devdocs](https://docs.julialang.org/en/v1/devdocs/jit/) currently states:
> Currently, only one thread at a time is permitted to enter the optimize-compile-link pipeline at a time, due to restrictions imposed by one of our linkers (RuntimeDyld). However, the JIT is designed to support concurrent optimization and compilation, and the linker restriction is expected to be lifted in the future when RuntimeDyld has been fully superseded on all platforms.
But not everything in the docs is up to date. The most recent talk I could find on this is from JuliaCon 2022 ([Unlocking Julia’s LLVM JIT Compiler - Prem Chintalapudi](https://www.youtube.com/watch?v=A0VwcXcAz4o)). Since then, v1.10 (December 2023) has introduced [parallel precompilation](https://julialang.org/blog/2023/12/julia-1.10-highlights/#parallel_precompile_on_using), but [Chintalapudi’s master’s thesis](https://hdl.handle.net/1721.1/151537) distinguishes precompilation from JIT compilation, including how they could be parallelized at the time of writing (June 2023). Chapter 5 covers JIT concurrency along the lines of this topic (“multiple application threads…running compilation simultaneously”), and there’s a similar mention there:
> In particular, LLVM’s old RuntimeDyld linker could not handle multithreaded linking, while LLVM’s new JITLink linker is not supported on some platforms that Julia supports, which precludes a redesign of parallel codegen. However, JITLink support is getting better, which could permit such a redesign in the future
That’s as far as I would read for now, so I’m still in the dark on whether current Julia releases parallelize any JIT compilation in multithreaded programs.
---
### Author:  [@WalterMadelim](https://discourse.julialang.org/u/WalterMadelim)
#### Post date: [April 18, 2026, 1:50pm UTC](https://discourse.julialang.org/t/compilation-behavior-in-the-multi-threading-context/136632/3 "2026-04-18T13:50:44Z")
I used all my 256 threads in parallel to build `256*20` JuMP models, when measured with `@time`, the result is
```julia-auto
julia> const mst = TSSP.build_2ssp!(sub, t, T, tks);
1096.368006 seconds (70.98 G allocations: 2.090 TiB, 79.74% gc time, 106.36% compilation time: <1% of which was recompilation)
```
I could understand the heavy gc though, since JuMP needs to build expressions.
I wonder why there is `106.36%` compilation time? How does this figure exist? Every task will compile it’s own methods to build JuMP model?
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [April 18, 2026, 3:09pm UTC](https://discourse.julialang.org/t/compilation-behavior-in-the-multi-threading-context/136632/4 "2026-04-18T15:09:18Z")
Misleading denominator: [compilation time reported incorrectly with @time and multithreading · Issue #53016 · JuliaLang/julia](https://github.com/JuliaLang/julia/issues/53016)
> [@WalterMadelim](#):
>
> Every task will compile it’s own methods to build JuMP model?
The bit of your example I’ve seen heavily reuses `Threads.@spawn` in one spot wrapping the same closure, and as stated before, that compiled code will be reused in further scheduled tasks. However, the thesis does point out that compilation across simultaneous threads has to contend with synchronization (locks, effective serialization; 5.3), especially when starting from the same method, and redundant inference (5.4.3) prior to still-documented single-threaded codegen. Idling further inflates the \>100% compilation figure despite not doing much more effective work.