feat(hash): latency + throughput (Short/Web) rendering; 128-bit throughput - #260
Merged
Conversation
…8-bit throughput Report: distill and render the latency (ns, exact length) / throughput (GiB/s, bounded Short/Web distributions) split - each a chart + table per hash width, in order 64-latency, 64-throughput Short/Web, 128-latency, 128-throughput Short/Web, with absent sections dropped. Bundles are re-distilled from their raw on read, so old bundles still yield latency tables and no bundle needs re-packing when the tool changes; plot/compare/publish/verify all follow the new schema. Benchmark: add BmHash128Throughput and guard the 64-/128-bit paths by HasGetHash64 / HasGetHash128. Data: publish the merged-main (80a4c8a) bundles (64-bit latency, 64-bit throughput Short/Web, 128-bit latency per machine; 128-bit throughput awaits a re-measure) and drop the superseded 1417af5 bundles + old throughput charts. Refreshed the README perf prose, "Reading the results", and SMHasher3 tables.
The narrow ~1-decade GiB/s throughput axis only labelled decade powers (1, 10); add 1-2-5 x 10^n gridlines/labels per decade (also denser on the latency axis). Regenerated the committed charts.
The headline claimed mumbo/jumbo "post the best mixed-length latency"; the new data does not cleanly support a raw-latency win. Reframe mumbo as the all-round default - among the fastest on every machine, SMHasher3-clean, notice-free Apache-2.0, with streaming and a Starlark port - and jumbo as the excellent native 128-bit choice.
helly25
enabled auto-merge (squash)
July 15, 2026 06:24
Fab-Cat
approved these changes
Jul 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #259: renders the latency vs throughput split from the new benchmark, adds the 128-bit throughput benchmark, and republishes the README from the merged-main (
80a4c8a8) measurements.Report tool
_results_from_bundle), so a bundle measured before this split still yields today's schema (e.g. latency tables from old data) and no bundle ever needs re-packing when the tool changes.distill/tables/plot/compare/publish/verifyall follow the new schema; charts gainedy_label/x_label(GiB/s vs ns/op) and 1-2-5 × 10ⁿ y-axis ticks (readable on the narrow throughput axis).Benchmark
BmHash128Throughput(128-bit bounded-range throughput) and guarded the 64-/128-bit paths byHasGetHash64/HasGetHash128(handles 64-only / 128-only algorithms).Data & docs
80a4c8a8bundles → per machine: 64-bit latency, 64-bit throughput Short/Web, 128-bit latency. 128-bit throughput awaits a re-measure (the data predatesBmHash128Throughput).1417af5ebundles + old throughput charts.Follow-up
Re-measure on each machine with this branch to populate the 128-bit throughput sections (they'll appear automatically).