WASM Memory boosting mode with lazy cache #3079
Conversation
There was a problem hiding this comment.
Not quite sure how valuable this is, but that LazyCache is definitely doing some strange things.
I suggested you use LazyLock but realized that it only recently landed in stable and we're a little further behind.
It might be worth looking into how it's implemented though.
Using Box<dyn FnOnce() -> T> instead of Mutex<Option<Arc<Fn() -> T>>> would be much better if there's a way to do that. I guess the question of if that's possible is kind of dependent on where/when you expect cloning.
I also think that Default implementation is super dangerous and I'm curious why you needed that.
It seems LazyLock is available from 1.80. |
Closes o1-labs/o1js#2006 (kimchi-side o1-labs/o1js#2074)
This PR introduces a new enum called
LazyCachewhich is meant to provide support for expensive evaluations that can be computed on-demand on the prover, instead of precomputed on the setup to save memory space for WASM.LazyCachecontains two variants:CachedandLazy. By default, these evaluations (selector polynomials, precomputed constants, and lookups) will be cached in memory. But when the flaglazy_cache = true, then their computation is deferred from constraint system creation until the prover. This is done by passing anArcclosure that will obtain the evaluations when prompted. The API is quite simple, as it just requires to use.get()in these structures. This method will simply access the cached values in theCachedvariant, and if it is aLazyvariant it will invoke the closure the first time, and then the result will be available in thecomputedfield which is aOnceCell. When this is done, the closure is taken from memory to decrease the counter of theArcand free theMutex.The main change is in
kimchi/src/circuits/lazy_cache.rs. The rest of the diff is about adapting the constraint system, prover index, and prover code to the new type.