3 ms·
> The CPU will randomly speed up or slow down constant_tsc has been a thing for more than a decade > execute instructions out of order, and even speculativel
by blibble 3y ago
> The CPU will randomly speed up or slow down
constant_tsc has been a thing for more than a decade
> execute instructions out of order, and even speculatively execute
rdtscp serialises
> Not to mention that it'll have a dozen different clocks - which are not guaranteed to be in sync.
synchronised_tsc has been a think for about 6 years now
- lazide 3y agoNone of these are performant, no? Generally, you can have consistency, speed, or low cost - but not more than two at the same time.
- kprotty 3y agoInvariant (Constant) TSC is detectable via `cpuid` and applies to `rdtsc/rdtscp` by default. In that aspect, there's no tradeoff being made there (observable to software) AFAICK.
- lazide 3y agointeresting results! i guess it depends in if you consider 35ish cycles expensive or not. [https://community.intel.com/t5/Software-Tuning-Performance/High-impact-of-rdtsc/m-p/1092539#M5675 https://community.intel.com/t5/Software-Tuning-Performance/H...]
- kprotty 3y agoAre there cheaper ways of getting elapsed time with sub microsecond precision? Interested as I've only ever heard of rdtsc at the lowest level in userspace for x86.
- lazide 3y agoI ran across a random stackoverload thread with benchmarks claiming it was about 2x the cost of doing a naive gettime(). But frankly, hard to figure out when you factor in all the various caches, OO execution pipelines, etc,