# About static compilation and static analysis

**URL:** <https://discourse.julialang.org/t/about-static-compilation-and-static-analysis/87492>\
**Category:** Internals & Design\
**Created:** [September 19, 2022, 8:30pm UTC](https://discourse.julialang.org/t/about-static-compilation-and-static-analysis/87492 "2022-09-19T20:30:44Z")\
**Posts on this page:** 3\
**Page:** 2

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [September 27, 2022, 12:07pm UTC](https://discourse.julialang.org/t/about-static-compilation-and-static-analysis/87492/21 "2022-09-27T12:07:33Z")

</div>

> [@martin.d.maas](#):
>
> I was basing my views of StaticCompiler on what StaticTools says to be doing: bypassing the GC to enable static compilation. But it seems that you have another very interesting approach.

Yes, PackageCompiler.jl should work, just slow and huge binaries, that should work with Python and all features. But for smaller binaries:

> [@martin.d.maas](#):
>
> things like Python interoperability are harder to obtain with Julia than with C++.

You can look at:

> **[GitHub - Suzhou-Tongyuan/jnumpy: Writing Python C extensions in Julia within...](https://github.com/Suzhou-Tongyuan/jnumpy)**
>
> Writing Python C extensions in Julia within 5 minutes. - GitHub - Suzhou-Tongyuan/jnumpy: Writing Python C extensions in Julia within 5 minutes.

I’m not sure it’s been announced yet.

PythonCall.jl is also excellent, and also allows you to call Julia from Python. There’s strictly no reason to need to make a Python extension, if you _just_ want to use Julia code with other languages (callable from C, C++ with jluna, Rust and many other languages have packages to call Julia). When calling Python, PythonCall.jl takes care of all the Python dependencies, so it’s easy, not sure about when calling from Python to Julia, if it does the same for Julia. Julia’s package manager is for that, and likely it’s also (as) easy. I just haven’t checked it, since Julia is my main language.

It took me some time to find this back for you, but while looking I also found (I recalled that was the programmer, they’re both excellent):

> **[GitHub - thautwarm/DIO.jl: Julia implementation for Python Restrain JIT](https://github.com/thautwarm/DIO.jl)**
>
> Julia implementation for Python Restrain JIT. Contribute to thautwarm/DIO.jl development by creating an account on GitHub.

> # In-process C Compiler Via Julia!

I’m not sure what I found, that’s not documented and is old, but seems interesting.

> [@martin.d.maas](#):
>
> StaticCompiler.jl is only compatible with a small subset of Julia as of now. […] For example, it is not compatible with [anything that contains ccall](https://github.com/tshort/StaticCompiler.jl/issues/80)

That should be documented, it’s not obvious it would be missing. It seems calling C code, using a Julia keyword, would be easy, but I suspect calling C is the easy part, the keyword is about calling a compiled .so binary.

I suppose there’s a workaround, or hopefully soon `ccall` will be supported. And the GC. That’s not inherently difficult, and GC only from the runtime should be small. I suppose that would enable a lot more stuff working, possibly I/O without the workarounds.

If you call from Python you have all than I/O, GC on the Python side, or with PythonCall.jl all on both sides.

Note also (Julia can run with 2 KB of RAM):  
[https://seelengrab.github.io/articles/Running%20Julia%20baremetal%20on%20an%20Arduino/](https://seelengrab.github.io/articles/Running%20Julia%20baremetal%20on%20an%20Arduino/)

For static analysis, I would look into JET.jl. I just started trying it out and it gave me 5, then 50 possible errors for rather short code (which is actually working), so a bit intimidating.

---

<div class="post-metadata">

**Author:** ![martin.d.maas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/martin.d.maas/32/50964_2.png) [@martin.d.maas](https://discourse.julialang.org/u/martin.d.maas)\
**Post date:** [September 28, 2022, 8:11pm UTC](https://discourse.julialang.org/t/about-static-compilation-and-static-analysis/87492/22 "2022-09-28T20:11:28Z")

</div>

> [@Palli](#):
>
> PythonCall.jl is also excellent, and also allows you to call Julia from Python. There’s strictly no reason to need to make a Python extension, if you _just_ want to use Julia code with other languages

Well, the problem with this is that the Julia code will have to be JIT-compiled, which is not a problem for interactive development, but I do see it as a problem for distributing code to Python end users, who expect fast code to be compiled.

> [@Palli](#):
>
> It seems calling C code, using a Julia keyword, would be easy, but I suspect calling C is the easy part, the keyword is about calling a compiled .so binary. (…) I suppose there’s a workaround, or hopefully soon `ccall` will be supported.

Yes, exactly. StaticCompiler is a work in progress, and you need to go through the open issues to understand what works and what (for now) doesn’t. What I get from this thread there is no language design impeding its development, it’s only that static compilation is inherently difficult to implement.

I guess it should be possible to write a macro that replaces any occurrence of `ccall` with an alternative llvm call which does work with StaticCompiler.

> [@Palli](#):
>
> Yes, PackageCompiler.jl should work, just slow and huge binaries, that should work with Python and all features.

As said earlier in this thread, there are things that won’t work with PackageCompiler such as LoopVectorization, which interestingly does work with StaticCompiler. So the problem is not just big binaries (not a big problem anyway) but that none of the existing approaches supports the full language yet.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [September 28, 2022, 8:14pm UTC](https://discourse.julialang.org/t/about-static-compilation-and-static-analysis/87492/23 "2022-09-28T20:14:53Z")

</div>

> [@martin.d.maas](#):
>
> but I do see it as a problem for distributing code to Python end users, who expect fast code to be compiled.

That’s a solved problem (if the code is tuned for that):

> [How Julia ODE Solve Compile Time Was Reduced From 30 Seconds to 0.1](https://sciml.ai/news/2022/09/21/compile_time/#how_julia_ode_solve_compile_time_was_reduced_from_30_seconds_to_01)  
> We did it. We got control of our compile times in a large-scale \>100,000 line of code Julia library

the problem with this is that the Julia code will have to be JIT-compiled

> [@martin.d.maas](#):
>
> there are things that won’t work with PackageCompiler such as LoopVectorization, which interestingly does work with StaticCompiler.

That is interesting, I thought we could rely on PackageCompiler to work with all code. Anyway it has a successor, because of compilation time (in part):

> **[GitHub - JuliaSIMD/LoopModels: "Full speed or nothing." - James Hetfield](https://github.com/JuliaSIMD/LoopModels)**
>
> "Full speed or nothing." - James Hetfield. Contribute to JuliaSIMD/LoopModels development by creating an account on GitHub.

But thanks for the heads up, I’m not sure how serious this is, the issue is still open, there may be a workaround (one would be not using it (and many do not even know of it, thus not use it), or somehow disabling the macros at runtime?):

It seems it works for many users (just not all systems, and you of course want that): [LoopVectorization PackageCompiler'd into sysimage crashing · Issue #364 · JuliaSIMD/LoopVectorization.jl · GitHub](https://github.com/JuliaSIMD/LoopVectorization.jl/issues/364#issuecomment-991980068)

> On certain systems, it’s possible for LoopVectorization to produce code that is invalid/will crash when you try to run it on others.

It requires AVX anyway so if you want binaries that work on all systems, also old you can’t use it (also AVX not on e.g. ARM, though similar SIMD is there, not yet targeted).

> [@martin.d.maas](#):
>
> the problem with this is that the Julia code will have to be JIT-compiled

I don’t think so. I mean the point of PackageCompiler is you no longer distribute source code (also you do not use source with precompilation of packages, by default). I believe it gives you IR bitcode, but it’s fast to compile the last step to binary, has already been optimized(?), and anyway to full native code is around the corner. That should be as fast as binary extensions in Python.

> write a macro that replaces any occurrence of `ccall` with an alternative llvm call  
> I suppose, a great idea, if llvm call directly isn’t good enough, or just using default Julia.

[Previous page](https://discourse.julialang.org/t/about-static-compilation-and-static-analysis/87492.md?page=1)