YHK - yet another hacker news clone

Really depends on what you benchmark and how reliable you want the measurement and what domain you are benchmarking. For example, criterion can sometimes spend quite a bit of time because it needs to stabilize the measurements. The author’s claim is “well you don’t need that accuracy” but I’ve seen wasted time chasing ghosts or making claims on performance improvements that were either neutral or net negative due to this noise.

> Anything faster than, say, 10ms risks being skewed by fixed costs (e.g, interpreter startup).

Sounds like the author’s experience is strictly in Python. For example with Java you have to make sure the JIT has sufficient optimized your program.

Additionally there’s plenty of situations where it can take a really long time to generate a representative dataset worth benchmarking and it can take time to evaluate the performance (eg databases). Short and quick microbenchmarks can be useful as building points, but at some point you need to evaluate steady state performance of the full thing. Other domains this comes up with is game rendering performance where a 300ms sample tells you nothing about whether you have frame drops after minute 25 or have a memory leak.

Love it. Unfortunately, for some benchmarks, it can be bit difficult to get representative inputs which take hundreds of milliseconds. I'm curious as to why the author doesn't loop 1-10ms inputs to deal with variance? Which also deals with startup costs. Rust microbench harnesses were already good at this stuff-out of-the-box (run-to-run variance, etc) several years ago.

Assuming the subject of the benchmark is a web/API request here, otherwise the advice does not really apply. Milliseconds would be too large for benchmarking GPU- or CPU-intensive work.

Benchmarking like that is often broken because of continuous CPU core clock speed adjustments, system interrupts, SMIs, etc.

I tried to fix it by switching hyperthreading off, playing with the scaling governor, boost, setting a CPU frequency to no avail. The jitter was too much and the results were not reproducible, so I just gave up.

Of course your mileage may vary; this was on an AMD Zen 3 CPU.

if you are doing benchmarks using interpreted languages but care about smaller timescales perhaps your problem is using interpreted languages.

This has to be read in terms of https://xkcd.com/2400/. If you're chasing low-hanging fruit, and searching for a 3x or 10x speedup on something that has never been optimized, this advice probably can be ok.

The harder you push, and the more you need to start finding smaller improvements, the more this advice becomes a rule of thumb you can't rely on.

In creating https://github.com/bhouston/webgpu-bench, a microbenchmark for WebGPU, I found that if you run in browsers you do not control, you need to run longer than 10ms to get an accurate result. Modern browsers by default round to the nearest 1ms. [1] So I generally try to get 50 to 100ms of run time for browser benchmarks.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Performance...

Microseconds are a much more convenient unit when you are working with inter-thread communication concerns.

I also prefer microseconds when working with SQLite and AspNetCore.

The benchmarks for 'xc' - "my" compiler for heterogenous computing (gpu and cpu, all in the same language, compiler managing data-hazards between them) are all on the order of a second to a few seconds, for the long pole.

So if I'm comparing against (say) C++, Swift, ObjC, on a given (arm64 or x86_64) architecture, I want to see that sort of timescale, a bit less is fine, a bit more is fine.

Of course, when you (today [grin]) get auto-vectorisation of 2D matrix multiplies, and you have an SME/SME2 target on arm64 that most compilers don't pick up so you're 150x faster than clang/g++, you might have to run it a bit longer so you can get reasonable comparison numbers :)

1: https://compile-xc.org/compiler/performance/

If you are benchmarking Java, there is Java Microbenchmark Harness (https://github.com/openjdk/jmh), which:

- Does several warm-up runs so the JIT-optimized code is benchmarked instead of the interpreted code/compilation.

- Create multiple forks of the JVM to eliminate JVM run variance.

- Provide utilities like `Blackhole` to prevent dead code elimination and `State` to do setup and prevent constant folding.

I would rather say: "benchmark with confidence intervals" or maybe "benchmark with comparisons".

It's very hard to say much about an absolute number. You need to compare against some alternative or control, and because of CPU load, throttling, GC, and a thousand other variables, you really should be comparing against that control _in the same run_, and importantly round robin across multiple runs to spread out the noise fairly across each implementation.

Then once you have a bunch of measurements you have a distribution and shouldn't just take a mean to compare, but should calculate something like the 95% confidence interval. If you see that those confidence intervals overlap, the you might not really know which is faster. If they don't overlap, then you probably do know which is faster.

If you have a good benchmark, then running it more times can narrow the confidence intervals and let you tease out very small improvements at the cost of longer runs. If confidence intervals don't narrow, then you hit the limits of signal-to-noise.

This is the only way I've been able to get reliable, actionable benchmarks outside of a very, very controlled hardware lab. It's what Google's Tachometer benchmark runner does, and I wish more runners did this: https://github.com/google/tachometer