# Understanding better JIT and LLVM in Julia

**URL:** https://discourse.julialang.org/t/understanding-better-jit-and-llvm-in-julia/42784
**Category:** Internals & Design
**Tags:** compilation
**Created:** [July 9, 2020, 3:00pm UTC](https://discourse.julialang.org/t/understanding-better-jit-and-llvm-in-julia/42784 "2020-07-09T15:00:22Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![Fred](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fred/32/14175_2.png) [@Fred](https://discourse.julialang.org/u/Fred)
#### Post date: [July 9, 2020, 3:00pm UTC](https://discourse.julialang.org/t/understanding-better-jit-and-llvm-in-julia/42784/1 "2020-07-09T15:00:22Z")

</div>

Hi,  
I am not specialist of compilers and I have a few questions about Julia design.  
1- Julia is JIT compiled, because this design enable an interactive use in the REPL without the loss of performances of an interpreted langage. Is that true ?  
2- if 1 is true, are there another motivations for JIT compilation instead of static compilation ?  
3- in Julia it is optional but possible to indicate the type of all variables. If one write a Julia program like if it was a statically typed langage, in theory the compiler have all the information to build a binary executable ?  
4- is LLVM able to build a binary executable under some conditions ?  
5- if 3 & 4 are true, what is missing to build a executable ?

Thank you !

---

<div class="post-metadata">

### Author: ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)
#### Post date: [July 9, 2020, 3:17pm UTC](https://discourse.julialang.org/t/understanding-better-jit-and-llvm-in-julia/42784/2 "2020-07-09T15:17:15Z")

</div>

The biggest reason julia is JIT compiled is that for a basic function like `f(a,b)=a+b`, there are probably tens of thousands of possible things this could compile to depending on what types `a` and `b` are. This gets exponentially harder for functions with more arguments. Thus Julia’s approach is to only `f` for the types with which it is actually called. For a simple program whose compiled output can not fit on your computer cosider

```julia
x = tuple([rand()>.5 ? 1 : 2.0 for _=1:200]...)
f(x) = sum(x)
f(x)

```

There are 2^200 possible functions to compile here. Good luck fitting that on a hard drive.

Furthermore, even if all of your code has static types for everything, Julia itself has lots of code (eg `+`) that don’t specify concrete types for everything. Thus your code being all statically typed is mostly irrelevant.

p.s. in this case, a very smart compiler could probably make a fallback that checks element types and does the right type of addition, but solving this generally would basically require including a Julia interpreter (or JIT) in the compiled binary.

---

<div class="post-metadata">

### Author: ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [July 9, 2020, 3:25pm UTC](https://discourse.julialang.org/t/understanding-better-jit-and-llvm-in-julia/42784/3 "2020-07-09T15:25:13Z")

</div>

You can currently build executables without too much consternation: [Home · PackageCompiler](https://julialang.github.io/PackageCompiler.jl/dev/)

Note that by default, those executables ship with the JIT compiler such that it doesn’t need to exhaustively compile every possibility. You can, however, trace the execution of a program to record what signatures are required, and it’ll include that native code for you.

---

<div class="post-metadata">

### Author: ![Fred](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fred/32/14175_2.png) [@Fred](https://discourse.julialang.org/u/Fred)
#### Post date: [July 9, 2020, 3:37pm UTC](https://discourse.julialang.org/t/understanding-better-jit-and-llvm-in-julia/42784/4 "2020-07-09T15:37:58Z")

</div>

Thank you @Oscar_Smith, @mbauman !
