backend: cache resolved var cells per reference site (run-path ~5x)
Profiling jolt-i5if showed <=60-bit arithmetic is already native-fast; the real general overhead in the run/-e/-m path is var resolution. Every var reference compiled to (var-deref ns name), which builds + hashes a fresh "ns/name" string and does a hashtable lookup per access (~45ns). The var cell is interned and def-var! mutates it in place, so caching the resolved cell is sound under redefinition. Generalize the devirt per-site cache-cell mechanism to var value references: a ref inside a fn resolves its cell once into the def's closure, then reads it via var-cell-deref (a field read after the first). var-cell-deref is the cell-based var-deref — binding-aware (dynamic vars + *ns* still resolve) and lenient on an unbound root (a forward-declared var doesn't throw, unlike jolt-var-get). Gated by a runtime flag: ON for runtime-compiled code (compile-eval.ss), OFF for the seed mint and AOT build (emit-image.ss) so the seed stays a byte-fixpoint -- prelude.ss is unchanged, only image.ss picks up the new backend. ~5x on a var-ref-heavy loop (1058ms->205ms); ~1.2x on test.check (its generators are more deftype/dispatch-bound than var-deref-bound). No C/FFI. Corpus rows pin redefinition / dynamic binding / forward ref through a cached ref. make test + shakesmoke green, selfhost holds, SCI 211/218, certify 0-new.
This commit is contained in:
parent
f17b68ccfe
commit
04180c1e4e
6 changed files with 245 additions and 164 deletions
File diff suppressed because one or more lines are too long
Loading…
Add table
Add a link
Reference in a new issue