Performance
⚠️ Every number on this page names the machine it came from, and none of it is something you can currently reproduce yourself. clockwright is distributed as a compiled artifact (see Installation) — there is no public build of the engine, and the cross-engine comparison below was produced inside the private development environment against two other engines fetched for that purpose. Treat everything here as self-reported context for planning, not as a benchmark you can rerun and check. If you need a number you can stand behind, time your own models with your own build on your own hardware — that is the only figure in this space that is fully yours.
The machine
All figures below were measured on one AMD Ryzen 7 7840U (Zen 4, 8 cores / 16 threads, 16 MiB L3) — a 15–28 W mobile part — and single-threaded, with one exception: what a question costs runs a question's replications across all 16 threads, because that is how a question is answered. An all-core figure from a part like this partly measures its thermal limit rather than the engine, so that section says so beside its numbers. A number produced on different hardware is not comparable to anything on this page.
cwright run, compare and propose execute replications concurrently by default — the
replication streams are independent by construction, so the answer is identical whether one core
or sixteen produce it, and only the wall time changes. ⚠️ Every other figure on this page is
single-threaded on purpose, because that is what makes them comparable to each other and to the
other engines measured here. Use --threads 1 to reproduce them.
Throughput
| workload | events/sec |
|---|---|
| PHOLD, 4,000 resident logical processes | 8.9 million |
| one simulated SMT2020 fab-year: 105 tool groups, 1,043 tools, about 35 million events | 12.6 seconds wall-clock |
The fab figure is the median of three cwright simulate --replication 0 runs of SMT2020 dataset 1
— one warm-up year and one reported year, 25.25 s in all (24.64, 25.25, 25.73) — measured
2026-10-09 at 0cfe35b, with a review running alongside. Each run simulated the full 730 days,
released the 20,877 lots the dataset's order file declares and completed 20,617. ⚠️ An earlier
version of this row read "8–12 seconds" and "70–110 million events": that was the prediction
made before the fab ran, not a measurement of it.
What a question costs
One question about a variant is one cwright run with 8 replications, which run across all
16 threads — ⚠️ the one figure on this page that is not single-threaded, because it is how a
question is actually answered. Median wall-clock, measured 2026-10-09 at b0892ca, the two models
interleaved:
| model | size | one what-if, 8 replications | 1,000 what-ifs |
|---|---|---|---|
examples/wafer-fab.yaml (.json at b0892ca, the same model hash) | 7 tool groups, 11 machines, 100 days | 0.020 s | about 20 seconds |
| SMT2020 dataset 1 | 105 tool groups, 1,043 tools, 2 years | 32.3 s | about 9 hours |
The fab's three runs read 31.0, 32.3 and 33.7 s, rising with each round: the thermal limit the machine section above warns about, and the reason the figure is a median.
Against other engines
M/M/3 with 200,000 customers, compared against kalasim and salabim — two mature, independently written engines. All four configurations are gated on the Erlang C closed-form answer for mean wait before any timing is reported: a broken model that does less work runs faster, and a comparison that only measured wall-clock time without checking correctness first could not tell the difference between a fast engine and a broken one.
| median seconds | customers/sec | relative | |
|---|---|---|---|
| clockwright | 0.076 | 2,626,605 | — |
| kalasim, tracing off | 1.827 | 109,469 | 24× slower |
| kalasim, tracing on (its default) | 5.774 | 34,638 | 76× slower |
| salabim | 32.610 | 6,133 | 428× slower |
⚠️ Read this table with three caveats, all of which argue against clockwright rather than for it:
- clockwright's figure includes process startup, reading the model document from disk, and validating it. The other two engines' figures do not include an equivalent step.
- The comparison against salabim is largely a language comparison, not an engine-design one. salabim runs on CPython; clockwright is a compiled binary. Most of that 428× gap is the language, not the architecture.
- kalasim and salabim buy something clockwright deliberately gives up. Both let you write a simulated process as ordinary straight-line code — a coroutine or generator that suspends and resumes. clockwright's processes are explicit state machines instead, which is markedly less pleasant to write, and is the price of being checkpointable at all (see Architecture) — a language continuation cannot be serialised, so a coroutine-based engine cannot survive a restart mid-replication the way clockwright is built to.
⚠️ This is one model. M/M/3 is a small, simple queue, and the table above is a single data point rather than a general claim about relative engine speed — it grows as the comparison does.
Next
- Validation & known limitations — the correctness checks these benchmarks were gated on, and where the engine's accuracy currently falls short.
- Architecture — why the event list and the state-machine design behind these numbers look the way they do.