search

brenhinkeller / StaticTools.jl

Enabling StaticCompiler.jl-based compilation of (some) Julia code to standalone native binaries by avoiding GC allocations and llvmcall-ing all the things!
MIT License
167 stars 11 forks source link

Questions on e.g. GC.@preserve #53

Closed PallHaraldsson closed 22 hours ago

PallHaraldsson commented 9 months ago

I see GC.@preserve used here (actually also at StaticCompiler.jl in one place), and it's a bit confusing.

It got me thinking, while this package is for use with StaticCompiler, and then not supporting Windows since it doesn't, does it make send to use it without? That might explain if you use with full Julia, its runtime and the GC.

You can use ManualMemory.jl only (or just Libc.malloc) and/or Bumper.jl, so this package doesn't maybe provide much for use with the full runtime. It seems all it has or most at least it to work around the limitations when you don't have the runtime (and then all features).

Another question, you mention threads not supported. You mean Julia's i.e. @threads (for some reason it requires the runtime, not sure it requires GC and that's (only) why). But that's for spawning threads (or at least using already prespawned). It seems to be if you're calling from say C, or Python, and make threads there, then you can call from threads to Julia, also if using these static packages. Can you confirm? I mean then without automatic speedup, i.e. to work on the same problem. But that could potentially also happen some way.

One more, does it also make sense to use this package for GPUCompiler.jl (or is it fully featured already for what applies to GPUs)? Or at least part of the functionality here? I guess excluding all malloc related or related to printing. Maybe that only leaves out e.g. RNGs.

brenhinkeller commented 9 months ago

GC.@preserve is actually necessary to get the compiler to not optimize away certain memory references. There's no actual use of the GC involved