6 ms·
Related reading is absl’s linear approximation of gettime from cycle counters, which I thought is a neat trick: https://github.com/abseil/abseil-cpp/blob/351086
by rockwotj 5mo ago
Related reading is absl’s linear approximation of gettime from cycle counters, which I thought is a neat trick: https://github.com/abseil/abseil-cpp/blob/351086314d46e73d430296c9eca1f6d6c0372cd1/absl/time/clock.cc#L289 https://github.com/abseil/abseil-cpp/blob/351086314d46e73d43...
- hmpc 5mo agoThanks for sharing this! I hadn't seen it before, I'll definitely add a mention in the post. This approach is a smart way to get the same precision as the kernel without tying it to the vDSO implementation as in the post, so presumably someone at Google was worried about very similar issues. I also considered an implicit automatic refresh, but ultimately for my purposes controlling when to take the hit was more important than the slight increase in API complexity introduced by an explicit call.
- rockwotj 5mo agoIIRC (it’s been awhile) this was an optimization that was inspired by someone noticing all of Google spent a lot of time in vDSO using https://research.google/pubs/google-wide-profiling-a-continuous-profiling-infrastructure-for-data-centers/ https://research.google/pubs/google-wide-profiling-a-continu... Google generally doesn’t have any (well that I have ever heard of) hard realtime requirements like the high frequency trading or HPC systems do. Cool stuff thanks for sharing!