3R — Reverse & Rebuild to Rust: fly readout aggregation
Research record
- Question
- Can a Rust implementation reproduce the readout-counting portion of a saved fly-experiment audit, and how does this specific workload compare?
- Evidence
- Previously published saved Parquet trial events, matching result JSON, the original Python audit, and newly written Python and Rust implementations.
- Experiment
- Linux CPU: 24 saved Parquet trial files; three seeds, two patterns and four variants; nine fresh processes per implementation, ten aggregations per process.
- Results
- The 24-row result TSV was byte-identical. Median measured wall times were 486.719 ms for Python and 409.321 ms for Rust in this bounded workload.
- Limitations
- Warm-cache, same-host measurements use different Parquet implementations and include process startup. This rebuild covers readout counting only, not the whole audit or neural simulation.
- Reproduction
- Use the linked public bundle for source, locked dependencies, original input hashes, output TSVs, raw benchmark records, commands, and stated limitations.
Sources
Run evidence
Task
Rebuild one bounded part of an existing fly-experiment audit: count four recorded output neuron IDs from saved Parquet spike tables. This is a read-only analysis of completed records, not a rerun of the fly model and not evidence of new behavior.
Same input, same rule
The Python reference is newly written for this case from the readout portion of the original audit; neither implementation replaces the complete original audit. Both implementations read the same 24 saved Parquet files: three seeds, two movies, and four recorded variants. The frozen protocol defines a 0.1 ms step, with the observation interval from 200 to 1000 ms; both count only steps [2000, 10000). Flywire IDs are read as signed 64-bit integers, preserving the exact identifiers used by the Python audit.
The Python reference and the Rust release binary produced an identical 25-line TSV file (SHA-256 15852b74a7741541046b3dd5e35c9454003ec22938a56a0c1c8e0ac5b8c9a1a7). Counts were also checked against each saved JSON result. The existing audit was separately rerun read-only and passed.
Measurement
Nine fresh processes per implementation ran on one Linux CPU at low priority. Each process completed ten identical full aggregations; process launch, Parquet reading/parsing, counting, JSON comparison, and TSV writing were included. Compilation and installation were not.
| Metric | Python reference | Rust native |
|---|---|---|
| Median wall time | 486.719 ms | 409.321 ms |
| Kernel-reported median peak RSS | 135,580 KiB | 9,808 KiB |
Limits
This is a narrow, warm-cache saved-data task. Python uses pandas/Parquet while Rust uses a streaming Parquet record reader. The result does not generalize to the complete audit, cold-cache execution, build cost, neural simulation speed, or any behavioral claim about the model. It is a reproducible starting point for deciding whether a larger, separately specified component is worth rebuilding.
Reproduce
The public evidence bundle includes Rust source, Cargo.lock, the Python reference, output TSVs, raw wait4 benchmark records, input hashes and a SHA-256 manifest. The previous experiment and matched-input study provide the original saved data and full-audit context. Rust was installed in the experiment directory only via the official Rust installation route; no system PATH or shared toolchain was changed.
Update record
- 2026-10-31: Ran a saved-data comparison and benchmark on Linux; no fly neural dynamics were rerun.