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

Precompile in the cloud #30487

Closed
davidanthoff opened this issue Dec 22, 2018 · 13 comments
Closed

Precompile in the cloud #30487

davidanthoff opened this issue Dec 22, 2018 · 13 comments

Comments

@davidanthoff
Copy link
Contributor

One way to get rid of precompile times for most normal users would be that for every registered package/version, precompiled code is hosted somewhere in the cloud that the package manager automatically pulls when available during package installation. As long as users stay on tagged versions of registered packages, that might lead to a situation where no precompile ever happens on the user machine, which would be a much better experience from a performance point of view.

Obviously a ton of details related to that: where does this get compiled (travis? some julia specific service?), where is it hosted (github? somewhere else?) etc.

@ViralBShah
Copy link
Member

This is certainly a good idea, and @aviks may perhaps know what is blocking it (since I have discussed it a bit with him and @vtjnash). If not already possible, we are certainly close.

If we do this, I think that there should be some automatic service to precompile, test, and publish somewhere automatically, and of course Pkg would need to know about it.

@ViralBShah
Copy link
Member

Perhaps this is more a discourse discussion - rather than a Julia issue.

@davidanthoff
Copy link
Contributor Author

I mainly opened the issue so that 1) it can eventually be added to a milestone, 2) I can subscribe to it and follow any progress on it (given that I won't be contributing to it, way out of my league) :)

@ViralBShah
Copy link
Member

It is unlikely we can add such a large feature to one milestone. This and #30488 are things that will most likely get done slowly in multiple different releases. It only makes sense to add things to milestones when people are working on things that push us in the right direction. In general, we have moved away in the base repos from having such large milestones.

As far as subscribing, you can do that on discourse for relevant threads and receive updates there as well.

@jpsamaroo
Copy link
Member

One thing to note is that currently, precompile files contain absolute paths within them (paths that are only valid on the system they were generated on), making them non-transferable. That problem would probably need to be solved before this issue can be adequately addressed.

@JeffBezanson
Copy link
Member

Precompile files are also a function of your package environment. I suppose we'd have to provide files only for certain supported combinations of package versions.

@tkf
Copy link
Member

tkf commented Dec 23, 2018

Let me also add that precompilation file may depend on the configuration of each machine, e.g., by embedding the path of the shared library to be used in ccall as a constant.

Precompiling everything after add/update #16409 seems to be easier to do. Maybe add post-add hook registry so that users can do Pkg.after_add(Pkg.precompile)? I posted an issue in JuliaLang/Pkg.jl#973

@jlperla
Copy link
Contributor

jlperla commented Dec 23, 2018

For what it is worth, I (1) agree that this is the biggest impediment to getting matlab users to consider Julia; (2) am not sure that this is the best step towards a solution because it could make things more fragile.

To me, the real issue is less that the compiling happens and more that it happens when you don't want it to. Nobody bats an eyelid that an installation of matlab takes an hour or conda updates take forever, because it all happens at once. It is the precompilation after the compilation that is infuriating.

I think the bigger problem, then is increasing the number of things that can be done in the precompilation step (e.g. plotting, etc.)

@ViralBShah
Copy link
Member

What do you mean by precompilation after compilation?

@jlperla
Copy link
Contributor

jlperla commented Dec 23, 2018

Sorry, switch the word ordering. It is the amount of "compilation after precompilation". Especially with plotting.

I really thing you have cart blanche to spend as much time as you want precompiling on a particular computer as long as it is all happening at predictable "installation/upgrade" event times. In jupyterhub setups those steps can be done in the generation of a particular docker container for the user images. Anything you can move to a precompilation phase makes the experience better for everyone

... Again, for what it is worth.

@ViralBShah
Copy link
Member

We have made tremendous progress on this, and it is a topic of ongoing improvement. I think it is fine to close this issue.

@LilithHafner
Copy link
Member

LilithHafner commented Dec 19, 2022

I still spend a fair bit of time waiting for precompilation to take place on my machine—I think there is still lots of room for improvement here.

Nevertheless, the points against precompiling in the cloud do seem valid.

@vtjnash
Copy link
Member

vtjnash commented Dec 19, 2022

That is mostly the fault of package authors, either depending on slow packages or making them. The new conditional packages may help with that problem somewhat, as people adopt it.

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

8 participants