comparison.md — how mc compares, measured against C, Go, Zig, Rust and C# (2026-09-06)

Two benchmarks, run on one Mac, comparing mc against five real toolchains on the same code: a CPU-bound integer workload compiled and run by all six, and 17 minimal HTTP servers under load (nine in the first set: mc, C, Go, Zig, Rust threads, C#; eight more in a second set: Node, Rust axum, Python, Ruby, PHP). Every command, every number and every failure hit along the way is in ../bench/RESULTS.md, ../bench/http/RESULTS.md and ../bench/http2/RESULTS.md; this page is the five-minute version. The benchmark sources are in ../bench/ and build with the same mc this repository builds — nothing here is a projection.

Conditions #

The hour-long soak below (§ "The hour under load") is a separate measurement, on separate hardware: it runs on GitHub's hosted Actions runners (one per server, four vCPU each), not on the Apple M4 this table describes -- its own conditions block gives the runner, kernel and toolchain versions for that run.

The HTTP tables below merge two measurement sets on the same host, back to back: the first (mc, C, Go, Zig, Rust threads, C#) ran to completion before the second (Node single/cluster, Rust axum, Python, Ruby, PHP) was started, so neither harness's load competed with the other's for the ten cores. Every command and number for the second set is in ../bench/http2/RESULTS.md.

The cell of record #

The table above is one developer's Mac, and it is labelled as one. The reference measurement is the reproducible cell of specs/M50.md — one GitHub Actions job per toolchain on three cells, clang -O2 of the same program built and timed inside every job as the reference, a release tarball whose .sha256 the job verifies before unpacking, and every binary recorded by SHA-256. Its runs are committed as dated JSON, so a regression is a git blame and not a chat log.

Run 34783020976, 2026-09-13, committed at bench/results/2026-09-13-34783020976/:

Pins for that run, from ../bench/cell/versions.env: clang-18 on Linux, go1.26.7, zig 0.16.0, rustc 1.96.0, .NET SDK 10.0.400 — each recorded as the tool itself printed it, never as the pin claimed. Seven repetitions per row, interleaved, the first dropped; TOLERANCE = 0.05 on a row's ratio and the teeth (mc --opt=0 against mc --opt=1 on the mix phase) floored at 1.5 on AArch64 and 1.10 on x86-64. 17.2 minutes of runner time for all three cells.

What the cell fixed, and what no machine can fix. The two caveats this block used to carry are gone. The stale tree label — the workload binary reporting e5a1643, a real commit that is not the one that produced it — is structurally impossible now: the cell records the SHA-256 of the tarball it verified and of the binary it timed, and a digest cannot go stale. The shared host is not cured by any machine this project can reach, and the cell does not pretend otherwise; what it does instead is compare only numbers taken in the same run, on the same core, in the same minute, and report the reference's own absolute median as the machine's health indicator. Between two runs of that cell twenty minutes apart, ubuntu-latest came up as an AMD EPYC 7763 and then as an Intel Xeon 8573C, and macos-15's reference median moved by up to 31.8% between jobs — both visible in the committed JSON, neither hidden. So absolute seconds on this page are a snapshot of one machine on one day, and only the ratios are comparable across runs.

The HTTP tables keep their own caveat and it is unchanged: one host, the load generator sharing the cores it measures. ../bench/http/RESULTS.md § Notes 13 names three runs whose numbers swing ~20% run-to-run with nothing in the logs to explain it beyond that contention (c-serial on the serial no-keep-alive configuration, mc-forkka and go-nethttp on one of their three keep-alive runs); best of 3 is reported everywhere and the spread is in the raw results. The HTTP rows are deliberately out of the cell — their recorded spread is 0.9% to 228.5%, against the workload's 2–8% — and the hour-long soak below is the right protocol for them.

Where mc stands #

The workload: one integer program, six languages #

200,000,000 iterations of a wrapping 64-bit LCG + xorshift mix, a sieve of Eratosthenes over 50,000,000 bytes, and naive recursive fib(38). Every variant printed the same three numbers (cross-checked, ../bench/RESULTS.md § A).

(Full table with every variant, every failure and the exact build command: ../bench/RESULTS.md § A.)

The same workload in the cell, as ratios #

The table above is the developer's Apple M4 and its absolute seconds are that machine's. The cell's verdict is a ratio to a clang -O2 built and timed in the same job, which is the only number that survives a change of machine — and it changes the picture, because mc -O's register allocator has ten registers on AArch64 and five on x86-64. Run 34783020976, medians of six kept repetitions, hand-copied from the three committed results.json under bench/results/2026-09-13-34783020976/ (nothing generates this page):

Three things worth reading off it. The arithmetic phase is where the optimizer lives: mix is 1.42x clang -O2 on the macOS cell against the plain road's 3.44x. fib is not, anywhere — the gap there is clang's recursion-to-loop rewrite, which -O does not do, and on the macOS cell -O is a hair slower than plain on that phase (1.684 against 1.669, inside the noise). And the x86-64 allocator buys 19–21% where AArch64's buys 130–265%, which is the first timing that side has ever had (M49 step D2 shipped with an instruction count and nothing else).

Toolchain footprint #

(Full table with version strings and exact measurement commands: ../bench/RESULTS.md § B.)

The HTTP servers #

Seventeen servers, same contract (GET / → 200 text/plain hello, world\n, verified byte-identical across all of them, first set and second set each checked on their own), driven with ab -k -c 64 -n 200000 (64 keep-alive connections) and ab -c 1 -n 50000 (one connection, no keep-alive), plus oha once per configuration. CPU ms / 1k req is the number comparable across concurrency models: total server-life CPU time (user+sys, children included) divided by requests served. The second set (Node single-process and cluster, Rust axum, Python stdlib and uvicorn, Ruby WEBrick and Puma, PHP's built-in server) is marked with its runtime version in the server column; its full method, environment and per-run numbers are in ../bench/http2/RESULTS.md.

Keep-alive, 64 connections — best of 3:

No keep-alive, 1 connection — best of 3:

oha -c 64 -z 5s (keep-alive), one run:

py-stdlib's oha keep-alive run succeeded (13,280 req/s) even though its ab -k run did not — the failure is specific to that combination of ab and ThreadingHTTPServer, not to keep-alive connections in general; its no-keep-alive number (5,722 req/s, above) is unaffected either way.

(Both ab tables in full, plus the oha -c 1 --disable-keepalive run and the per-run spread: ../bench/http/RESULTS.md and ../bench/http2/RESULTS.md.)

The hour under load #

The first full run of the soak (.github/workflows/bench-soak.yml, protocol in ../bench/README.md § "C. The soak"): every server above plus round 2's, under a FIXED 3,000 req/s for 60 minutes, one GitHub Actions runner per server, pinned to two of its four cores (oha and the sampler on the other two), the whole process tree sampled every 5 s. Full tables, results.json and the SVG time series: ../bench/soak/results/2026-09-06-34062566194/RESULTS.md.

Conditions #

Memory and CPU #

RSS is the sum over the process tree in KiB; slope is the least-squares fit over the fitting window named in the verdict (after the first 10 minutes, here), with its R²; flat/drifted is a rule (projected move ≥ 5% of the window's mean AND R² ≥ 0.5), not a judgement.

Throughput and latency #

req/s is what oha achieved against 3,000 asked; latencies in ms from oha's own histogram; startup is time to the first 200. Every server served effectively all 10,800,000 requests the hour asks for (0–11 connection-level errors each, the normal way a timed run ends: oha aborts its still-open connections at the deadline).

Charts #

The full set -- rss.svg, cpu.svg, threads.svg and one three-panel chart per server -- is in ../bench/soak/results/2026-09-06-34062566194/RESULTS.md (same directory on disk).

Verdicts, verbatim #

• mc-serial: RSS 940 -> 940 KiB over minutes 10-60 (+0.0%), slope +0.0 KiB/min (R^2 1.00), peak 940 KiB: flat
• mc-forkka: RSS 5,348 -> 5,348 KiB over minutes 10-60 (+0.0%), slope +0.0 KiB/min (R^2 1.00), peak 5,348 KiB: flat
• c-serial: RSS 1,124 -> 1,124 KiB over minutes 10-60 (+0.0%), slope +0.0 KiB/min (R^2 1.00), peak 1,124 KiB: flat
• go-nethttp: RSS 15,784 -> 16,108 KiB over minutes 10-60 (+2.1%), slope +2.0 KiB/min (R^2 0.08), peak 16,556 KiB: flat
• rust-threads: RSS 2,436 -> 2,436 KiB over minutes 10-60 (+0.0%), slope +0.0 KiB/min (R^2 1.00), peak 2,436 KiB: flat
• rust-axum: RSS 3,832 -> 3,832 KiB over minutes 10-60 (+0.0%), slope +0.0 KiB/min (R^2 1.00), peak 3,832 KiB: flat
• zig-threads: RSS 12,480 -> 12,480 KiB over minutes 10-60 (+0.0%), slope +0.0 KiB/min (R^2 1.00), peak 12,480 KiB: flat
• cs-jit: RSS 68,452 -> 69,732 KiB over minutes 10-60 (+1.9%), slope +26.2 KiB/min (R^2 0.98), peak 69,988 KiB: flat
• cs-aot: RSS 19,488 -> 20,640 KiB over minutes 10-60 (+5.9%), slope +23.1 KiB/min (R^2 0.96), peak 20,640 KiB: drifted
• node-single: RSS 72,496 -> 94,128 KiB over minutes 10-60 (+29.8%), slope +369.6 KiB/min (R^2 0.68), peak 94,396 KiB: drifted
• node-cluster: RSS 199,336 -> 215,216 KiB over minutes 10-60 (+8.0%), slope +448.1 KiB/min (R^2 0.80), peak 215,776 KiB: drifted
• py-uvicorn: no RSS window (server did not answer 200 within 90 s (exit 2))
• rb-puma: RSS 46,536 -> 47,304 KiB over minutes 10-60 (+1.7%), slope +12.8 KiB/min (R^2 0.91), peak 47,304 KiB: flat
• php-builtin: RSS 143,024 -> 564,400 KiB over minutes 10-60 (+294.6%), slope +8437.6 KiB/min (R^2 1.00), peak 564,784 KiB: drifted

Reading it #

Every server with a compiled, ahead-of-time runtime underneath it — mc in both shapes, C, Go, both Rust servers, Zig — holds its RSS flat to within a few KiB over the full hour, and four of those five fit their slope with an R² of 1.00 (a perfectly straight, perfectly flat line — Go's 0.08 says the opposite, a slope with no explanatory power, i.e. noise around a flat mean, not a trend). The two JIT/managed runtimes split: C# under Kestrel/JIT drifted +1.9% and does not clear the 5%-of-window rule (flat), but its own NativeAOT build — no JIT, no GC warm-up to finish — drifts +5.9% over the same hour and does. Node's event loop drifts hardest of the JavaScript/managed group: +29.8% single-process, +8.0% in cluster mode (11 processes sharing the RSS, so the per-process share of that drift is smaller even though the aggregate crosses the rule). PHP's built-in development server is the outlier by an order of magnitude — RSS goes from 143 MB to 564 MB over the hour (+295%, R²=1.00, a process that leaks at a constant rate and never stops) — which is consistent with it being explicitly a development tool, not a production server, in PHP's own documentation. Ruby's Puma holds flat (+1.7%). On CPU per 1,000 requests, mc (25.46 serial, 27.07 fork-per-connection) sits in the same band as the other compiled servers — C 24.79, Rust threads 22.52, Rust axum 21.22, Zig 22.53 — a few CPU ms apart, all under 30; Node's single-process event loop is the lowest of everything measured this hour at 16.00 ms/1k, ahead of every compiled server, which is the event-loop model paying almost nothing per request once the JIT is warm. py-uvicorn has no row: the workflow's own UVICORN_VERSION environment variable collided with uvicorn's click-based CLI (which reads any UVICORN_<OPTION> variable automatically — auto_envvar_prefix="UVICORN" — so UVICORN_VERSION=0.39.0 was read as the value of uvicorn's own --version flag, a boolean, and the process refused to start: Error: Invalid value for '--version': '0.39.0' is not a valid boolean); the workflow now uses PY_UVICORN_VERSION instead, and py-uvicorn's hour has not been re-run.

Reading the numbers #

Compile time, binary size and toolchain size are where mc leads everything measured here. 4.1 ms to build the workload (clang -O2's own compile is 27x slower at 0.11 s; Zig's optimized build is 2,400x slower at 9.8 s), a 33 KB executable matching clang -O2's within 3 bytes with no linker involved, and a 1.2 MB single-file toolchain against Rust's 1.7 GB or clang's 1.0 GB. No .dll/.so to find at run time, no SDK to install, no linker to configure — build/mc1 alone compiles and signs a working macOS executable.

The default road is at clang -O0 level; -O closes most of the gap and is now MEASURED, not estimated. The numbers in the table above are the DEFAULT road, where mc does constant folding and nothing else: 1.09 s, between clang -O0 (1.02 s) and clang -O2 (0.49 s). Since M49 the same compiler takes -O, and on the same workload and the same host that road measures 0.548 s against clang -O2's 0.420 s — 1.30x (wall clock, best of nine, the binaries interleaved; three runs at growing repetition counts gave 1.29x, 1.31x and 1.29x, so the host's own 2% spread straddles the figure). Per phase: the arithmetic loop reaches parity (0.216 s against clang's 0.215), the sieve is 0.202 against 0.138 — the remaining gap is clang -O2's NEON vectorisation of the counting loop — and fib(38) is 0.132 against 0.073, a gap that is the number of CALLS and not the quality of the code between them (clang -O2 turns one of the two recursive calls into a loop). The compiler's own __text is 10% SMALLER with -O than without.

What -O is: the callee-saved registers (x19..x28) allocated to locals and parameters by weighted use count, two emission-time peepholes that fuse a comparison into the branch reading it, and a loop's invariant constants and global addresses materialised once at function entry (guide/15-optimizing.md, reference/machine.md § 5). What it is not: there is still no inlining, no constant propagation, no unrolling and no vectorisation (surface.md), and the x86-64 machines have not been taught the allocator yet, so --opt=1 on a Linux or Windows x86-64 target is accepted and does nothing. The default stays 0 — the plain road is the determinism reference and the seed for every foreign bootstrap chain — so a project opts in with one flag or one [project].opt line.

Both roads are self-hosting and they agree on the compiler: an mc built with -O compiles src/mc.mc to byte for byte the object the plain one writes (bootstrap.md § The optimized chain).

In the HTTP benchmark, the concurrency MODEL decides more than the language does. mc-forkka (fork per connection, the process kept alive across a connection's requests) is in the same band as Rust/Zig/Go/Kestrel — 120k req/s, and at 12.5 CPU ms per 1,000 requests it is the second-lowest CPU cost measured, behind only Rust and Zig's raw thread-per-connection servers (11.5). The serial shape (mc-serial, one connection at a time, no keep-alive) is at parity with the equivalent C server (28,578 vs 25,128 req/s, 9.6 vs 8.2 CPU ms/1k — close enough to be inside this host's ~20% run-to-run variance). The shape to retire is fork-per-request (mc-fork1): it is the examples/api / early registry-server pattern, and at 3,892 req/s with 335 CPU ms per 1,000 requests it costs 28x the CPU of the keep-alive shape for a fifth of the throughput — the fork() and waitpid() overhead dominates once every request pays for a fresh process. Memory tells the same story from a different angle: the mc-forkka PARENT holds 1.3 MB RSS the whole time; the 65 worker processes it fans out to under load sum to 66 MB, against Rust's 3.9 MB (65 threads in one process), Go's 22 MB, or C#'s 118 MB (Kestrel/JIT) — a process-per-connection design pays in per-process baseline (stack, TLS, libSystem's own footprint) what a thread-per-connection or event-loop design does not.

The second HTTP set lands where each runtime's model predicts, one order of magnitude apart in two steps. Node's single-process event loop (node-single) reaches 47% of mc-forkka's keep-alive throughput (56,679 vs 120,177 req/s, ab -k) at 1.4x the CPU per request (17.0 vs 12.5 CPU ms/1k req) — one JS thread against mc-forkka's process-per-connection fan-out. Node's cluster mode (11 processes: 1 primary + os.availableParallelism() = 10 workers sharing the listening socket) closes most of that gap to 75% of the throughput (89,468 req/s) but at 727 MB of combined RSS across those 11 processes and 2.8x the CPU (34.8 ms/1k) — the primary alone stays under 52 MB, the ten workers are where the memory and the CPU go. Rust's axum (0.8, on hyper 1 and a multi-thread tokio runtime) lands inside the same 120k–133k req/s band as mc-forkka and rust-threads (124,042 req/s), between Node's CPU cost and mc's own (16.2 vs 17.0 and 12.5 ms/1k) — a general-purpose async framework paying a little more than a hand-rolled thread-per-connection loop, and about the same as mc's own fork-per-connection shape. The four servers with no compiled runtime underneath the request path — py-uvicorn, rb-webrick, rb-puma, php-builtin — sit an order of magnitude below that band (5,030–17,094 req/s) at 3 to 16x the CPU per request (45.3–195.0 ms/1k against mc-forkka's 12.5). py-stdlib's ab -k run failed outright — 0 requests completed in warm-up on all three attempts, the same ThreadingHTTPServer that its own no-keep-alive run (5,722 req/s) and its oha keep-alive run (13,280 req/s) both completed without incident, so the failure is specific to that combination of ab and the server, not to keep-alive itself (../bench/http2/RESULTS.md § Notes).

What is not measured, and is not comparable #

• No floating-point workload. <float> is a library, not core (f32/f64 via type_new + a derived machine, surface.md § M24); neither benchmark here exercises it.
• No GC-pressure test. mc allocates nothing itself (no core allocator); Go and C# pay a GC under sustained allocation that a pointer-free integer workload never triggers.
• No I/O-bound test beyond the HTTP servers, and those are all GET / returning a fixed 13-byte body — no database, no disk, no JSON parsing.
• One host, one architecture (Apple M4 / arm64). mc also targets x86_64 (macOS via Rosetta is not tested; Linux/Windows x86_64 are supported build targets — machine_x86_64.mc — but not benchmarked here) and RISC-V/AVR bare metal, none measured in this pass.
• The second HTTP set (Node single-process and cluster, Rust axum, Python, Ruby, PHP) is now merged into the tables above and read in § Reading the numbers. Its full method, environment and every command run are in ../bench/http2/RESULTS.md; the sources are in ../bench/http2/.
• The soak (§ "The hour under load") only ran once, on 2026-09-06, and py-uvicorn is not in it. A single hour is one data point, not a trend line across runs; a GitHub-hosted runner is shared hardware (../bench/README.md § "The runner caveat"), so a second hour on a different day could move the noisier rows (Go's +2.0 KiB/min, R²=0.08 is noise by its own fit). py-uvicorn's row is a workflow defect (UVICORN_VERSION colliding with uvicorn's own click auto-envvar prefix), now fixed; its hour has not been re-run.
• No connection churn. The soak holds 16 keep-alive connections open for the whole hour (--disable-keepalive exists as an option and was not used this run); a server's behaviour under connections opening and closing continuously — the shape a real front end sees — is untested.
• The soak's hour is still short next to a service's uptime. php-builtin's slope (+8,437.6 KiB/min) would exhaust a small container's memory in well under a day; whether the other drifted rows (Node, C# NativeAOT) are heading somewhere similar or asymptoting is a question a longer window would answer and this one does not.

Feature matrix #

Facts only — cited to the reference docs for mc, from general knowledge of each language's current version elsewhere (../bench/RESULTS.md § D has the full row-by-row citations; this is the summary).

Where to improve #

Ranked by what it buys. Item 1 is now MEASURED and largely DONE; the rest are estimates, and each links to the milestone that would carry it in plan.md.

1. A register allocator, a peephole and loop-invariant hoisting — done, measured, 1.30x. This was the single biggest lever on the one gap this page shows, and M49 took it: mc -O allocates x19..x28 to locals and parameters by weighted use count, fuses cmp/cset/branch into one b.<cond>, and materialises a loop's invariant constants and global addresses once at function entry. Measured on this workload and this host: 0.548 s against clang -O2's 0.420 s, 1.30x, with the arithmetic phase at parity — against the 2.2x the default road shows and against the "estimated target: within 1.3x" this item used to carry as a guess. What is still open and still an estimate: inlining and constant propagation as pass()-level AST rewrites (deferred by M49 § 10 with its own spec and its own measurement first, and worth 0 on this workload — fib's gap is clang's recursion-to-loop rewrite, which inlining does not reach). The x86-64 machines have the same allocator since M49 step D2, and M50's cell gave it its first timing: 19–21% on the mix phase, against 130–265% on AArch64, because it allocates five registers there (rbx, r12..r15) against AArch64's ten — so mc -O is 1.45x clang -O2 on that phase on ubuntu-latest (§ "The same workload in the cell"). Whether the two registers Win64 makes callee-saved (rdi, rsi) are worth adding is now a question with a measurement in front of it, which is what M49 § 12 risk 11 was waiting for. See plan.md § M49 and guide/15-optimizing.md.
2. A reproducible bench cell — done (M50). One GitHub Actions job per toolchain on three cells, every version pinned in one file, a release tarball whose .sha256 is verified before unpacking, the SHA-256 of every binary timed, and each run committed as dated JSON under bench/results/ so a regression is a git blame. It replaced both caveats the § Conditions block used to carry. The plan row's bench/Dockerfile-on-a-fixed-VPS shape was measured against and refused — the VPS is production and is itself a shared VM, and Actions is the only road with both architectures — and is kept priced as an option for a road off GitHub. See plan.md § M50 and specs/M50.md.
3. A bundled <http> library with the fork-per-connection-with-keep-alive shape (mc-forkka above) as an #include <http> away, with an event-loop shape to follow once one exists, so a program gets the 120k-req/s band by including a library instead of hand-rolling sockets — and so the registry server itself (minicompiler/mc-registry) can move off its current fork-per-request shape onto it. The registry server's own migration is minicompiler/mc-registry's work, not this repository's — this repository only owns the library. See plan.md § M51.
4. The LSP, the debugger, and the rest of the feature matrix's blanks the plan already names: mc lsp (M28), DWARF + lldb (M30), and the register-allocator work above is itself a prerequisite this page did not know it had until it was measured.

Edit this page