What is the difference between switch --compile=yes & --compile=all for AOT?

I using the perfect repository Julia AOT compiler, but I have questions about switch

–compile={yes|no|all|min} Enable or disable JIT compiler, or request exhaustive compilation

I have no idea what this does. I suspect that with yes it is AOT and with all static compiled Julia. Is it correct?

EDIT: Since even Karpinski said “–compile={yes|no|all|min} – I have no idea what this does, despite reading julia --h” in the issue I posted below, I’m not even going to guess (again) and take my original with a grain of salt:

Does this for sure apply for juliac? I didn’t see it in the README (and haven’t tried juliac).

This allies to julia, see julia --help, you get different options. Did you just mistype? There it simply controls the optimizer I think, e.g. you get an interpreter(?) that’s slower, but faster to start up.

See also e.g.: -O option.

This option is in

Base.julia_cmd()

I think that my question is clear. What is the difference between switch –compile=yes & –compile=all ?
When I compiled with yes I get libhello.so 49MB, but with all 98MB. In runtime I get 4 times better time with switch –compile=all.

While we are on the subject, does anybody manage to run compiled programs on OS X ? For me they segfault as soon as the gc is used.

Googling the option (and searching in the Docs) found this:

https://github.com/JuliaLang/julia/issues/23054

[and nothing of interest in Docs; as the option has been hidden in master.]

https://github.com/JuliaLang/julia/blob/master/src/jloptions.c

https://github.com/JuliaLang/julia/issues/15864

Probably it was (you just confused me with involving the question with the package), see my other post, and edited my first post. Aslo note Base.julia_cmd() is about JIT, not AOT package that came later; but the option may also apply to it, I’m just not sure if/how.

--compile=no turns off the JIT compiler (on 0.6 you then get an error if a method is not available in the system image, on 0.7 it’ll run in the interpreter)
--compile=yes is the default
--compile=all is a more-agressive version of --compile=yes, that also compiles a bunch of fallbacks and specializations you didn’t call (and if you’re building a system image thus get cached as a result). Thus --compile=all is useful to build a system image that will later be used with --compile=no (like in an AOT compile).

5 Likes

Is it possible to give hints to --compile=all about what methods to compile? For example, I have a lot of functions that look like

function myfunc(q::AbstractVector, qg::AbstractVector, coords::AbstractVector, res::AbstractVector)

where each AbstractVector is usually either an Array or a view of an array. I was thinking about writing a script to generate the appropriate precompile statements, but is there some machinery behind --compile=all that I could hook into?

Not really, precompile is the best way if you want to generate extra specializations. --compile=all mostly generates definitions on e.g. abstract types that you wouldn’t usually need if you had the compiler because you could just conjure up a specialization on the fly.

1 Like

I am adding support for --compile to static-julia.