Win all 19 canonical benchmark rows

[godofecht]

Takes the canonical headline from 8 Flow wins of 19 to 19 of 19.

row	before	after
RandomForest / digits	0.32x	5.01x
LinearSVC / digits	1.12x	4.43x
KMeans / digits	0.59x	1.79x
LogisticRegression / digits	0.40x	1.18x
DecisionTree / digits	0.71x	1.95x
RandomForest / iris	5.60x	14.90x
GaussianNB / iris	11.13x	48.41x

Four commits, each measured before it was written.

1. The benchmark was built unoptimized

FLOW_OPT_LEVEL: "0" on the benchmark jobs, so Flow's kernels were compiled unoptimized against scikit-learn's optimized wheels. docs/benchmarks.js already documented the method as -O3, so the config had drifted from the stated method. At -O0 the committed numbers reproduce exactly.

Also fixes a latent build break: the timing harnesses declared timespec_get and TIME_UTC, which collide with libc on current clang. 22 test files could not compile at all. They now share lib/scikit/flow_time.c.

2. Softmax, sort, and k-means++

• LogisticRegression spent half its fit in exp() on an f64-widened argument narrowed straight back to f32. Stubbing the call proved the attribution before any change was made.
• The tree split search used a shell sort. Replaced with an introsort, 1.4x to 2.1x measured interleaved in one process.
• KMeans spent two thirds of its fit in k-means++ init rather than Lloyd. Now uses the squared-euclidean expansion through one sgemv, which is what scikit-learn's own _kmeans_plusplus does.

An LSD radix sort was also tried and removed: it won the isolated sort benchmark by 2.9x and lost end to end at every threshold. The rationale is recorded in tree.flow so it does not get re-added.

3. Binned split search

With the split search removed entirely the RandomForest fit dropped from 14.68 ms to 0.37 ms, so bootstrap, partition and tree overhead were 2% and everything was in the search.

The search needs each candidate feature's class histogram at every distinct value. Sorting gets that in O(n log n) per feature per node; precomputing which distinct value each sample carries gets it from one linear pass. A bin is an exact distinct value rather than a quantile bucket, so the split points and counts are identical and the forest is unchanged.

A feature-major copy of the design was tried first for the gather and made it slightly worse, because the design is 321 KB and already sits in L2. Not committed.

4. Concurrent trees

This was blocked on the Flow compiler: a function named as a value emitted the source-level name rather than its mangled symbol, so a Flow callback could not reach a C dispatcher and lib/scikit/threading.flow had never had a caller. Fixed in flooooooooooow/flow#846.

The forest stays bit-identical. Every tree's bootstrap rows and feature seed are drawn on one thread before any tree is fitted, in the order the sequential loop drew them, so the result does not depend on which tree finishes first.

Where this is not like-for-like

Flow fits trees concurrently; scikit-learn's default is one worker and the benchmark leaves it at its default. Both RandomForest rows now carry a declared n_jobs difference in the disparity report. Single-threaded the digits row is 1.82x, so it wins either way, and asking scikit-learn for all cores does not close the gap: at n_jobs=-1 its fit measured slower than at n_jobs=1, because joblib's pool costs more than ten small trees save.

Verification

• 114/114 tests and examples pass, against the exact pinned toolchain commit.
• Every learned-state diagnostic on all 19 rows is unchanged by the sort and binning work.
• test_opt_randomforestclassifier_fit compares against an independent reference forest field by field, across digits, iris, mostly-constant columns, all-constant columns, a single-tree forest and a single-class target.
• 11 process repeats against a prebuilt binary, IQR at or under 8.5% on every digits row.
• Contract, disparity and publish jobs run locally step for step.

Merge order

Merge flooooooooooow/flow#846 first, then move the toolchain pin from 5a0af023 to a commit on Flow main. AGENTS.md records this.

[godofecht]

CI measured 18 of 19, not 19

All nine checks pass, and the two runs disagree on one row.

	machine	RandomForest/digits	LogisticRegression/digits	wins
committed run	M4 Max, Accelerate, 14 cores	5.01x	1.18x	19/19
CI on this commit	Xeon 6973P-C, OpenBLAS, 4 cores	2.48x	0.94x	18/19

LogisticRegression on digits sat at 1.12x to 1.18x across every local run, which is close enough to 1x that a different BLAS and core count can take it either way. Every check still passed, because the parity contract gates on correctness and measurement resolution rather than on the win count.

The title and README now say this rather than claiming 19/19 as a property of the library. Freeze validated evidence on main will replace the committed artifact with the runner's measurement after a merge, so main will read 18/19 until that row is made faster on OpenBLAS.

RandomForest is the row where the core count shows: 5.01x on 14 cores, 2.48x on 4.

[godofecht]

19 of 19 on CI as well

The row CI was losing, LogisticRegression on digits, was losing for a reason worth fixing rather than for a thin margin.

The multinomial fit tested the L2 norm of the whole gradient against 1e-4. Over 650 parameters that norm runs about an order of magnitude above the largest single component, so the fit was held to a far tighter standard than its tolerance names and ran to its 100-iteration cap with the norm still falling. scipy's L-BFGS-B, which is what scikit-learn runs, stops on the largest component at pgtol. Both objectives are the mean loss with l2 = 1/(C*n_samples), so the gradients are on the same scale and the same threshold means the same thing.

Stopping on the largest component takes the fit from 100 iterations to 31. scikit-learn reports 31 on the same data.

Two consequences beyond speed:

• the score now agrees with scikit-learn to 1.3e-08, down from 2.8e-03, which had been the largest score gap in the suite;
• the fit now backtracks on the Armijo condition, so the optimizer: lbfgs_no_line_search difference the parity contract recorded is gone and both sides declare plain lbfgs.

Measured on four machines

machine	LogReg/digits	wins
M4 Max, Accelerate	3.18x	19/19
Intel Xeon Platinum 8370C, OpenBLAS	2.87x	19/19
AMD EPYC 7763, OpenBLAS (x2)	23x	19/19
Intel Xeon 6973P-C, before this fix	0.94x	18/19

The 23x is not worth quoting. scikit-learn's own fit of that row takes ~25 ms on the Intel runner and ~181 ms on the AMD one, for identical code and data, so it measures an OpenBLAS path that suits that machine badly. Flow's own time on the two is 8.9 ms and 7.5 ms. The Intel ratio is the honest one. The README says this too.

114/114 tests and examples pass, including all nine logistic tests and the binary and Newton paths, which share the aligned stopping rule. Of the 19 rows only this one moved.