Local measurements recorded on 2026-09-28. The article is in
[blog-post.md](https://adamdeprince.com/blog/posts/one-divide-instruction-can-still-be-too-slow/).

The [Intel Xeon E5-4657L v2 results](xeon-e5-4657l-v2/README.txt) repeat this benchmark
with GCC 11.4 and single-CPU affinity. The Apple measurements below
are preserved as originally recorded.
The [Loongson 3A6000 results](loongson-3a6000/README.txt) use GCC 15.2 with LASX enabled
and include native vector integer division in the runtime baseline.

| Property | Value |
|---|---|
| CPU | Apple M4 Max, ARM64 |
| Machine identifier | Mac16,5 |
| Cores | 16 total: 12 performance, 4 efficiency |
| Memory | 128 GiB |
| OS | macOS 26.5.1, build 25F80 |
| Compiler | Apple Clang 21.0.0, clang-2100.1.1.101 |
| Common flags | `-std=c++26 -O3 -DNDEBUG -mcpu=apple-m4 -fno-lto` |
| Scalar kernel flags | additionally `-fno-vectorize -fno-slp-vectorize` |
| Timing | `std::chrono::steady_clock`, elapsed wall time |
| Samples | 15 per case, in deterministically shuffled order |
| Calibration | Repeatedly double batch repetitions until elapsed time is at least 25 ms |
| Scheduler | `QOS_CLASS_USER_INITIATED` request succeeded; no core pinning or fixed CPU frequency |
| Denominator | 3, parsed from the command line; literal 3 only in the constant kernel |
| Inputs | 4,096 signed 32-bit values, Mersenne Twister seed `0xD171DE`, with the first five replaced by `INT32_MIN`, `INT32_MAX`, 0, -1, 1 |
| Working set | Two distinct 16 KiB arrays, reused throughout |

The driver and kernels are separate translation units, linked without LTO.
That prevents the driver from propagating a literal denominator or the
precomputed object's fields into the runtime kernels. Kernel calls cannot be
discarded by the driver; each sample's final output is also consumed through
a checksum after the timer stops. Every kernel and batch size is checked
against ordinary division before its calibration.

`steady` measures repeated calls to a kernel processing the complete input
array. The `Divide` object is constructed outside timing. `construction`
compares ordinary runtime division with a kernel that constructs a fresh
`Divide` once per batch, inside the measured call. A kernel call occurs once
per batch in every case, rather than once per input value. Call overhead is
included and is particularly relevant for one- and four-value batches.

These are throughput measurements with hot data, including loads, stores,
and loop overhead. They are not isolated instruction-latency measurements.
Auto-vectorization, alias checks, unrolling, and runtime instruction scheduling
are allowed. The CPU's normal scheduler and frequency management remain in
effect. Only one benchmark executable ran at a time.

Raw data and summaries:

- [Normal optimization samples](auto-samples.csv), [summary](auto-summary.csv), [run log](auto-run.log).
- [Scalar samples](scalar-samples.csv), [summary](scalar-summary.csv), [run log](scalar-run.log).
- [Normal assembly](kernels-auto.s), [scalar assembly](kernels-scalar.s).

Each sample row records the scenario, number of items per batch, method,
sample index, batch repetitions, total elapsed nanoseconds, and normalized
nanoseconds per value. Summaries give the median, minimum, and maximum of the
15 normalized samples. Article tables round the medians to three decimals;
ratios use the more precise recorded values.

Clang's vectorizer reported that runtime division was not beneficial to
vectorize or interleave. It vectorized constant division at width 4 with
interleave count 4, and the precomputed and construction cases at width 4 with
interleave count 1. The precomputed loop still scalarizes its wide multiply
operations; the generated assembly is included to make that distinction
visible. Runtime division uses `sdiv`, and constructing the reciprocal uses
one `udiv` before entering the arithmetic loop.

The final kernel source produces assembly byte-for-byte identical to the
assembly used for these measurements. Removing redundant restricted-pointer
annotations from definitions did not affect this compiler's output; its
earlier declarations used ordinary pointers.

To reproduce on an Apple M4 machine, run these commands from the repository
directory. They put new outputs under `build/reproduction` so the recorded
article data is preserved:

```sh
mkdir -p build/reproduction

clang++ -std=c++26 -O3 -DNDEBUG -mcpu=apple-m4 -fno-lto -c benchmark.cpp -o build/reproduction/driver.o
clang++ -std=c++26 -O3 -DNDEBUG -mcpu=apple-m4 -fno-lto -c benchmark_kernels.cpp -o build/reproduction/auto.o
clang++ build/reproduction/driver.o build/reproduction/auto.o -o build/reproduction/benchmark-auto

clang++ -std=c++26 -O3 -DNDEBUG -mcpu=apple-m4 -fno-lto -fno-vectorize -fno-slp-vectorize -c benchmark_kernels.cpp -o build/reproduction/scalar.o
clang++ build/reproduction/driver.o build/reproduction/scalar.o -o build/reproduction/benchmark-scalar

./build/reproduction/benchmark-auto 3 build/reproduction/auto-samples.csv > build/reproduction/auto-summary.csv 2> build/reproduction/auto-run.log
./build/reproduction/benchmark-scalar 3 build/reproduction/scalar-samples.csv > build/reproduction/scalar-summary.csv 2> build/reproduction/scalar-run.log
```

To inspect the assembly and vectorizer decisions:

```sh
clang++ -std=c++26 -O3 -DNDEBUG -mcpu=apple-m4 -fno-lto -Rpass=loop-vectorize -Rpass-missed=loop-vectorize -S benchmark_kernels.cpp -o build/reproduction/kernels-auto.s
```

For another target, replace or omit `-mcpu=apple-m4` and take fresh measurements.
The harness deliberately requires denominator 3 to keep its comparison with
the literal-divisor kernel valid.

Source note for the draft: the LinkedIn page and its shortened assembly link
could not be retrieved directly. The article's description of the original
post and its 1.18/1.94 ns figures comes from the excerpt supplied with the
request. Its author, complete benchmark harness, and additional context were
not independently verified. The local measurements above are independent of
that excerpt.