[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #29 from github-bugzi...@puremagic.com --- Commits pushed to dmd-cxx at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/8e29e0621b074a8d368b4d7d344281adb7a91e54 Add ClockType enum to core.time for issue# 13433. https://github.com/dlang/druntime/commit/bcfc36b3ca5a229c751c972c607fee57d4febcb2 Merge pull request #990 from jmdavis/13433 --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #28 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/5f3c6f1a647c83247aea8811184d2b93f5147b46 Implement issue 13433: coarser realtime clock https://github.com/D-Programming-Language/phobos/commit/14330724fd4a24bea22c807310e7b46fa9167327 Merge pull request #2584 from jmdavis/13433 --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 Jonathan M Davis issues.dl...@jmdavisprog.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #27 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/5f3c6f1a647c83247aea8811184d2b93f5147b46 Implement issue 13433: coarser realtime clock This adds an option for getting the time using an alternative clock chosen via core.time.ClockType, including access to a coarser clock as requested by issue# 13433. For ClockType.normal, the normal clock which has always been used is used. For ClockType.coarse, a faster clock is used if available even if it's coarser so long as it still has sub-second precision, and the normal clock is used if no such clock is available. For ClockType.precise, a more precise clock is used if available (currently only on FreeBSD), otherwise the normal clock is used. For ClockType.second, a faster clock is used which only has second precision. If no such clock is available, then the normal clock is used, but the result is truncated to second precision. https://github.com/D-Programming-Language/phobos/commit/14330724fd4a24bea22c807310e7b46fa9167327 Merge pull request #2584 from jmdavis/13433 Implement issue 13433 - add option for using coarser realtime clock. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #26 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/8e29e0621b074a8d368b4d7d344281adb7a91e54 Add ClockType enum to core.time for issue# 13433. https://github.com/D-Programming-Language/druntime/commit/bcfc36b3ca5a229c751c972c607fee57d4febcb2 Merge pull request #990 from jmdavis/13433 --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Version|unspecified |D2 --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #25 from Jonathan M Davis issues.dl...@jmdavisprog.com --- https://github.com/D-Programming-Language/phobos/pull/2584 --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 Jonathan M Davis issues.dl...@jmdavisprog.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #23 from Jonathan M Davis issues.dl...@jmdavisprog.com --- The druntime changes have been pulled, but the Phobos changes - which is what the request is actually for - haven't been pulled yet. I have to finish updating the PR for them based on the druntime changes. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #24 from Steven Schveighoffer schvei...@yahoo.com --- (In reply to Jonathan M Davis from comment #23) The druntime changes have been pulled, but the Phobos changes - which is what the request is actually for - haven't been pulled yet. I have to finish updating the PR for them based on the druntime changes. Sorry, I thought the request applied to druntime, my mistake. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #18 from Vladimir Panteleev thecybersha...@gmail.com --- (In reply to Sobirari Muhomori from comment #17) How about server platforms? Those are less conservative than desktop. So we release two Windows DMD builds, one for client version of Windows and one for server versions? With the caveat that the binaries they produce might not be inter-compatible? Makes no sense. The function can just be loaded dynamically. This is already done in Phobos in a few places (grep for GetProcAddress). --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #19 from Sobirari Muhomori dfj1es...@sneakemail.com --- (In reply to Vladimir Panteleev from comment #18) Makes no sense. Already done: 64-bit executables are incompatible with 32-bit systems. I think, it fits D ideology good by default, closer to the system if requested. Well, I agree, dynamic loading is already good enough. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #20 from Vladimir Panteleev thecybersha...@gmail.com --- (In reply to Sobirari Muhomori from comment #19) Already done: 64-bit executables are incompatible with 32-bit systems. Except that: - We do not actually release separate 32-bit and 64-bit versions - 64-bit Windows versions go as early as Windows XP - The API in question is available equally on 32 and 64 bit editions of Windows - The pointer size has nothing to do with the OS edition or version. Like I said, makes no sense. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #17 from Sobirari Muhomori dfj1es...@sneakemail.com --- (In reply to Steven Schveighoffer from comment #16) But we can't require Windows 8 for D. How about server platforms? Those are less conservative than desktop. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #21 from Sobirari Muhomori dfj1es...@sneakemail.com --- I mean, D compiler can compile 64-bit programs, which are incompatible with 32-bit systems. And I believe 64-bit linux can be set up without ability to run 32-bit executables. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #22 from Steven Schveighoffer schvei...@yahoo.com --- Vladimir pointed out a mechanism to make the decision at runtime. That's the only option I see here. I'm not sure how it's done, but it seems it would incur some runtime cost. But I think it could be made to work. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #15 from Sobirari Muhomori dfj1es...@sneakemail.com --- BTW, Windows 8 has GetSystemTimePreciseAsFileTime function for time reading with better precision. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Steven Schveighoffer schvei...@yahoo.com --- (In reply to Sobirari Muhomori from comment #15) BTW, Windows 8 has GetSystemTimePreciseAsFileTime function for time reading with better precision. If there's a way to utilize this and still be binary compatible with Win XP, that might be possible. But we can't require Windows 8 for D. And actually, this has been pulled, so I think we can close this. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #14 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/8e29e0621b074a8d368b4d7d344281adb7a91e54 Add ClockType enum to core.time for issue# 13433. This adds an enum for indicating which type of clock to use when it's appropriate for a time function to have multiple options for the source clock. In the case of MonoTime, to make that work cleanly, the implementation of MonoTime has become MonoTimeImpl, templated on ClockType, and MonoTime has become an alias to MonoTimeImpl!(ClockType.normal). In the case of SysTime (in a separate PR), that will a default template argument to Clock.currTime and SysTime will be unaffected (because in MonoTime's case, the clock that it came from is integral to the type, whereas in SysTime's case, it doesn't matter after the SysTime has been initialized). https://github.com/D-Programming-Language/druntime/commit/bcfc36b3ca5a229c751c972c607fee57d4febcb2 Merge pull request #990 from jmdavis/13433 Add ClockType enum to core.time for issue# 13433. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #13 from Steven Schveighoffer schvei...@yahoo.com --- (In reply to Jonathan M Davis from comment #12) As I said, I'm not against adding it. It just seems to me that in most cases where you'd be getting the time that quickly, it wouldn't make sense to only have a resolution of 1 ms. Precision vs. speed of retrieval is a reasonable tradeoff which I find quite natural. Think of a printer's fast draft vs. best quality -- I can think of reasons where you would want both. The most obvious application is logging: you want logging to be very very light CPU time-wise, and the time of the log doesn't have to be generally precise (but it should be accurate). In fact, a log can do without time outputs if necessary -- the most important aspect is the order of the log. The time between two log messages is really a secondary concern. I think it should be added as an option. In regards to Windows or Mac options, I think it's OK to just return the same thing as a normal call at this point until we can find another possibility. The optional parameter can mean use fastest retrieval mechanism even if it's less precise which would be true if there's only one mechanism :) --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #11 from Kevin L kevin.lamo...@gmail.com --- std.logger's current design doesn't permit Logger subclasses to avoid the call to Clock.currTime() before they get control of the output at Logger.beginLogMsg()/writeMsgPart()/finishLogMsg()/writeLogMsg(). It also doesn't provide any method to filter except via Logger.logLevel = something. Together these mean in practice that filtering on anything other that logLevel cannot be performed very quickly. Here are some use cases where a std.logger client might send millions of log calls/sec into Logger.writeLogMsg(), but the Logger implementation emits only a little output: * Filtering on LogEntry.msg text itself, i.e. only show messages that match this regex. This is equivalent to Log4j/Log4perl/Log4D StringMatch filter. * Filtering on an exact log level rather than at equal or greater to log level. This is equivalent to Log4j/Log4perl/Log4D LevelMatch filter. * Filtering on a restricted range of log levels rather than all at equal or greater to log level. This is equivalent to Log4j/Log4perl/Log4D LevelRange filter. * Filtering on a Thread/Tid/etc. * Writing all messages to a memory buffer, but only emitting the last X when an ERROR level message comes in. This is equivalent to Log4perl/Log4D BufferAppender. * Any kind of dynamic filtering such as, when you see _this_ kind of message, start logging a bunch of stuff until you see _that_ kind of message. These could be addressed solely in the std.logger API, but we could also get 90% time gain here. As the submitter, obviously I have a bit of bias already. But the other use cases that led to CLOCK_REALTIME_COARSE/CLOCK_REALTIME_FINE are still out there, e.g. the V8 codec uses it when it is 1ms resolution. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #12 from Jonathan M Davis jmdavisp...@gmx.com --- As I said, I'm not against adding it. It just seems to me that in most cases where you'd be getting the time that quickly, it wouldn't make sense to only have a resolution of 1 ms. And even if it's being filtered, I would think that it would usually be rather ridiculous to be logging stuff hundreds of thousands of times a second and that the number of logging statements should be seriously reduced in such code, so I really think that that's a pretty crazy use case. But I'll add the ability to use the coarse clock instead and let folks shoot themselves in the foot with it if they really want to. Given that it was added to both Linux and FreeBSD's APIs, presumably there are at least some folks who think that it's worth having, even if I think that it's kind of crazy. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #5 from Jonathan M Davis jmdavisp...@gmx.com --- H. 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. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #6 from Jonathan M Davis jmdavisp...@gmx.com --- https://github.com/D-Programming-Language/phobos/pull/2584 --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #7 from Marco Leise marco.le...@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. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433
--- Comment #8 from Marco Leise marco.le...@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.
--
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #9 from Jonathan M Davis jmdavisp...@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. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #10 from Marco Leise marco.le...@gmx.de --- You might be right. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||jmdavisp...@gmx.com, ||schvei...@yahoo.com --- Comment #3 from Steven Schveighoffer schvei...@yahoo.com --- CCing Jonathan. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 Marco Leise marco.le...@gmx.de changed: What|Removed |Added CC||marco.le...@gmx.de --- Comment #4 from Marco Leise marco.le...@gmx.de --- Yes, he is the master of time. --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- Shouldn't you be using the monotonic clock for benchmarking? --
[Issue 13433] Request: Clock.currTime option to use CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST
https://issues.dlang.org/show_bug.cgi?id=13433 --- Comment #2 from Vladimir Panteleev thecybersha...@gmail.com --- Oh, I see - std.logger needs the realtime clock to log the time together with the log message. --
