Hacker News Reader

Comment by moelf | Hacker News Reader

with PackageCompiler.jl, you can do this within 100 ms

Alternatively, you could run it with --compile=min and --optimize=0 to minimize latency at the cost of runtime performance (making it comparable to Python).

jlpkg does this to speed up package installation: https://github.com/fredrikekre/jlpkg https://live.juliacon.org/talk/N39HSX

Why is this not the default?

This bakes in a particular version of the Plots library. Which is mostly great, but you need to re-bake to move on to a new version.

(All the standard libraries are baked in by default, in much the same way I think, and so can't be updated without making a new version of Julia. But they all load fast.)

Because it involves making a julia sysimage with the Plots.jl functions AOT compiled into it. PackageCompiler.jl makes this quite easy and straightforward though, it takes like 5 minutes and you won't have to worry about plotting latency again until you upgrade Julia or Plots.jl.

Here's the instructions: https://julialang.github.io/PackageCompiler.jl/dev/examples/...

Why doesn't it cache the results of a compilation automatically the first time you hit the module after any change? This shouldn't be difficult. Much of Julia's target audience don't know what "AOT" is.

> This shouldn't be difficult.

It is actually exceedingly difficult due to multiple dispatch. There's an effectively infinite number of different method signatures a function can have.

Currently, anything you want to AOT needs to go into a big monolithic sysimage with the full julia runtime. We might be able to eventually do a shared library approach that you can dynamically link to, but it'll take time.

Doing this automatically without the user opting in would make latency problems worse, not better.

does that mean that if one starts a new julia kernel, and imports a package, something different happens each time they do that? if not, then it would seem one could at least save on those super long imports. Reading about this a bit more, it almost seems like whatever PackageCompiler.jl is doing could be automated and baked into the the core julia executable with simple options/flags.

There will likely be more caching in the future, but it's a hard problem and for now, they're working on lower hanging fruit to speed up compile times.

> Reading about this a bit more, it almost seems like whatever PackageCompiler.jl is doing could be automated and baked into the the core julia executable with simple options/flags.

Not really, no. Fundamentally, PackageCompiler is building a monolithic executable with your desired packages baked into it. Every time you want to add a new method to compile, you need to rebuild the whole thing and you cause it to be larger on the disk and slower to start up.

Even if we could quickly cache methods, I have hundreds of Julia packages installed locally on my machine. and regularly call methods with exotic signatures. If I baked every method I ever compiled into my sysimage, it'd probably be hundreds of terabytes in size at least. You have to remember that every time I call a function f on arguments x, y, and z, I need to compile a new method for each distinct signature

    f(::typeof(x), ::typeof(y), ::typeof(z))

There are more Julia function signatures that it's possible to create and compile from just Base functions and types than there are atoms in the universe.

Of course, it's possible to do more caching and faster than we currently do, but I just want to emphasize that it's a hard problem.

Reply on news.ycombinator.com