docs(vm): record the measured speed steps of fibonacci(30) #165
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Goal
Measure the VM speed steps against
fibonacci(30)and write the numbers into VM.md section 8, and bring section 10 "Speed, the next steps" and slice 10 of section 9 up to date with what landed.Source
torb run --vmminus that of a program that prints one line,releaseprofile, one machine, best of five) and the table.Split out of #8: a speed step's change is verified by CI, but the loop's workers never run a bootstrap or a release build in their own exec (LOOP rule), so the numbers are taken here, from the toolchains the nightly publishes (a download, no build).
Acceptance criteria
fibonacci(30)andfibonacci(32)oftorb run --vmmeasured with a published nightly toolchain from before and one from after each step that landed, same machine, best of five, startup subtracted; the machine and the dates are stated.docs/change regeneratesskills/(torb docs skill docs skills);tools/check-commits.shclean.docs(vm): record the measured speed steps.Seed
No.
Dependencies
Starts when the step's PR (#8, and #163 and #164 if they land) is merged and a nightly built after it is published; until then it is not
ready. Docs only: sonnet/medium.[loop:torbscript] intake: in scope (author orion, label loop), split from #8 by its refine; the numbers come from published nightly toolchains after #8 lands, next: waiting (dependency on #8)
[loop:torbscript] intake: not ready. The measured steps are still landing (#163 part 2 has a worker running, #164 part 2 waits behind it), and the numbers need a nightly built after the last of them. next: waiting (#163 and #164 part 2, then a nightly after them) until 2026-10-10T04:00:00Z
[loop:torbscript] intake: not ready, unchanged. #163 part 2 landed but #164 part 2 waits for a published seed with the part 1 natives, and the numbers need a nightly built after the last step. next: waiting (#164 part 2, then a nightly after it) until 2026-10-10T04:30:00Z
[loop:torbscript] claim refine by session:loop-torbscript-20261024 until 2026-10-24T03:00Z
[loop:torbscript] decided by the loop: the dependencies are met, the issue is
readywith the corrections and the method below. Nothing here is an owner question (measurable, technical, docs only, no seed).Dependencies (checked at main
d1710631and later, 2026-10-24). #8 (PR #166,068e52da), #163 (parts 1 and 2: PR #22191c009ff, PR #2509889e8f9) and #164 (parts 1 and 2: PR #239d25e2889, PR #305d1710631) are all merged and closed. Nightlies published after each exist with alinux-x64toolchain asset, so nothing waits any more.Corrections to the text above (VM.md has moved since the issue was written; headings checked at main).
What it costs, measured" is a bullet of section 8The gate: C and the VM agree, with the table of two rows. "Section 10Speed, the next steps" is a bullet of section 10Open. Slice 10 is a row of the table of section 9. Use these places; do not renumber anything.Speed, the next stepsalready says the fourth step (Machine.loadAt/Machine.storeAt, #163) is in, but still lists as open "a call reads five header words where a per-chunk record could be one" (landed with #166;recordOf/parametersOfincompiler/src/vm/interpret.trb) and "aPlaceis a record ofList<PlaceStep>" (already words of the image: section 4, "the places and witness entries, which are words of the image", commit94c4a99e). Both go; the bullet then says no step of the list is open.headerWords = 10: correct the number (read the code for which words the header holds) in the same commit; it is the description of the per-chunk record step.A retain or a release of one pointer counts in the loop(#164) is already written and stays; only its measured number (docs/PERFORMANCE.md 9.12) may be linked from the new table row.Measurement method, decided by the loop (forge CI only, never in the worker's exec). The worker uses a throwaway branch
loop/165-measurewith one extra workflow file.forgejo/workflows/measure-vm-speed.yml(triggerpull_request,ci.ymlonly runs onmain/release/*pushes and PRs;workflow_dispatchneeds the file on main), opens it as a draft PR againstmain, reads the numbers from the job log withci-wait.sh, then closes that PR unmerged and deletes the branch (the pattern ofloop/164-measure2). That workflow is never part of the docs PR. The job downloads each toolchain withsh tools/forge.sh download <tag> torb-<version>-linux-x64.tar.gz, writesfibonacci(30)andfibonacci(32)plus a program that prints one line, and for every toolchain timestorb run --vmfive times (best of five, wall time, startup run subtracted, as VM.md states). The toolchains are timed round-robin inside one job (all toolchains per round, five rounds) so a busy shared runner hits all of them alike; it logsuname -a, the CPU model,nprocanduptimeand runsnightly-20261008once more at the end as a drift check (more than 10% off its first number: repeat the job once). The machine statement in VM.md names the runner class (the forge'subuntu-latestrunner, CPU model from the log) and the dates; numbers of a different machine than the 0.19 s and 0.46 s row of the table are not compared with it.Toolchain pairs (ancestry checked with the forge's compare API).
068e52da)nightly-20260929(3b6b8355)nightly-20261008(e82cfa36)runtime/loadAt/storeAtin the loop (#221 natives, #250 loop;9889e8f9)nightly-20261009(7ee364b7, has #221, no loop change)nightly-20261010(5f22f071)vm/debug.trbd1710631)nightly-20261010nightly-20261011(a95cb5c3)6ffd6cc5perf(vm)(loop record written only where a call back begins, breakpoints tested by a bit) is in the same delta; no nightly lies between, so the row names both commitsnightly-20261023(40164061)perf(runtime)commits (e1806c37torb_retain fast path,e414ece5map slot) and debugger workcompiler/src/vm,runtime/machine*.candir/rangescommits of each delta (git log, read-only) into the row's note so that a reader sees what a number stands on.fibonacci(30)retains nothing, so the #164 row is expected to be within noise there: it is recorded as measured, with the pointer to docs/PERFORMANCE.md 9.12 (chain walk, 1.15x) for what that step buys; do not claim a gain the number does not show. If a row's ratio disagrees with the issue-time expectation, the table still records what was measured.Acceptance criteria stay as written, with these clarifications.
Speed, the next steps, section 4 header count and slice 10 of section 9 (names the steps #166, #163, #164 and the measured ratio offibonacci(30); the "six times faster" text stays true or is restated with the new number).torb docs skill docs skillsregeneratesskills/(use a published nightly toolchain as in the workflow, a download, no build);pdiscstamp/index of VM.md (pdisc.ymlgate, skillprogressive-disclosure);sh tools/check-commits.shclean.docs(vm): record the measured speed steps. PRCloses #165, forge CI green (tier A docs gates). Seed: No. Touches onlydocs/design/VM.mdand generatedskills/.Size: one docs PR plus a scratch PR that is closed. Implementer: sonnet/medium (docs, tooling; the CI job is shell). Estimated 150k tokens. Claim lease 6 h for implement.
Refine worker usage: sonnet, about 100k tokens.
[loop:torbscript] refine: ready, claim released, next: implement. Dependencies #8, #163 and #164 are merged and nightlies after each are published; the issue text is corrected against VM.md at main (section places, two stale open steps, header word count) and the measurement runs in forge CI on a throwaway draft PR, all in the decision comment above. No seed impact, one docs commit, sonnet/medium. Worker usage: sonnet, about 100k tokens.
[loop:torbscript] claim implement by session:loop-torbscript-20261024 until 2026-10-24T05:30Z
[loop:torbscript] release implement: the implement worker hit its run timeout without a result comment after opening PR #449; forge CI pending. next: waiting (CI running on PR #449)