Question

I am attempting to transition an existing program to use the new time facilities in C++11 from (homegrown) existing time classes. For real-time processing it is clear how to map the C++11 functionality into the homegrown time classes. It is less clear how the C++11 chrono time facilities can be used to support a non-real time mode (e.g., a “run as fast as you can batch mode”, a “run at quarter speed demonstration mode”, etc.) which the homegrown classes support. Is this accomplished via defining special clocks that are mapping the wall time to the “playback” speed properly? Any help appreciated and an example would be fantastic.

For example, the code I will transitioning has constructs such as

MessageQueue::poll( Seconds( 1 ) );

or

sleep( Minutes( 2 ) );

where the Seconds or Minutes object is aware of the speed at which the program is being run at to avoid having to use a multiplier or conversion function all of over the place like

MessageQueue::poll( PlaybackSpeed * Seconds( 1 ) );

or

MessageQueue::poll( PlaybackSpeed( Seconds( 1 ) ) );

What I was hoping was possible was to obtain the same sort of behavior with std::chrono::duration and std::chrono::time_point by providing a custom clock.

Answer 1

Whether or not making your own clock will be sufficient depends on how you use the time durations you create. For example if you wanted to run at half speed but somewhere called:

std::this_thread::sleep_for(std::chrono::minutes(2));

The duration would not be adjusted. Instead you’d need to use sleep_until and provide a time point that uses your ‘slow’ clock. But making a clock that runs slow is pretty easy:

template<typename Clock,int slowness>
struct slow_clock {
    using rep = typename Clock::rep;
    using period = typename Clock::period;
    using duration = typename Clock::duration;
    using time_point = std::chrono::time_point<slow_clock>;

    constexpr static bool is_steady = Clock::is_steady;

    static time_point now() {
        return time_point(start_time.time_since_epoch() + ((Clock::now() - start_time)/slowness));
    }

    static const typename Clock::time_point start_time;
};

template<typename Clock,int slowness>
const typename Clock::time_point
slow_clock<Clock,slowness>::start_time = Clock::now();

The time_points returned from now() will appear to advance at a slower rate relative to the clock you give it. For example here’s a program so you can watch nanoseconds slowly tick by:

int main() {
    using Clock = slow_clock<std::chrono::high_resolution_clock,500000000>;
    for(int i=0;i<10;++i) {
        std::this_thread::sleep_until(Clock::now()
                                      + std::chrono::nanoseconds(1));
        std::cout << "tick\n";
    }
}

All of the functions you implement, like MessageQueue::poll(), will probably need to be implemented in terms of a global clock typedef.

Of course none of this has anything to do with with how fast the program actually runs, except insofar as you’re slowing down the program based on them. Functions that time out will take longer, sleep_until will take be longer, but operations that don’t wait for some time point in the future will simply appear to be faster.

// appears to run a million times faster than normal according to (finish-start)
auto start = slow_clock<steady_clock,1000000>::now();
do_slow_operation();
auto finish = slow_clock<steady_clock,1000000>::now();