https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111588
--- Comment #4 from Mathias Stearn <redbeard0531 at gmail dot com> --- So even though I already knew in the back of my mind about how this can affect benchmark results, I *still* got burned by it! I was benchmarking a simple hazard pointer implementation against shared ptrs by having them crab-walk a list of 1000 pointers. This was an admittedly simple and unrealistic benchmark that only ever accessed the objects from a single thread and never had any contention. It was a few hours after getting the initial results that I remembered this issue and went back to add a bg thread. > This needs numbers, not opinions While my biggest concern was misleading benchmarks (which I now feel a bit validated by my own mistake :), here are the numbers I see. I added boost::shared_ptr on the assumption (unvalidated) that the primary difference would be that it unconditionally uses atomics. ----------------------------------------------------------------------- Benchmark Time CPU Iterations ----------------------------------------------------------------------- BM_scanLinks_HazPtr 6420 ns 6420 ns 108948 BM_scanLinks_BoostSharedPtr 11223 ns 11223 ns 62380 BM_scanLinks_StdSharedPtr 3217 ns 3217 ns 217621 BM_scanLinks_AtomicSharedPtr 28920 ns 28920 ns 24200 And with a bg thread doing nothing but sleeping: ----------------------------------------------------------------------- Benchmark Time CPU Iterations ----------------------------------------------------------------------- BM_scanLinks_HazPtr 6887 ns 6887 ns 101445 BM_scanLinks_BoostSharedPtr 11224 ns 11224 ns 62373 BM_scanLinks_StdSharedPtr 14221 ns 14221 ns 49221 BM_scanLinks_AtomicSharedPtr 49574 ns 49573 ns 14126
