My title may not be very helpful, I have an std::chrono::nanosecond, but I am asked to serialise and provide the second, and then the nanosecond as different values in a JSON.
So although my struct holds:
struct time
{
...
std::chrono::nanoseconds timepoint;
};
when asked for seconds, I do
uint32_t sec() const
{
return std::chrono::duration_cast<std::chrono::seconds>(timepoint_).count();
}
yet when asked for nanoseconds, I want the resolution in nanoseconds, but without the seconds (only the least significant values?) however, casting in nanoseconds returns both the seconds and the higher resolution.
uint64_t nanosec() const
{
return std::chrono::duration_cast<std::chrono::nanoseconds>(timepoint_).count();
}
How can I calculate the actual increased resolution (e.g., the nanoseconds without the actual seconds)?
You can retrieve the seconds using std::duration_cast to std::seconds and the nanoseconds using modulo operator:
template <typename T>
std::pair<T, T> split (std::chrono::duration<T, std::nano> const& duration) {
using seconds = std::chrono::duration<T>;
return {std::chrono::duration_cast<seconds>(duration).count(),
(duration % seconds{1}).count()};
}
There is a good example on this page showing the use of arithmetic operators on std::chrono::duration to achieve exactly what you want.
user #Xarn offered the solution:
auto sec = std::chrono::duration_cast<std::chrono::seconds>(tp);
auto nsec = std::chrono::duration_cast<std::chrono::nanoseconds>(tp);
auto diff = std::chrono::duration_cast<std::chrono::nanoseconds>(nsec - sec).count();
leaves the nanosecond resolution without the seconds.
Related
I have a user-provided duration
const int period_seconds = cfg.period_seconds;
I would like to floor a time_point to the granularity of that duration.
I see that there is a std::chrono::floor function for time_point and duration, but it's not immediately obvious how to use them to do what I'm looking for.
I have the following toy example which works:
const auto seconds = std::chrono::seconds{period_seconds};
const auto period = std::chrono::duration_cast<std::chrono::nanoseconds>(seconds);
const auto now = std::chrono::system_clock::now();
const auto floored = now - (now.time_since_epoch() % period);
The net effect of the above code, for a duration of 10 seconds would be the following:
now: 2022-04-19 15:06:26.781772408
floored: 2022-04-19 15:06:20.000000000 # so "floors" the 25.78 seconds to 20 seconds
I can't help but feel that working in terms of the time_since_epoch and a modulus operator isn't the "right" way of getting the result I'm looking for...
Is there a "better" / recommended way to floor a time_point to some user-provided duration?
Your solution looks pretty good to me. However it can be slightly simplified. There's no need to form the nanoseconds-precision period. You can operate directly with seconds:
const auto floored = now - (now.time_since_epoch() % seconds);
std::chrono::system_clock::time_since_epoch().count() gives me a result in microseconds.
I want the current time in nanoseconds. But I can't use high_resolution_clock because on my system it is an alias on steady_clock (the monotonic clock).
I know my system is nanoseconds capable, because if I use clock_gettime(CLOCK_REALTIME, &ts) I am getting a correct nanosecond-resolution epoch time.
How can I tell std::chrono to use the nanosecond resolution? I'd like to avoid using clock_gettime and stick to the cpp wrapper.
How can I tell std::chrono to use the nanosecond resolution?
This sounds like a good use for writing your own custom clock. It is much easier than it sounds:
#include <time.h>
#include <chrono>
struct my_clock
{
using duration = std::chrono::nanoseconds;
using rep = duration::rep;
using period = duration::period;
using time_point = std::chrono::time_point<my_clock>;
static constexpr bool is_steady = false;
static time_point now()
{
timespec ts;
if (clock_gettime(CLOCK_REALTIME, &ts))
throw 1;
using sec = std::chrono::seconds;
return time_point{sec{ts.tv_sec}+duration{ts.tv_nsec}};
}
};
Just have your now() call clock_gettime with CLOCK_REALTIME. Then package up the return in a chrono::time_point with nanoseconds resolution.
Warning, I just tried this on macOS and called now() twice in a row. It printed out the same number of nanoseconds each time. And there's no way that the call is executing in under a nanosecond. So I'm getting nanosecond precision, but not nanosecond accuracy.
If you would like my_clock to participate in the C++20 std::chrono::clock_cast facility (as suggested by Nicol Bolas
in the comments below), add these two static member functions to my_clock:
template<typename Duration>
static
std::chrono::time_point<std::chrono::system_clock, Duration>
to_sys(const std::chrono::time_point<my_clock, Duration>& tp)
{
return std::chrono::time_point<std::chrono::system_clock, Duration>
{tp.time_since_epoch()};
}
template<typename Duration>
static
std::chrono::time_point<my_clock, Duration>
from_sys(const std::chrono::time_point<std::chrono::system_clock, Duration>& tp)
{
return std::chrono::time_point<my_clock, Duration>{tp.time_since_epoch()};
}
Now you can say things like:
cout << clock_cast<system_clock>(my_clock::now()) << '\n';
You will also be able to clock_cast to or from all other C++20 and custom clocks that participate in the clock_cast facility.
I am getting a correct nanosecond-resolution epoch time.
Are you? clock_gettime is required to return a time in nanoseconds, regardless of what clock you're accessing. This doesn't mean that CLOCK_REALTIME actually provides this resolution. It may internally only have microsecond resolution and expresses nanoseconds by multiplying by 1000.
By contrast, the actual resolution of a chrono clock is specified by the implementation. It is not a mandated part of the UI; it can vary from system to system and from clock to clock. So if a particular implementation's system_clock::period is in microseconds, then that is all the resolution the implementation is willing to claim to provide.
Maybe the implementation could provide more resolution, but if it could, it would probably say so. So if it doesn't, then that means the implementation doesn't feel comfortable claiming to provide more resolution.
However, if you feel that clock_gettime really does provide better resolution (rather than simply giving more digits), you can just use that. In C++20, system_clock is explicitly UNIX time. As such, if you have a time in nanoseconds, you can convert it to a time_point<system_clock, nanoseconds>:
namespace chrono = std::chrono;
...
using nano_sys = chrono::time_point<chrono::system_clock, chrono::nanoseconds>;
auto sys_tp_ns = nano_sys(chrono::nanoseconds(time_in_nanoseconds));
First of all, mind you that on GCC+libstc++ std::chrono is just a thin wrapper of syntax sugar around clock_gettime(). You are talking about the same thing here. std::chrono uses clock_gettime().
system_clock::time_point
system_clock::now() noexcept
{
timespec tp;
clock_gettime(CLOCK_REALTIME, &tp);
return time_point(duration(chrono::seconds(tp.tv_sec)
+ chrono::nanoseconds(tp.tv_nsec)));
}
Source: https://code.woboq.org/gcc/libstdc++-v3/src/c++11/chrono.cc.html
(above code was cleaned up)
So the precision is there, you just need to retrieve it in nanoseconds with
uint64_t utc_now_nanos() {
std::chrono::steady_clock::time_point tp = std::chrono::steady_clock::now();
return std::chrono::time_point_cast<std::chrono::nanoseconds>(tp).time_since_epoch().count();
}
Assuming I have the number of milliseconds in variable x:
chrono::milliseconds x = std::chrono::duration_cast<chrono::milliseconds>(something);
how do I convert x from chrono::milliseconds to uint64_t?
I have tried:
uint64_t num = std::chrono::duration_cast<uint64_t>(x);
but it says:
no matching function for call to
duration_cast(std::chrono::milliseconds&)
First of all, you generally shouldn't do this sort of thing. <chrono> provides a type-safe and generic units library for handling time durations, and there are few good reasons to escape this safety and genericity.
Some examples of the ills that don't happen with a type-safe, generic units library and which do happen with type-unsafe integral types:
// a type-safe units library prevents these mistakes:
int seconds = ...
int microseconds = seconds * 1000; // whoops
int time = seconds + microseconds; // whoops
void bar(int seconds);
bar(microseconds); // whoops
// a generic duration type prevents the need for:
unsigned sleep(unsigned seconds);
int usleep(useconds_t useconds);
int nanosleep(const struct timespec *rqtp, struct timespec *rmtp);
int attosleep(long long attoseconds); // ???
// just use:
template<typename Duration>
int sleep_for(Duration t); // users can specify sleep in terms of hours, seconds, microseconds, femetoseconds, whatever. Actual sleep duration depends on QoI, as always.
An example of a good reason would be compatibility with a third party library that made the unfortunate decision not to use a type-safe, generic units library in their API. In this case the conversions should be done as close as possible to the API boundary in order to minimize the extent to which unsafe types are used.
So with that said, when you do have a good reason, you do so like this:
std::chrono::milliseconds x = ...
std::uint64_t num = x.count();
Keep in mind that the predefined chrono durations such as chrono::milliseconds use signed representations, so you'll need to take care to ensure the value is appropriate for conversion to uint64_t.
The prototype for std::chrono::duration_cast is:
template <class ToDuration, class Rep, class Period>
constexpr ToDuration duration_cast(const duration<Rep,Period>& d);
You can't get an uint64_t directly, because it converts durations (duration_cast). So you need to create a std::duration with std::uint64_t.
using cast = std::chrono::duration<std::uint64_t>;
std::uint64_t ticks = std::chrono::duration_cast< cast >(something).count();
I have a duration
typedef std::chrono::high_resolution_clock Clock;
Clock::time_point beginTime;
Clock::time_point endTime;
auto duration = std::chrono::duration_cast<std::chrono::milliseconds>(endTime - beginTime);
And I get duration in std::chrono::milliseconds. But I need duration as float or long long. How to do that?
From the documentation
template<
class Rep,
class Period = std::ratio<1>
> class duration;
Class template std::chrono::duration represents a time interval. It
consists of a count of ticks of type Rep and a tick period, where the
tick period is a compile-time rational constant representing the
number of seconds from one tick to the next.
And:
count returns the count of ticks
So a duration stores a number of ticks of a specified period of time, and count will return that number using the underlying representation type. So if the duration's representation is long long, and the period is std::milli, then .count() will return a long long equal to the number of milliseconds represented by the duration.
In general you should avoid using weak types like float or long long to represent a duration. Instead you should stick with 'rich' types, such as std::chrono::milliseconds or an appropriate specialization of std::chrono::duration. These types aid correct usage and readability, and help prevent mistakes via type checking.
Underspecified / overly general:
– void increase_speed(double);
– Object obj; … obj.draw();
– Rectangle(int,int,int,int);
Better: – void increase_speed(Speed);
– Shape& s; … s.draw();
– Rectangle(Point top_left, Point bottom_right);
– Rectangle(Point top_left, Box_hw b);
— slide 18 from Bjarne's talk
std::chrono is "a consistent subset of a physical quantities library that handles only units of time and only those units of time with exponents equal to 0 and 1."
If you need to work with quantities of time you should take advantage of this library, or one that provides more complete unit systems, such as boost::units.
There are rare occasions where quantities must be degraded to weakly typed values. For example, when one must use an API that requires such types. Otherwise it should be avoided.
As float answer.
std::chrono's duration typedefs are integer. However, duration class can accept float.
See my duration typedefs:
https://github.com/faithandbrave/Shand/blob/master/shand/duration.hpp
...
template <class Rep>
using seconds_t = std::chrono::duration<Rep>;
using seconds_f = seconds_t<float>;
using seconds_d = seconds_t<double>;
using seconds_ld = seconds_t<long double>;
template <class Rep>
using minutes_t = std::chrono::duration<Rep, std::ratio<60>>;
using minutes_f = minutes_t<float>;
using minutes_d = minutes_t<double>;
using minutes_ld = minutes_t<long double>;
...
These durations usage is here:
#include <iostream>
#include <shand/duration.hpp>
int main()
{
std::chrono::seconds int_s(3);
shand::minutes_f float_m = int_s; // without `duration_cast`
std::cout << float_m.count() << std::endl; // 0.05
}
I'm writing a progress bar class that outputs an updated progress bar every n ticks to an std::ostream:
class progress_bar
{
public:
progress_bar(uint64_t ticks)
: _total_ticks(ticks), ticks_occured(0),
_begin(std::chrono::steady_clock::now())
...
void tick()
{
// test to see if enough progress has elapsed
// to warrant updating the progress bar
// that way we aren't wasting resources printing
// something that hasn't changed
if (/* should we update */)
{
...
}
}
private:
std::uint64_t _total_ticks;
std::uint64_t _ticks_occurred;
std::chrono::steady_clock::time_point _begin;
...
}
I would like to also output the time remaining. I found a formula on another question that states time remaining is (variable names changed to fit my class):
time_left = (time_taken / _total_ticks) * (_total_ticks - _ticks_occured)
The parts I would like to fill in for my class are the time_left and the time_taken, using C++11's new <chrono> header.
I know I need to use a std::chrono::steady_clock, but I'm not sure how to integrate it into code. I assume the best way to measure the time would be a std::uint64_t as nanoseconds.
My questions are:
Is there a function in <chrono> that will convert the nanoseconds into an std::string, say something like "3m12s"?
Should I use the std::chrono::steady_clock::now() each time I update my progress bar, and subtract that from _begin to determine time_left?
Is there a better algorithm to determine time_left
Is there a function in that will convert the nanoseconds into
an std::string, say something like "3m12s"?
No. But I'll show you how you can easily do this below.
Should I use the std::chrono::steady_clock::now() each time I update
my progress bar, and subtract that from _begin to determine time_left?
Yes.
Is there a better algorithm to determine time_left
Yes. See below.
Edit
I had originally misinterpreted "ticks" as "clock ticks", when in actuality "ticks" has units of work and _ticks_occurred/_total_ticks can be interpreted as %job_done. So I've changed the proposed progress_bar below accordingly.
I believe the equation:
time_left = (time_taken / _total_ticks) * (_total_ticks - _ticks_occured)
is incorrect. It doesn't pass a sanity check: If _ticks_occured == 1 and _total_ticks is large, then time_left approximately equals (ok, slightly less) time_taken. That doesn't make sense.
I am rewriting the above equation to be:
time_left = time_taken * (1/percent_done - 1)
where
percent_done = _ticks_occurred/_total_ticks
Now as percent_done approaches zero, time_left approaches infinity, and when percent_done approaches 1, 'time_left approaches 0. When percent_done is 10%, time_left is 9*time_taken. This meets my expectations, assuming a roughly linear time cost per work-tick.
class progress_bar
{
public:
progress_bar(uint64_t ticks)
: _total_ticks(ticks), _ticks_occurred(0),
_begin(std::chrono::steady_clock::now())
// ...
{}
void tick()
{
using namespace std::chrono;
// test to see if enough progress has elapsed
// to warrant updating the progress bar
// that way we aren't wasting resources printing
// something that hasn't changed
if (/* should we update */)
{
// somehow _ticks_occurred is updated here and is not zero
duration time_taken = Clock::now() - _begin;
float percent_done = (float)_ticks_occurred/_total_ticks;
duration time_left = time_taken * static_cast<rep>(1/percent_done - 1);
minutes minutes_left = duration_cast<minutes>(time_left);
seconds seconds_left = duration_cast<seconds>(time_left - minutes_left);
}
}
private:
typedef std::chrono::steady_clock Clock;
typedef Clock::time_point time_point;
typedef Clock::duration duration;
typedef Clock::rep rep;
std::uint64_t _total_ticks;
std::uint64_t _ticks_occurred;
time_point _begin;
//...
};
Traffic in std::chrono::durations whenever you can. That way <chrono> does all the conversions for you. typedefs can ease the typing with the long names. And breaking down the time into minutes and seconds is as easy as shown above.
As bames53 notes in his answer, if you want to use my <chrono_io> facility, that's cool too. Your needs may be simple enough that you don't want to. It is a judgement call. bames53's answer is a good answer. I thought these extra details might be helpful too.
Edit
I accidentally left a bug in the code above. And instead of just patch the code above, I thought it would be a good idea to point out the bug and show how to use <chrono> to fix it.
The bug is here:
duration time_left = time_taken * static_cast<rep>(1/percent_done - 1);
and here:
typedef Clock::duration duration;
In practice steady_clock::duration is usually based on an integral type. <chrono> calls this the rep (short for representation). And when percent_done is greater than 50%, the factor being multiplied by time_taken is going to be less than 1. And when rep is integral, that gets cast to 0. So this progress_bar only behaves well during the first 50% and predicts 0 time left during the last 50%.
The key to fixing this is to traffic in durations that are based on floating point instead of integers. And <chrono> makes this very easy to do.
typedef std::chrono::steady_clock Clock;
typedef Clock::time_point time_point;
typedef Clock::period period;
typedef std::chrono::duration<float, period> duration;
duration now has the same tick period as steady_clock::duration but uses a float for the representation. And now the computation for time_left can leave off the static_cast:
duration time_left = time_taken * (1/percent_done - 1);
Here's the whole package again with these fixes:
class progress_bar
{
public:
progress_bar(uint64_t ticks)
: _total_ticks(ticks), _ticks_occurred(0),
_begin(std::chrono::steady_clock::now())
// ...
{}
void tick()
{
using namespace std::chrono;
// test to see if enough progress has elapsed
// to warrant updating the progress bar
// that way we aren't wasting resources printing
// something that hasn't changed
if (/* should we update */)
{
// somehow _ticks_occurred is updated here and is not zero
duration time_taken = Clock::now() - _begin;
float percent_done = (float)_ticks_occurred/_total_ticks;
duration time_left = time_taken * (1/percent_done - 1);
minutes minutes_left = duration_cast<minutes>(time_left);
seconds seconds_left = duration_cast<seconds>(time_left - minutes_left);
std::cout << minutes_left.count() << "m " << seconds_left.count() << "s\n";
}
}
private:
typedef std::chrono::steady_clock Clock;
typedef Clock::time_point time_point;
typedef Clock::period period;
typedef std::chrono::duration<float, period> duration;
std::uint64_t _total_ticks;
std::uint64_t _ticks_occurred;
time_point _begin;
//...
};
Nothing like a little testing... ;-)
The chrono library includes types for representing durations. You shouldn't convert that to a flat integer of some 'known' unit. When you want a known unit just use the chrono types, e.g. 'std::chrono::nanoseconds', and duration_cast. Or create your own duration type using a floating point representation and one of the SI ratios. E.g. std::chrono::duration<double,std::nano>. Without duration_cast or a floating point duration rounding is prohibited at compile time.
The IO facilities for chrono didn't make it into C++11, but you can get source from here. Using this you can just ignore the duration type, and it will print the right units. I don't think there's anything there to that will show the time in minutes, seconds, etc., but such a thing shouldn't be too hard to write.
I don't know that there's too much reason to be concerned about calling steady_clock::now() frequently, if that's what your asking. I'd expect most platforms to have a pretty fast timer for just that sort of thing. It does depend on the implementation though. Obviously it's causing an issue for you, so maybe you could only call steady_clock::now() inside the if (/* should we update */) block, which should put a reasonable limit on the call frequency.
Obviously there are other ways to estimate the time remaining. For example instead of taking the average over the progress so far (which is what the formula you show does), you could take the average from the last N ticks. Or do both and take a weighted average of the two estimates.