TL;DR Wouldn’t RDTSC assembly instruction be best, or even currently used (it seems not used, though maybe a next best option)?
I’m doing:
julia> time_ns() # implied by @time and I believe @btime
0x000c3f1aaef6b319
and I want to know what’s it actually doing.
I use sudo strace -C -p my_julia_pid to monitor, and note I typed that into the REPL, and I’m only showing what happens after I press ENTER until the prompt appears again:
% time seconds usecs/call calls errors syscall
42,42 0,000014 0 40 epoll_wait
36,36 0,000012 0 17 write
21,21 0,000007 0 23 ioctl
0,00 0,000000 0 2 read
100,00 0,000033 0 82 total
[The number of syscalls seem a bit excessive, though not really a problem, and I fail to find one getting the time, which is a good thing, something I wanted to confirm. It can be done otherwise.]
[{events=EPOLLIN, data={u32=10, u64=10}}], 1024, -1) = 1
read(10, “\r”, 65536) = 1
[apparently showing it read the ENTER there.]
epoll_wait(3, , 1024, 0) = 0
ioctl(13, TIOCGWINSZ, {ws_row=55, ws_col=238, ws_xpixel=0, ws_ypixel=0}) = 0
ioctl(13, TIOCGWINSZ, {ws_row=55, ws_col=238, ws_xpixel=0, ws_ypixel=0}) = 0
write(13, “\r\33[0K\r\33[0K\33[32m\33[1mjulia> \33[0m\33[”…, 54) = 54
[That’s strange, seemingly related to the prompt, but I haven’t yet gotten my ans back.]
write(13, “\n”, 1) = 1
epoll_wait(3, , 1024, 0) = 0
epoll_wait(3, , 1024, 0) = 0
ioctl(10, TCGETS, {B38400 opost -isig -icanon -echo …}) = 0
ioctl(10, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo …}) = 0
ioctl(10, TCGETS, {B38400 opost isig icanon echo …}) = 0
write(13, “\33[?2004l”, 8) = 8
“SNDCTL_TMR_STOP or TCSETSW”
I wasn’t up-to-speed on what all the output was, thinking e.g. TMR meaning timer, and having something to do with my timing. But it’s unrelated, and I would expect to see some “syscall” for it if it had applied.
I’m not sure why it shows “or”, and TCSETSW, which likely applies not the other. Trying to google for stuff, e.g. the other gets me:
https://docs.huihoo.com/doxygen/linux/kernel/3.7/uapi_2linux_2soundcard_8h.html
https://docs.huihoo.com/doxygen/linux/kernel/3.7/uapi_2linux_2soundcard_8h_source.html#l00170
Since sound cards plausibly need timers, times are important, I wasn’t sure I was ruling out a syscall related to time at first.
Anyway, I haven’t confirmed that Julia uses the optimal way to get the time, but it’s likely not way off. A syscall would have been bad and very slow.
I wanted to confirm RDTSC assembly instruction used, what I think is optimal, or possibly the very interesting, virtual syscalls" i.e. vDSO (Virtual Dynamic Shared Object) Linux provides::
https://www.reddit.com/r/linux/comments/14mittl/linux_vdso_virtual_dynamic_shared_object/
A user program CAN actually use vDSO directly, but I don’t see that Julia does that, but likely it does indirectly, i.e. uses libc and it does.
What I’ve confimed happens I call:
time_ns() [it’s very short code doing assembly call to:] → jl_hrtime() → uv_hrtime() → uv__hrtime(UV_CLOCK_PRECISE) # can also be called with UV_CLOCK_FAST
and it calls libc.
I get a few of these redundant syscalls (why print “”?):
write(13, "", 0) = 0
epoll_wait(3, [], 1024, 0) = 0
epoll_wait(3, [], 1024, 0) = 0
write(13, "\33[1m", 4) = 4
and finally (my value, non-optimal separate for “0x”, not a big problem, and then more stuff, in total strace log about a screenful):
write(13, "0x", 2) = 2
epoll_wait(3, [], 1024, 0) = 0
epoll_wait(3, [], 1024, 0) = 0
write(13, "000c47d03f4e89cb", 16) = 16
Something I googled from strace, that may be done, or another false alarm:
A terminal mode is one of a set of possible states of a terminal or pseudo terminal character device in Unix-like systems and determines how characters written to the terminal are interpreted. In cooked mode data is preprocessed before being given to a program, while raw mode passes the data as-is to the program without interpreting any of the special characters.
[…]
cbreak mode (sometimes called rare mode) is a mode between raw mode and cooked mode