Upload README.md with huggingface_hub

README.md

@@ -26,13 +26,15 @@ each candidate together with the query and scores it properly.
 
 | build | file | size (MB) | worst score error vs eager | Mac median (ms)* | backend takes |
 |---|---|---|---|---|---|
-| fp32 | `rerank_bge_reranker_base_xnnpack_fp32.pte` | 1112.3 | 0.0000 logits | 55.3 | 78.3% |
-| fp16 | `rerank_bge_reranker_base_xnnpack_fp16.pte` | 556.4 | 0.0067 logits | 96.6 | 67.8% |
-| Core ML (fp16, iOS) | `rerank_bge_reranker_base_coreml_all.pte` | 557.7 | 0.0419 logits | 20.1 | 100.0% |
+| fp32 | `rerank_bge_reranker_base_xnnpack_fp32.pte` | 1112.3 | 0.0000 logits | 54.9 | 78.3% |
+| fp16 | `rerank_bge_reranker_base_xnnpack_fp16.pte` | 556.4 | 0.0067 logits | 95.6 | 67.8% |
+| Core ML (fp16, iOS) | `rerank_bge_reranker_base_coreml_all.pte` | 557.7 | 0.0419 logits | 19.9 | 100.0% |
 
-\*Mac arm64, single process, median of 10, one query-document pair at 512 tokens — a
-reference point for relative cost, not a device number. PyTorch eager fp32 on the same
-machine: 62.4 ms.
+\*Mac arm64, one query-document pair at 512 tokens, **fastest of five medians of ten** — a
+reference point for relative cost, not a device number. The host shares its cores with
+other work, and a single median does not survive that; contention only ever adds time, so
+the fastest repetition is the one that means something. PyTorch eager fp32, measured the
+same way: 62.3 ms.
 
 Correlation is not reported because it cannot be: the output is a single number, and the
 correlation of a one-element vector is undefined. The column above is the error in the
@@ -65,21 +67,20 @@ this shelf, scores the same passage -10.96 and puts it fifth of
 ## The attention is eager, and that is the faster export
 
 `F.scaled_dot_product_attention` does not survive export as one operation. The edge
-dialect lowers it through `_safe_softmax`, whose guard against a row with no unmasked
-key at all leaves **eleven operations XNNPACK cannot take, in every attention block** —
-`scalar_tensor`, `where`, `mul.Scalar`, `logical_not`, `eq`, `full_like`, `any.dim`.
-Each one cuts the subgraph in two. The count is exact and does not vary by family:
-measured across this shelf, from a 4-layer cross-encoder to a 28-layer causal reranker,
-it is 11 per block every time.
-
-The guard is emitted whether or not it can ever fire, and here it cannot. It triggers
-only on `-inf`, which reaches the graph only because the sdpa path hands `F.sdpa` a
-**boolean** mask for PyTorch to fill; `attn_implementation="eager"` masks with
-`torch.finfo(dtype).min`, a large finite number, and never produces one. So the two
-arms differ only on rows that have no unmasked key — sdpa zeroes them, eager gives them
-a uniform row — and those are padding rows, which the pooling discards and every real
-query row masks out. Measured with all but eight positions masked, as adversarial as
-this shape gets, the two graphs agree to 1.1e-05.
+dialect lowers it through `_safe_softmax`, whose guard against a row with no unmasked key
+at all leaves **11 operations XNNPACK cannot take, in every attention
+block** — `scalar_tensor`, `where`, `mul.Scalar`, `logical_not`, `eq`, `full_like`, `any.dim`. Each one cuts the subgraph in two.
+
+The switch is `attn_implementation="eager"`: transformers then builds the mask
+itself, as `torch.finfo(dtype).min`, instead of handing `F.sdpa` a **boolean** mask
+for PyTorch to fill with `-inf`.
+
+The guard is emitted whether or not it can ever fire, and here it cannot: it triggers only
+on `-inf`, and this arm never produces one. So the two differ only about rows that have no
+unmasked key at all — sdpa zeroes them, this one gives them a uniform row — and those are
+padding rows, which the pooling discards and which every real query row masks out anyway.
+Measured with all but eight positions masked, as adversarial as this shape gets, the two
+graphs agree to 1.1e-05.
 
 XNNPACK fp32 goes from **62.5% to 78.3%** delegated.