Goose benchmark results

Deprecated language features: reusable and reusable[]. Use slot_pool<T> for slots and slice_pool<T> for contiguous runs. Builtin behavior and historical examples below remain relevant to existing code; removal is planned separately, after the remaining migration gaps.

Generated by bench/run_bench.py on 2026-10-16 14:59. Do not edit by hand. The benchmarks themselves are bench/goose/*.goose, bench/cpp/*.cpp and bench/rust/*.rs; their purpose is explained in bench/design.md.

How to read this

• Start with Across all benchmarks: it shows the whole suite in one table. The per-benchmark sections below it give the details, and each ends with a sentence or two on what that row means.
• There is one table per benchmark. Rows are implementations. The three time columns are the data sizes (the small one is meant to fit in cache, the large one is meant not to), and the last column is peak memory at the large size.
• Every Goose and C++ time cell is v145 / clang: the same source built by each of the toolchains in the table below, so a gap between those numbers comes from the backend alone. Goose is compiled to C once per size and every toolchain builds that same C. Rust rows carry a single time, because rustc is the only Rust backend here; it is LLVM, so it is the clang column they are most directly comparable with.
• Times are the best of 3 whole-process wall clocks, after two discarded warm-up runs. Memory is the peak working set, the larger of the toolchains (they rarely differ).
• Everything a program does, including generating its input, building its structure and tearing it down, is inside the measurement. Whole-process timing measures these lifecycle costs together; input generation can dilute differences in the phase under study. Goose now has os.clock_ns for separate kernel experiments, but this suite retains its whole-process measurement policy.
• Every implementation of a benchmark, under every toolchain, prints the same checksum lines and the harness verifies they agree.

Environment

Startup floor (an empty program, best of 5): Goose 13.1 ms / 7.8 MB, C++ 13.8 ms / 7.8 MB. Account for this startup cost when interpreting ratios at small sizes.

Across all benchmarks

How many times faster (or smaller) Goose is than the best row of each comparison at the large size. Idiomatic is what a C++ programmer writes first (unique_ptr, vector<string>, unordered_map, std::variant); expert is the hand-built version (exactly-reserved arena with indices, string_view, flat offsets, open addressing, CSR); rust is the best safe Rust row for that benchmark, whichever implementation that is. Above 1.00 means Goose is ahead. The suite figure is the geometric mean over the 16 benchmarks.

There is only one rustc build, so the Rust number is the same in every toolchain column; those columns differ only in which Goose build they compare against.

The October 16, 2026 run puts Goose at 3.51x / 3.54x the speed of idiomatic C++, 1.24x / 1.26x the speed of expert C++, and 1.13x / 1.19x the speed of the best safe Rust rows, under MSVC / clang respectively. These are geometric means over the sixteen benchmarks at their large sizes. Peak-memory ratios are 1.95x, 1.32x and 1.25x in Goose's favor. The full suite was rebuilt and rerun at all three sizes, including the separate JIT measurements.

The source improvement in this refresh is check-free graph traversal. Both Goose graph rows store vertex IDs as u32 in dist; CSR also stores prefix offsets as u32 upto out. Validation happens during construction, and checkfree fn bfs verifies that no bounds check remains in the traversal. The entries are still four bytes, and construction and validation are still timed. The fresh large CSR times are 699/617 ms, against C++ 784/761 and Rust 811: 1.12x/1.23x ahead of matching C++, and 1.16x/1.32x ahead of Rust. Linked adjacency remains much slower than CSR in every language. Alternating same-compiler trials against the original Goose sources measured speedups of 1.21x/1.19x for linked adjacency and 1.08x/1.17x for CSR at the large size (notes.md). These measure the whole source rewrite; the full-suite table alone does not isolate a source change from other changes since the previous report.

Compact representation remains the clearest advantage. records is 2.02-2.26x faster than Rust on 3.98x less memory: a variable-mode enum stores each record at the size of its own payload, including inline text. interp is 1.29-1.41x faster on 2.04x less memory for the same distinction in a tree. sexp uses 2.43x less memory than the Rust arena and 5.04x less than the C++ owning nodes. For strlist, distinguish Goose's owned inline strings from the borrowing string_view, flat-offset and Vec<&str> rows; those have different lifetime requirements.

Losses and near-ties remain. calc takes 481/491 ms against the Rust arena's 436 ms. lru takes 2,760/2,068 ms against Rust's 2,249, so it loses under MSVC and wins under clang. scene is 460/371 ms against Rust 379, again a loss under MSVC and approximately level under clang. This refresh measures these differences; it does not re-establish the older diagnostic claims about which individual compiler mechanisms caused them.

A check-free kernel can still be limited by backend optimization. The flat blur is now explicitly checkfree and takes 952/266 ms. The row-slice form, also checkfree including slice construction, takes 298/269 ms. Rust's two forms take 299-300 ms. Removing bounds checks therefore does not by itself close the MSVC flat-kernel gap. The scene composition and recursive update also carry checkfree contracts. The fastest particle rows are nearly level across Goose, Rust and clang C++; small differences are not evidence of a language advantage on this flat numeric workload.

Allocation and interfaces matter to the comparison. bintrees takes 206/204 ms, against C++'s arena at 393/407 and Rust's arena at 235. The per-node allocation rows exceed three seconds. Goose uses typed references into growing storage where the safe Rust arena rows use integer indices. In respond, the inline Goose DTO takes 507/491 ms against Rust's DTO at 1,338, while Goose streaming takes 454/400 against Rust streaming at 540. Compare matching interfaces when deciding which result applies to an application.

The aggregate combines results from different implementations. For each backend and comparison tier, it uses the fastest Goose implementation. Memory figures are selected separately, using the implementation with the lowest memory use. For example, graph speed comes from CSR and its memory figure from linked adjacency. words speed comes from the hand-written table and its memory figure from dictionary. The respond headline uses streaming; blur uses row slices under MSVC and flat indexing under clang. No single implementation has all of these results. Also, words compares different hash functions and table policies: the Goose dictionary uses less memory than its hand-written table but runs more slowly.

These are whole-process measurements on one machine. They include input generation, construction and teardown, use the best of three runs after two warm-ups, and do not pin cores. Treat small differences cautiously, especially in cache-sensitive graph and LRU workloads. The empty-process floor is now 13.1 ms for Goose and 13.8 ms for C++, versus about 8 ms in the October 10 report, and MSVC has changed from 19.51.36257 to 19.51.36260. Cross-date timing changes cannot be attributed solely to Goose compiler improvements. The older diagnostic studies are retained, explicitly marked historical, in notes.md; current comparisons come from the fresh tables.

sum

Control: build a flat i32 array, then scan it eight times.

Time in ms as v145 / clang for the Goose and C++ rows, and a single rustc time for the Rust ones; memory is the peak working set at the largest size.

This control uses the same flat scalar layout in all three languages. The unreserved C++ vector pays for growth and spare capacity; the reserved vector and Rust collect over a TrustedLen iterator allocate the exact size. Whole-process time includes both building the array and scanning it.

push

Push N records while keeping pointers to every 64th one.

Time in ms as v145 / clang for the Goose and C++ rows, and a single rustc time for the Rust ones; memory is the peak working set at the largest size.

Goose retains typed Item& references across later pushes. The C++ vector and safe Rust Vec rows retain indices instead; the pointer-stable C++ deque has a different allocation and locality cost. Compare the reserved vector with Goose to separate growth strategy from the cost of building records.

strlist

Split a text into N words, keep them as a list, scan it four times.

Time in ms as v145 / clang for the Goose and C++ rows, and a single rustc time for the Rust ones; memory is the peak working set at the largest size.

Goose, vector, and Vec own the split words. The string_view, flat-offset, and Vec<&str> rows borrow the input instead, so their lifetime and ownership requirements differ. Goose uses the standard library each_split and packs owned strings into one contiguous list.

records

Build a log of N variant records, aggregate it four times.

Time in ms as v145 / clang for the Goose and C++ rows, and a single rustc time for the Rust ones; memory is the peak working set at the largest size.

The variable enum stores each record at the size of its own variant, including inline text. C++ variant and Rust enum reserve space for the largest payload in every element; their owned strings may also allocate separately.

tree

Build a complete binary tree of the given depth, sum it eight times.

Time in ms as v145 / clang for the Goose and C++ rows, and a single rustc time for the Rust ones; memory is the peak working set at the largest size.

The arena rows avoid per-node allocation and recursive destruction. Goose links its 12-byte nodes with typed nullable relative references; C++ and safe Rust use u32 indices. Compare bintrees for the cost of repeatedly building and discarding this shape.

interp

Build an expression tree of the given depth, evaluate it eight times.

Time in ms as v145 / clang for the Goose and C++ rows, and a single rustc time for the Rust ones; memory is the peak working set at the largest size.

Variable-size leaves and binary nodes use different amounts of storage in Goose. The C++ tagged union and Rust enum arenas reserve the largest payload in every node. The owning-pointer rows additionally pay for allocation and recursive destruction.

graph

Build adjacency for V vertices and 8V edges, then BFS from four sources.

Time in ms as v145 / clang for the Goose and C++ rows, and a single rustc time for the Rust ones; memory is the peak working set at the largest size.

CSR and linked adjacency have very different traversal locality in every language; compare matching representations before attributing a gap to the compiler. Both Goose BFS functions are checkfree: u32 vertex index types validate destinations on insertion, and CSR bound types validate offsets during construction. These retain the original four-byte entries. Construction and distance-array resets remain inside the measured process. Random-access timings vary substantially between runs.

words

Count word frequencies over a text of N words.

Time in ms as v145 / clang for the Goose and C++ rows, and a single rustc time for the Rust ones; memory is the peak working set at the largest size.

The hand-written Goose table and std dictionary differ in capacity and load-factor policy as well as implementation. Goose uses the standard library hash; the C++ and Rust open-addressed tables use FNV-1a, while Rust HashMap uses its default keyed hasher. The timing comparison therefore includes different hash functions. The dictionary row measures the convenience and memory tradeoff of the standard container.

particles

Integrate N particles for 200 steps of f32 vector math.

Time in ms as v145 / clang for the Goose and C++ rows, and a single rustc time for the Rust ones; memory is the peak working set at the largest size.

This flat floating-point workload offers little representation advantage. Compare elementwise and per-component rows to see the cost of expression style under each backend. The C++ struct-of-arrays row changes layout as well. All arithmetic is exact in binary32, so checksum equality is required across implementations.

sexp

Generate N s-expression forms, parse them into a tree, walk it four times.

Time in ms as v145 / clang for the Goose and C++ rows, and a single rustc time for the Rust ones; memory is the peak working set at the largest size.

Goose stores symbol text inline in variable-size nodes and links them with four-byte relative references. The C++ and Rust arenas borrow symbol text from the completed input; their owning-pointer rows allocate nodes and strings separately. Input generation, parsing, four walks, and teardown are all timed.

lru

An LRU cache of capacity N/8 under N skewed lookups, with an invalidation every 16th operation.

Time in ms as v145 / clang for the Goose and C++ rows, and a single rustc time for the Rust ones; memory is the peak working set at the largest size.

Goose uses a reusable pool with four-byte pool-relative references in both nodes and map slots. The C++ and Rust expert rows use arena indices; the idiomatic C++ row uses list plus unordered_map. Backend differences and cache-sensitive random access matter here. The separate lru_indices.goose experiment is not a headline row.

scene

Build a scene graph of the given depth, then animate it and recompute world transforms for 16 frames.

Time in ms as v145 / clang for the Goose and C++ rows, and a single rustc time for the Rust ones; memory is the peak working set at the largest size.

Goose stores child references inline in each 117-byte node and composes transforms directly through references. The Rust arena uses child indices and a temporary transform to work within its borrowing rules. The Goose compose and recursive update functions are checkfree, which protects the matrix kernel and its traversal against bounds-check regressions.

calc

Generate, parse and evaluate N small arithmetic expressions, a third of them malformed.

Time in ms as v145 / clang for the Goose and C++ rows, and a single rustc time for the Rust ones; memory is the peak working set at the largest size.

The workload includes malformed input and division by zero, so error propagation is part of the comparison. Goose uses a local pool, varint number payloads, a global parse cursor, and return from; C++ compares exceptions with explicit error codes, and Rust uses Result. This refresh does not isolate the individual costs of those choices.

bintrees

The Benchmarks Game binary-trees: build, check and discard many trees up to the given depth.

Time in ms as v145 / clang for the Goose and C++ rows, and a single rustc time for the Rust ones; memory is the peak working set at the largest size.

This repeatedly builds and discards trees rather than retaining one large tree. Goose releases a local pool by resetting its data-stack pointer; vector arenas reuse their capacity, while new/delete and Box pay per-node allocation and teardown. The arena comparisons are the relevant controls for the allocator advantage.

respond

Build and render N JSON responses, each a DTO holding a name and a list of line items.

Time in ms as v145 / clang for the Goose and C++ rows, and a single rustc time for the Rust ones; memory is the peak working set at the largest size.

The DTO rows construct an object before rendering; streaming rows write the same response without constructing it. Goose keeps the DTO name, item list, and per-item text inline and performs no heap allocation. All rows checksum the rendered bytes with FNV-1a, including the Goose implementations.

blur

16 passes of a 3x3 blur over a WxW 8-bit image.

Time in ms as v145 / clang for the Goose and C++ rows, and a single rustc time for the Rust ones; memory is the peak working set at the largest size.

Both Goose kernels are checkfree, including the row-slice constructions, so a backend gap is not evidence of surviving bounds checks. Row slices change the information available to the C compiler for alias analysis and vectorisation. Compare flat indexing and row-based implementations separately; all perform the same stencil and include image generation.

Toolchain: v145 vs clang

Ratio of v145 time to clang time at the large size (>1 means clang is faster). Only rows differing by more than 5% are listed, biggest gap first.

Goose: compiled vs JIT

The same Goose source is run two ways: built by v145 from the generated C and then run, and compiled and run by the compiler in one process through TinyCC. Each cell is compiled / JIT in ms.

The JIT number includes the compiler's own front end and TinyCC compiling the program, as well as running it, and TinyCC is a one-pass compiler with no optimizer. So this does not measure Goose against another language; it measures the cost of not needing a C toolchain. The memory columns are the peak working set; the JIT process holds the compiler, the generated C and the program at the same time.

Floor for a JIT row (an empty program compiled and run, best of 5): 30.5 ms / 15.6 MB. That time is almost all compilation, and it is included in every JIT cell above.

October 16, 2026 refresh

The main tables are a fresh run of all sixteen benchmarks, at all three sizes, under MSVC, clang-cl, rustc and Goose's TinyCC backend. The compiler was rebuilt in Release from f6d31d0e, with the benchmark source changes in this refresh and no optional native packages:

cmake -S . -B build-bench-refresh -DGOOSE_BUILTIN_LIBS=
cmake --build build-bench-refresh --config Release --parallel 1 -- /nodeReuse:false
python bench/run_bench.py --exe build-bench-refresh/Release/goose.exe

The default measurement policy is unchanged: two warm-ups, then the best of three whole-process runs, with checksum agreement across implementations. Input construction, validation, traversal, and teardown remain timed. No bounds checks are disabled in the headline measurements. The JIT rows also include compiling the program, and their peak memory includes this minimal compiler build; compare them separately from native executables.

All 528 measurements succeeded. The 48 benchmark/size combinations agree across implementations and with the saved previous run's checksums (after normalizing line endings). The original and revised graph implementations also agree at V=1, V=2 and V=17.

Index types and checkfree kernels

Both graph implementations now store destinations and queue entries as u32 in dist. The CSR implementation additionally stores prefix offsets as u32 upto out. The arrays still have four-byte elements and perform the same graph construction and four breadth-first searches. dist and out are initialized before constructing the typed values they validate.

Both bfs functions are checkfree. A length assertion on the companion head/offset array states its relationship to dist once per search. Every access in traversal is then proven, including an index loaded from another array. The CSR successor offset widens the vertex to i64 before adding one, so the proof does not have to allow wrapping u32 arithmetic.

At the source files' default sizes, --bce-lines reports:

The blur and scene annotations only enforce bounds-check elimination that the compiler already did; they do not change the computation. An attempted LRU rewrite could not prove masked probe indices from a dynamic table length, so it was not adopted. This refresh makes no claim that every benchmark is entirely check-free.

bench/bce_ab.py still supports the annotated sources: its --no-bce diagnostic copy removes only the checkfree annotations, since their purpose is to reject that build. It retains runtime bounds checks and index-type validation. The ordinary source and all headline builds retain their contracts.

Paired comparison of the graph rewrite

Original sources from f6d31d0e and the revised sources were built with the same fresh Release compiler and C toolchains. Each pair ran in alternating order, with two discarded warm-up pairs and five measured pairs. The table reports the best time of each version at V=2,000,000 (16,000,000 edges, four searches); checksums agree in every run.

This measures the complete source rewrite, including global array placement, unsigned index storage and extraction of BFS. It does not isolate the cost of removing bounds checks alone. The entry widths and storage requirements are unchanged. The separate small-size CSR trials were not consistently faster; the improvement claim is for these large inputs.

Raw full-suite measurements are saved locally in bench/gen/results.json; the paired samples and source snapshots are in bench/gen/refresh/. As with other generated benchmark files, that directory is ignored by Git.

Historical analysis through October 10, 2026

Everything below records earlier measurements and compiler experiments. Those A/B studies were not all repeated for the October 16 refresh. Their times, elision counts, causal explanations and references to "this report" describe the older run, not the current tables. In particular, the old conclusion that graph indices loaded from memory cannot be proven is superseded by the index-type implementation above. Use the current generated tables and summary.md for present-day comparisons; the historical material is retained as a record of the experiments.

Reading the Rust rows (historical)

The Rust comparisons use safe, idiomatic implementations. C++ has separate idiomatic and expert tiers. Where two Rust implementations differ in ownership or data structure, both are listed:

• strlist has Vec<String> and Vec<&str>, which differ in ownership. Only the first can outlive the text it came from, which is the semantics the Goose row has.
• tree, interp, sexp, scene, calc and bintrees have an owning-pointer row (Box) and an arena row (Vec plus u32 indices). Both are safe and both are idiomatic; the arena is what the community recommends for anything pointer-heavy, and design.md predicted it would be the real comparison point rather than Box. That prediction held: the arena row is 2.5x (calc) to 14x (bintrees) faster than the Box row on the six benchmarks that have both.
• graph has three rows for the same reason the C++ side does: Vec<Vec>, CSR, and the one-pass index-linked arena. CSR is the fastest in every language and is index-based in every language, so graph is the only benchmark where the references-versus-indices question does not show up in the fastest row.
• words and lru have both a HashMap row and a hand-written open-addressed table. std's default hasher prioritizes security over speed. Rust programmers commonly substitute a hasher crate, but this suite allows only std. In lru, both rows use the same Vec arena and free list for the nodes; only the map differs. The arena is also the idiomatic choice here: std has no intrusive list, and LinkedList provides no way to refer to an individual node.
• respond has a DTO row (String and Vec<Item> built per request, rendered by a function returning a fresh String) and a streaming row that writes the JSON directly into one reused String, mirroring the two Goose rows.
• blur has a version that indexes every element and a version using row slices and windows(3) iterators. The latter is a common way to avoid bounds checks when profiling shows they are costly. They are not costly here (see the bounds-check section).

Everything else is a single row. The aggregate table compares Goose against the fastest Rust implementation in this suite.

Build flags are -O -C codegen-units=1. Using one codegen unit matches the C++ compilation model: every C++ row is one translation unit compiled as a whole, and with the rustc default of 16 units Rust would not get the same cross-function view. All other settings are the defaults a shipped Rust binary uses: bounds checks on, unwinding panics, and no target-cpu beyond the x86-64 baseline that the C++ rows also build for. Goose and Rust are therefore both checked, with C++ as the unchecked baseline.

Data layouts and memory use

Measured with size_of and sizeof, or read off the packed declarations:

The records row is where Rust beats C++ outright and still loses to Goose by 4.1x. Rust's 32 bytes against MSVC's 48 comes from two things: String is three words where std::string is four, and the enum tag is stored in the pointer's niche rather than needing its own word. But it is still a fixed enum, so every one of the 16M elements is sized for Say whether it is a Say or not, and the text needs a second allocation as well. This is a property of Rust's enum layout.

Three Goose layouts differ substantially from the corresponding C++ and Rust implementations:

• A sexp node is only as big as its variant needs. Its symbol bytes are stored inline after a varint length, and its two links are 4-byte offsets into the pool. This makes the program 1.3x smaller than the same program with 8-byte links, which is what a language that cannot make a null link relative would have to use.
• A scene node is a 117-byte record whose four child links are 4-byte offsets in a limited array inside the record (spec 5.3, 3.9), so the whole scene is one contiguous, position-independent block. The arena rows in C++ and Rust both reach 120 bytes with uint32 indices, and their idiomatic rows add a heap vector/Vec per node for the children on top of 128 bytes.
• A calc binary node is 6 bytes: a tag, an operator byte and two 2-byte relative references, which are enough because a per-input tree never spans more than a few hundred bytes. The arenas' u32 links make the same node 12-16 bytes, and the owning-pointer rows make it 24-32 bytes plus a heap block per node.

Reading the toolchain table

The two backends are within 10% on most rows and neither dominates. The gaps that remain:

• clang vectorises what v145 does not. Goose's flat blur is the largest gap in the suite at 3.64x (930 against 256 ms), and the next two are the C++ __restrict row of the same kernel at 1.83x and particles cpp SoA at 1.62x. Every check in the flat kernel is proven, so what stops v145 from vectorising it is aliasing: MSVC reports a possible loop-carried dependence between the loads through src and the stores through dst (C5002, reason 1200) and leaves the loop scalar. It does vectorise the row-slice form, where the gap is 1.12x.
• v145 is better at std::vector::push_back and at dispatch. push cpp vector+reserve is 0.61 (185 ms against 301), and clang trails on every interp row (0.84-0.91) and on sum (0.93 on the reserved vector, 0.97 on Goose).
• clang is consistently 5-25% ahead on string, hash, allocator and float-and-pointer work: words (1.10-1.12 on the C++ rows), strlist (1.06-1.13), records variant+string (1.14), sexp unique_ptr (1.16), respond (1.16 and 1.23 on the two C++ rows), calc cpp arena (1.16), and scene, where it is 1.21 on the Goose row and 1.10 on the C++ arena.
• On Goose's own rows: records and interp favour v145 (0.89 and 0.91), respond streaming, particles elementwise and blur_rows favour clang by 12-14%, words by 1.28-1.33, and lru by 1.53, because its pool-relative loads are base-plus-offset loads, which clang schedules and v145 does not. bintrees, which favoured v145 at 0.84, is now level.

Three conclusions change with the backend, which is why every ratio in this report is given per backend: against the best safe Rust row, lru is 0.72x under v145 and 1.10x under clang, scene 0.83x and 1.00x, and blur 0.98x and 1.10x. graph and bintrees, which used to be on this list, are on the same side of the Rust row under both backends now.

Reading the JIT table

TinyCC keeps a C local in a stack slot and holds values in registers only within one expression. The generated C reads each operand into a temporary of its own before later operands run, so that a later operand cannot change what an earlier one read. clang and MSVC optimize those temporaries away, but TinyCC turns each one into a store and a reload. This accounts for most of the increase in the JIT rows from 2.96x their compiled time in the previous report to 3.48x in this one. On blur, whose kernel is one long expression per pixel, bisecting the JIT slowdown points to the commit that introduced this operand ordering; that commit took the W=2048 row from 365 to 666 ms.

Bounds-check elimination, measured

The compiler proves most index and slice checks away (spec 10.5). bench/bce_ab.py builds each benchmark with and without --no-bce under both toolchains, at the size baked into each source file rather than the report's large one. --no-bce disables more than check elimination: the loop-view hoist decides whether a loop's array length is invariant by asking BCE's kill summary, so with the pass off the view is re-read every iteration too. The A/B measures both together. The counts are per generated function, so a kernel inlined at two call sites counts its checks twice.

For words under v145 and graph under clang, the binary with the pass on measures slower. This is the noise floor of a cache-bound random-access row, not a real result. Everything between -7% and +7% falls in the same category, which now includes graph_csr's clang column (+31% in the previous round).

The row where it matters is the image kernel, and only under v145. At W=2048, 16 passes, ms, best of four:

Under v145 the nine checks per pixel keep the loop scalar: proving them away makes the flat kernel 1.8x faster and the row-slice form 2.9x faster. The flat kernel stays scalar even with every check gone, because MSVC cannot rule out that the stores through dst feed later loads through src. The row-slice form does vectorise, which accounts for the remaining 2.6x between the two. Under clang the checks have no measurable cost: clang vectorises the checked loop to run as fast as the unchecked one, as it does for the Rust blur_index row, which keeps ten panic_bounds_check sites in its assembly and runs at the speed of the checkless windows row. In the previous round clang also needed the loop-view hoist, which accounted for most of a +327% on the blur row, because src and dst were fat reference parameters whose headers a byte store through dst might change. The kernel is now inlined at both of its calls in main, where the two arrays are locals whose headers no store can reach, and the clang build is as fast with the pass off as with it on.

blur proves its checks from what main itself knows: that both arrays are W * W long. Before the kernel was inlined, the same facts reached it through its call sites. Every call site of a specialization records what it proves about the lengths and integers it passes, and the body starts with the meet of those facts (spec 10.5). The fact stays valid between the two calls because a call does not kill it: a callee's effects on its callers' arrays are summarized, and a kernel that only reads and writes elements has no such effects. So at the second call in blur(a, b); blur(b, a) the compiler knows as much as at the first. The assert in blur_assert.goose is redundant, and the two rows time the same. The row slices in blur_rows.goose also lose their slice checks, since each slice's upper bound is compared against a length the kernel knows.

Every check that survives elsewhere is an index that came out of memory. Examples are dist[u] where u = q[qh], dist[w] where w = cur.to, out[cursor[s]] in the CSR fill, and pool[slots[at].node] throughout lru. The analysis proves the checks on every index derived from loop counters, lengths, constant masks and reductions, and on none that was loaded from a data structure, as test/optimizer/bce.goose documents. blur adds a second class of index, the product of two counters. For that idiom the difference-constraint domain has one-shot product and two-term-sum bases, which is also what gets scene to 12/12.

Four rewrites were tried to see whether any natural form lets the compiler prove the loaded-index checks, and none is worth adopting:

• making graph's arrays globals (the invariant would have to hold on array contents);
• deriving words's mask from slots.len;
• using the documented % reduction (the range fact does not survive the loop back-edge);
• one assert at the top of the probe loop.

All four time within noise of each other, because those checks are perfectly predicted branches on values already in registers. Array-contents invariants themselves were implemented and measured. They removed more checks on the two graph rows but saved no measurable time on either, so they were dropped. The blur measurement above is the counterexample: a check per load in a loop that would otherwise vectorise has a large cost.

What the standard library costs the benchmarks

Seven of the sixteen benchmarks use stdlib/ functions in place of hand-written code with the same behavior. Each adoption was measured on its own against the hand-written form it replaced, at the large size, under both toolchains, best of three interleaved runs (above 1.00 means the library form is faster):

The adopted library functions add no measurable cost; on two benchmarks they are slightly faster than the loops they replace. The words figures were measured before std's hash started reading 8 bytes per step. Compared with the byte-wise FNV-1a that std's hash used to be, which is also what the C++ and Rust tables hash with, the current hash measures 0.94 under v145 and 1.19 under clang on that row. respond and respond_stream also used hash, as the checksum of each rendered response, and now compute FNV-1a in their own code instead: every row of a benchmark has to print the same checksum, and the other languages' rows compute FNV-1a. words also keeps a second row, words_dictionary.goose, which replaces the hand-written table with dictionary<u8[:], i32>. That row is a data-structure comparison rather than a comparison of notation, and its results are in the per-benchmark table.

Three other substitutions were tested but not adopted:

• format_int in respond and respond_stream costs 3-5% under v145 against the hand-written digit loop, and nothing under clang. Most of the original gap came from format_uint dividing by its base parameter: that is a real division per digit, where the hand-written loop divides by the constant 10. Giving base ten its own loop in the library recovered about half of the gap. What is left is the extra call layer and the padding branch, on a row that renders four numbers per request and does nothing else expensive. sexp, which formats one number per node among much other work, shows no measurable difference.
• push_n in graph and graph_csr costs 2-3%: the generic push loop does not compile to the specialised one, and it also makes the destination array's length unprovable to the bounds-check pass a few statements later. fill alone, which is where the readability gain was, has no measurable cost.
• push_n of a value containing self-relative references does not compile: push_n<A, T>(xs: A&, v: T, n: i64) takes its value by value, and such a value cannot be copied (spec 3.9). graph's edge-head fill stays a loop for that reason. A T& parameter would not help either: the library would still be copying out of it.

Benchmark code also has to avoid names that hide library functions. The std functions are global, so a local named fill shadows the library function, and the error appears at the call rather than at the declaration. graph_csr's CSR write cursor is called cursor for that reason, and the name also describes what it is.

Where Goose loses

Relinking through relative references is the mutation-heavy case, and the pool-relative form is what makes it competitive. lru is the only benchmark in the suite that mutates links rather than building them once. With self-relative links and index slots it is 1.5x behind the Rust and C++ arenas. With spec 3.9's in pool form, the nodes and the 8-byte map slots hold 4-byte offsets from the pool's base, and pool.free(pool.index_of(n)) turns a link back into a freelist index. In that form the row takes 3,163/2,065 ms against the Rust arena's 2,274 and the C++ arena's 2,607/2,437: 1.10x and 1.18x ahead of them under clang and 1.39x and 1.21x behind under v145, while using the least memory of the three. The index form is kept as lru_indices.goose; measured back to back in an earlier round, it was level under v145 and 1.31x slower under clang. The table below shows the same program written in more ways, at the large size, all with the map holding indices, also from an earlier round:

Plain references and indices are level, so the cost comes neither from references as such nor from the reusable pool (every variant frees and reuses through the same freelist, 1.3M times). It comes from the self-relative encoding. Every relink (six per hit) computes an offset from two addresses and stores it, and every load needs a null test and an add before the next load can issue. The range check accounts for a tenth of that cost under clang and none of it under v145; the rest is the arithmetic on the pointer-chasing critical path. The links were made relative to save 8 bytes per node against plain references, but lru gets no benefit from that, because the index form is also 16 bytes. On the build-once benchmarks (tree, interp, sexp, scene, bintrees) the same links have no measurable cost against indices, so the cost is specific to the relink pattern. The pool-relative form replaces the subtraction of the field's address with a subtraction of a base held in a register, and replaces the load with base + off. clang schedules that much better than v145; this accounts for the 1.53x between the two backends on this row, and for all of the remaining gap. The build-once benchmarks keep self-relative links, because they want the position independence and the links have no measurable cost against indices there.

Recursive construction is no longer one of the losses, except in calc. bintrees builds and discards 34M nodes in recursive calls, and used to trail the Rust arena by 24% under clang (282 against 228 ms). The builder takes its pool by reference, and the compiler now keeps that pool's top and count in locals across the recursion instead of going through its header at every push. With that, Goose takes 196/191 ms against the Rust arena's 221 and the C++ arena's 378/391. On tree, which builds a tree of the same nodes once and sums it eight times, Goose is 6-10% ahead of the Rust arena. calc runs at 0.84-0.87x of the Rust arena; the remaining costs there are the global cursor, the return from discriminant and a varint decode on values that mostly need two bytes.

Flat scalar kernels depend on backend optimization, with no memory advantage. The flat, indexed form of blur is 3.3x slower than flat Rust under v145. MSVC leaves the loop scalar because it cannot rule out dst aliasing src. Under clang, the same form is 1.10x faster than Rust (256 against 282 ms). Written over row slices, it is level with Rust under both backends. particles is 2-4% ahead of Rust with identical memory use, which is within the noise of that row. Neither benchmark shows a Goose advantage beyond noise, and the design did not predict one.

Pointer-linked adjacency loses to CSR, in all three languages. On graph the one-pass linked build is 5-6x slower to traverse than two-pass count-then-fill, in every language. The Goose CSR row exists to show this is a data-structure effect rather than a language one, and the Goose CSR implementation is level with both: 791/793 ms against C++'s 803/824 and Rust's 833.

v145 is also a worse backend than clang for the float-and-pointer mix. scene is level with the Rust arena under clang and 21% behind under v145, with the C++ arena 10% behind its own clang build on the same row. Padding the 117-byte node to 120 changes nothing, so the packed layout is not the cause.

Caveats on these numbers

• Whole-process wall clock, so input generation is inside every measurement. Where generation is a large share of the work (sexp, words, graph, calc) the ratios are diluted toward 1.0 and the gap on the interesting phase is larger than the table shows.
• Best of three runs after two discarded warm-ups. The warm-ups are necessary: on this machine a freshly written executable takes up to 10x its steady-state time on its first execution and about three runs to settle, and the effect is far larger on clang-linked binaries than on MSVC-linked ones. Without the warm-ups the toolchain comparison would measure the malware scanner.
• One machine, no core pinning. Differences under ~10% are within measurement noise. The threshold is ~15% for the two cache-bound random-access cases, graph's linked rows and lru: two byte-identical lru binaries measured 14% apart in the bounds-check A/B.
• The allocator-heavy rows are the least reproducible in the suite, and they are the ones the headline ratio rests on. When the whole harness is run twice back to back, the Goose rows stay within 3% of their earlier times, as do the arena and CSR rows in every language, but the malloc-bound rows move by up to 23%. A difference of less than about 10% in the "vs idiomatic" geometric mean is not significant, and a single suite run is not enough to attribute a change to the compiler. That needs a per-commit A/B built from the same sources minutes apart, with -falign-loops=32 under clang so that a shifted hot loop cannot look like a codegen change.
• Reports are not comparable with each other across machine updates. Between the previous report and this one, most C++ and Rust rows got up to 6% faster, every row in every language got 3-4 MB smaller, and the process-start floor fell from 12.4 to 7.9 ms, with no change to their sources. Something outside the compilers changed, and MSVC changed too (19.51.36256 to .36257). The malloc-bound C++ rows moved most, sexp's unique_ptr row by 1.42x. tree's Goose row under v145 went from 956 to 605 ms, although the C that the previous compiler generated for it runs in the same time today as the current compiler's C. Compare compiler versions by building both and running them side by side.
• This CPU has a very large L3, so small and medium can sit entirely in cache. The large rows are the ones that stress the memory subsystem, and calc, respond and bintrees never leave the cache by design: each one's working set is a single input, request or tree.
• The process-start floor is not constant between runs, and it is inside every small cell, so read those as differences from the floor and read ratios only at large.
• Rust rows are a single rustc time, not one per backend. rustc is LLVM, so the clang column is the one they are most directly comparable with; the Goose-vs-Rust ratios are reported against both Goose builds anyway.

What the benchmarks say about the language

These findings come from writing and maintaining the sixteen benchmarks, independent of how fast anything ran. Together the benchmarks use reusable pools, per-input arenas inside recursion, return from as a taken error path, inline child arrays, DTOs with nested variable-size parts, and the standard library.

Features that worked well:

• grow-only pools with interior references;
• relative references inside a single root;
• variable-mode ADTs with inline variable-size payloads;
• case functions as the dispatch mechanism;
• reusable pools with sentinel-linked lists;
• limited arrays of relative references inside pool elements;
• a DTO with a variable-size string and an inline list of variable-size records, built by a function returning directly into the field;
• return ... from taken on a third of all inputs from three levels of recursion;
• per-input local pools reset by scope exit;
• a recursive builder building into a pool it is handed by reference.

Difficulties encountered:

• Inline child arrays need their count at construction. The A.2 shape (T&<u32>)[varint] requires the children to exist and their number to be known before the parent is built. A builder that discovers children as it goes uses a limited [..k] array inside a fixed-size node (scene, 17 bytes for four links), or sibling links (sexp).
• A plain reference parameter cannot be stored relatively outside a recursive cycle. fn link(prev: Node?) { pool.push(Node { next: prev }) } is rejected at any call site that passes a pool-rooted reference: the parameter's root is its own per-call-site class, and nothing identifies that class with the global the argument came from. Inside a recursive cycle the pool-class machinery (spec 7.8) does make the identification, which is why sexp's parser can do exactly this. The same identification outside a cycle is the natural fix.
• Arithmetic at the operands' width bites on u8 data. The first version of blur summed nine u8 taps in u8 and produced incorrect results; every tap needs as u16. C promotes to int silently and Rust would panic in a debug build; Goose wraps, as the spec says it will (6.2), but nothing in the source points at it.
• A negative literal through a generic parameter takes i64. push_n(dist, -1, V) on an i32[>..] fails inside the library, where the bound T is i64 and the push does not narrow; push_n(dist, -1 as i32, V) works, and a plain 0 binds fine. The literal's type should follow the destination through the instantiation.
• Two parses to know about. x as u64 & mask reads u64& as a reference type (parenthesise the cast), and an if/else if chain that ends without an else in tail position is an error (write early returns).
• Self-relative references trade speed for position independence in code that relinks; pool-relative ones do not. Self-relative links have no measurable cost against indices on the five benchmarks that build a structure once and walk it, but cost 1.5x on lru, which relinks six links per hit. Spec 3.9's in pool form (offsets from a named global pool's base) turns the relink into a subtraction from a register and lets other arrays hold 4-byte links into the pool; with it, lru is level with the arenas under clang. The encoding is a per-field decision: self-relative for blobs and for local pools, in pool for relink-heavy structures in a global pool.
• Thread queues cannot carry a relative-reference structure (not flat, TODO 9), and at the time of these measurements, save/load also lacked the whole-region copy of TODO 16. Serialization has since been implemented (docs/design/serialization.md); queues can carry its byte images, but cannot directly carry values containing relative references.

What the Rust implementations say about Rust

These findings come from implementing the suite in Rust, independent of how fast anything ran. In these measurements, Rust is closer to Goose than idiomatic C++ on speed. The implementation differences below help explain the remaining gaps.

push requires indices in the Rust implementation. push keeps a pointer to every 64th element of an array it is still appending to. In Goose that is marks.push(items.push(...)), and the reference stays valid for the array's lifetime. In Rust the equivalent does not compile: a &Item borrows items for as long as it is held, so the following items.push is rejected. No std container is both pointer-stable and O(1)-append. The row uses indices because that is what a Rust programmer writes; the interesting difference is in the source code, not in the timings.

Several Rust implementations use indices where Goose uses references. This applies to tree, interp, graph, sexp, scene, calc, bintrees and lru: the fast, safe, recommended Rust form is a Vec arena with u32 links, as design.md predicted. The arena does not give up safety, since an out-of-range index panics like any other Rust index. Its costs are these: the type says u32 rather than what it points at; Option<&T> becomes a sentinel that occupies a real slot; and an index into a pool that is later reused goes stale in a way the compiler cannot detect, where a reference would have been rejected. Goose gets the same layouts with TNode&<u32>?, which is checked, nullable, and typed to the thing it points at.

The arena is sometimes harder to write than the Box row. In scene_arena.rs, update cannot compose into the node in place: &pool[i].local and &mut pool[i].world are two borrows of one Vec, and neither Index nor IndexMut can split them. So the transform is built in a stack local and copied in, and the child list is copied out of the node before recursing. scene_box.rs has neither problem, because disjoint fields of one &mut borrow independently. Goose composes directly through Xf& references into the pool element.

The idiomatic LRU is already the arena. std has no intrusive list, and LinkedList provides no handle to an individual node, so O(1) move-to-front by handle needs Rc<RefCell<Node>> (two allocations and a refcount pair per node) or the Vec-plus-indices arena. Both Rust rows use the arena; they differ only in whether the map is HashMap (SipHash) or open addressing.

Rust enums are the best fixed-tag ADT of the three. They have a byte discriminant, a jump table from match, no vtable pointer, and a niche optimisation that hides the tag inside a payload pointer. That is enough to beat std::variant on both time and memory in records and interp. But a Rust enum is still a fixed enum: every element is sized for the largest variant. Variable-mode enums are the only Goose feature in this suite that has no direct counterpart in Rust's builtin enums.

Result and ? work well in calc. The Rust code reads like the C++ exception implementation and has a runtime cost similar to the error-code implementation. The arena version gets an O(1) teardown from Vec::clear(), but only because Expr owns nothing. If a node held a String, the clear would become a per-node drop walk again; that is the ordinary case, and one that never arises in Goose.

In two cases, Rust's idiomatic form is already the fast one. collect() over a TrustedLen iterator preallocates the exact size, so the "did you remember to reserve" gap that sum and push measure against C++ does not exist against Rust. And borrowing is the default, so Vec<&str> and HashMap<&str, _> are what a Rust programmer writes first. Both are real language-design advantages over C++, and both reduce the Goose margin.

Where Rust still pays:

• Box::new(T { .. }) builds the value in a stack temporary and moves it to the heap (there is no guaranteed construct-in-place; spec 4.3/7.3).
• Teardown is real work, and it is the same cache-hostile pointer chase that building was (interp's Box row is behind C++ virtual dispatch; bintrees consists of nothing else).
• std's HashMap hashes with SipHash-1-3 by policy.
• The borrow that makes sexp's arena row fast works only because the text is complete before parsing starts.

LLVM removes what the Goose pass cannot, and keeps what it can. Rust's blur_index row keeps ten panic_bounds_check sites in its assembly and runs as fast as the checkless windows row, because LLVM vectorises around them. The Goose flat row under v145 is 3.3x slower for a different reason: its checks are all proven, but MSVC cannot rule out that the stores through dst alias the loads through src, so it leaves the loop scalar. The Goose row-slice form, which MSVC does vectorise, runs 3.3x faster than the flat one.

Where the Goose-Rust gap comes from, and where it can still move

The sixteen rows fall into three groups by why the Rust comparison comes out as it does, and only two of the three groups are worth working on.

Gains from data representation. The clearest gains come from differences in layout and reference rules:

• Variable-mode enums. records is 2.1-2.3x faster on 4.1x less memory because each element takes the space of its own variant rather than of the largest one, and a Say's text is inline rather than a second allocation. interp and sexp show the same property in a tree. Rust's enum is the best fixed-tag ADT of the three languages and still uses the maximum payload size for every element; changing that requires a different representation.
• Variable-size parts stored inside records. respond builds a DTO whose string, item list and per-item sku are all inline, renders it with no allocation anywhere, and runs level with the streaming rows, which never build the object. The Rust DTO allocates per string and per list, per request.
• References into a container that is still growing. Safe Rust cannot express this at all for push, and for tree, graph, scene, bintrees and calc it can express it only as u32 indices. Goose gets the arena's layout with the types of the pointer version.
• Links narrower than a pointer. sexp's nodes link with 4-byte offsets, calc's with 2-byte ones, and scene's four child links are stored in a 17-byte array inside the node. Rust's arena also gets down to 4 bytes, but as an index, which is untyped, needs a sentinel slot, and goes stale silently when the pool is reused.

Backend, not language. This group is lru under v145 (0.72x), scene under v145 (0.83x), and blur's flat form under v145 (0.98x). In all three the C++ row built by the same toolchain loses in the same direction, so the gap comes from what MSVC makes of a given C shape, not from what Goose asked for. Changing the language would not close any of these gaps, and the upper limit is visible: each of these rows is level or ahead under clang. bintrees under clang (0.81x) was on this list, but turned out not to be a backend effect: keeping the builder's pool top and count in locals put it 1.16x ahead of the Rust arena.

Costs required by the chosen semantics. The bounds checks that survive are on indices loaded from a data structure, which is where a check is not redundant. calc's return from discriminant serves a real error path; the C++ error-code row also pays this cost, and the exception row pays far more. These are not gaps to close.

What would extend the lead, in order:

1. Identify a reference parameter's root class with its pool outside a recursive cycle (item 1 below). Narrow links provide the memory advantage, and today a structure linked by them can be built only by functions inside the cycle that builds it. Removing that restriction would make the advantage available to ordinary code, not only to parsers.
2. Cross-array narrow links, everywhere they typecheck. T&<u32 in pool> already lets a side table hold 4-byte links into a pool instead of indices. lru's map does this, and a grow-only array of such links works the same way, so sexp's root list is a candidate. This idiom should be the default advice for a side table, rather than an lru special case.
3. Keep looking for places a root requirement is not really needed. A sentinel-ended chain does not force plain 8-byte links, because null needs no root; that alone accounts for 1.3x of sexp's memory. The same question is worth asking of every rule that currently demands an exact root: what does the representation actually require?

Compiler work, ordered by measured benefit

The first item of the previous round, carrying array lengths across calls, is done. A call site's facts about the arguments now reach the callee's entry, and a call kills only facts about arrays the callee can actually resize. As a result blur proved all ten checks from what main knows and ran at the speed of the asserted kernel under both toolchains (1.75x under v145, 141 to 77 ms at the time). What remains:

1. Identify a reference parameter's root class with its source pool outside recursive cycles too. A non-recursive function that takes a Node? and stores it into a Node&<u32>? field of the same pool is rejected today. The identical code inside a recursive cycle is accepted; the cycle machinery already computes the information needed. This restriction prevents linked-structure helpers from being factored out of the cycle that builds the structure.
2. Specialise the library's element loops. push_n costs 2-3% against the for loop it replaces and blocks a bounds-check elision downstream, which is why two benchmarks kept their loops. The generic form should compile to what the loop compiles to.
3. Inline a base case that is not the first statement (scene, interp), and match expression-bodied folds (if c { 0 } else { 1 + f(x) }) in tail-recursion elimination.

Measurements ruled out the following ideas:

• Array-contents invariants for the bounds-check pass: more checks removed, but no measurable time saved.

• Merging tag dispatch: a 1% gain.

• Dropping #pragma pack(1) where the layout is already gap-free: no difference on either backend.

• Fusing an optional relative-reference load with its null test: both backends get worse.

• Rewriting benchmark code so the bounds-check pass can prove loaded indices: no measurable gain.