I wonder how many people need milliseconds in time stamps because they need the real sub second time or if they record milliseconds because they need the happens-before history. They are different problems. The latter can be solved with an atomic counter at a much faster rate.
-
-
Yeah, I know that. But on every reasonable hardware that
@kellabyte uses, it would be OK. See my four years old laptop. It's a perfectly reasonable assumption to make IMHO. Here's Ivy-bridge from 2012. Surprised to see modern server w/o it. For'em slower alternative availablepic.twitter.com/xCHdBrWGwf
-
FYI the only x86's not affected by Spectre seem to lack invariant tsc. You should never hard-code unsafe assumptions like this that will break critical invariants if they're not met.
-
Use the proper OS facilities that wrap the functionality with safe fallbacks or probe the OS for whether tsc is invariant & fallback or refuse to run if it's not.
-
Proper OS facilities are worse than useless here, since they do not guarantee what you really want, and don't guarantee certain latency, which
@kellabyte need Proper CPU facilities are useful here, and I perfectly agree that adding hard failure for CPUID w/o inv TSC is a must -
Not entirely sure why does "x86 not affected by Spectre" relevant here. In my experience nowadays non-inv TSC CPUs in server context are pretty uncommon. Of course some use cases (e.g., widely used library) can't assume invTsc rdtsc, or even rdtsc at all.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.