About static compilation and static analysis

[Palli]

@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...

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

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

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/

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.

[martin.d.maas]

@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.

[Palli]

@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
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

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

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.