Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[julia] Use package for the wrapper to speed up compilation #1259

Open
giordano opened this issue Mar 25, 2024 · 6 comments
Open

[julia] Use package for the wrapper to speed up compilation #1259

giordano opened this issue Mar 25, 2024 · 6 comments

Comments

@giordano
Copy link
Contributor

I created a small Julia package, CompilerExplorer.jl, which simply replicates what the Julia wrapper in Compiler Explorer currently does. The code in that wrapper would simply become

using CompilerExplorer

CompilerExplorer.main()

The significant advantage is that when Julia code is saved into a package, it can cache some precompile code (and from Julia v1.9 onwards also native code), which can significantly improve runtime performance for the first run, as the methods called don't need to be JIT-compiled (or not as much extensively). Note that here I'm talking about the compilation of the functions calling the compiler infrastructure to eventually compile the code the user inputs in Compiler Explorer, that code will of course still have to be compiled regularly, but at least that'd be where most of the time will be spent.

As an example, for the default example code for the Julia language, in my local Compiler Explorer instance I get runtime going down from ~1800 ms with the current version of the wrapper
image
to ~400 ms with using the package
image

Using this package would also make testing easier for us for all versions, and hopefully avoid silly mistakes like compiler-explorer/compiler-explorer#5927 (comment).

I'm happy to make a PR to make this happen, but I want to understand whether this would be effective in the production version of Compiler Explorer. If we install this package during the installation of the Julia toolchain here, can we cache its precompiled code? By default Julia stores it in the ~/.julia/compiled directory, but the location can be changed with the environment variable JULIA_DEPOT_PATH, to accommodate whatever caching infrastructure is used here.

CC: @vchuravy

@partouf
Copy link
Member

partouf commented Mar 29, 2024

So if it's user-code independent caching, yes we definitely can do it during installation. But we'll have to save it to a read-only directory on the installation path in /opt/compiler-explorer/julia-version/.julia/compiled - or potentially copy the directory to a writeable /tmp directory during usage by users, but any changes done to the directory cannot persist.

@vchuravy
Copy link

That is sensible. We could be cute and just install it into the stdlib location.

So /opt/compiler-explorer/julia-v1.10/share/julia/stdlib/v1.10/CompilerExplorer and then we can do JULIA_DEPOT_PATH=/opt/compiler-explorer/julia-v1.10/share/julia/ julia -e "using CompilerExplorer" to create the cache file in the right location.

@partouf is an after_stage_script like

after_stage_script:
the right tool here?

@partouf
Copy link
Member

partouf commented Mar 29, 2024

@partouf is an after_stage_script like

after_stage_script:

the right tool here?

Yes, correct

@vchuravy
Copy link

Is there a way to access the source of compiler-explorer/compiler-explorer within the staging process? It would probably make sense to vendor the source there since the output of it is coupled to the compiler invocation there.

Or is the infra stage independent of the compiler-explorer deployment

@partouf
Copy link
Member

partouf commented Mar 29, 2024

they are independent, but you could curl https://raw.githubusercontent.com/compiler-explorer/compiler-explorer/main/somethingsomethingsomething

But for Julia nightly the script will run every night when it's being re-installed, just not for the fixed versions

@giordano
Copy link
Contributor Author

Thank you so much for the explanations! A start to address this issue is in #1264.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants