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);
Related
Suppose I want to call my_func() periodically at CALL_PERIOD intervals
auto last_call_time = CHRONO_NEGATIVE_INFINITY;
while (true)
{
if (std::chrono::system_clock::now() - last_call_time > CALL_PERIOD)
{
last_call_time = std::chrono::system_clock::now();
my_func();
}
}
What would be an appropriate CHRONO_NEGATIVE_INFINITY such that the line
std::chrono::system_clock::now() - last_call_time > CALL_PERIOD
will always evaluate true on the first run?
I've tried time_point::min() but that doesn't seem to work
One of the main reasons to have a type like std::optional is so that we don't have to have hacks like picking a specific value to mean "not a value":
std::optional<std::chrono::system_clock::time_point> last_call_time;
while (true)
{
auto curr = std::chrono::system_clock::now()
if (!last_call_time || (curr - *last_call_time) > CALL_PERIOD)
{
last_call_time = std::chrono::system_clock::now();
my_func();
}
}
If C++17 is not available to you, and/or you're just dead-set on using the old hack of picking a special value, you can get the clock's rep type and compute the minimum possible integer of it:
using sys_clock = std::chrono::system_clock;
constexpr auto min_int = std::numeric_limits<sys_clock::rep>::min();
constexpr sys_clock::duration min_duration(min_int);
sys_clock::time_point min_time(min_duration);
Of course, min_time is still a valid time, so it's unlike any "infinity" representation for floats.
The rationale that there is no time_point::infinity equivalent is that time_points are simple wrappers around arithmetic types. Simplistic wrappers lead to the highest performing code. And this same rationale is also a clue that for special cases, time_point::infinity actually does exist!
Let me elaborate further on that entirely confusing first paragraph...
system_clock::time_point is a simple wrapper around a duration. Exactly which duration is unspecified, but let's just say it is nanoseconds. And nanoseconds is a simple wrapper around a 64 bit signed integer (say long long).
long long has no representation of +/- INFINITY. But it does have a minimum value: -9223372036854775808.
A shortcut for putting this value into a duration (say nanoseconds) is nanoseconds::min(), and a shortcut to putting this value into system_clock::time_point is system_clock::time_point::min().
However when you do so, it is an invitation for plain old signed integral overflow. After all:
cout << (10 - numeric_limits<long long>::min() > 1) << '\n';
overflows and prints out 0 (false). And that's precisely why:
auto CHRONO_NEGATIVE_INFINITY = system_clock::time_point::min();
didn't work.
There are several ways to get your code to work. Which is best for your application is up to you. But now that <chrono> is just a little less mysterious, you can better make that decision.
Perhaps the easiest way is to set CHRONO_NEGATIVE_INFINITY to something that isn't quite so negative so that you don't risk overflow:
auto CHRONO_NEGATIVE_INFINITY = std::chrono::system_clock::now() - CALL_PERIOD;
C++20 standardizes the existing practice that system_clock's epoch is 1970-01-01, so here's another possibility (that works back to C++11):
// Set CHRONO_NEGATIVE_INFINITY to 1970-01-01 00:00:00 UTC
auto CHRONO_NEGATIVE_INFINITY = std::chrono::system_clock::time_point{};
But let's say that for some reason you really, really need a time_point that is infinitely in the past. You can do that too, it just takes a little more work. float and double are arithmetic types too, and they do have a representation of INFINITY! So you can just build a time_point out of one of those types.
using dsec = std::chrono::duration<double>;
using tp_dsec = std::chrono::time_point<std::chrono::system_clock, dsec>;
auto CHRONO_NEGATIVE_INFINITY = tp_dsec{dsec{-INFINITY}};
The first line makes dsec a name for double-based-seconds. The second line makes tp_dsec a name for a system_clock-based time_point using dsec as its representation. And then the third line just stuffs negative infinity into a tp_dsec. The rest of your code will implicitly convert to double-based time_points and durations when doing the test.
If you rewrite your test like this:
auto last_call_time = std::chrono::system_clock::min();
...
if (std::chrono::system_clock::now() - CALL_PERIOD > last_call_time)
you shouldn't overflow.
Use 0:
std::chrono::duration CALL_PERIOD(std::chrono::seconds(2));
std::chrono::steady_clock::time_point last_call_time; //auto init to 0,
// or can use explicit initialization to 0:
// std::chrono::steady_clock::time_point last_call_time(std::chrono::seconds(0));
while (true)
{
auto now = std::chrono::steady_clock::now();
if (now - last_call_time > CALL_PERIOD)
{
last_call_time = now;
my_func();
}
}
How can one multiply a chrono timepoint by a scalar? It works for durations, but timepoints can't be multiplied by a scalar ("error: invalid operands to binary expression").
Context:
I have some code that in real life will run for a long time. For testing purposes, I want to be able to speed it up by a factor, so everything happens similarly, but just in fast forward.
I thought of making my own ScaledClock class, that returns values from chrono::steady_clock, but with a scaling parameter that can be set to something greater than 1 to achieve a speed up. Here is some code:
steady_clock::time_point ScaledClock::now() {
return steady_clock::now() * speedUp; // <--- error
}
void ScaledClock::sleep_for(steady_clock::duration duration) {
std::this_thread::sleep_for(duration / speedUp);
}
void ScaledClock::sleep_until(steady_clock::time_point time) {
std::this_thread::sleep_until(time / speedUp); // <--- error
}
If the speedUp is 2, for instance, then the program will always think that twice as much time has passed. It will also sleep for half as long. As long as I am disciplined about not using this class for all timing, I think it should work.
(Alternatively, if someone has a much better way of achieving this, I'd love to hear it).
Edit: copy of comment, because I think it is useful clarification:
en.cppreference.com/w/cpp/chrono/time_point:
Class template std::chrono::time_point represents a point in time. It
is implemented as if it stores a value of type Duration indicating the
time interval from the start of the Clock's epoch.
So I want all the times since the epoch doubled. If the epoch is not start of program execution, and my code happens to think that it is running in 4036, I'm not really bothered
You will need to store a starting point (now() e.g. at program start) and then determine the time passed since that starting point as a duration. You can then add this duration multiplied with your factor to the start point and return it as time point in your ScaledClock::now() function. Just like this:
#include <chrono>
#include <unistd.h>
int main() {
auto start = std::chrono::steady_clock::now();
sleep(1);
auto actualNow = std::chrono::steady_clock::now();
auto timePassed = actualNow - start;
auto timePassedScaled = timePassed * 2.0;
auto scaledNow = start + timePassedScaled;
return 0;
}
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.
I'm using OpenCV to write a video file. For cv::VideoWriter to work correctly the call to the write() function has to happen exactly 30 times per second (for a 30fps video).
I found this code which uses the boost library to achieve this. I want to to the same but using std::chrono in my program. This is my implementation:
std::chrono::high_resolution_clock::time_point prev = std::chrono::high_resolution_clock::now();
std::chrono::high_resolution_clock::time_point current = prev;
long long difference = std::chrono::duration_cast<std::chrono::microseconds>(current-prev).count();
while(recording){
while (difference < 1000000/30){
current = std::chrono::high_resolution_clock::now();
difference = std::chrono::duration_cast<std::chrono::microseconds>(current-prev).count();
}
theVideoWriter.write(frameToRecord);
prev = prev + std::chrono::high_resolution_clock::duration(1000000000/30);
difference = std::chrono::duration_cast<std::chrono::microseconds>(current-prev).count();
}
theVideoWriter.release();
I'm not sure if thats the correct way to do this or if there is a more efficient way. Is there anything better than casting the duration to long long difference?
There is a basic tenant to working with chrono, which goes something like:
If you use count(), and/or you have conversion factors in your
chrono code, then you're trying too hard.
This is not your fault. There really is no good chrono tutorial and that is my bad, and I've recently decided I need to do something about that.
In your case, I recommend rewriting your code along the lines of the following:
First create a duration unit which represents the period of your frame rate:
using frame_period = std::chrono::duration<long long, std::ratio<1, 30>>;
Now when you say frame_period{1}, that means exactly 1/30 of a second.
The next thing to note is that chrono comparisons are always exact, as long as you stay in the chrono system. count() is a "trap door" for escaping out of the chrono system. Only escape out when you have no other choice. So...
auto prev = std::chrono::high_resolution_clock::now();
auto current = pref;
// Just get the difference, and don't worry about the units for now
auto difference = current-prev;
while(recording)
{
// Find out if the difference is less than one frame period
// This comparison will do all the conversions for you to get an exact answer
while (difference < frame_period{1})
{
current = std::chrono::high_resolution_clock::now();
// stay in "native units"...
difference = current-prev;
}
theVideoWriter.write(frameToRecord);
// This is a little tricky...
// prev + frame_period{1} creates a time_point with a complicated unit
// Use time_point_cast to convert (via truncation towards zero) back to
// the "native" duration of high_resolution_clock
using hr_duration = std::chrono::high_resolution_clock::duration;
prev = std::chrono::time_point_cast<hr_duration>(prev + frame_period{1});
// stay in "native units"...
difference = current-prev;
}
theVideoWriter.release();
The comments above are overly verbose once you get chrono. There's more comment than code above. But the above just works as you intended, with no need for "escaping out" of the chrono system.
Update
If you would want to initialize difference such that the inner loop won't be executed the first time, you could initialize it to something just over frame_period{1} instead of to 0. To do this, the utilities found here come in handy. Specifically ceil:
// round up
template <class To, class Rep, class Period>
To
ceil(const std::chrono::duration<Rep, Period>& d)
{
To t = std::chrono::duration_cast<To>(d);
if (t < d)
++t;
return t;
}
ceil is a replacement for duration_cast that will round up when the conversion is inexact, as opposed to truncate towards zero. Now you can say:
auto difference = ceil<hr_duration>(frame_period{1});
And you are guaranteed that difference >= frame_period{1}. Furthermore, it is known in practice that the duration of high_resolution_clock is nanoseconds, thus you can deduce (or test) that difference is actually initialized to 33,333,334ns, which is 2/3 of a nanosecond greater than 1/30 of a second, which equals frame_period{1}, which equals 33,333,333+1/3ns.
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.