Skip to content
3 changes: 2 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -106,7 +106,8 @@ Measured head-to-head against the original FastHenry (operator-run,
one machine, self-authored decks; method, hardware and caveats in
[`docs/benchmarks.md`](docs/benchmarks.md)):
fasterhenry's dense path is faster on wall clock at every size up to
~20 000 filaments (3× at small sizes, ~1.2× at 20 k, where FastHenry's
~20 000 filaments except around 1 000, where the two are within noise
(1.6–3× at a few hundred filaments or fewer, ~1.2× at 20 k, where FastHenry's
multipole stays 14× ahead *per thread* — that dense-path edge is
parallelism; the algorithmic answer is the pFFT + GMRES path above).
On shared segment fixtures the two engines
Expand Down
8 changes: 5 additions & 3 deletions docs/benchmarks.md
Original file line number Diff line number Diff line change
Expand Up @@ -34,9 +34,11 @@ contaminates nothing. CI never invokes it.
Reading it honestly:

- **Wall clock on a many-core machine, fasterhenry's dense path beats
FastHenry's multipole on every completed deck** — 3× at small sizes,
~1.2× at 20 k filaments, crossover around 30–50 k where neither
finishes comfortably.
FastHenry's multipole on every completed deck except the 1 000-filament
serpentine, where the two are within noise** (73 ms vs 69 ms) —
1.6–3× at a few hundred filaments or fewer, ~2.2× at 5 k, ~1.2× at
20 k filaments, crossover around 30–50 k where neither finishes
comfortably.
- **Per thread, FastHenry's multipole is far ahead at scale** (14× at
20 k filaments single-threaded). Our dense wall-clock advantage is
parallelism + SIMD + a blocked LU; it is not an algorithmic win.
Expand Down
Loading