I’m a bit confused what’s changed. In Julia v0.5 or so I used SnoopCompile on all tests to generate precompiles and this worked quite well. Then at some point the precompiles stopped showing any noticeable improvement and I deleted the precompiles.
But now you are saying use SnoopCompile To generate precompile statements, but not on the tests?
It never really changed. It just has to do with how much gets invalidated and how much of it can be isolated to specific packages. Precompiles which “share types” are currently just dropped (probably one of the biggest limitations to even using something like SnoopCompile)
We need to time more, but my feeling is that if Gadfly/Compose and Plots both dropped their dependency on Measurements.jl and instead embedded a version into themselves as a package so that all of those weird number types can precompile and then a snoop file is used for that, I think it could do quite a bit.
(In fact, if anyone wants to contribute, this is a very nice thing to try. Make Measurements.jl a submodule of Plots by pasting it in, and use the SnoopCompile stuff from Leon’s PR to add precompiles that utilize this module. See what happens. Beginner friendly!)
I guess this can be done with just a few lines, without copying the whole codebase?
include(Base.locate_package(Base.PkgId(Base.UUID("eff96d63-e80a-5855-80a2-b1b0885c5ab7"), "Measurements")))
using .Measurements # notice the leading dot
(Note that, strictly speaking, this requires Measurements.jl to make deps a part of public API.)
Yes Measures
You don’t really have to do any diving now with @snoopi. The old @snoopc measured codegen time (dominated by LLVM time), which isn’t terribly relevant. With @snoopi you both measure inference time and can then figure out how well your intervention “worked.”
It’s already in a submodule so this should be very easy https://github.com/JuliaPlots/Plots.jl/blob/master/src/Plots.jl#L149-L164
I just tried that and could not notice any significant change.
julia> @time using Plots
11.759940 seconds (22.34 M allocations: 1.123 GiB, 3.96% gc time)
julia> @time display(plot(rand(10)))
Plot{Plots.GRBackend() n=1}
14.330170 seconds (28.71 M allocations: 1.385 GiB, 3.41% gc time)
(with code from Measures.jl copied into a submodule of Plots)
julia> @time using Plots
12.408045 seconds (22.58 M allocations: 1.137 GiB, 4.08% gc time)
julia> @time display(plot(rand(10)))
Plot{Plots.GRBackend() n=1}
14.317090 seconds (28.69 M allocations: 1.384 GiB, 3.63% gc time)
GR now contains a snoop function that can be used to minimize time-to-first-plot:
julia -e 'using PackageCompiler; compile_incremental("GR", joinpath(pwd(), "snoop.jl"), cc_flags="-mtune=\"generic;sandybridge,-xsaveopt,clone_all;haswell,-rdrnd,base(1)\"")'
time julia snoop.jl
The results are OK for me:
Build shared library "/usr/local/lib/julia/packages/PackageCompiler/CJQcs/sysimg/sys.dylib":
`cc -shared '-DJULIAC_PROGRAM_LIBNAME="/usr/local/lib/julia/packages/PackageCompiler/CJQcs/sysimg/sys.dylib"' -o /usr/local/lib/julia/packages/PackageCompiler/CJQcs/sysimg/sys.dylib -Wl,-all_load /usr/local/lib/julia/packages/PackageCompiler/CJQcs/sysimg/sys.a -std=gnu99 -I/usr/local/Applications/Julia-1.3.app/Contents/Resources/julia/include/julia -DJULIA_ENABLE_THREADING=1 -fPIC -L/usr/local/Applications/Julia-1.3.app/Contents/Resources/julia/lib -Wl,-rpath,/usr/local/Applications/Julia-1.3.app/Contents/Resources/julia/lib -Wl,-rpath,/usr/local/Applications/Julia-1.3.app/Contents/Resources/julia/lib/julia -ljulia -m64 -O3 '-mtune="generic;sandybridge,-xsaveopt,clone_all;haswell,-rdrnd,base(1)"' -Wl,-install_name,@rpath//usr/local/lib/julia/packages/PackageCompiler/CJQcs/sysimg/sys.dylib`
real 0m1.166s
user 0m0.655s
sys 0m0.524s
I have a similar script for the Plots + GR combination, which I can provide, if desired …
thanks for trying it!
There’s a significant change for Plots + GR:
% time julia snoop-Plots.jl
julia snoop-Plots.jl 33.29s user 1.16s system 101% cpu 34.065 total
… compared with a “package-compiled” sysimg:
% time julia snoop-Plots.jl
julia snoop-Plots.jl 0.92s user 0.34s system 95% cpu 1.323 total
snoop-Plots.jl is a mix of plain GR and basic Plots functions.
The speedup is ~ 35x.
Wow, this looks promising. Thanks @jheinen! I’m trying it locally, but PackageCompiler seems to have trouble locating shared object libraries:
julia -e 'using PackageCompiler; compile_incremental("GR", "/Users/ifiske/julia-testing/snoop-GR-Plots.jl", cc_flags="-mtune=\"generic;sandybridge,-xsaveopt,clone_all;skylake,-rdrnd,base(1)\"")'
┌ Warning: seriestype violin has been moved to StatsPlots. To use: `Pkg.add("StatsPlots"); using StatsPlots`
└ @ Plots /Users/ifiske/.julia/packages/Plots/qZHsp/src/args.jl:1079
┌ Warning: seriestype violin has been moved to StatsPlots. To use: `Pkg.add("StatsPlots"); using StatsPlots`
└ @ Plots /Users/ifiske/.julia/packages/Plots/qZHsp/src/args.jl:1079
┌ Warning: seriestype violin has been moved to StatsPlots. To use: `Pkg.add("StatsPlots"); using StatsPlots`
└ @ Plots /Users/ifiske/.julia/packages/Plots/qZHsp/src/args.jl:1079
┌ Warning: seriestype violin has been moved to StatsPlots. To use: `Pkg.add("StatsPlots"); using StatsPlots`
└ @ Plots /Users/ifiske/.julia/packages/Plots/qZHsp/src/args.jl:1079
┌ Warning: seriestype violin has been moved to StatsPlots. To use: `Pkg.add("StatsPlots"); using StatsPlots`
└ @ Plots /Users/ifiske/.julia/packages/Plots/qZHsp/src/args.jl:1079
ERROR: LoadError: LoadError: error compiling #kde: error compiling conv: error compiling *: could not load library "@rpath/libfftw3.3.dylib"
dlopen(@rpath/libfftw3.3.dylib, 1): image not found
I’d appreciate any ideas. I’ve experimented with PackageCompiler in quite a few other ways and always run into some similar error, where it cannot find a shared library, though the specific shared library varies by what I’m trying. I’ve tried setting the LD_LIBARAY_PATH variable and also passing the -L cc_flag, but this doesn’t help. I’m on OS X, julia 1.3.
I think the problem is not related to GR directly. It’s probably another package dependency (for FFTW.jl). On macOS, the latter might be provided by Homebrew - did you try to rebuild it?
Thanks for the tip – GR and all associated packages (including FFTW) work fine on my system outside of PackageCompiler. I only get these image not found errors from PackageCompiler attempts. Just to check though, I just did ] build FFTW and then repeated the same experiment above, and got the same error.
While I was horking around Julia GUI’s and things I found something. I’m of course very interested in the ideas of interactive plots using native Julia and stuff like that so I ended up in Plots.jl. When I was groking the GR backend for how plots get rendered, I realized something a little funny. It looks like every display has a read and write step via something called GKS? Is that correct? I’m no wizard, but typically reading and writing is pretty slow compared to in memory. I don’t foresee this being a huge deal in time-to-first plot but, it could be if the plots were large enough. Could also introduce latency in animations.
Is there a direct way to convert Plots to a graphical context without I/O? Or does this even matter according to benchmarks?
For PDF as shown in the above example it would not make much sense. In Plots, however, the GR.emergencyclosegks() might cause some overhead within GR, which should be avoided in a future version.
The @time macro does not seem to tell the full truth, at least for me. Doing the timing actually gives me 7 seconds.
julia> @time (using Plots; gr(); plot([1,2,3], [4,5,6]))
7.053711 seconds (15.98 M allocations: 845.897 MiB, 3.60% gc time)
However, at the time the output (7s) is shown, the plot is not yet displayed. It will (measured manually) take an additional ~5-6 seconds for the plot to pop up, i.e. in total it’s 13 seconds not 7. A second plot will however appear nearly instantly. Is this a known behavior and if so, where do these additional 5-6 seconds come from?
What version of Julia are you running (julia> versioninfo())?
Have you updated your packages (julia> using Pkg; Pkg.update())?
They come from calling display on the Plot object, which is implicitly called when returning the plot to the REPL. Call display(plot(...)) explicitly to time the full operation.
Thank’s for the quick response, this is really good to know, when doing some measurements!