Rewrite for 1.9?

[timholy]

In principle it seems like it should be possible to do away with GPUCompiler entirely on 1.9+. I suspect you basically want to call jl_save_system_image_to_stream with a custom list of new_specializations containing the Julia CodeInstances you want to cache to your library. Because I've barely glanced at how this package works, I don't have a clear understanding of how the interaction with the Julia runtime works, that might take some additional effort. But it seems likely that the actual compilation work would be vastly simpler now and likely handle a much larger fraction of the language.

You would surely need to create a custom wrapper (in Julia's repo) of jl_save_system_image_to_stream that handles your case. An example JL_DLLEXPORTed wrapper is jl_create_system_image which you might be able to use as a model. (I suspect your wrapper might be less complicated, but I am not sure.)

[vchuravy]

I think the challenge is "What about the system image". If the purpose of this package is to get packages as small as possible that 80mb is to much, especially if you don't need it. But I agree this package could focus on creating the executable that load the julia runtime and the set of pkgimage asked for by the user.

[brenhinkeller]

It's a good question. Personally I think there's definitely value in keeping the "small standalone executable" option, but it would also be great to have an option (/ future default) that can support the whole language

[timholy]

Even if the goal is to be able to make things that are independent of the sysimage, I wonder if there would be some value in developing core Julia functionality that would make a gradual transition (granular by package) possible. For example, one could conditionally throw an error in https://github.com/JuliaLang/julia/blob/a70bbdf29e7820569316d0a0d03c22757c910142/src/staticdata.c#L890 if any external linkage is needed. You could start with it in error-triggering mode and learn what aspect of the runtime is needed. Then you can choose whether you want to suck up the 80mb or continue to go to effort to expunge the sysimage.

I just worry that issues like #69 (whose notification triggered my post here) mean that in the long run it may be more work to keep up with the Julia compiler than it will be to integrate with it.

[ToucheSir]

Was also subscribed to #69 and found this issue. Not quite sure I understand the following:

I just worry that issues like #69 (whose notification triggered my post here) mean that in the long run it may be more work to keep up with the Julia compiler than it will be to integrate with it.

Isn't #69 about adding some kind of compiler plugin interface? Even if StaticCompiler switches off of GPUCompiler, adding such plugins will require either as-yet-nonexistent Base APIs or libraries like Mixtape.

[tshort]

69 has actually gotten simpler. It's been updated to Julia v1.9, and the mixtape support is just a couple of functions added on top of a verbatim copy of the interpreter that comes with GPUCompiler. I like the idea of pursuing the small-as-possible option. This approach might also be easier for cross compilation to WebAssembly and embedded targets.

I also like Tim's idea and see what we could do without GPUCompiler.

[timholy]

adding such plugins will require either as-yet-nonexistent Base APIs

I'm proposing that adding such APIs might be a time-efficient investment for the future of StaticCompiler. I'm not proposing to work on them myself, but I am happy to share what I know with anyone who might want to work on it.

[ToucheSir]

Having followed the previous multi-month, multi-person effort towards this (compiler plugins and more stable user-facing compiler APIs) quite closely before it fizzled out, I guess my reaction is "once bitten, twice shy" :frowning:. Maybe the lessons learned would make a second attempt more successful.

[timholy]

I suspect much of the needed code is already in src/staticdata.c and src/staticdata_utils.c (which is why I proposed it specifically as a rewrite around Julia 1.9), as a pkgimage has a lot in common with the needs StaticCompiler. But I have spent exactly zero time thinking about the specific needs of StaticCompiler.

[ToucheSir]

Hmm, perhaps we're actually talking about different parts of the compiler? I was thinking of how Mixtape tries to provide an equivalent to https://github.com/JuliaLang/julia/pull/44950 and https://github.com/JuliaLang/julia/pull/41632, which is pretty orthogonal to StaticCompiler's core functionality or static compilation in general.

[timholy]

Yeah, I'm basically talking about leveraging the new pkgimages code. We now have the capability to cache the native code, and to make that work we have to do things like scoop up lists of new external specializations that were forced to compile. Naively it seems you could piggyback off that: just prepare a list of all the MethodInstances you need for your application, and pass their corresponding CodeInstances as a list of new_specializations. The worklist of modules would presumably be empty. There would definitely be some changes needed to Julia to make that work, but I'd estimate the work to be between 30 and 1000 lines of C code (which admittedly is a large range, but it doesn't seem completely impossible that it could turn out to be on the low end of that range). Of course most jobs turn out to be much bigger than you expect going into them, and this would be no different. But the point is mostly that there's a lot of recently-developed infrastructure just waiting to be taken advantage of.

[VarLad]

https://github.com/tshort/StaticCompiler.jl/pull/69 has actually gotten simpler. It's been updated to Julia v1.9, and the mixtape support is just a couple of functions added on top of a verbatim copy of the interpreter that comes with GPUCompiler. I like the idea of pursuing the small-as-possible option. This approach might also be easier for cross compilation to WebAssembly and embedded targets.

@tshort That reminds me, there's a project which aims to take a StaticCompiler like approach but using wasm for target. https://github.com/arhik/WASMCompiler.jl

[tshort]

Good to know about WASMCompiler! Compiling to WASM was my original goal for StaticCompiler. The fixPointers and other utilities look interesting.