Microbenchmarks: measure the question you actually asked

To estimate producer-to-consumer latency, create a chain in which every operation needs the previous result. Ensure the final answer is observed so the compiler cannot discard the computation, and inspect the generated instructions to confirm that the intended chain exists. Loop bookkeeping and measurement overhead must be separated or amortized. Some instruction forms have different input-to-output dependency paths, so state operand types and forms instead of attaching one unexplained number to a mnemonic.

To explore reciprocal throughput, provide enough independent chains that latency does not force every issue slot to wait. Increase their count cautiously: too few leave dependencies exposed, while too many can create register spills or different front-end pressure. The best isolated throughput does not automatically predict a full workload with loads, stores, branches, and other operations sharing resources. A microbenchmark answers its constructed scenario; the application comparison decides whether that scenario was relevant to users.

RDTSC reads an x86 timestamp counter but is not a serializing instruction. Without appropriate documented ordering, surrounding work may not line up with the apparent measurement boundaries. The exact sequence of fences, timestamp instructions, and compiler barriers must match the experiment and processor guidance. Do not present an unqualified timer snippet as a universal solution. Operating-system scheduling, interrupts, migration, power management, and virtualization can also affect the result or the interpretation of the counter.

An invariant timestamp counter advances at a stable reference rate independent of changing core frequency; its ticks are therefore not necessarily actual core cycles. Conversely, a core-cycle performance event counts according to its own documented scope and conditions. Elapsed seconds, TSC ticks, and core cycles can all be useful if named correctly. Record which one was collected, how it was converted, and whether the process could migrate across dissimilar cores. Avoid turning a rate assumption into an architectural guarantee.

Warm up the chosen code and data state when steady-state behavior is the target; measure cold behavior separately when startup matters. Repeat runs, report variability, and distinguish the minimum observed interference from a representative distribution. Pinning a thread can control one source of variation but does not freeze all power and memory behavior. Record processor model, relevant features, compiler version and flags, code bytes or assembly, data sizes, and loop structure so another engineer can assess the measurement.

The binomial lab can illustrate the uncertainty of a hypothetical pass/fail event across independent trials: choose an assumed p and n and predict the count distribution. It does not collect timing samples or fit latency distributions. Real timing observations can be correlated and continuous, so this lab cannot validate benchmark significance. For a real comparison, define the expected improvement first, examine timing distributions, and then run the application workload. If the isolated win disappears, update the performance explanation rather than hiding the broader evidence.