Thanks for that point: Why is the compilation needed? If i used the package in a previous session (and compiled there) and none of the dependencies did change, what is gained in fully compile the package rather than caching a major part directly in machine code?
Over the years i follwed some discussions and the answer i learned is: Because something could change.
From my understanding: Packages are only pre-compiled to intermediate code. The final compilation/linking stage happens only when you call a function in a session the first time.
- advantage: small function can be inlined at the place where they are called
- disadvantage: long time for the first call
For me the advantage is a factor of 10 compared to Python/ Numba.
Also keep in mind that it would take a huge amount of time to fully precompile every single possible combination of inputs to all methods⌠the advantage of Julia is that it is also flexible enough to generate specialized code for unexpected input types, which can only happen with staged compilation
If the methods are generic (and most Julia code is), you cannot compile all possible combinations since they work for types in other packages, or yet undefined.
You can of course compile a specific subset, see
As for Plots.jl, my understanding is that the lazy loading of backend code makes this more tricky.
1 Like
By the way, Matlab doesnât encourage packaging your code. By now I have hundreds of my *.m files-functions in common code base folder, roughly arranged into different sudfolders (plot_utils, file_utils, and so on). So, when I have to transfer a prototype to someone else, I should manually copy included files from my codebase.
3 Likes
I got excited by this and built Julia master. Unfortunately it wasnât as impressive as this suggests:
julia> @time using ApproxFun # Julia v1.1
24.868237 seconds (67.19 M allocations: 4.559 GiB, 4.50% gc time)
julia> @time using ApproxFun # Julia 1.2-
16.261295 seconds (56.27 M allocations: 3.828 GiB, 4.87% gc time)
I seem to remember Stefan posting a Julia roadmap saying that Debugger was higher priority than compile time, which I think makes sense with the push for Machine Learning, where âtime-to-plotâ isnât such an important metric. But in the meantime, any talk about replacing Matlab in the use cases where Matlab excels is delusional.
1 Like
Thanks for your reply! why PyPlot.jl is much more faster?
Significant work has been done on both mostly by different people. Despite the shade above, a 35% reduction in compile is nothing to sneeze at.
14 Likes
I doubt Mathworks knows that Julia exists at the âmanagementâ level. The company is notorious for both their arrogance and their ignorance; if theyâre even aware of Juliaâs existence, which I doubt, then they donât treat it as a serious competitor.
As an example of what Mathworks is like: 10 years ago, while I was writing up my Ph.D., I encountered a problem with their FlexLM system. It simply stopped supporting my departmental license. When I explained the details to their tech support via telephone, a Mathworks agent screamed âyou must be some kind of idiot!â (then hung up on me). The issue: my computerâs default internet connection was not an Ethernet interface named eth0. FlexLM was hard-coded to work only through eth0 (whence, I guess everyone using WiFi, or a replacement adapter, or a Linux distro with non-standard interface names was âsome kind of idiotâ). The rationale from the Mathworks representative was âthatâs like having a Windows machine without a C drive!â. I leave spotting the irony in that statement as an exercise to the reader⌠
As another example, in the late 90s they tried to hire someone I knew as a developer with an offer of $38k/yr. He had 10+ years of relevant experience. He literally thought the offer email had accidentally reversed the digitsâŚ
7 Likes
âand most Julia code isâ - is exactly the point. Some code isnât generic, but rather close to specific types and more or less constant. And julia (today, afaiu) does not provide a good means to compile code like this to a library that contains functions that just can be called without compilation.
Plotting is such a case where major parts of the workload could be done with functions purely on specific types - many steps in plotting just work well enough with values as doubles. And plotting is one part of tooling - esp. for REPL - that needs to be super-reactive. Iâve discussed with people that were first time julia users (and were attracted by the âfastâ sticker on the outside of the box) that were disappointed by hitting RETURN and then see the REPL going into thinking-mode (btw: a simple visual hint like changing the cursor color while compiling could help here âŚ).
Iâm not questioning the value of full compilation and generic code. I just see for tooling (written in julia) the need for this library mode, and if itâs challenging, this should rather motivate people to work on itâŚ
I donât think its 100% clear what triggers the long latency for some code / packages. It might be compilation but it might be also type inference. PyPlot is for instance pretty snappy but Winston has a higher latency. The long loading times are a different story since there is no compilation step involved (as far a I have understood).
So from my perspective we have a non-trivial problem that no-one has a direct solution for but the main devs of Julia are certainly aware that this is an important problem to be solved. The reason that the problem is not fully solved might be that the problem is harder than it might look from a first sight.
2 Likes
Itâs great to hear that you are motivated to work on this! I know that PRs are appreciated by the Plots.jl team.
1 Like
It might be compilation but it might be also type inference
Yes you are right, it is definitely type inference in the case of ApproxFun.jl (and I think DifferentialEquations.jl too, which takes about 10s in both Julia v1.1 and v1.2-), so I was being a bit sloppy in my snarky post.
That said, it used to be more like 1s for both in Julia v0.6, and itâs a mystery to me why type-inference canât be done at the pre-compile stage. I suspect it can, but other things have higher priority (which I get). But in that context itâs hard to be overly enthusiastic about a 30% speedup.
Have you tried compile=min? I think you could turn JIT off when you want.
I am not enthusiastic either and am eagerly waiting for more drastic improvement. I just wanted to make clear that this is an open problem and that there is nobody to blame for it. With respect to Matlab I would just try to keep things honest. There are pros and cons for Julia. Latency is currently a weak point.
3 Likes
IIRC the compilation speed problem is due to Plots.jlâs recursive argument handling pipeline specializing on type when it doesnât need to, and the problem here is that it needs to handle and treat things as Any. So it does need generic code, but it just needs to handle Any without performing optimizations. It would be interesting to see if itâs any faster using JuliaInterpreter.
Juliaâs compiler itself has a similar problem (Expr has args which is an array of Any), but more carefully chose when and when not to specialize so it doesnât have as big of an issue.
But anyways, this is something that has been statically compiling for months now: - Nextjournal . compile_incremental also works.
For DiffEq itâs type inference on the function type. We specialize on the function type (since for small ODEs that is a pretty substantial difference, for Lorenz itâs like a 4x gain!) by type parameterizing to match f. Then inside the solver we make an integrator object which also does that, and then the entire solution is done by function which mutate the integrator. So the entirety of OrdinaryDiffEq.jl is recompiled every single time you solve a new ODE. We will likely have a GSoC project that will change some of these functions around so that way the bulk of it is not dependent on the function type and can thus be compiled and cached more easily. And also we have setup a no-recompilation mode that doesnât specialize on f, and we want to set that up with @cfunction soon instead of just Any. So while it is always nice to get blanket compiler improvements, this is something we can affect ourselves.
2 Likes
ApproxFun has a similar problem, though we worked around it for many calls using a non-type inferred DFunction that wraps a function for the intermediate steps. Hopefully there will soon be an @interpreted macro using JuliaInterpreter which will make these changes a lot. Though I donât think this will help with the initial using time.
this problem exists with most implementations of Abstract Syntax Trees, they are typically not typed and must be Any in most languages
would be interesting to see an example of a language compiler that doesnt work this way