The two columns change places between runs, which is the actual finding

The prose still said --two-process measured faster in every column, which was
true of the one number taken before item 1 and not of the four retaken back to
back. In the after pair the merged build is 0.9ms ahead; in the before pair
two-process was 1.3ms ahead. A difference that changes sign between runs is a
difference made of noise, and that is a better argument than a direction would
have been.

NEXT.md's file table gains lib/agent.ml and stops describing dev.ml and the
agent as though the compiler reached the program over a socket. It is the index
a next lane reads first.
This commit is contained in:
Joseph Ferano 2026-09-12 22:35:09 +07:00
parent a3baa0b25a
commit b8b84cd418
2 changed files with 7 additions and 4 deletions

View File

@ -1077,8 +1077,10 @@ internal socket. Everything else is noise: the redefinition column moves by less
directions.
**The transport was about 40µs of a 21ms redefinition, and removing it does not move that number.** That is the
finding, and it is worth more than a speedup would have been. `--two-process` is not slower than the merged build in
any column — it measured *faster* on both sides of this change — so **the merge's prize was never latency.** It is that
finding, and it is worth more than a speedup would have been. The sharpest evidence for it is that the merged and
two-process columns *change places between runs* — two-process ahead by 1.3ms in the before pair, merged ahead by
0.9ms in the after pair — which is what a difference made of noise looks like. **The merge's prize was never
latency.** It is that
the compiler and the program share an address space, which is what makes the items below deletable at all and what
unblocks reading the stopped frame's memory directly. Anyone reaching for an in-process JIT on the strength of
"transport is slow" should read the build row first: code generation is 19 of the 21 milliseconds, and the socket was

View File

@ -322,7 +322,8 @@ reader ✅ → parse ✅ → load ✅ → check ✅ → emit ✅ → clang ✅
| `lib/check.ml` | AST → typed IR; two passes, bidirectional |
| `lib/session.ml` | **a live program: what the process was built from, plus every change since** |
| `lib/wire.ml` | **the editor protocol: one s-expression per message, length framed** |
| `lib/dev.ml` | **`flan dev`: a session, the program running beside it, and a socket** |
| `lib/agent.ml` | **the agent, called rather than connected to, when it is in this process** |
| `lib/dev.ml` | **`flan dev`: a session, an editor socket, and the program it is a thread inside** |
| `lib/prelude.ml` | printers + `rand-f32`, written in Flan |
| `lib/emit.ml` | typed IR → LLVM IR text |
| `lib/build.ml` | `.ll` + the shim + the packages' C → clang → executable |
@ -330,7 +331,7 @@ reader ✅ → parse ✅ → load ✅ → check ✅ → emit ✅ → clang ✅
| `runtime/flan_dev.c` | **dev only: the by-name registry a run-time-new name needs** |
| `lib/shim.ml` | **`declare-c` -> the generated C that flattens a struct crossing** |
| `vendor/raylib/` | **the raylib package: `raylib.flan` and `link`, and no C at all** |
| `vendor/agent/` | **the dev agent: a socket, a loader thread, install at a frame boundary** |
| `vendor/agent/` | **the dev agent: one verb table, a loader thread, install at a frame boundary** |
| `emacs/` | **`flan-mode.el`, `flan-dev.el`, `flan-repl.el`: the editor half of the dev loop** |
| `bin/main.ml` | `flan read \| parse \| check \| emit \| shim \| build \| run \| reload \| dev` |
| `test/test_flan.ml` | reader, parser and checker |