Mooncake Upgrades

[willtebbutt]

In response to a couple of things, I've decided to add much better tools for caching various things in Mooncake. As a result, we can substantially simplify Mooncake's implementation in DifferentiationInterface.

I've tested this locally, so I'm hoping it still works...

[codecov]

Codecov Report

Attention: Patch coverage is 95.23810% with 1 line in your changes missing coverage. Please review.

Project coverage is 97.52%. Comparing base (cc8818a) to head (9369bd5).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
.../ext/DifferentiationInterfaceMooncakeExt/twoarg.jl	91.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #645      +/-   ##
==========================================
- Coverage   97.53%   97.52%   -0.01%     
==========================================
  Files         111      111              
  Lines        5550     5536      -14     
==========================================
- Hits         5413     5399      -14     
  Misses        137      137              

Flag	Coverage Δ
DI	98.65% <95.23%> (-0.01%)	⬇️
DIT	95.35% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[willtebbutt]

(failures because the right version of Mooncake is not yet available, because I messed up doing releases)

[willtebbutt]

(codecov is lying -- the line it says is uncovered is definitely covered)

[gdalle]

Thanks! This new cache thingy isn't documented anywhere in Mooncake.jl, is it the new name for rules? Is it an internal or part of the API?

[gdalle]

will this new closure slow things down?

[willtebbutt]

I don't believe so -- Mooncake generally has no problems with closures.

[willtebbutt]

This new cache thingy isn't documented anywhere in Mooncake.jl, is it the new name for rules?

It's a wrapper around a rule, and all of the various tangents that you need in order to avoid allocations. Unlike build_rrule, which just used static information, the cache makes use of dynamic information (e.g. array sizes) which it uses to make life easier.

Is it an internal or part of the API?

It's internal for now. I plan to make it available publicly in short order, but want to make sure it's doing everything as I intend it before telling users about it.