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

Add utilities to convert object models #46

Closed tshort closed 1 year ago

tshort commented 1 year ago

The utilities static_type and static_type_contents are utilities to help convert an object to something similar with fields and type parameters that are amenable to static compilation.

static_type is mainly useful for converting objects that are heavily paramaterized. The SciML infrastructure has a lot of this. The main objects like a DiffEq.Integrator has many type parameters, and by default, some are not amenable to static compilation. static_type can be used to convert them to forms that can help numerical code to be statically compiled.

Note that these require some expertise to use. static_type can fail if the constructor has been overridden, so that passing in the standard field list as arguments won't work.

tshort commented 1 year ago

Could me tagging StaticCompiler have caused the integration tests to fail?

brenhinkeller commented 1 year ago

Oh hmm, let's rerun CI on a branch with nothing else happening to check..

Looks like there are possibly some failures over here that may or may not be related https://github.com/tshort/StaticCompiler.jl/actions/runs/4899537514/jobs/8749566672?pr=117

brenhinkeller commented 1 year ago

https://github.com/brenhinkeller/StaticTools.jl/pull/47

brenhinkeller commented 1 year ago

Ah ok, similar failures in #47, so looks like something changed outside this repo since last time tests were run... It looks like integration tests on the StaticCompiler side got accidentally disabled in https://github.com/tshort/StaticCompiler.jl/pull/69 (c.f. https://github.com/tshort/StaticCompiler.jl/pull/117) so either something in or after that PR it would seem?

MasonProtter commented 1 year ago

I think the integration tests have probably been borked for a little while now.

MasonProtter commented 1 year ago

Automatically turning arrays into MallocArrays will leak memory, since MallocArrays must have their memory freed unlike regular arrays. Same for MallocString.

tshort commented 1 year ago

Yes, that'll leak by default. One possibility is to write a version of free that scans through an object and frees all the MallocArrays and MallocStrings it finds.

In my use case, I'm only generating an object to be able to generate some interfacing code with WebAssemblyInterfaces. Leaking doesn't matter for that use.

MasonProtter commented 1 year ago

I just worry about actually exposing that to unsuspecting users.

brenhinkeller commented 1 year ago

Is the size (or maximum) size of array you'll need be known at compile-time, such that it could be StackArrays instead?

tshort commented 1 year ago

If you're converting an object, you'll know the size of it, so you could convert to StackArrays. We could provide a DefaultStackCtx to do that.

If you're converting a type, you won't know the size of the Arrays baked into the type. And, the type conversion is what you might want to fill in the type tuple when compiling.

brenhinkeller commented 1 year ago

I guess there’s also the stack limit to worry about.. I’ll leave it to you, but we should probably try to figure out what broke the integration tests

brenhinkeller commented 1 year ago

Ok, looks like we're back in action on the integration tests. In the interest of keeping things moving I'll merge plus some warnings about freeing but we should see if we can see a better way to do that in the future