Obtaining time difference in nanoseconds

Question

Referring to Obtaining Time in milliseconds

Why does below code produce zero as output?

int main()
{
    steady_clock::time_point t1 = steady_clock::now();
    //std::this_thread::sleep_for(std::chrono::milliseconds(1500));
    steady_clock::time_point t2 = steady_clock::now();
    auto timeC = t1.time_since_epoch().count();
    auto timeD = t2.time_since_epoch().count();
    auto timeA = duration_cast<std::chrono::nanoseconds > ( t1.time_since_epoch()).count();
    auto timeB = duration_cast<std::chrono::nanoseconds > ( t2.time_since_epoch()).count();

    std::cout << timeC << std::endl;
    std::cout << timeB << std::endl;
    std::cout << timeD << std::endl;
    std::cout << timeA << std::endl;

    std::cout << timeB - timeA << std::endl;


    system("Pause");
    return 0;
}

The output:

14374083030139686
1437408303013968600
14374083030139686
1437408303013968600
0
Press any key to continue . . .

I suppose there should be a difference of few nanoseconds, because of instruction execution time.

Your ticks aren't as fast as nanoseconds, so the tick count cannot be represented at nanosecond accuracy. Surely? Observe the clock's `period` to verify. You can't get better accuracy than the clock period. — Lightness Races in Orbit, Jul 20 '15 at 16:14
Well, your code doesn't do very much, so that's hardly a surprise either. What about if you add the sleep back in? — Lightness Races in Orbit, Jul 20 '15 at 16:15
@LightnessRacesinOrbit Do you think the compiler could optimize away the second function call since nothing happened in between? — NathanOliver, Jul 20 '15 at 16:18
@Nathan - No, the `now()` call likely involves an OS-call, which can not be optimized away. Your problem is that you read the clock more often than its hands move. — Bo Persson, Jul 20 '15 at 16:21
@NathanOliver: No but a single call to get the time takes a lot less than a millisecond. — Lightness Races in Orbit, Jul 20 '15 at 17:24

score 3 · Accepted Answer · edited May 23 '17 at 12:14

3

Under VS2012, steady_clock (and high_resolution_clock) uses GetSystemTimeAsFileTime, which has a very low resolution (and is non-steady to boot). This is acknowledged as a bug by Microsoft.

Your workaround is to use VS2015, use Boost.Chrono, or implement your own clock using QueryPerformanceCounter (see: https://stackoverflow.com/a/16299576/567292).

edited May 23 '17 at 12:14

Community

1
1

answered Jul 20 '15 at 16:28

ecatmur

152,476
27
293
366

Dale Wilson · Answer 2 · 2015-07-29T16:00:05.470

Just because you ask it to represent the value in nanoseconds, doesn't mean that the precision of the measurement is in nanoseconds.

When you look at your output you can see that the count are nanoseconds / 100. That that means that the count is representing time in units of 100 nanoseconds. But even that does not tell you the period of the underlying counter on which steady_clock is built. All you know is it can't be better than 100 nanoseconds.

You can tell the actual period used for the counter by using the periodmember of the steady_clock

double periodInSeconds = double(steady_clock::period::num) 
                       / double(steady_clock::period::den);

Back to your question: "Why does below code produce zero as output?"

Since you haven't done any significant work between the two calls to now() it is highly unlikely that you have used up 100 nanoseconds, so the answers are the same -- hence the zero.

Obtaining time difference in nanoseconds

2 Answers2