108 lines
6.6 KiB
Markdown
108 lines
6.6 KiB
Markdown
Yep — what you’re describing is *exactly* how fast JS engines make “normal-looking arrays” fast: **an array carries an internal “elements kind”**, e.g. “all int32”, “all doubles”, “boxed values”, and it *transitions* to a more general representation the moment you store something that doesn’t fit. V8 literally documents this “elements kinds” + transitions model (packed smi → packed double → packed elements, plus “holey” variants). ([V8][1])
|
||
|
||
### 1) “Numbers-only until polluted” arrays: do it — but keep it brutally simple
|
||
|
||
For CellScript, you can get most of the win with just **three** internal kinds:
|
||
|
||
* **PACKED_I32** (or “fit int” if you want)
|
||
* **PACKED_F64**
|
||
* **PACKED_VALUE** (boxed JSValue)
|
||
|
||
Rules:
|
||
|
||
* On write, if kind is I32 and value is i32 → store unboxed.
|
||
* If value is non-i32 number → upgrade whole backing store to F64.
|
||
* If value is non-number → upgrade to VALUE.
|
||
* Never downgrade (keep it one-way like V8 does). ([V8][1])
|
||
|
||
Extra credit that matters more than it sounds: **forbid sparse arrays** (or define them away). If an out-of-range write extends the array, *fill with null* so the storage remains dense. That keeps iteration tight and avoids “holey” variants (which are a real perf cliff in engines). ([V8][1])
|
||
Your standard library already nudges toward dense arrays (constructors like `array(n)` fill with null).
|
||
|
||
### 2) Your “fast property op assuming data properties only” is the biggest bang
|
||
|
||
Since you’ve banned Proxy and all descriptor/accessor machinery , you can add VM ops that assume the world is sane:
|
||
|
||
* `GET_PROP_PLAIN`
|
||
* `SET_PROP_PLAIN`
|
||
|
||
Then slap an **inline cache** (IC) on them: cache `(shape_id, slot_offset)` for a given property name/key. On hit → direct load/store by offset. On miss → slow path resolves, updates cache.
|
||
|
||
This is not hypothetical: QuickJS forks have pursued this; QuickJS-NG had discussion of polymorphic inline caches (PolyIC) with reported big wins in some forks. ([GitHub][2])
|
||
|
||
Even if you keep “objects are fully dynamic”, ICs still work great because most call sites are monomorphic in practice.
|
||
|
||
### 3) “What else should I remove to make JITing easier + faster?”
|
||
|
||
The best deletions are the ones that eliminate **invalidation** (stuff that forces “anything could change”):
|
||
|
||
1. **Prototype mutation** (you already forbid it; `meme` creates, “prototypes cannot be changed”).
|
||
2. **Accessors / defineProperty / descriptors** (you already forbid it).
|
||
3. **Proxy / Reflect** (already gone).
|
||
4. **Property enumeration order guarantees** — and you already *don’t* guarantee key order for `array(object)`.
|
||
That’s secretly huge: you can store properties in whatever layout is fastest (hash + compact slots) without “insertion order” bookkeeping.
|
||
5. **Sparse arrays / hole semantics** (if you delete this, your array JIT story becomes *way* easier).
|
||
|
||
Stuff that’s *less* important than people think:
|
||
|
||
* Keeping `delete` as a keyword is fine *if* you implement it in a JIT-friendly way (next point).
|
||
|
||
### 4) You can keep `delete` without wrecking shapes: make it a “logical delete”
|
||
|
||
If you want “`obj[k] = null` deletes it”, you can implement deletion as:
|
||
|
||
* keep the slot/offset **stable**
|
||
* store **null** and mark the property as “absent for enumeration / membership”
|
||
|
||
So the shape doesn’t thrash and cached offsets stay valid. `delete obj[k]` becomes the same thing.
|
||
|
||
That’s the trick: you keep the *semantics* of deletion, but avoid the worst-case performance behavior (shape churn) that makes JITs sad.
|
||
|
||
### 5) What assumptions do “meme + immutable prototypes” unlock?
|
||
|
||
Two big ones:
|
||
|
||
* **Prototype chain links never change**, so once you’ve specialized a load, you don’t need “prototype changed” invalidation machinery.
|
||
* If your prototypes are usually **stone** (module exports from `use()` are stone) , then prototype *contents* don’t change either. That means caching “property X lives on prototype P at offset Y” is stable forever.
|
||
|
||
In a JIT or even in an interpreter with ICs, you can:
|
||
|
||
* guard receiver shape once per loop (or hoist it)
|
||
* do direct loads either from receiver or a known prototype object
|
||
|
||
### 6) What do `stone` and `def` buy you, concretely?
|
||
|
||
**stone(value)** is a promise: “no more mutations, deep.”
|
||
That unlocks:
|
||
|
||
* hoisting shape checks out of loops (because the receiver won’t change shape mid-loop)
|
||
* for stone arrays: no push/pop → stable length + stable element kind
|
||
* for stone objects: stable slot layout; you can treat them like read-only structs *when the key is known*
|
||
|
||
But: **stone doesn’t magically remove the need to identify which layout you’re looking at.** If the receiver is not a compile-time constant, you still need *some* guard (shape id or pointer class id). The win is you can often make that guard **once**, then blast through the loop.
|
||
|
||
**def** is about *bindings*, not object mutability:
|
||
|
||
* a `def` global / module binding can be constant-folded and inlined
|
||
* a `def` that holds a `key()` capability makes `obj[that_key]` an excellent JIT target: the key identity is constant, so the lookup can be cached very aggressively.
|
||
|
||
### 7) LuaJIT comparison: what it’s doing, and where you could beat it
|
||
|
||
LuaJIT is fast largely because it’s a **tracing JIT**: it records a hot path, emits IR, and inserts **guards** that bail out if assumptions break. ([GitHub][3])
|
||
Tables also have a split **array part + hash part** representation, which is why “array-ish” use is fast. ([Percona Community][4])
|
||
|
||
Could CellScript beat LuaJIT? Not as an interpreter. But with:
|
||
|
||
* unboxed dense arrays (like above),
|
||
* plain-data-property ICs,
|
||
* immutable prototypes,
|
||
* plus either a trace JIT or a simple baseline JIT…
|
||
|
||
…you can absolutely be in “LuaJIT-ish” territory for the patterns you care about (actors + data + tight array loops). The big JS engines are still monsters in general-purpose optimization, but your *constraints* are real leverage if you cash them in at the VM/JIT level.
|
||
|
||
If you implement only two performance features this year: **(1) dense unboxed arrays with one-way kind transitions, and (2) inline-cached GET/SET for plain properties.** Everything else is garnish.
|
||
|
||
[1]: https://v8.dev/blog/elements-kinds?utm_source=chatgpt.com "Elements kinds in V8"
|
||
[2]: https://github.com/quickjs-ng/quickjs/issues/116?utm_source=chatgpt.com "Optimization: Add support for Poly IC · Issue #116 · quickjs- ..."
|
||
[3]: https://github.com/tarantool/tarantool/wiki/LuaJIT-SSA-IR?utm_source=chatgpt.com "LuaJIT SSA IR"
|
||
[4]: https://percona.community/blog/2020/04/29/the-anatomy-of-luajit-tables-and-whats-special-about-them/?utm_source=chatgpt.com "The Anatomy of LuaJIT Tables and What's Special About Them"
|