Conversation
|
!bench |
|
Benchmark results for 61fc909 against da19ea0 are in. There are significant results. @Kha
Large changes (5✅)
and 1 hidden Medium changes (56✅) Too many entries to display here. View the full report on radar instead. Small changes (937✅, 14🟥) Too many entries to display here. View the full report on radar instead. |
|
!bench mathlib |
|
Benchmark results for leanprover-community/mathlib4-nightly-testing@742a28b against leanprover-community/mathlib4-nightly-testing@d87691e are in. There are significant results. @Kha
No significant changes detected. |
|
Reference manual CI status:
|
|
Mathlib CI status (docs):
|
|
!bench mathlib |
|
Benchmark results for leanprover-community/mathlib4-nightly-testing@742a28b against leanprover-community/mathlib4-nightly-testing@d87691e are in. (These commits have already been benchmarked in a previous command.) There are significant results. @Kha
No significant changes detected. |
|
!bench mathlib |
|
Benchmark results for leanprover-community/mathlib4-nightly-testing@df4c7ab against leanprover-community/mathlib4-nightly-testing@d87691e are in. There are significant results. @Kha
Large changes (26✅, 1🟥) Too many entries to display here. View the full report on radar instead. Medium changes (286✅, 1🟥) Too many entries to display here. View the full report on radar instead. Small changes (983✅, 3🟥) Too many entries to display here. View the full report on radar instead. |
|
!bench |
|
!bench mathlib |
|
Benchmark results for 922cb1f against da19ea0 are in. There are significant results. @Kha
Large changes (16✅)
and 1 hidden Medium changes (73✅, 2🟥) Too many entries to display here. View the full report on radar instead. Small changes (1029✅, 11🟥) Too many entries to display here. View the full report on radar instead. |
|
Benchmark results for leanprover-community/mathlib4-nightly-testing@b6e0896 against leanprover-community/mathlib4-nightly-testing@d87691e are in. There are significant results. @Kha Warning These warnings may indicate that the benchmark results are not directly comparable, for example due to changes in the runner configuration or hardware.
No significant changes detected. |
|
!bench mathlib |
|
Benchmark results for leanprover-community/mathlib4-nightly-testing@8998e87 against leanprover-community/mathlib4-nightly-testing@5edfd4c are in. There are significant results. @Kha
Large changes (105✅) Too many entries to display here. View the full report on radar instead. Medium changes (662✅, 1🟥) Too many entries to display here. View the full report on radar instead. Small changes (1430✅, 2🟥) Too many entries to display here. View the full report on radar instead. |
Normalize the free variables of `.noMVars` type class resolution queries so that structurally identical queries in different local contexts can share a persistent cache entry. The free variables of the query type and `localInsts` are renamed to canonical positional variables for the cache key, and the result is stored abstracted over that closure as loose bound variables (`Expr.abstract`) and re-instantiated with the current context on a hit, analogously to how `abstractMVars` produces a closed schema. Checkpoint: on core algebra, order, and logic modules this cuts misses noticeably (e.g. `Algebra.Group.Basic` from 58% to 46%), but a `grind` instance-canonicalization regression in `Mathlib.Logic.Equiv.Prod` still needs fixing, where a reopened instance is not definitionally equal to a fresh synthesis. Set `LEAN_NO_FVAR_NORM=1` to disable it for A/B measurement. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
`SynthNorm.normExpr` and the `hasAnyFVar` escape check in `abstractOverClosure?` recursed over query terms as trees, so `.noMVars` queries whose types are heavily DAG-shared (as built by `grind`'s e-matching via substitution, e.g. nested `if`s in `Mathlib.Logic.Equiv.Prod`) burned exponential allocations, exhausting the heartbeat budget and failing `grind` with a deterministic `whnf` timeout. Memoize `normExpr` on `ExprStructEq`-keyed subterms (sound since canonical positions are assigned by first occurrence and never change) with a `hasFVar` fast path, and rewrite `abstractOverClosure?` to abstract first (DAG-cached in C++) and check the O(1) `hasFVar` flag of the result, keeping both linear in the DAG size of the query. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…tavariables This PR improves type class resolution cache reuse: instance queries whose local context mentions an already-solved metavariable now share a cache entry with structurally identical queries in other contexts, instead of falling back to a context-specific key. `SynthNorm.normExpr` gave up whenever a closure free variable's type satisfied `Expr.hasMVar`. That flag is syntactic and stays set for metavariables that are already assigned, whose values are context-free and normalize fine. Instantiate the type before deciding, and bail only on a metavariable that is still unassigned. On `Mathlib.Algebra.Group.Basic` this takes the number of queries that fall back to a raw key from 878 to 0: cache misses drop from 1676 to 1230, and the heartbeats spent inside missed searches drop by 35%. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…normalization This PR speeds up type class resolution in contexts with many local instances, where normalizing the cache key dominated the cost of a cache lookup, including of the lookups that hit. The free-variable normalization runs on every `.noMVars` lookup, because its result *is* the key. Almost all of its cost is the closure of the local instances, which does not depend on the query: on `Mathlib.RingTheory.DedekindDomain.Different` it is 98% of the normalization, rebuilt on each of 84550 lookups over an average of 18 local instances. Normalize the local instances first, so their canonical positions do not depend on the query, and memoize the resulting closure in `Meta.Cache`. A memoized closure is reused while the local instances are unchanged and every closure variable whose type mentions a metavariable still instantiates to what the closure was built from; a `LocalDecl`'s type is otherwise immutable. Contexts that cannot be normalized memoize the failure, so they too cost a single lookup. The same file spends 62 heartbeats per normalization instead of 1587, a 25-fold reduction, with the closure served from the memo 98% of the time. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This PR lets instance queries whose local context contains a `let` share a cache entry with structurally identical queries in other contexts, instead of falling back to a context-specific key. The free-variable normalization gave up on a let-bound closure variable, because its value is visible to definitional unfolding but was not part of the key. Record the normalized value alongside the normalized type, so that contexts agreeing on the types but not the values stay apart. A nondependent `ldecl` (a `have`) hides its value from unfolding and needs no value in the key. On `Mathlib.RingTheory.DedekindDomain.Different` this removes every let-induced fallback: the queries that fall back to a raw key drop from 32938 to 19192, cache misses from 15420 to 15023, and the heartbeats spent inside missed searches by 5.3%. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
!bench mathlib |
|
Benchmark results for leanprover-community/mathlib4-nightly-testing@8998e87 against leanprover-community/mathlib4-nightly-testing@5edfd4c are in. (These commits have already been benchmarked in a previous command.) There are significant results. @Kha
Large changes (104✅) Too many entries to display here. View the full report on radar instead. Medium changes (662✅, 1🟥) Too many entries to display here. View the full report on radar instead. Small changes (1424✅, 2🟥) Too many entries to display here. View the full report on radar instead. |
|
!bench mathlib |
|
Benchmark results for leanprover-community/mathlib4-nightly-testing@a8784fe against leanprover-community/mathlib4-nightly-testing@5edfd4c are in. There are significant results. @Kha
Large changes (104✅) Too many entries to display here. View the full report on radar instead. Medium changes (673✅, 1🟥) Too many entries to display here. View the full report on radar instead. Small changes (1422✅, 1🟥) Too many entries to display here. View the full report on radar instead. |
|
!bench mathlib |
|
Benchmark results for leanprover-community/mathlib4-nightly-testing@a8784fe against leanprover-community/mathlib4-nightly-testing@5edfd4c are in. (These commits have already been benchmarked in a previous command.) There are significant results. @Kha
Large changes (98✅)
Medium changes (639✅, 1🟥)
Small changes (1402✅, 1🟥)
|
This PR lets an instance query whose class has output parameters share a cache entry with structurally identical queries in other local contexts, and persist across commands, as queries without metavariables already do. The free-variable normalization ran only on `.noMVars` queries, so every other key kept the free variables of the context that created it and could never be shared. Run it on all queries: metavariable identities are left exactly as they are, so only the free variables are canonicalized. The wildcard that `preprocess` puts in output-parameter positions is left alone, being a marker rather than a variable of the local context. The gate on persistence tested `.noMVars`, which is a proxy for what it actually requires: a key without metavariables. Test that directly. An `.mvarsOutputParams` key has its output parameters replaced by a wildcard, so it is metavariable-free whenever every metavariable sits in an output parameter, and is then as context-free as a `.noMVars` key: the wildcard stands for a value the input parameters determine, and a hit re-derives it by unifying the cached result against the query. On `Mathlib.Algebra.Group.Basic` the misses drop from 1230 to 944 and the heartbeats spent inside missed searches by 45%. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This PR fixes a slowdown in `grind` in the presence of the persistent type class resolution cache: a cached instance, reopened from an abstracted schema, is not maximally shared, so `grind` re-walked it on every `shareCommon` of a term containing it. `Sym.synthInstance?` now runs the synthesized instance through `Sym.shareCommon`, interning it into the local term store once, as `grind` already does for every other term it internalizes. Later `shareCommon` calls then find it shared by pointer. On `Mathlib.Logic.Equiv.Prod` this cuts elaboration from 93.7G to 43.1G instructions (the cost without the cache), with the alpha-hash-consing (`Sym.AlphaShareCommon`) share of runtime dropping from 28% back to near zero. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
No description provided.