Suggestion: Switch back to std::chrono::high_resolution_clock

[BerriJ]

Hi,

I figured the cause of the MacOS compilation problem that I mentioned earlier. It turns out that those 2 #defines were causing trouble:

#define duration(a) std::chrono::duration_cast<std::chrono::nanoseconds>(a).count()
#define now() std::chrono::steady_clock::now()

You can check out this clock.h file which compiles fine on every OS.

That said, you may want to switch back to using std::chrono::high_resolution_clock as it may be more accurate as discussed here.

Thanks again for this awesome package
BerriJ

[zdebruine]

Thanks, the #define statements are not used in the dev version (which should go to CRAN). I was waiting on CRAN submission until I could test std::chrono::high_resolution_clock vs std::chrono::steady_clock (currently on dev version) on more platforms. On three Windows machines, std::chrono::steady_clock accurately times ten-nanosecond-level processes, where std::chrono::high_resolution_clock times only processes consuming greater than 1 microsecond (100x less sensitive). On CentOS7, both perform equally well. Have you documented any cases where std::chrono::high_resolution_clock outperforms std::chrono::steady_clock other than the StackOverflow post? If there is evidence for improved performance beyond Windows (especially Linux), I certainly can switch back to std::chrono::high_resolution_clock. This appears to be very much an implementation-specific thing, and some implementations may actually use the same backends for multiple classes, but not Windows. I don't care about things like Daylights Savings Time affecting the output, and don't care about absolute runtime either, after all, we are after relative performance, and so a CPU clock vs a steady clock doesn't matter in the grand scheme of things.

[BerriJ]

On my Linux machine std::chrono::high_resolution_clock yields indeed nanoseconds resolution. However, the resolution depends on the specific CPU you have in your machine. I guess using std::chrono::high_resolution_clock does not have drawbacks.