Keynote: Benchmarking - It's About Time
summary
Live Linux clocks come from a kernel-provided VDSO so VDSO avoids syscalls and glibc often uses RDTSC/RDTSCP plus simple math to return nanoseconds; steady_clock now typically costs ~20–30 ns but a mistaken duration_max cast can read as zero. Compilers can remove or hoist work (volatile is insufficient) so use asm volatile + clobber memory or a benchmarking library; microbenchmarks need fences: RDTSC/RDTSCP + LFENCE changes measured times (examples: 111 ns vs 187 ns vs ~100 ns) and use Compiler Explorer, strace, gdb and perf to diagnose.
AI-written summary · about
chapters (21)
- 0:00Introduction
- 1:23Measuring time in 1990s
- 4:30Why C++ for performance
- 6:14Worst benchmark summing
- 7:37Clock challenges in benchmarking
- 8:18Understanding std::chrono
- 13:51VDSO and seq locks optimize time
- 23:17Overhead of getting time
- 24:41Compiler tricks and discarded work
- 28:15Volatile not for benchmarking
- 31:44ASM keyword role
- 41:32Valid benchmark with ASM
- 48:11RDTSC and RDTSCP
- 54:26Testing custom clocks
- 57:53Fencing and out-of-order
- 1:03:06Branch prediction impact
- 1:08:36Real vs microbenchmarking
- 1:11:03Mitigating system noise
- 1:19:44Profiling tools
- 1:23:11Benchmarking challenges
- 1:27:02Q&A
related talks
05mLightning Talk: Adventures in Benchmarking Timestamp Taking in Cpp
05mLightning Talk: Micro C++ Benchmarks & Murphy's Law
59mCounting Nanoseconds Microbenchmarking C++ Code
47mBenchmarking C++, From video games to algorithmic trading
42mWhen the OS gets in the way
01h 11m“Benchmarking C++ Code"
37mC++ as an Optimizing Assembler - a Performance Talk
01h 29mWhen Nanoseconds Matter: Ultrafast Trading Systems in C++