Azure / Azure/m

FP hardware survey — fleet capture campaign (tracking)

Open
#170 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
2
Forks
8
PR merge metrics
No merged PRs in 30d

Description

# FP hardware survey — fleet capture campaign

Coordinates the cross-machine floating-point hardware survey produced by
`crates/fp-hw-survey`. The tool captures native scalar FP results + exception
flags through per-architecture inline asm (not libcore math), then `merge`s
captures from many machines to surface the rows where hardware actually
disagrees. See `crates/fp-hw-survey/README.md` → **Collecting captures across
the fleet**.

## Why this campaign
- **Confirm intra-ARMv8 determinism.** The Arm ARM defines `frecpe`/`frsqrte`/
`frecpx`/`fmulx` via exact pseudocode; distinct ARMv8 vendors *should* produce
bit-identical estimates. A **zero-divergence** merge across AArch64 machines is
the expected, informative result — positive confirmation of conformance.
- **Map the genuinely divergent axes.** Cross-architecture x86-64 ↔ AArch64
semantics (`fmax`/`fmin` NaN handling, float→int saturation, flush-to-zero
edges), and any single-precision estimate difference attributable to a
`FEAT_RPRES` / `FPCR.AH` context gap (`rpres`/`afp` are recorded in each
capture header precisely so such a row is read as a feature difference, not an
erratum).

## Target SKUs
- [ ] Apple Silicon (M-series, arm64/macOS) — #166
- [ ] Snapdragon X-series (arm64/Windows-on-ARM) — #167
- [ ] Ampere Altra / AWS Graviton (arm64/Linux) — #168
- [ ] x86-64 baseline (Intel + AMD) — #169

## Acquisition (manual, per machine)
No CI capture job — the interesting SKUs are physical hardware a hosted runner
does not represent. Each machine owner builds `--release`, runs `info` +
`selftest` (capture refuses to write if the self-test fails), then `capture
--label `, and submits the NDJSON plus the one-line header on the
matching per-SKU issue above.

## Ingest (offline, on one machine)
```sh
fp-hw-survey merge --out divergences.ndjson capture-*.ndjson
```
Commit **only**, never the raw multi-hundred-MB captures:
- **`divergences.ndjson`** — the merge output (expected *empty* for intra-ARMv8
estimate ops; an empty file is the positive result).
- a **provenance table** — one row per contributing capture copied from its
header: `label`, `cpu`, `os`, `features`, `captured_utc`, row count,
`tool_version`.

Raw captures are retained out-of-band (issue attachments / artifact storage).

## Close-out
Paste the `merge` stderr summary (machine count, aligned-key count, divergence
count, per-op breakdown) into this issue and check off the contributing SKUs
above.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with crates/fp-hw-survey/README.md, especially “Collecting captures across the fleet,” then build --release and run info, selftest, and capture on an available target machine. Submit the NDJSON and header to the matching SKU issue, then run fp-hw-survey merge and record divergences.ndjson, the provenance table, and the stderr summary here.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
embedded-iot
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.