https://issues.dlang.org/show_bug.cgi?id=13433

Vladimir Panteleev <thecybershadow@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thecybershadow@gmail.com

--- Comment #1 from Vladimir Panteleev <thecybershadow@gmail.com> ---
Shouldn't you be using the monotonic clock for benchmarking?

--

https://issues.dlang.org/show_bug.cgi?id=13433

--- Comment #2 from Vladimir Panteleev <thecybershadow@gmail.com> ---
Oh, I see - std.logger needs the realtime clock to log the time together with the log message.

--

https://issues.dlang.org/show_bug.cgi?id=13433

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com,
                   |                            |schveiguy@yahoo.com

--- Comment #3 from Steven Schveighoffer <schveiguy@yahoo.com> ---
CCing Jonathan.

--

https://issues.dlang.org/show_bug.cgi?id=13433

Marco Leise <Marco.Leise@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Marco.Leise@gmx.de

--- Comment #4 from Marco Leise <Marco.Leise@gmx.de> ---
Yes, he is the master of time.

--

https://issues.dlang.org/show_bug.cgi?id=13433

--- Comment #5 from Jonathan M Davis <jmdavisProg@gmx.com> ---
Hmmmm. The precision of the _COARSE variants is abysmal. Apparently, it's only 1 ms (at least on Linux). So, I certainly think that it would be foolish to use them normally, but I see no problem with adding a defaulted parameter which would use them underneath the hood, and then anyone who wants to make the tradeoff for the worse precision can. I'll make a pull request for it.

However, I think that the only systems that this will affect are Linux and FreeBSD. Mac OS X currently uses gettimeofday (which I'm not enthused about, but I don't know of a better option there), and AFAIK Windows doesn't have anything like the COARSE option, and I don't know how fast GetSystemTimeAsFileTime is in comparison to the options on the POSIX systems. So, the new parameter will effectively be ignored on some systems.

--

https://issues.dlang.org/show_bug.cgi?id=13433

--- Comment #6 from Jonathan M Davis <jmdavisProg@gmx.com> ---
https://github.com/D-Programming-Language/phobos/pull/2584

--

https://issues.dlang.org/show_bug.cgi?id=13433

--- Comment #7 from Marco Leise <Marco.Leise@gmx.de> ---
Do you have a source Jonathan? All I could find about it was references to the kernel ticks on Linux which is 100, 250 or 1000 Hz, but never as low as 10 Hz. On tickless systems I couldn't figure out how exactly the time is updated, but assumed it would not fall behind the tick rate.

--

https://issues.dlang.org/show_bug.cgi?id=13433

--- Comment #8 from Marco Leise <Marco.Leise@gmx.de> ---
I just ran a test:

void main(string[] args)
{
    while (true)
    {
        timespec time;
        clock_gettime(CLOCK_REALTIME_COARSE, &time);
        printf(":%03ld ms\n", time.tv_nsec / 1_000_000);
    }
}

My kernel has CONFIG_HZ=1000 and CONFIG_NO_HZ=y (tick-less). The coarse timer shows a precise 1 ms precision. What's more, compared to the fine grained timer, it is ~100 times faster (!) [compiled with DMD and release options, Core2Duo 2Ghz]:

1024 ms for 100,000,000 calls to the coarse real-time clock. 1059 ms for   1,000,000 calls to the regular real-time clock.

If your code benefits much from the 100 times faster time queries, millisecond precision is a good trade off.

--

https://issues.dlang.org/show_bug.cgi?id=13433

--- Comment #9 from Jonathan M Davis <jmdavisProg@gmx.com> ---
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/2/html/Realtime_Reference_Guide/sect-Realtime_Tuning_Guide-Timestamping-POSIX_Clocks.html#Realtime_Reference_Guide-Timestamping-COARSE_Clocks

says 1ms, but you could use clock_getres to get the actual resoluton of the COARSE clock. IIRC, I also ran into somewhere online that had a table comparing the various options and OSes, but I can't find it now.

The main reason the coarse clock seems like a wonky idea to me is that if you're getting the time quickly enough for it to matter, then you're doing it at way faster than 1 ms, so you're going to keep getting the same time over and over again. If that really doesn't matter for a particular use case, then obviously the coarse clock could be a good choice, but that strikes me as a rather odd use case where you don't actually care about the clock being slower than the rate you're asking for the time. But adding support for it doesn't really hurt anything as far as I can tell, and if it makes sense for std.log, then great, though if you're logging hundreds of thousands of messages a second, then I'd strongly argue that you're logging so much that it borders on useless. So, it seems to me that the test that's triggering this enhancement request seems fairly contrived rather than demonstrating much of anything practical.

--

https://issues.dlang.org/show_bug.cgi?id=13433

--- Comment #10 from Marco Leise <Marco.Leise@gmx.de> ---
You might be right.

--