4 ms·

That may be the result of inlining clock_gettime, though that would imply a pretty different implementation from the one I am familiar with. AFAIR on x86 a loc

That may be the result of inlining clock_gettime, though that would imply a pretty different implementation from the one I am familiar with. AFAIR on x86 a locked rdtsc is ~20 cycles. So to answer the gp question, it has around a precision in the few nanoseconds range. Accuracy is a different question, IE compare numbers from the same die, but be a little more suspicious across dies. No clue how this is implemented on the M1, or if the M1 has the same modern tsc guarantees that x86 has grown over the last few generations of chips.

saagarjha 6y ago
Yeah, clock_gettime is somewhat more complicated than this. If anything, it might have an inlined mach_absolute_time in it…
lilyball 6y ago
I was actually misremembering a bit. Sufficiently old versions of mach_absolute_time used a function called clock_get_time() on i386 (if the COMM_PAGE_VERSION was not 1). This changed in macOS 10.5 to a tiny bit of assembly that just read from _COMM_PAGE_NANOTIME on i386/x86_64/ppc (the arm implementation(!!) triggers a software interrupt). The i386/x86_64/ppc definitions were also copied into xnu. For the next few years it kind of bounced back and forth between libc and xnu, and the routine was complicated by adding timebase conversion as needed. And at some point arm support was added back (it vanished when it first went to xnu), but this time using the commpage if possible. As for M1, I assume it's using the arm64 routine in xnu, which can be found at https://opensource.apple.com/source/xnu/xnu-7195.50.7.100.1/libsyscall/wrappers/mach_absolute_time.s https://opensource.apple.com/source/xnu/xnu-7195.50.7.100.1/.... As for clock_gettime_nsec_np(), at least as of Big Sur, it's in libc¹ instead of xnu and defers to mach_continuous_time()/mach_continuous_approximate_time()/mach_absolute_time()/mach_approximate_time() for the CLOCK__RAW[_] clocks. And clock_gettime() for those clocks is implemented in terms of clock_gettime_nsec_np(). ¹https://opensource.apple.com/source/Libc/Libc-1439.40.11/gen/clock_gettime.c.auto.html https://opensource.apple.com/source/Libc/Libc-1439.40.11/gen...

saagarjha 6y ago

Yeah, clock_gettime is somewhat more complicated than this. If anything, it might have an inlined mach_absolute_time in it…

lilyball 6y ago

I was actually misremembering a bit. Sufficiently old versions of mach_absolute_time used a function called clock_get_time() on i386 (if the COMM_PAGE_VERSION was not 1). This changed in macOS 10.5 to a tiny bit of assembly that just read from _COMM_PAGE_NANOTIME on i386/x86_64/ppc (the arm implementation(!!) triggers a software interrupt). The i386/x86_64/ppc definitions were also copied into xnu. For the next few years it kind of bounced back and forth between libc and xnu, and the routine was complicated by adding timebase conversion as needed. And at some point arm support was added back (it vanished when it first went to xnu), but this time using the commpage if possible. As for M1, I assume it's using the arm64 routine in xnu, which can be found at https://opensource.apple.com/source/xnu/xnu-7195.50.7.100.1/libsyscall/wrappers/mach_absolute_time.s https://opensource.apple.com/source/xnu/xnu-7195.50.7.100.1/.... As for clock_gettime_nsec_np(), at least as of Big Sur, it's in libc¹ instead of xnu and defers to mach_continuous_time()/mach_continuous_approximate_time()/mach_absolute_time()/mach_approximate_time() for the CLOCK__RAW[_] clocks. And clock_gettime() for those clocks is implemented in terms of clock_gettime_nsec_np(). ¹https://opensource.apple.com/source/Libc/Libc-1439.40.11/gen/clock_gettime.c.auto.html https://opensource.apple.com/source/Libc/Libc-1439.40.11/gen...