Re: [lmi] Using std::chrono::high_resolution_clock for Timer implementation

[Vadim Zeitlin]

On Thu, 3 Jun 2021 19:14:20 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> I never studied std::chrono in much depth, because all of lmi's
GC> chronological needs are met, and also because this doesn't seem
GC> to be one of the LWG's better efforts. For example, overloading
GC> the division operator to mean a field separator is abusive, but
GC> several dozen overloads is an outrage.

 I don't like this neither, but this ship has sailed a long time ago and
Howard Hinnant (whose opinion you seem to respect if I remember the past
discussions correctly) is still adamant about it being the best thing to do
and his only advice for people like me and you is to avoid using these
operators if you dislike them, which is exactly what I do in my own code.

 But, more importantly, we're speaking just about clocks here, not dates,
so this is completely unrelated to the subject at hand.

GC> If temporary convenience in one source file you're working on is
GC> the motivation, then would something as simple as
GC> 
GC> +#include "timer.hpp"
GC> +#include "timer.cpp"
GC> 
GC> be enough?

 This would make compiling this file even longer and, well, just seems
ugly. But currently I insert

        #include "stop_watch.hpp"

with my own code anyhow, so I guess it's not that different.

GC> >  Again, this is not urgent at all but I just wanted to confirm that you
GC> > didn't have any objections to it before adding it to my TODO list/queue
GC> > (actually I should probably switch to a hash soon, for better access 
speed,
GC> > considering its size...).
GC> 
GC> What we have is familiar and well validated; why replace it?

 To get rid of ugly-looking platform-specific code, possibly making it
portable to more platforms in the future. And just to reduce the line count
which is IMO always a good thing.

GC> Perhaps using a tiny part like std::chrono::high_resolution_clock
GC> would be a good idea for the long term, as it would automatically
GC> adapt to operating-system changes.

 Yes.

GC> That might even make sense in the short term, if we can verify that the
GC> bindings to glibc and msw are correct--for glibc, I don't think we'd
GC> even have to ask, but for MinGW-w64, it's important to ask.

 Yes, verifying this is part of what I planned to do.

GC> Oh, but wait:
GC> 
GC>   https://en.cppreference.com/w/cpp/chrono/high_resolution_clock
GC> | The high_resolution_clock is not implemented consistently across
GC> | different standard library implementations, and its use should be
GC> | avoided.
GC> 
GC> Of course, that's not normative, but it seems scary: it sounds
GC> like if I decide I want a high-resolution clock (which I can
GC> implement very well myself), but some implementation decides to
GC> veto my decision, then they prevail. Shouldn't I just veto them
GC> in advance by avoiding std::chrono?

 No, I don't think so because I don't know of any platform that does this
and I think it's rather unlikely that any of the currently supported ones
would ever do it.

GC> And if we use std::chrono for this, what do we get when we ask
GC> for the tick count? A 64-bit integer? No: std::chrono::time_point,
GC> with a helper class std::common_type<std::chrono::time_point> and
GC> so on. Why isn't that wrong? Why shouldn't it be as simple as an
GC> integral tick count? I worry that using any part of std::chrono
GC> introduces a taint that would tend to propagate.

 I admit that I also find time_point and durations over-generic, but this
might be appropriate for the standard library which is supposed to be used
in many different circumstances. Of course, in your particular
circumstances you don't need to use all of these possibilities and just
need to select whether you want to use an integer or a floating-type for
the ticks representation and the scaling you want to use.

 E.g. in my stop_watch.hpp I just do the equivalent of the following:

    using clock = std::chrono::high_resolution_clock;
    clock::time_point const start = clock::now();

    ... code to benchmark here ...

    clock::duration const elapsed = clock::now() - start;
    std::cerr
        << "Elapsed time: "
        << std::setw(10)
        << 
std::chrono::duration_cast<std::chrono::microseconds>(elapsed).count()
        << "us\n"
        ;

which is really not that bad and definitely much simpler than the
equivalent code in timer.cpp.

 Isn't it?
VZ

pgp4YYy81zLTO.pgp
Description: PGP signature