One comparison per capability: this library against the library a reader would otherwise reach for, with that library's version, the machine the pair ran on and the window the run took. Both sides are checked to return the same answers before either is timed — the agreement checks, the corpora and every command are bench/README.md's subject, and this page carries only what came out.

A before/after of this repository's own code is not here. It is an argument about one commit, and it belongs in the pull request that made it.

• A ratio above 1 means this library is faster, unless the table's own header says otherwise; each table states its direction.
• A named machine is not a shared runner. Every row below names the processor, the operating system and the runtime it ran on. Where a row comes from a hosted runner or a session container it says so, and is read as a ratio: such a machine's absolutes are not comparable between nights, or with another machine's.
• A cross-language row is processor time as well as wall time where the Python side can use more than one core, because a wall-clock lead over a multi-threaded reference is a different claim from a lead per core.
• Every baseline here is single-threaded unless the row says otherwise.

Levenshtein.Distance against rapidfuzz 3.14.6 on Python 3.12, through the cross-language harness over bench/corpus/pairs.json — the same committed corpus and the same ns/pair methodology on both sides. Method, corpora and which bucket reaches which kernel: bench/README.md.

Machine: AMD Ryzen 7 8700G w/ Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores (BenchmarkDotNet's own header), Ubuntu 26.04.1 LTS, .NET SDK 10.0.401, .NET 10.0.12 runtime, AVX-512. Window: one harness run per side on 2026-09-14.

Ahead on both alphabets at both lengths. The Latin buckets take Myers' blocked kernel two words at a time; the CJK buckets leave Latin-1 once their affixes are trimmed — 993 of 1,000 pairs at 128 and all 1,000 at 512 — and take the row-major kernel with the side table that carries symbols above U+00FF. Buckets of 8 and 64 do not reach the blocked kernel at all; at those lengths rapidfuzz pays per-call interop overhead and this package is further ahead.

Indel is len(a) + len(b) - 2·LCS, so what runs is Lcs.SubsequenceLength — and that is also what fuzz.ratio, every process.extract and every blocking deduplication pass runs. Same corpus, same harness and the same rapidfuzz 3.14.6 as the table above.

Machine: the AMD Ryzen 7 8700G named above. Window: the harness's compare-indel, one run per side on 2026-09-13, the C# side published once over three rounds; the range below is the three rounds' spread.

Latin 512 is the one row behind, and what it pays there is the four-word group's stored carry and the equality table's clear; the CJK rows, which take a different route, are ahead by more the longer the input gets.

Machine: AMD Ryzen 7 8700G w/ Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores (BenchmarkDotNet's own header), Ubuntu 26.04.1 LTS, .NET SDK 10.0.401, .NET 10.0.12 runtime, AVX-512. Window: BenchmarkDotNet 0.14.0, default job, 2026-09-14, one run per class. The class and its agreement check: bench/README.md section 15.

This is not like-for-like, and section 15 of bench/README.md counts the difference. FeaturizeText adds character n-grams, so it produces 70,307 non-zero features at 200 documents where this package stores 7,996, and 351,217 at 1,000 against 39,974. Per non-zero feature produced, that is 0.63 μs against 0.41 μs at 200 documents, ML.NET ahead, and 0.56 μs against 0.69 μs at 1,000. The claim is the sparse representation, not a faster kernel.

Bm25Index against LuceneSharp.Core 26.8.4415's BM25Similarity, by Bm25Benchmarks: one query term, the top ten, over a seeded corpus of 500 terms and 40 tokens a document. Method: bench/README.md section 21.

Both sides return the same ten documents in the same order, checked at 1,000 and at 20,000 documents before either was timed. This package's K1 is 1.5 and Lucene's 1.2; with one term and documents of equal length the ranking follows the term's frequency alone, whatever K1 is.

Machine: AMD Ryzen 7 8700G w/ Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores (BenchmarkDotNet's own header), Ubuntu 26.04.1 LTS, .NET SDK 10.0.401, .NET 10.0.12 runtime, AVX-512. Window: BenchmarkDotNet 0.14.0, default job, 2026-09-14 — the query rows from the run that measured both sides after #751 replaced Top's sort with a bounded heap, the text-to-ranking rows from the run before it, which that change does not touch because the row is the vectorizer's.

The query splits by size. What is left at 20,000 documents is the pass over every document's score, 20,000 comparisons against the heap's root; Lucene never reads a document without the term, and skips postings blocks whose best score cannot enter its top ten, as its design has it. The query no longer allocates in proportion to the corpus.

The text-to-ranking row is the vectorizer's, not the index's. Each phase, split with a Stopwatch on the same machine and corpus, lowest of several runs:

For a caller who already holds the matrix — one who has vectorized for something else, TF-IDF or a classifier — building Bm25Index and answering q queries costs 0.36 ms + 1.22 μs·q at 1,000 documents against Lucene's 4.45 ms + 1.94 μs·q, cheaper at every q. At 20,000 documents it is 3.23 ms + 15.2 μs·q against 86.3 ms + 10.6 μs·q, which crosses near 18,000 queries. From text Lucene stays ahead from the first query. These crossings mix Stopwatch build figures with BenchmarkDotNet query figures, so read them as orders of magnitude.

No .NET package publishes a BK-tree, so the alternative is the loop a caller would otherwise write: BkTreeBenchmarks.LengthFilteredScan, a linear scan that skips any word whose length already rules it out, then calls Levenshtein.Distance on what survives. Both arms materialise and sort the same shape of result — a List<BkTreeMatch> ordered by distance ascending — so neither pays a cost the other is exempt from. 20,000 words per shape, 200 queries drawn from the corpus. Building the tree runs in [GlobalSetup], which BenchmarkDotNet excludes from every measured iteration: the scan has no structure to build, so a reader weighing the k = 1 win should price the build in separately.

python3 bench/corpus/generate_dictionary.py
dotnet run -c Release --project bench/Lodestar.Text.Benchmarks -- --filter '*BkTree*'

Machine: 4-core Intel Xeon Processor @ 2.10GHz (BenchmarkDotNet's own header; the physical CPU behind this virtualized host is not otherwise identified), Ubuntu 24.04.4 LTS, .NET SDK 10.0.111, .NET 10.0.11 runtime — a hosted session container, not a dedicated benchmark machine, so these ratios are directional rather than exact. Window: one BenchmarkDotNet run, default job, 2026-09-02, no other load on the container, 6 min 16 s across 16 benchmarks.

Ratio is Mean(TreeWithinDistance) / Mean(LengthFilteredScan), BenchmarkDotNet's own baseline column: below 1 the tree is faster, above 1 it is slower than never having built it. Only the k = 1 rows are below 1, and the gap widens with radius rather than closing — 0.52/0.59 (uniform/clustered) at k = 1 against 1.79/1.74 at k = 4.

Pruning is not the whole cost. An instrumented run in the same window counted raw distance computations, tree over scan, at 0.33/0.34 (k = 1), 0.79/0.86, 0.92/0.95 and 0.96/0.93 (k = 4): the tree does compute fewer distances at every radius. What that count cannot see is per-node traversal — a Dictionary<int, Node> lookup, a Stack<Node> push and a call through the stored Func<string, string, int> metric delegate, against the scan's one array read and one integer subtraction through a static method the JIT inlines. That fixed cost is cheap at k = 1, where the tree visits a third as many nodes as the scan has candidates, and dominates from k = 2, where it visits most of the corpus one node at a time instead of one array element at a time.

The allocation column carries the same story: the tree starts at 3.81× to 4.88× the scan at k = 1, where a Stack<Node> costs more than a 20-word hit list, and falls to 1.41× to 1.44× by k = 4 as the shared result list comes to dominate both sides. docs/guides/dictionary-lookup.md carries the reader-facing version: the tree is worth using at k = 1, and a length-filtered scan is the better answer past it.

Machine: AMD Ryzen 7 8700G w/ Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores (BenchmarkDotNet's own header), Ubuntu 26.04.1 LTS, .NET SDK 10.0.401, .NET 10.0.12 runtime, AVX-512. Window: BenchmarkDotNet 0.14.0, default job, 2026-09-14, one run per class. The class and its agreement check: bench/README.md section 15.

Ahead of all three at every length: 2.8× to 4.1× against Quickenshtein, the closest, and 2.9× to 63.8× against the other two. Neither Lodestar nor Quickenshtein allocates.

Machine: AMD Ryzen 7 8700G w/ Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores (BenchmarkDotNet's own header), Ubuntu 26.04.1 LTS, .NET SDK 10.0.401, .NET 10.0.12 runtime, AVX-512. Window: BenchmarkDotNet 0.14.0, default job, 2026-09-14, one run per class. The class and its agreement check: bench/README.md section 15.

Ahead on all four, and allocating less on each.

Full method, and the check that both sides return the same ids: bench/README.md.

Machine: AMD Ryzen 7 8700G w/ Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores (BenchmarkDotNet's own header), Ubuntu 26.04.1 LTS, .NET SDK 10.0.401, .NET 10.0.12 runtime, AVX-512. Window: BenchmarkDotNet 0.14.0 runs of TokenizerIncumbentBenchmarks, default job, on 2026-09-13, encoding all 5 000 documents of the corpus per operation. Microsoft.ML.Tokenizers 2.0.0. spiece_30k.model is a unigram model.

Both encoders run ahead of the incumbent, and the ids agree with it over the whole corpus. Each allocates more than the incumbent does: what is left is the result lists, the normalized text and, for WordPiece, the lowercased copy — a matched token is the vocabulary's own string rather than a new one.

Both encoders find every piece starting at a position in one walk of a double-array trie, rather than probing a hash table once per candidate substring.

What the trie costs the loader, which decision 0004 makes the product. Measured with a Stopwatch over the same two vocabularies on the same machine, not by BenchmarkDotNet:

Construction is 6–7 ms warm and about 35 ms on the first call in a process, paid once per tokenizer; where the first call's extra time goes was not measured apart. Reading spiece_30k.model itself takes 14 ms on the same run.

Full method, and the check that both sides return the same ids: bench/README.md.

Machine: AMD Ryzen 7 8700G w/ Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores (BenchmarkDotNet's own header), Ubuntu 26.04.1 LTS, .NET SDK 10.0.401, .NET 10.0.12 runtime, AVX-512. Window: BenchmarkDotNet 0.14.0, default job, on 2026-09-14, of BpeBenchmarks, BpeScalingBenchmarks and TokenizerIncumbentBenchmarks. Every document of the corpus is encoded per operation, with tokenizer_30k_bpe.json's byte-level model. Microsoft.ML.Tokenizers 2.0.0.

Byte-level BPE is 2.57× faster than the incumbent, and 3.36× the cost of this package's own unigram baseline, which is the cheaper model rather than the faster implementation. The ids agree with the incumbent's over the whole corpus. Decision 0005 was taken on these numbers.

The largest single step was a hash function. The merge ranks were a Dictionary<long, int> keyed by the two ids packed into a long, and long.GetHashCode is the exclusive or of the two halves, so every pair whose ids share an exclusive or collided — (1, 2) with (2, 1), (0, 3) among them. An open-addressing table with a Fibonacci hash removed two thirds of what was left.

What compiling the split pattern costs. Matching it over the corpus takes 17 ms interpreted and 5 compiled. Code generation moves to the tokenizer's first encode, about 2 ms, measured with a Stopwatch; building the tokenizer stays at 5 to 6 ms warm either way. The netstandard2.0 build compiles it too, and that cost was not measured on .NET Framework.

One token with no split point, BpeScalingBenchmarks:

The step from 2,048 to 4,096 costs 3.1×, where the others cost about 2×. It is one step, not a curve: a Stopwatch taken further measured each doubling from 4,096 to 32,768 characters at 2.0 to 2.2×.

tensor-primitives (bench/README.md section 14) on the machine below, pinned to one core, three conditions interleaved over five runs of nine. Median of the five medians, in ms, over 10,000 × 384 floats. Ratios above 1 mean TensorPrimitives is faster.

Our kernel is ahead on the kNN pattern at every width, 3–7×, and one long sweep is at parity. Turning the 512-bit path off halves TensorPrimitives' time without changing the direction. Decision 0004 records it against the hosted runner's opposite reading in 0004.

Machine: AMD Ryzen 7 8700G w/ Radeon 780M Graphics, 16 logical and 8 physical cores, Ubuntu 26.04.1 LTS, .NET 10.0.12 runtime. 2026-09-16.

The nightly's compare-persistence of 2026-09-12 has Lodestar at 0.13–0.34× numpy on every uncompressed index row. Most of that is not code on either side: it is whose allocator keeps a freed 15–20 MB block's pages. glibc raises its mmap threshold after the first free of a block that size, so a Harness.Measure loop of np.load refills warm pages; the .NET GC decommits a dead large-object region, so every iteration of the C# loop page-faults its 15 MB again.

Conditions. AMD Ryzen 7 8700G, 8 cores / 16 threads, Ubuntu 26.04.1, .NET 10.0.12, numpy 2.5.3 on Python 3.12, a workstation shared with other sessions under the machine lock, one-minute load average 2.2–4.1. The probes are a Harness.Measure-shaped Stopwatch loop, median of five rounds, and are not BenchmarkDotNet; read their ratios.

Each side, with its allocator's retention turned off or on:

• numpy pays 6.8× on its load the moment its pages are fresh, and a memcpy into a fresh float[] costs 3.7× one into kept pages. A caller who loads one index once pays those faults on both sides; only a loop of loads collects the difference, and the harness is a loop.
• The save rows charge the C# side for the harness's sink. new MemoryStream(indexArtifact.Length) allocates and zeroes 20.6 MB inside the timed window: 3.911 ms of the 4.057 ms embedding_index_save measures here, against 0.568 ms for the whole chunked base64 encode. io.BytesIO() grows on pages glibc kept.
• What remains with retention on both sides is the format's own work, which decision 0001 already prices: a JSON scan of the 20.6 MB document with its 10 000 ids (0.581 ms), a base64 decode (0.760 ms into warm pages), and the finite scan numpy does not promise (0.235 ms). embedding_index_ingest_npy stays the like-for-like row.

Two levers inside that remainder were measured and not taken: a Vector512 exponent-bits finite scan, 0.235 to 0.167 ms, is 1.5% of a load; decoding and scanning in L2-sized slices, 3.711 to 3.655 ms, is noise.

The artifact is base64 inside JSON, which spends eight bits to carry six, so it is about 1.33× the raw block. Deflate takes that back almost exactly — base64 is the one expansion a general-purpose coder undoes perfectly. The question is what the time costs.

Machine: Intel Core i7-4770S, .NET 10.0.10, a synthetic 4,000 × 384 index through the real Save and Load. Window: warmed, median of 7, the five modes interleaved in one window, published 2026-08-20.

The size claim holds exactly: 0.747 × 1.333 = 0.996 of the raw block. Level 9 gives the same bytes as level 6, so there is nothing to tune, and deflate is dominated on all three axes — brotli Fastest is smaller than gzip Optimal and writes it seven times faster.

Against numpy, compressed, from the nightly's own rows at 10,000 × 384 on a hosted runner — ratios only, per that page's warning, since a shared runner's absolutes are not comparable:

• Compressed, this package is ahead of numpy on the write and level with it on the read — 1.40× on savez_compressed, 0.88× coming back. The deflate coder is the same on both sides, so what is compared is what each side hands it.
• Compression closes most of the format gap. Uncompressed the artifact is 1.34× numpy's block, the expansion decision 0001 priced; compressed it is 1.09×.
• The price grows with the artifact, which is the opposite of what would make it worth paying: 0.741× the size for 76.8× the save and 14.8× the load on the corpus, against 37.62× and 5.92× for Optimal on the 8 MB synthetic index. The indexes big enough for 26 % of a disk to matter are the ones where compressing costs most.

dotnet run -c Release --project bench/Lodestar.Text.Benchmarks -- --filter '*BatchEmbedding*' --inProcess

Read this before quoting the ratio. The model is tiny_embedder.onnx: one Gather node over a 64 × 4 table, because weights are never committed (CONTRIBUTING.md) and a real encoder is a hundred megabytes. Its arithmetic is free. So what is measured is the per-sequence cost that batching removes — graph dispatch, thread-pool wake-up, tensor wrapping — and none of the matrix multiplication a real encoder adds to both sides. This is an upper bound on the speed-up, not the speed-up.

Machine: Intel Core i7-4770S (Haswell, 4 physical cores), Ubuntu 24.04, .NET 10.0.10, X64 RyuJIT AVX2. Window: four runs in one window — two per target, alternating — published 2026-08-06; the run's own date was not recorded. Full job, [MemoryDiagnoser], InProcessEmitToolchain. Corpus of 1 to 61 words per text, sub-batch 8. UnitLoop is the baseline — one Embed call per text, which is what the guide's three lines amounted to before EmbedBatch existed. Two runs, both shown, because BenchmarkDotNet's ± describes dispersion inside one process and not reproducibility across processes.

Batching removes about 40 % of the wall clock from 8 texts upward and stays there — 0.56–0.62 across every pairing — as the per-call overhead is amortized over the whole sub-batch. At a single text there is nothing to amortize and the two paths are a wash: 1.06 in one run, 0.99 in the next, which is a way of saying this benchmark cannot tell them apart there rather than that either wins.

Bucketing is a different story, and the honest answer is smaller. It engages only when the corpus spans more than one sub-batch, so the rows at 1 and 8 above run the identical code in both columns — they are the control, and what they differ by is this harness's noise floor: 1–3 % on seven of the eight control measurements taken here, with one outlier at 5.7 %. At 128 texts bucketing is ahead by 5.8–7.5 % in all four pairings, and ahead at 32 in all four as well. The sign is consistent where the magnitude alone would not be decisive. What is decisive is the allocation column, which is counted rather than sampled: 1 764 KB → 1 697 KB at 128 texts, in every run. That is padding genuinely not written. On a model doing real work that padding would be matrix multiplication not performed, and the time would follow; this model cannot show it, so the claim stops here.

The two builds are level here, and that is the structurally correct answer. The same benchmark against the netstandard2.0 assemblies puts that side 1.4–5.7 % ahead of net10 in all four pairings (355 / 365 µs against 360 / 381 at 32 texts; 1 418 / 1 419 against 1 482 / 1 460 at 128) — inside the harness's noise, but consistent in direction. Pooling guards its Vector<T> branch with accumulator.Length >= Vector<float>.Count, and tiny_embedder.onnx has a hidden size of 4 (EMBEDDING_DIM in tools/build_tiny_models.py) against Vector<float>.Count of 8 under AVX2, so on net10 the guard is false and both builds run the same scalar tail loop. This benchmark cannot resolve a difference between the targets, and reports that instead of a number. Where the vector path does engage it is worth 4×–7×, in VectorMath over 384–1024 dimensions (bench/README.md section 2). The one difference it does resolve is counted rather than timed: the unit-loop path allocates 0.6 % more on netstandard2.0 (1 887 KB against 1 875 at 128 texts), identically in both runs, while the two batch paths allocate byte for byte the same on both targets.

dotnet run -c Release --project bench/Lodestar.NetStandard.Benchmarks -- --filter '*BatchEmbedding*'

--inProcess on the first command and not on the second is the point. The netstandard2.0 project pins InProcessEmitToolchain in its Program.cs — it has to, or BenchmarkDotNet's generated project re-resolves the ProjectReference and silently restores the net10.0 build — so the flag is what puts the net10 side on the same toolchain. Without it the two commands measure the same code two different ways.

Conditions. The four runs behind the table were taken back to back in one window, alternating net10 and netstandard2.0, with the one-minute load average between 5.1 and 5.9 on 8 logical cores — the editor's language servers and the session driving the runs are part of that load and cannot be excluded from inside it. Both columns pay it equally, so the table is internally comparable; it is not comparable to figures taken on this machine in a quieter state, and the ratios travel between such sets while the absolute microseconds do not.

python bench/corpus/generate_metrics.py           # writes bench/corpus/metrics/, git-ignored
.venv-oracles/bin/activate && python bench/python/bench_metrics.py
dotnet run -c Release --project bench/Lodestar.Text.Benchmarks -- compare-metrics
python bench/compare.py metrics

Six operations — confusion_matrix, accuracy, precision_recall_f1_macro, classification_report, roc_auc_binary, roc_auc_ovr_macro — over six shapes (1 000 / 100 000 / 1 000 000 samples, 2 or 10 classes), on the same corpus files on both sides. This is the merge gate for the branch, on processor time: every row must be ≥ 1×, and it is.

Machine: Intel Core i7-4770S, .NET 10.0.10, against scikit-learn 1.9.0 / NumPy 2.5.1 on Python 3.12.3. Window: one run per side, published 2026-08-06. Both sides measured back to back, Python first, on a machine left to settle (one-minute load 1.52 at the Python start — below this workstation's 1.9–2.3 floor, itself a permanent ~30–40 % background from the desktop client, an editor and a browser). The C# side started 49 seconds later, in the Python run's own wake, so its figures are the ones taken on the busier machine and every ratio below is conservative rather than flattering; bench/README.md records the full conditions.

Gate result: 29/29 operations at or above 1× on processor time. The narrowest margin is 2.74×, on roc_auc_ovr_macro at n=100 000, k=10 — the row the design brief flagged as the one most likely to need a radix-sort rewrite of BinaryRoc. It did not: even the heaviest sort-bound row clears the gate by a comfortable margin, so no algorithmic change was needed on this branch.

Read this before quoting a single ratio. The rows at n=1 000 (70×–620×) are dominated by CPython's per-call interpreter overhead, not by the computation — a confusion matrix over 1 000 samples is sub-microsecond work on either side. The rows that carry the argument are the ones at n=100 000 and n=1 000 000, where the ratios settle to a more modest but still decisive 2.7×–43×.

Unlike the persistence comparison, wall and processor time agree here to within about 1% on every row (up to 3.4% on the single heaviest-cpu row): these metrics allocate little enough per call that .NET's background collector is never a factor, so there is no gap between the two columns to explain away.

Full breakdown, including the intra-C# and net10-vs-netstandard2.0 tiers and where the two language sides do not do identical work, in bench/README.md.

Balanced accuracy, Matthews correlation and Cohen's kappa (issue #93, Tasks 3–5) add three operations — balanced_accuracy, matthews, cohen_kappa — run over all six shapes above, unweighted and with default label handling on both sides, matching scikit-learn's balanced_accuracy_score, matthews_corrcoef and cohen_kappa_score. Same corpus files, same harnesses, same methodology as the table above — but measured in a separate window from the original 29 rows, with its own load: uptime's one-minute average was 19.70 just before the Python side started and 7.65 by the time compare.py printed the numbers below (fifteen-minute average 13.2–14.9 throughout that window). That is nowhere near the 1.52 one-minute load the paragraph above states for the original run, so these 18 rows should not be read as sharing that sentence's conditions — only their own, given here.

18/18 at or above 1× on processor time — the gate holds for these three metrics too. The two narrowest are balanced_accuracy_n1000000_k10 at 16.59× and cohen_kappa_n1000000_k10 at 16.87×; every other row clears 17×. As with the original 29, the busier the machine gets, the more conservative (not flattering) a ratio above 1× is — and this window's load average was roughly 5–13× the original run's, so these margins are, if anything, understated relative to a quiet machine.

The eleven regression metrics landed for issue #92 add four benchmark operations — mse, mae, median_ae, r2 — covering the four distinct cost shapes among them: a squared mean, an absolute mean, a sort, and a two-pass centred sum. The other seven metrics are one of those four with a different arithmetic kernel and are not separately timed. They run over y_true_real/y_pred_real, continuous targets drawn by a separate seeded random generator and attached to each of the six existing corpus shapes, independent of the classification columns those shapes already carry. The generator inserting these draws would otherwise have shifted every classification array after the insertion point, invalidating the 29 and 18 rows above. A before/after comparison of y_true[:10] on the regenerated corpus confirmed it did not. Same corpus files, same harnesses, same methodology as the tables above — but measured in yet another separate window, with its own load: uptime's one-minute average was 8.05 just before the Python side started (five/fifteen-minute: 11.95 / 14.25) and 6.05 by the time compare.py printed the numbers below (five/fifteen-minute: 7.15 / 11.07). That is well below the 16–23 one-minute load this session saw at dispatch and while the code changes were being made, but still noticeably busier than the 1.52 one-minute load recorded for the original 29 rows. So these 24 rows should be read only under their own conditions, given here — except the six median_ae rows marked †. Those come from a later window described below, after MedianAbsoluteError's unweighted path was rewritten.

Read the k suffix as a corpus file name, not as a workload. The regression arrays are drawn from SeededRandom(SEED + 1_000 + n), which depends on the sample count and not on the class count, so metrics_n1000_k2 and metrics_n1000_k10 carry byte-identical y_true_real. That is deliberate — all four operations here are single-output, and k is a property of the classification columns those files also hold — but it means the 24 rows below are 12 distinct workloads, each measured twice. The pairs are useful for exactly that: they bound the run-to-run spread. At n=1 000 000 the two members agree to within 0.04× (mse 1.04× / 1.00×), while at n=1 000 the same identical array gives 98.88× and 141.17× — a 43 % spread, which is what a sub-millisecond mse measurement is worth on a machine at this load, and the reason no conclusion on this page rests on an n=1 000 row.

† The six median_ae rows were measured after WeightedPercentile's unweighted branch stopped sorting the whole residual array, in a separate window from the other eighteen rows and under a deliberately comparable load (one-minute average 6.62 falling to 6.52, against the table's own 8.05 to 6.05). They are superseded: #140 took a further 38 % off median_ae at n = 1 000 000, so these rows measure a partition this package no longer ships and the current one has not been re-measured against scikit-learn.

‡ The four r2 rows predate #127: they measure the original sequential-sum R2, not the Neumaier-compensated one this package ships, and are kept only so the pairing this table relies on stays intact.

20 of 24 rows at or above 1× on processor time, which under the pairing above is 10 of 12 distinct workloads. The four below the gate are median_ae at n = 100 000 and n = 1 000 000 — 0.80× to 0.90× — and the cause is algorithmic rather than a run: scikit-learn's median_absolute_error calls NumPy's median, which selects by introselect in expected O(n). This package now selects the one or two order statistics the median needs with a median-of-three quickselect, falling back to Array.Sort on the remaining range once partitioning exceeds a budget proportional to log2(n) — the same worst-case guarantee NumPy relies on — so the two do the same order of work and what is left reads as constant overhead: managed bounds checks, the Lomuto partition's extra writes, no SIMD comparison loop. mse_n1000000_k10 is the narrowest passing row at 1.00×, near enough to parity that a busier or quieter machine could tip it either way.

Machine: AMD Ryzen 7 8700G w/ Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores (BenchmarkDotNet's own header), Ubuntu 26.04.1 LTS, .NET SDK 10.0.401, .NET 10.0.12 runtime, AVX-512. Window: BenchmarkDotNet 0.14.0, default job, 2026-09-14, one run per class. The class and its agreement check: bench/README.md section 15.

Ahead on every row, by less as the sample grows: 4.84× at 100,000 samples to 1.57× at a million for the full bundle. ML.NET computes the bundle whatever is asked, so accuracy alone costs a caller the six.

Machine: AMD Ryzen 7 8700G w/ Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores (BenchmarkDotNet's own header), Ubuntu 26.04.1 LTS, .NET SDK 10.0.401, .NET 10.0.12 runtime, AVX-512. Window: BenchmarkDotNet 0.14.0, default job, 2026-09-14, one run per class. The class and its agreement check: bench/README.md section 15, and the decomposition class in section 16.

A 2,000 × 500 term-document matrix at 2% density, rank 20:

ML.NET's PCA is 1.18× faster, and it is a different decomposition: centred and dense against uncentred and sparse. Section 16 of bench/README.md says what is checked instead of agreement, and decision 0004 why the gap that matters is the explained variance, which ML.NET does not report.

Full method and what the pair does and does not compare: bench/README.md.

Machine: AMD Ryzen 7 8700G w/ Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores (BenchmarkDotNet's own header), Ubuntu 26.04.1 LTS, .NET SDK 10.0.401, .NET 10.0.12 runtime, AVX-512. Window: one BenchmarkDotNet run, default job, on 2026-09-13, 8 benchmarks. NumFlat 1.3.4. Both sides were checked to return the same spectrum before either was timed.

This package is faster on three shapes of four and slower on one, while NumFlat's row also computes the eigenvectors and the mean. The one it loses is the one where the eigen solve dominates: 50 × 50 is where a one-sided Jacobi, several sweeps of O(p³), falls behind a tridiagonal solver. At 10 columns the Gram matrix is most of the work, and centring each row into a buffer of one row's width keeps it in cache.

The wide block is solved through the 100 × 100 Gram matrix of its rows rather than the 200 × 200 one of its columns, which is where the 1.19 and half the allocation come from.

The path to these numbers is in decision 0003: a Jacobi solve over the whole centred block measured 13× slower than NumFlat at 2,000 × 50 before the Gram route replaced it. Below net8.0 the second row is Meta.Numerics: NumFlat does not install there and ML.NET reports no eigenvalue, and its section has the numbers.

Full method, the two classes and why only one is like-for-like: bench/README.md.

Machine: AMD Ryzen 7 8700G w/ Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores (BenchmarkDotNet's own header), Ubuntu 26.04.1 LTS, .NET SDK 10.0.401, .NET 10.0.12 runtime, AVX-512. Window: one BenchmarkDotNet 0.14.0 run, default job, on 2026-09-14, 15 benchmarks. NumFlat 1.3.4, Meta.Numerics 4.2.0. Every pair was checked to return the same centres before either side was timed; the largest difference was zero.

Lloyd's iterations from the same centres — the like-for-like pair:

This package is ahead on every shape, 1.52× to 3.66×, and allocates more on the two wider ones: its current and previous labels are one int per row each, 80 KB at 10,000 rows, where NumFlat's allocation grows with the iteration count instead — which is why the 101-iteration row is level.

A whole fit, k-means++ included, under each library's own stopping rule:

Read this table as what a caller pays, not as a kernel ratio. On these well-separated blobs scikit-learn's scaled tolerance stops this package after one or two iterations, and neither incumbent reports how many it ran. The second table is the one that compares arithmetic; this one says that a default fit here is 4× to 20× cheaper, and part of that is when it decides to stop.

Meta.Numerics is the comparison that holds below net8.0, and the only one: NumFlat does not install there.

Full method, the two classes and what the agreement check refused: bench/README.md.

Machine: AMD Ryzen 7 8700G w/ Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores (BenchmarkDotNet's own header), Ubuntu 26.04.1 LTS, .NET 10.0.12 runtime, AVX-512. Window: one BenchmarkDotNet 0.14.0 run, --job short, on 2026-09-16, 10 benchmarks. NumFlat 1.3.4, Dbscan 3.0.0. Every shape was checked to return the same partition — cluster numbering ignored — on all the libraries in its table before any was timed.

Planar, where all three compete:

Above two features, where only NumFlat follows:

Ahead on every shape, 2.47× to 10.92×, and allocating 2.89× to 5.46× less: 13.98 MB against NumFlat's 66.59 MB and Dbscan's 40.40 MB at 5,000 planar points, 111.97 MB against 531.88 MB and 372.11 MB at 20,000.

Dbscan 3.0.0 has no row in the second table because it has no entry point there. Its Point carries X and Y and nothing else, which is decision 0004's whole argument for writing this class — the gap is reach below net8.0, and the speed is a second finding rather than the claim.

One measured defect in an incumbent, and it is not ours. NumFlat 1.3.4 marks a non-core sample noise permanently when the ascending scan reaches it before any cluster has been grown, where the original algorithm and scikit-learn let a later expansion take it as a border sample. Nine points in one dimension separate them, and at sixteen features with a radius of 3 it costs 1,017 rows of 5,000 — where this package matches scikit-learn exactly. bench/README.md section 48 has the reproducer and the alternative explanation that was tested and refused.

Full method, what was measured before any code and why the benchmark runs on blobs: bench/README.md.

Machine: AMD Ryzen 7 8700G w/ Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores (BenchmarkDotNet's own header), Ubuntu 26.04.1 LTS, .NET 10.0.12 runtime, AVX-512. Window: one BenchmarkDotNet 0.14.0 run, --job short, on 2026-09-16, 16 benchmarks, with nothing else running — a first run that shared the machine with the oracle generator was discarded. Aglomera 1.1.1. Every combination was checked to return the same merge heights in order, and the same partition at the cut, before either side was timed.

Ahead on every row, 24× to 590×, and the gap widens with the sample count — the three nearest-neighbour-chain linkages go from 24–31× at 500 to 64–71× at 1,500. Single linkage holds no distance matrix at all, 185 KB where Aglomera allocates 733 MB.

These rows are the only ones where the comparison is fair. Blobs have no tied merge heights; on data that does, Aglomera breaks ties the other way and can build a different tree, and its Ward height is reported as d²/2. The speed is a second finding — the reason this class exists is that Aglomera's answer is not scikit-learn's.

Full method and what cannot be made to agree: bench/README.md. Machine: the AMD Ryzen 7 8700G named above, on 2026-09-16. BenchmarkDotNet 0.14.0, default job, one run. Five folds, three classes at 60 / 30 / 10.

ML.NET's split is lazy, so it appears twice: the call, and the call followed by reading which rows each fold holds. Only the second is a split a caller can fit on, and it is the one that scales with the data — the construction is flat in the row count because it builds ten wrappers and stops.

Stratifying costs 136.77 μs at 10,000 rows and 1,489.37 μs at 100,000 — 2.6× and 2.1× the plain fold cut. ML.NET has no row to compare it against: CrossValidationSplit and TrainTestSplit never stratify (dotnet/machinelearning#4396, open since 2019).

Allocation, per operation: 273.94 KB against ML.NET's 149.07 KB at 10,000 rows for the fold cut — this returns every index of every fold, where ML.NET returns views that allocate again on each read, so the two columns count different things and the larger one is the one holding the answer.

Against scikit-learn 1.9.0 through compare-splitters, one run of each side, milliseconds per split, best of five:

The million-row rows move about ±20% run to run on this machine — KFold there read 10.0 ms once and 12.0 to 12.4 ms in the four runs after, on unchanged code. The ratios below 100,000 rows are stable to the third decimal across every run.

TrainTest writes the two index halves straight out: an identity read comes out ascending already, so neither half is sorted and no order array is filled.

Full method, and why fixZero: false is passed: bench/README.md. Machine: the AMD Ryzen 7 8700G named above, on 2026-09-16. BenchmarkDotNet 0.14.0, one invocation per iteration, five warmups and twenty iterations. Ten features per row; ML.NET's estimator is lazy, so it appears both as a fit and as a fit whose values are read back.

MaxAbsScaler costs 65.21 μs and 1,116.54 μs at the two sizes and has no ML.NET row: its normalizers offer mean-variance, min-max, log-mean-variance, robust scaling, binning and L_p norm, and none of them is "divide by the largest absolute value" — NormalizeMinMax(fixZero: true) comes closest and is a different transform.

Both sides scale the same column to the same values, checked row by row to 1e-6 before either was timed — single precision, which is what ML.NET's pipeline carries.

Where the cost is. RobustScaler is about nine times MinMaxScaler here and allocates twice as much: a percentile has to order its column, so it sorts each feature once where the other two take a single pass. numpy.percentile partitions rather than sorting, which is the same asymptotic work with smaller constants and is where to look if that row ever needs to be cheaper. Allocation, at 20,000 rows: 1,563.96 KB for min-max against ML.NET's 1,133.80 KB, and 3,126.26 KB for robust against 4,821.33 KB.

Full method, and the shape that had to be corrected first: bench/README.md. Machine: the AMD Ryzen 7 8700G named above, on 2026-09-16. BenchmarkDotNet 0.14.0, one invocation per iteration, five warmups and twenty iterations. Twenty categories; ML.NET's estimator is lazy, so it appears as a fit and as a fit whose values are read back.

Encoders.Ordinal costs 133.73 μs and 2,875.13 μs at the two sizes — about three quarters of the one-hot encoding, at a tenth of the allocation (16.70 KB against 165.24 KB at 1,000 rows), since it produces one column rather than one per category. ML.NET's MapValueToKey is its counterpart and is not measured here: it maps to a key type inside the pipeline rather than to a number a caller holds.

The correction, stated because the first table was wrong. OneHotEncoding takes one named column where this package's encoders take a matrix of however many features, so the first run encoded four features here against one there — four times the work for the same row, reported as 2.8× slower at 20,000. One column on both sides is the comparison above. ReplaceMissingValues does take a vector column, so the imputer rows compare four features against four.

Allocation is where the two differ most on the read: 165.24 KB against 413.76 KB at 1,000 rows, and 3,282.43 KB against 1,212.64 KB at 20,000 — this package materialises every encoded column as a double, where ML.NET's cursor yields rows one at a time and never holds the matrix.

Full method, correctness cross-check, and how Accord's 2017-era API names were resolved against the restored package: bench/README.md. This section carries only the numbers, per the rule for where a fact belongs (CLAUDE.md's "Where a fact belongs" table).

Machine: Intel Xeon Processor 2.80GHz, 1 CPU, 4 logical and 4 physical cores (BenchmarkDotNet's own header), Ubuntu 24.04.4 LTS, .NET SDK 10.0.111, .NET 10.0.11 runtime — a hosted session container, not a dedicated benchmark machine, so this row is indicative, not authoritative, the same caveat every other container row in this document carries; docs/guides/performance.md records a case where a container read a full 3× slower than the dedicated machine on the same code, so treat the ratios below as directional rather than exact. Window: one BenchmarkDotNet run, ShortRun job — fewer iterations than the default, exact parameters in bench/README.md — 2026-09-05, no other load on the container during the run; total run time 1 min 51 s across the 12 benchmarks (6 pairs × 2 sample sizes). The short job matters for reading the table: three iterations is enough to see which side is faster by an order of magnitude, as every row below is, and not enough to trust the last digit of a ratio.

Lodestar.Stats is faster on TTest.Independent (30× at 100 samples, narrowing to 3.2× at 10,000, as Accord's fixed per-call overhead is amortised over more work) and on MannWhitney.Test (5.1× at 100, 2.9× at 10,000, allocating 61-62% less at both sizes — both sides take the guarded asymptotic path at 10,000, past MannWhitney's own 20_000-product exact-method bound). Those two MannWhitney rows predate #711, after which the ranking no longer allocates the pooled arrays; that allocation column measures a path this package no longer ships and has not been re-measured against Accord. Accord is faster on ChiSquare.Contingency (roughly 380 ns against 294 ns, flat with sample size since a 2×2 table has four cells regardless of how many observations produced it) — the one family where this package's richer result (Chi2ContingencyResult carries the expected-value table; Accord's ChiSquareTest does not expose one) costs more than it buys at this shape.

The chi-square row has since reversed, on a different machine. The tail reads an integer or half-integer degree of freedom up to 100 as a finite sum rather than iterating the incomplete gamma's continued fraction, and ChiSquare.Contingency reads 66.52 ns at 100 samples and 63.42 ns at 10,000 against Accord's 121.7 ns at both, at 168 B on both sides — AMD Ryzen 7 8700G, Ubuntu 26.04.1 LTS, .NET 10.0.12, BenchmarkDotNet 0.14.0 default job, 2026-09-13, StatsBenchmarks and DistributionTailBenchmarks. Correctness against scipy is unchanged or tighter: 60,001 erfc points over [-6, 27.5] agree to a relative 7e-15, and 22,500 chi2.sf points at 1 to 250 degrees of freedom to 1.7e-13. The two machines are not comparable cell by cell; what is comparable is each run's own pair.

Correctness, not just speed. All three families were checked against scipy on frozen tests/oracles/stats_*.json corpus cases through both implementations; no case disagreed beyond floating-point noise (the last one or two digits of a double, inside the 1e-9 tolerance docs/equivalence.md already uses). bench/README.md has the three cases and the exact figures.

Full method, and the six p-values that differ with their causes: bench/README.md. Machine: the AMD Ryzen 7 8700G named above, on 2026-09-16. BenchmarkDotNet 0.14.0, default job, one run. Meta.Numerics 4.2.0, MS-PL, netstandard2.0.

Eight test families. Ratio above 1 means this package is faster; every statistic was checked to agree before anything was timed.

The Kolmogorov-Smirnov row at n = 10,000 was re-measured on 2026-09-16 after #802 made Auto exact there; it read 1.16 when Auto was asymptotic. The other rows are the original run's.

Two rows were costs in this package rather than differences in what the two libraries compute, and this comparison is what found them. Both are now ahead of Meta.Numerics:

• Fisher walked the hypergeometric probabilities through nine log-gammas per candidate table — three per binomial coefficient — with the denominator recomputed every iteration. Neighbouring probabilities differ by a ratio of four small integers, so the range now costs one exponential and O(range) multiplications, anchored at the mode. Still zero allocation.
• Kolmogorov-Smirnov built an (n+1)×(m+1) table even when the samples are the same size, where D is always a whole number of steps of 1/n and Hodges' exceedance probability is a closed form: O(n) multiplications against O(n·m) cells and n+1 row allocations. Allocation fell from 86,512 B to 1,610 B.

Neither is an approximation, and no default moved. ExactMethod.Auto chooses exactly what it chose before; the exact branch is simply cheaper. The corpus gained an equal-size pair of 100 and a 100-against-99 pair — the second of which must take the table rather than the closed form — and both replay scipy 1.18.1 at 1e-9. This package still returns the exact p-value where Meta.Numerics returns an asymptotic one, and is now faster doing it.

The explained variance. Ratio above 1 means this package is faster.

Both report the same first component's variance fraction, checked to 1e-9 relative before either was timed. Meta.Numerics refuses the fourth shape: 100 rows by 200 features raises InsufficientDataException, where this package and NumFlat both answer — so the wide matrix has no Meta.Numerics row at all rather than a slow one.

Full method, what the pair does and does not compare, and why MathNet.Numerics is not a candidate here: bench/README.md. This section carries only the numbers, per the rule for where a fact belongs (CLAUDE.md's "Where a fact belongs" table).

Machine: AMD Ryzen 7 8700G w/ Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores (BenchmarkDotNet's own header), Ubuntu 26.04.1 LTS, .NET SDK 10.0.112, .NET 10.0.12 runtime — a developer workstation shared with other checkouts of this repository, so this row is indicative, not authoritative. Window: one BenchmarkDotNet run, ShortRun job (IterationCount=3, WarmupCount=3, LaunchCount=1), 2026-09-10; run time 28.65 s across the 4 benchmarks (2 pairs × 2 sample sizes). Four regressors throughout, on a seeded design.

The two rows are not doing the same work, and that is the finding rather than a caveat. Accord.Statistics exports no variance inflation factor anywhere in its 4 796 members — decision 0003's reading established that — so MultipleLinearRegressionAnalysis.Learn performs one solve. OrdinaryLeastSquares.Fit performs five at four regressors: the model, plus one auxiliary regression per regressor for the VIFs, each with its own Householder QR over the full design.

Read that way the numbers are consistent. At 100 rows the fixed per-call overhead dominates and this package is 2.7× faster despite doing five times the factorisation. At 10,000 rows the O(mn²) work dominates instead, and doing it five times costs 1.33× Accord's single solve. The allocation follows the same shape — 1.8× Accord's at both sizes — because each auxiliary regression materialises a standardised copy of the design and its own Q.

So the honest summary is a shape rather than a winner: below roughly a thousand rows this package is faster and returns strictly more; above it, the extra diagnostic is what you are paying for. A caller who does not want VIFs has no way to say so today, and that is the obvious next measurement rather than a defect — the table is one call by design.

Full method, and why the untyped GeneralizedLinearRegression is the one driven: bench/README.md. Accord.Statistics 3.8.0 is archived. Its last package shipped on 2017-10-19 and the repository was archived on 2020-11-18 (docs/migration/README.md). A lead over it is a smaller claim than a lead over a maintained library, and a deficit against it is still a deficit.

Machine: AMD Ryzen 7 8700G w/ Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores (BenchmarkDotNet's own header), Ubuntu 26.04.1 LTS, .NET SDK 10.0.401, .NET 10.0.12 runtime, AVX-512. Window: one BenchmarkDotNet run, default job, on 2026-09-14, 8 benchmarks. A binomial model with a logit link and an intercept, both sides given 100 iterations and a 1e-8 tolerance. The benchmark project builds Lodestar.Stats 0.5.0 from source. Its normal quantile is inverted by Newton (#709) on the erfc docs/guides/performance.md describes. Lodestar.Stats.Regression's published floor, Lodestar.Stats 0.4.0, carries neither yet.

At 200 rows the two are level, and at 2,000 Accord is 1.4× faster. This package allocates less in every cell, by 1.4× to 2.3×.

The 200-row result moved, and one call moved it. On 2026-09-13, before the quantiles stopped bisecting (issue #709), the same cells read 41.19 μs against Accord's 30.33 μs and 71.31 μs against 60.31 μs. The gap was 10.9 and 11.0 μs, flat across the regressor count. That is the one Distributions.NormalQuantile call the intervals need, which Accord's GetWaldTest does not make, and it then cost about 11.5 μs. It now costs 654 ns, and the two 200-row rows fell by 11.7 and 11.9 μs. The 2,000-row rows fell by 14.7 and 24.6 μs, where Accord's control rows moved by 3% to 4% the same way, so part of that is the window.

At 2,000 rows the gap is per iteration, not iteration count. The two stop on different quantities: this package when the absolute change in deviance falls to the tolerance, statsmodels' atol with rtol at zero; Accord's Run when the largest relative change in the coefficients does. On these designs this package stops after 4 iterations and Accord after 4 to 6. So at 2,000 × 1, where both take 4, each of this package's iterations costs about 73 μs against Accord's 53 μs. This run does not attribute that difference. Each iteration here is a Householder factorization of the weighted design, and reading its Q through IReadOnlyList<double> is one cost issue #670 already names.

Both sides return the same fit, and the check that says so is not the timed call. Run once outside BenchmarkDotNet on the same seeded designs:

The coefficients agree at the oracle tolerance under either rule. The standard errors do not under the benchmark's: each side computes its covariance from the IRLS weights of its own last iterate, and the two last iterates differ because the stopping rules do. Tightened, every quantity agrees within 1e-9. What this package computes beyond Accord's coefficients and standard errors — every interval, every p-value, the deviance, the null deviance, the log-likelihood and the AIC — is in the timed call.

Full method and what agrees: bench/README.md.

Machine: AMD Ryzen 7 8700G w/ Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores (BenchmarkDotNet's own header), Ubuntu 26.04.1 LTS, .NET SDK 10.0.401, .NET 10.0.12 runtime, AVX-512. Window: one BenchmarkDotNet 0.14.0 run, default job, on 2026-09-15. MathNet.Numerics 5.0.0, Accord.Statistics 3.8.0. Every pair returned the same slope before it was timed.

Level at 2,000 rows and faster everywhere else, while computing the whole table — Math.NET returns the coefficients alone — and allocating 17× to 32× less.

At 10,000 rows the robust covariances on top of that fit cost 0.628–0.631 ms for HC0 to HC3, and 6.27–6.31 μs at 100 rows (RobustCovarianceBenchmarks).

Full method and what agrees: bench/README.md.

Machine: AMD Ryzen 7 8700G w/ Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores (BenchmarkDotNet's own header), Ubuntu 26.04.1 LTS, .NET SDK 10.0.401, .NET 10.0.12 runtime, AVX-512. Window: BenchmarkDotNet 0.14.0, default job, on 2026-09-15, the run taken after GLS was rebased on the shared least-squares pipeline of #782. MathNet.Numerics 5.0.0. Four regressors and an intercept, AR(1) errors at 0.6; each pair returned the same slope within 1e-9 before it was timed.

Faster than Math.NET at every size, while computing the whole table — standard errors, p-values, intervals, R², the F test and the VIFs — against a Math.NET path that stops at the coefficients. Math.NET exports no GLS, so its row is the one its users write: its Cholesky factor of the covariance, and the normal equations solved through it.

From 500 rows on, the covariance's Cholesky factor is the fit, n³/6 products, which is why the ratio falls toward 1.20 as n grows rather than holding at the 1.9 it reaches at 200 rows.

Neither side is allocation-free, and neither can be: the factor is n² doubles, 8 MB at 1,000 rows, and each side holds one. Lodestar allocates 0.79× to 0.91× what Math.NET does.

Full method and what agrees: bench/README.md. No free .NET library fits this family at parity — Accord's IRLS is right only for canonical links, and commercial libraries are not timed under a trial licence — so the incumbent is statsmodels 0.15.0, through the cross-language harness. Machine: the AMD Ryzen 7 8700G named above, on 2026-09-15; the Python side is one run of bench_stats.py on the same machine. Milliseconds per fit, best of five, α = 1, four regressors and an intercept. The coefficients agree to 1.3e-14 relative or better with the same iteration counts.

The log-likelihood reads lnΓ(1/α) once rather than once per row — a few dozen logarithms per fit. At 100,000 rows statsmodels reaches LAPACK through numpy's threads and spends sixteen times the processor time it takes in wall clock; the wall column is still the comparison.

Full method and what agrees: bench/README.md. No free .NET library fits this family — Accord's generalized linear regression returned NaN coefficients on the inverse link — so the incumbent is statsmodels 0.15.0, through the cross-language harness. Machine: the AMD Ryzen 7 8700G named above. Window: BenchmarkDotNet 0.14.0 and the harness, default job, on 2026-09-15; the Python side one run of bench_stats.py. Log link, four regressors and an intercept; milliseconds per fit, best of five.

The IRLS loop the other families share is unchanged by the Gamma link, and their classes sit level with Accord or ahead of it: GlmBenchmarks' logistic fit reads 21.75 μs at 200 rows and one regressor against Accord's 28.29 μs, 29.80 against 58.82 at three regressors, 211.34 against 209.32 at 2,000 rows and one regressor — level — and 287.29 against 398.97 at three. GlmPoissonBenchmarks has no Accord counterpart and reads 191.5 to 197.6 μs across mean counts of 5 to 5,000,000, at 16.85 KB.

Full method and what agrees: bench/README.md. No free .NET library computes either covariance, so the incumbent is statsmodels 0.15.0 through the cross-language harness. Machine: the AMD Ryzen 7 8700G named above, on 2026-09-15. The harness side is one run of compare-ols and one of bench_stats.py. Four regressors and an intercept, four lags, clusters of 20 consecutive rows; milliseconds per fit, best of five, each row including the VIFs on both sides.

What each covariance costs beside the ordinary fit, from HacClusterBenchmarks, BenchmarkDotNet 0.14.0 default job:

HAC's filling runs once per lag, so four lags cost about five HC0 fillings.

HC0 and HC1 do not compute the leverages they never read. HC2 and HC3 do, and the two pairs sit about 15 % apart at both sizes for that reason (RobustCovarianceBenchmarks: 5.52 and 5.60 μs against 6.45 and 6.39 at 100 rows, 552 and 567 μs against 644 and 636 at 10,000).

Full method and what agrees: bench/README.md. Accord's GLM takes no offset, so the incumbent is statsmodels 0.15.0 through the cross-language harness. Machine: the AMD Ryzen 7 8700G named above, on 2026-09-15; one run of compare-glm and one of bench_stats.py. A Poisson fit of the corpus's counts, four regressors and an intercept, the exposure 1 + row % 3; milliseconds per fit, best of five.

What the exposure costs, from GlmOffsetBenchmarks, BenchmarkDotNet 0.14.0 default job:

Most of the difference is the null deviance. With an offset it is a second, intercept-only IRLS fit, as the reference computes it; without one it is the deviance at the response mean.

The loop every fit shares is unaffected by the offset: GlmBenchmarks' logistic rows read 22.71 and 30.93 μs at 200 rows (one and three regressors) and 222.05 and 297.03 μs at 2,000, and GlmPoissonBenchmarks 189.0 to 207.9 μs across mean counts of 5 to 5,000,000.

Full method and what agrees: bench/README.md. Machine: the AMD Ryzen 7 8700G named above, on 2026-09-16. BenchmarkDotNet 0.14.0, default job, one run. Three regressors and an intercept, three categories.

Accord's standard errors come from the lower-bound Hessian its algorithm iterates on, and are 33% to 43% from the ones this fit and statsmodels report. The race compares coefficients only.

Against statsmodels 0.15.0 through compare-glm, one run of each side: the corpus's four regressors and an intercept, the category the count modulo three, milliseconds per fit, best of five.

Part of the difference is the null log-likelihood: statsmodels refits the constant-only model with Nelder–Mead and BFGS, where this fit takes the closed form that refit approximates (decision 0004).

Full method and what agrees: bench/README.md.

Machine: AMD Ryzen 7 8700G w/ Radeon 780M Graphics, 1 CPU, 16 logical and 8 physical cores (BenchmarkDotNet's own header), Ubuntu 26.04.1 LTS, .NET SDK 10.0.401, .NET 10.0.12 runtime, AVX-512. Window: BenchmarkDotNet 0.14.0, default job, on 2026-09-15. Cortex.TimeSeries 1.1.0. Each pair returned the same statistic before it was timed.

The augmented Dickey-Fuller test is 1.79× to 2.26× faster than Cortex's. Its lag search fits through OrdinaryLeastSquares.Estimate, which applies the reflections to the response and stops at the coefficients, their standard errors and the residual sum of squares, rather than forming Q explicitly and pricing variance inflation factors and a Student quantile per coefficient to hand back one t statistic. It allocates more than Cortex at 2,000 points: the design and its column-major copy. The p-value stays what the test is for — Cortex's is clamped at 0.01, where MacKinnon's surface gives 1.1e-9 to 9.5e-4 on the regressions checked.

The decomposition is 1.85× faster: the moving average is a running sum over each window's interior rather than a weighted pass over the whole window, O(n) against O(n·period). KPSS is level, with half the allocation; its cost is the lagged products of the long-run variance, which both sides compute.

Full method, and why the partial autocorrelations of the two libraries differ: bench/README.md.

Machine: the AMD Ryzen 7 8700G named above. Window: one BenchmarkDotNet run, default job, on 2026-09-13, 12 benchmarks, 20 lags throughout.

The gap is one function call. Lodestar's ACF and PACF are 11.3 and 11.1 μs slower at 200 points and 11.4 and 10.9 μs slower at 2,000 — constant while the series grows tenfold, which a kernel difference could not be. Both compute the confidence band Cortex.TimeSeries does not, through one NormalQuantile call, and the Ljung-Box pair, which has no band, is 1.14× at 200 points and level at 2,000. Subtracting the 11.5 μs quantile leaves 7.1 μs against Cortex's 7.3 at 200 points and 76.6 μs against 76.7 at 2,000. The allocation difference is the band and the result record that carries it, and #709 confirmed it by removing that cost: without the bisection the pairs are level.

Full method and what agrees: bench/README.md. Nothing in .NET estimates a VAR, so the incumbent is statsmodels 0.15.0 through compare-var. Machine: the AMD Ryzen 7 8700G named above, on 2026-09-16; one run of each side. A two-variable series at lag 2, milliseconds per fit, best of five.

What the fit costs by shape, from VectorAutoregressionBenchmarks, BenchmarkDotNet 0.14.0 default job:

Both axes multiply: a system of K variables at lag p fits K least squares over a design of 1 + K·p columns.

Measured 2026-09-10, on the one machine bench/README.md's GPU gate says a GPU figure has to be published beside:

Read this before the numbers. Three caveats travel with every table below.

1. The baseline is single-threaded. bench/README.md's GPU gate asks a kernel to be priced against this repository's own path, and none of those paths is parallel. A Parallel.For over eight cores would close a large part of every gain here, most of all Myers'. These are honest against the gate as written; they are not a claim about a parallel CPU implementation.
2. --job short is three iterations. The GpuResident rows sit at 0.7–7 % standard error, which carries a verdict. Some GpuFromHost rows do not — one shows a confidence interval wider than its own mean — and those are read as orders of magnitude, not as figures.
3. The first run of these benchmarks measured the wrong device, and the numbers below are the second. Context.GetPreferredDevice(preferCPU: false) returned an OpenCL runtime that executes on the processor — ILGPU enumerated cpu-skylake-avx512-AMD Ryzen 7 8700G as an OpenCL device beside the CUDA card — and a check on the accelerator type called it a GPU. GpuContext now orders the devices itself and asks OpenCL for the device type, and the device's name is a column in every table so the mistake cannot repeat silently.

384 dimensions, top-10, seeded corpus. GpuResident is the gate row: query transfer and result read-back are inside the measurement, the corpus is not.

Clears the 5–10× gate at three sizes of four, and misses at the smallest corpus with a single query — which is where the crossing point belongs and why the sizes bracket it.

GpuFromHost is the argument for residency, and it is brutal. At 100 000 documents and one query it is 9.25× slower than the CPU path: 147 MB of corpus uploaded to answer one question. At 256 queries the same upload amortises and the row returns to 8.5× faster than the CPU. Below roughly a hundred queries per corpus, a GPU package that uploads per call is a pessimisation.

Allocation is the secondary win: 434 KB against the SIMD path's 200 MB at the largest size, a ratio of 0.002, because the kernel returns k hits rather than a score per document.

20 000 terms at 0.2 % density, double precision on both sides.

bench/README.md predicted this kernel might miss the gate on FP64, since a consumer card runs double precision at a fraction of single. That was wrong, and the reason is worth keeping: sparse-dense is bound by memory bandwidth, not by the double-precision units, so the reduced FP64 rate never becomes the constraint. It clears the gate at both realistic vectorizer sizes.

The cost it does carry is allocation — 5× the CPU path at the small sizes, from the staged upload and the downloaded result.

24-character pattern, 26-letter alphabet, seeded corpus.

This was written expecting a failure and is the largest gain of the four. The reasoning behind the prediction — that Myers is bit-parallel on both sides, so the CPU already spends tens of nanoseconds per short pair — was true and did not settle it: the baseline is one thread and the kernel is tens of thousands, over pairs with no dependency between them. Caveat 1 above bites hardest here.

GpuFromHost runs 4.1× to 6.5× below the CPU path: renaming the batch is a 64 KB code table on the host rather than a dictionary probe per character (#853). That column was measured on 2026-09-17, same machine and --job short, with a CpuBaseline of 1.73 ms, 8.08 ms, 34.4 ms and 162 ms in the same window; the other columns are the 2026-09-10 run.

24 tokens per document over a vocabulary of 5 000, seeded corpus, the same coefficients on both sides. Three rows because the two sides divide the work differently: the CPU path hashes and minimises in one pass, while the kernel takes hashes the host already computed.

GpuWithHashing is the row that matters, and it is the one that misses the gate. The minimisation is 34× to 66× faster on the accelerator; a caller starting from tokens sees 1.27× to 1.57×, because hashing is most of the work and it stays on the host. This kernel clears the GPU gate on the part it took and misses it on the part a caller experiences.

Located rather than disappointing: the next move is to hash on the accelerator, which is a separate kernel because parity requires the first four bytes of SHA-1 little-endian and a device implementation agreeing bit for bit is its own piece of work. Until then the kernel earns its place for a caller who already holds hashes — sketching one corpus under several permutation sets, for instance, where hashing is paid once and minimisation many times.

Two sparse-dense products; RoundTripped is the baseline because the question is what an intermediate costs when it crosses the bus, not whether the accelerator wins.

bench/README.md predicted the gap would be roughly flat in Rows. It is not — it shrinks, 2.23× to 1.24× at width 32, and the arithmetic never predicted otherwise: a fixed transfer against work that grows with Rows is a falling share of the total. The prediction in Width holds.

The reading for a caller inverts the usual intuition: residency is worth most where the work is smallest. A large job amortises a round trip on its own; a small one does not.