5 ms·
Bestcase seems like a poor metric when the CPU scheduler could certainly cause 7% variation. I would be interested to see, say, 100x the number of runs, and see
by sweettea 10y ago
Bestcase seems like a poor metric when the CPU scheduler could certainly cause 7% variation. I would be interested to see, say, 100x the number of runs, and see mean rather than best, since one usually cares about average more than best.
I also wish I knew what optimization settings GCC/etc was using, and what effect tweaking those has.
- flukus 10y ago> I also wish I knew what optimization settings GCC/etc was using, and what effect tweaking those has. From the makefile: GCCFLAGS = -O3 --std=c++11 MSFLAGS = /nologo /Ox /Ob2 /Ot /Oi /GL
- Too 10y agoWould march=native and fstrict-aliasing do any difference? It would be interesting to compare the compiled asm with the hand rolled one. The code has some potential improvements also but maybe the compiler is smart enough to find them, such as reading pivot.key in the loop even though it doesn't change.
- haldean 10y ago-march=native would almost certainly help, but I'm pretty sure -fstrict-aliasing is the default.
- kayamon 10y agoThe timing _should_ be constant each run, so best case is the best way to remove the scheduler variations. I tried mean also, and the results aren't that different. Optimization is -O3 (see the attached Makefile at the bottom).
- Joky 10y agoBecause of noise in general, "best case" seems always like the best metric to me. Over a large number of run, you're likely to hit the "perfect" measurement with on a microbenchmark. Otherwise, for an "adaptive" number of runs till enough time is spent to have some "confidence" on the measure, I've been fairly happy with: https://github.com/google/benchmark/ https://github.com/google/benchmark/
- andrepd 10y agoJust show more statistics: mean, variance, min, max, at least.