First call latency in distributed code

I run julia -p 2 --trace-compile=custom_precompile.jl myFile.jl, where myFile.jl runs a simple example. Then, when I try to generate the sysimage create_sysimage([:JuMP, :GLPK], sysimage_path="JuMPGLPKSysimage_CustomPrecompile.so", precompile_execution_file="custom_precompile.jl")

I get the following error:

**[ Info:** ===== Start precompile execution =====

**ERROR:** LoadError: UndefVarError: Distributed not defined
[...]

It might be not possible to generate a sysimage using a distributed code as precompile_execution_file.

It is possible, but you probably need to include Distributed in the sysimage too along with the other packages.

Sadly, the same happens if I include Distributed

julia> create_sysimage([:JuMP, :GLPK, :Distributed], sysimage_path="JuMPGLPKSysimage_CustomPrecompile.so", precompile_execution_file="custom_precompile.jl")
[ Info: ===== Start precompile execution =====
ERROR: LoadError: UndefVarError: Distributed not defined
[...]

Can you think of an alternative?

Thanks in advance

using them and use actualy pkg instead of Symbol?

I’m afraid I don’t fully understand your suggestion.

Use ["JuMP", "GLPK", "Distributed"] for the package list. I am not sure if this makes a difference. If not, maybe it is because Distributed is not added a dependency (even though it is in the standard library), so try ] add Distributed, otherwise, I am not sure why it isn’t working.

I cannot use an array of strings, there is no method matching. I guess it is because in version 1.4.1 of PackageCompiler only an array of symbols could be provided.

It is a pity we could not find the issue…

using JuMP, GLPK, Distributed
...

create_sysimage([JuMP, GLPK, Distributed]...)

julia> using JuMP

julia> using GLPK

julia> using Distributed

julia> create_sysimage(["JuMP", "GLPK", "Distributed"], sysimage_path="JuMPGLPKDistributedSysimage.so")
ERROR: MethodError: no method matching create_sysimage(::Array{String,1}; sysimage_path="JuMPGLPKDistributedSysimage.so")
Closest candidates are:
  create_sysimage() at /Users/shce/.julia/packages/PackageCompiler/2yhCw/src/PackageCompiler.jl:462 got unsupported keyword argument "sysimage_path"
  create_sysimage(::Union{Array{Symbol,1}, Symbol}; sysimage_path, project, precompile_execution_file, precompile_statements_file, incremental, filter_stdlibs, replace_default, base_sysimage, isapp, julia_init_c_file, version, compat_level, soname, cpu_target, script) at /Users/shce/.julia/packages/PackageCompiler/2yhCw/src/PackageCompiler.jl:462
Stacktrace:
 [1] top-level scope at REPL[29]:1

julia> create_sysimage([JuMP, GLPK, Distributed], sysimage_path="JuMPGLPKDistributedSysimage.so")
ERROR: MethodError: no method matching create_sysimage(::Array{Module,1}; sysimage_path="JuMPGLPKDistributedSysimage.so")
Closest candidates are:
  create_sysimage() at /Users/shce/.julia/packages/PackageCompiler/2yhCw/src/PackageCompiler.jl:462 got unsupported keyword argument "sysimage_path"
  create_sysimage(::Union{Array{Symbol,1}, Symbol}; sysimage_path, project, precompile_execution_file, precompile_statements_file, incremental, filter_stdlibs, replace_default, base_sysimage, isapp, julia_init_c_file, version, compat_level, soname, cpu_target, script) at /Users/shce/.julia/packages/PackageCompiler/2yhCw/src/PackageCompiler.jl:462
Stacktrace:
 [1] top-level scope at REPL[30]:1

I guess it should be an array of symbol for version 1.4.1 of PackageCompiler, see here.

you’re right,

but also, this is quite old

I cannot update it:

(@v1.5) pkg> status PackageCompiler
Status `~/.julia/environments/v1.5/Project.toml`
  [9b87118b] PackageCompiler v1.4.1

(@v1.5) pkg> update PackageCompiler
   Updating registry at `~/.julia/registries/General`
######################################################################## 100.0%
No Changes to `~/.julia/environments/v1.5/Project.toml`
No Changes to `~/.julia/environments/v1.5/Manifest.toml`

(@v1.5) pkg> status PackageCompiler
Status `~/.julia/environments/v1.5/Project.toml`
  [9b87118b] PackageCompiler v1.4.1

(@v1.5) pkg> 

Perhaps it is due to the julia version.

Is First call latency in distributed code - #19 by jmair not an option for updating the Julia version? If you want to still use the “module load” syntax for the cluster then I have a modulefile you can use (you don’t need any admin rights, and should work the same as if the admins installed it themselves). On your own local machine, you can use juliaup, and switch back to your old version if things don’t work out.

Yes, it is but I’m afraid that updating julia will break my code. I prefer not to update any software in the middle of a project. Nonetheless, based on your recommendations, I think it is worth installing the newest version of julia in my laptop and the cluster and see if problems are resolved…

1 Like

I agree with you on not updating during a project, and I usually feel the same, but when I did update, the code changes were extremely small, the main time was spent just updating the packages and precompiling.

Fortunately, each point release in Julia is non-breaking, but it’s the packages you have to be careful of. Keep a note of your current versions and if a specific package runs into trouble, you can always pin it at an earlier version using a [compat] header.

Alternatively, what about flag -L when starting julia? Does it make sense?

2 Likes

That’s good option I didn’t know about, but it won’t precompile your code in the way you want.

Argh… Thank you. I will report back as soon as I manage to update julia.

1 Like

It seems that the same behavior is observed for v1.6.

Interestingly, I tried my code for medium-complicated functions and it scales reasonably. Currently, I am investigating the issue for the most complicated function (it is with such function when I encounter the problem discussed herein). If it turns out it is something related to my specific function, it is a problem I have to solve myself. Otherwise, I will reopen the discussion.

Apologies and thank you very much.

shce

use 1.8 if possible?

@jling , I tried with v1.6 since it is the LTS currently.