Posts tagged "when the benchmark lies"

For the last part, I ran two earlier parts again with the same script. The assembly was identical, part 1 ran 10 to 14 percent faster, and the conclusions of both parts held. This is what a result must carry so that someone else can make the same check.

Alone, a lookup table was four times faster than a division. In a loop that also used 1 to 8 MiB of its own counters, the same table made the whole loop 4 to 34 percent slower. The microbenchmark had the cache for itself, and the program had to share it.

A small formatting function took 52 ns per call with a new String and 38 ns with a reused buffer. A 256 KiB buffer cost nothing extra after the first call. And the contention that I saw with four threads came from my own allocation counter, not from malloc.

The famous result says that a loop over sorted data is faster because of branch prediction. In my Rust version, sorting changed nothing, because the compiler removed the branch. With a branch that it could not remove, random data was 3 to 10 times slower.

One step of i = a[i] costs 1.4 ns when the array fits in L1 and 114 ns when it is 128 MiB, the same instruction. I measured the steps on a P-core and an E-core, a sequential read of the same arrays, and why I could not show the effect of huge pages.