2 ms·

I wonder if there’s many other spots where time is being read multiple times instead of reading it once and caching it. All that being said, it’s also surprisin

I wonder if there’s many other spots where time is being read multiple times instead of reading it once and caching it. All that being said, it’s also surprising how relatively expensive reading time is. Even rdtsc is 50-100ns if I recall correctly, but to put that in perspective that’s basically the performance of a 10-20Mhz chip to do an operation that should be a simple register read of a latch that’s incremented on every clock cycle. yes yes - I know in reality it’s a heck of a lot more complex for lots of reasons, but still, given how frequently we want to time things or obtain a timestamp, it’s surprising to me we don’t have a faster instruction and we have to do a bunch of caching (eg you’d not likely bother caching just the addition of two variables because addition is so fast)

lelanthran 3y ago
> . All that being said, it’s also surprising how relatively expensive reading time is. Typically you don't need granularity as fine as you think you do. Reading time at the finest granularity available is going to kill your throughput/latency no matter what because you are probing the hardware, so make sure you need that very fine granularity. IME, most (99.999%) of the case you need the time, you can get by with coarse granularity. I worked on realtime systems to control a jig in a factory, using embedded 486-class processors, with hard-realtime kernel patches, and even then I had no need to use the non-coarse timers when recording events for observability. In any case, here's the relative costs of the different timers: https://www.lelanthran.com/chap5/content.html https://www.lelanthran.com/chap5/content.html