Time measurements - Unix

This is a discussion on Time measurements - Unix ; Hi, in a C++ application running on Linux I'd like to measure the runtime of different code parts. Probably, the best way is to set a time before I run the code fragment I'd like to analyze, then have the ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 28

Thread: Time measurements

  1. Time measurements

    Hi,

    in a C++ application running on Linux I'd like to measure the
    runtime of different code parts. Probably, the best way is
    to set a time before I run the code fragment I'd like to analyze,
    then have the code executed and after that stop the timer and
    display the elapsed time. But how is this done in practice?
    If possible the measured time should be in seconds.

    Regards,
    Tim

  2. Re: Time measurements

    On Oct 8, 7:19 pm, Tim Frink wrote:
    > Hi,
    >
    > in a C++ application running on Linux I'd like to measure the
    > runtime of different code parts. Probably, the best way is
    > to set a time before I run the code fragment I'd like to analyze,
    > then have the code executed and after that stop the timer and
    > display the elapsed time. But how is this done in practice?
    > If possible the measured time should be in seconds.
    >
    > Regards,
    > Tim



    You should probably use "time" to measure application runtime under
    Linux, simply type

    time program

    in a command shell (of course "program" is the name of the application
    you want to measure).

    Regards,
    Viqtor
    Serbia


  3. Re: Time measurements

    On Mon, 08 Oct 2007 21:17:24 +0000, viqtor13th wrote:

    >
    > You should probably use "time" to measure application runtime under
    > Linux, simply type
    >
    > time program


    This will not do the job since "time" returns the different runtimes
    for the entire application "program". What I need is a C++ functionality
    that I can invoke within my C++ application to measure small code
    parts.

  4. Re: Time measurements

    Tim Frink wrote On 10/08/07 17:31,:
    > On Mon, 08 Oct 2007 21:17:24 +0000, viqtor13th wrote:
    >
    >
    >>You should probably use "time" to measure application runtime under
    >>Linux, simply type
    >>
    >>time program

    >
    >
    > This will not do the job since "time" returns the different runtimes
    > for the entire application "program". What I need is a C++ functionality
    > that I can invoke within my C++ application to measure small code
    > parts.


    If the parts are "small" their execution times may
    be difficult to measure with great accuracy.

    Still, you might try the gethrtime() function.
    Call it and save its value, execute your code, and call
    gethrtime() again. Subtract the two values to get the
    elapsed time in nanoseconds. Sounds simple, but

    - The fact that the elapsed time is *expressed* in
    nanoseconds doesn't prove that it is actually measured
    that finely. The resolution of the underlying "clock"
    may be noticeably coarser, producing gethrtime() values
    that are constant for a while and then suddenly jump
    by several steps. The true resolution probably varies
    from machine to machine.

    - The measurement is of elapsed wall-clock time,
    not of elapsed CPU time. If your code is suspended
    while the CPU services an interrupt or while another
    process gets a time slice, gethrtime() keeps on ticking
    while your code isn't running.

    - If your code is very brief, the time to execute
    gethrtime() itself may be significant. For example,
    if each gethrtime() call takes ten nanoseconds and your
    code takes two nanoseconds, a simple subtraction will
    show an elapsed time of around twelve nanoseconds, much
    longer than the actual time your code took.

    You'll need to exercise some care to deal with
    difficulties like these.

    --
    Eric.Sosman@sun.com

  5. Re: Time measurements

    Eric Sosman wrote:
    > - The measurement is of elapsed wall-clock time,
    > not of elapsed CPU time. If your code is suspended
    > while the CPU services an interrupt or while another
    > process gets a time slice, gethrtime() keeps on ticking
    > while your code isn't running.


    And just being paranoid - keep in mind that gethrtime() has no
    relationship on which you should count with the time of day.

    Besides HP-UX and Solaris, which platforms have gethrtime() now
    anyway?

    rick jones
    --
    web2.0 n, the dot.com reunion tour...
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  6. Re: Time measurements

    Rick Jones wrote:
    > Eric Sosman wrote:
    >> - The measurement is of elapsed wall-clock time,
    >> not of elapsed CPU time. If your code is suspended
    >> while the CPU services an interrupt or while another
    >> process gets a time slice, gethrtime() keeps on ticking
    >> while your code isn't running.

    >
    > And just being paranoid - keep in mind that gethrtime() has no
    > relationship on which you should count with the time of day.
    >
    > Besides HP-UX and Solaris, which platforms have gethrtime() now
    > anyway?


    Googling "gethrtime Linux" turns up lots of hits, and I
    took that as evidence that Linux provided it. A closer look
    suggests that on at least some Linux versions gethrtime is
    merely a wrapper on gettimeofday, which might not meet the
    original poster's need for measuring "small" pieces of code.

    I'm not familiar enough with the different breeds of Linux
    to know whether this is true of all of them.

    --
    Eric Sosman
    esosman@ieee-dot-org.invalid

  7. Re: Time measurements

    Tim Frink wrote:
    > On Mon, 08 Oct 2007 21:17:24 +0000, viqtor13th wrote:
    >
    >> You should probably use "time" to measure application runtime under
    >> Linux, simply type
    >>
    >> time program

    >
    > This will not do the job since "time" returns the different runtimes
    > for the entire application "program". What I need is a C++ functionality
    > that I can invoke within my C++ application to measure small code
    > parts.


    At this point, I'm not sure if you're talking about elapsed real-world
    ("wall clock") time or CPU-seconds. I think it's the former, but it might
    be the latter.

    In any case, as long as one-second resolution is good enough, you
    can do this:

    time_t before = time(NULL);
    do_something();
    time_t after = time(NULL);

    printf ("My code took %d seconds\n", (int) (after - before));

    If you need better resolution, you'll want to do this:

    struct timeval beforetv;
    gettimeofday(&beforetv, NULL);
    double before = beforetv.tv_sec + beforetv.tv_usec / 1000000.0;

    do_something():

    struct timeval aftertv;
    gettimeofday(&aftertv, NULL);
    double after = aftertv.tv_sec + aftertv.tv_usec / 1000000.0;

    printf ("My code took %f seconds\n", after - before);

    Of course, microsecond resolution will probably not be meaningful
    given how much inherent noise there is in the measurement, but something
    better than 1 second resolution probably is meaningful.

    - Logan

  8. Re: Time measurements

    Logan Shaw wrote:
    > If you need better resolution, you'll want to do this:
    >
    > struct timeval beforetv;
    > gettimeofday(&beforetv, NULL);
    > double before = beforetv.tv_sec + beforetv.tv_usec / 1000000.0;
    >
    > do_something():
    >
    > struct timeval aftertv;
    > gettimeofday(&aftertv, NULL);
    > double after = aftertv.tv_sec + aftertv.tv_usec / 1000000.0;
    >
    > printf ("My code took %f seconds\n", after - before);


    Is this somehow better than clock() ("man clock")? How?

    HT

  9. Re: Time measurements

    On 2007-10-08, Tim Frink wrote:
    > in a C++ application running on Linux I'd like to measure the
    > runtime of different code parts. Probably, the best way is

    [...]

    Have you considered using gprof? I've used it couple times and it works
    more or less acceptable. Try man gprof or info gprof.

    --
    Minds, like parachutes, function best when open

  10. Re: Time measurements

    Henry Townsend wrote:
    > Logan Shaw wrote:
    >> If you need better resolution, you'll want to do this:
    >>
    >> struct timeval beforetv;
    >> gettimeofday(&beforetv, NULL);
    >> double before = beforetv.tv_sec + beforetv.tv_usec / 1000000.0;
    >>
    >> do_something():
    >>
    >> struct timeval aftertv;
    >> gettimeofday(&aftertv, NULL);
    >> double after = aftertv.tv_sec + aftertv.tv_usec / 1000000.0;
    >>
    >> printf ("My code took %f seconds\n", after - before);

    >
    > Is this somehow better than clock() ("man clock")? How?


    You trimmed the part where I stated my assumption that the original
    poster wanted wall-clock time, not CPU time. (Maybe their code is
    doing I/O, and it's the speed of the I/O they want to measure, and
    the CPU time used is largely irrelevant.)

    Of course, I don't really know which one the original poster wants
    since they weren't completely clear on that.

    - Logan

  11. Re: Time measurements


    >
    > Of course, I don't really know which one the original poster wants
    > since they weren't completely clear on that.
    >
    > - Logan



    I am working on a game loop project that requires these timing
    functions. Hopefully this helps, i am still learning the best ways to
    do this. Also most of my reference has been from Advanced Unix
    programming by Marc J. Rochkind. http://basepath.com/aup/.

    To do my timing loop i am using something based on the following.

    #include
    /* This gets time based on CLOCK_REALTIME */
    struct timespec ts1, ts2, difference;
    clock_gettime( CLOCK_REALTIME, &ts1);
    do_foo();
    clock_gettime( CLOCK_REALTIME, &ts2);

    /* Version of difference based off the "Date and Time --> Elapsed
    Time" section of `info libc' */
    timespec_difference(&difference, &ts2, &ts1); /* subtracts ts1 from
    ts2 and stores in difference */

    printf("Difference: %ld,%09ld s \n", (long)difference.tv_sec,
    (long)difference.tv_nsec);


    In the AUP text above it is stated with a more thorough example that
    using you will get the
    'clock_t times(struct tms * time_buffer)' function which populates the
    tms struct and returns time in clock ticks.
    struct tms {
    clock_t tms_utime; /* user time */
    clock_t tms_cutime; /* user time of terminated children *
    clock_t tms_stime; /* sys time */
    clock_t tms_cstime; /* sys time of terminated children */
    };

    hopefully this helps, i have yet to play with the ' times ' function
    yet. I would absolutely recommend getting the book I mentioned, it
    has helped me out tremendously.

    - James.



  12. Re: Time measurements

    Logan Shaw wrote:
    > Henry Townsend wrote:
    >> Logan Shaw wrote:
    >>> If you need better resolution, you'll want to do this:
    >>>
    >>> struct timeval beforetv;
    >>> gettimeofday(&beforetv, NULL);
    >>> double before = beforetv.tv_sec + beforetv.tv_usec / 1000000.0;
    >>>
    >>> do_something():
    >>>
    >>> struct timeval aftertv;
    >>> gettimeofday(&aftertv, NULL);
    >>> double after = aftertv.tv_sec + aftertv.tv_usec / 1000000.0;
    >>>
    >>> printf ("My code took %f seconds\n", after - before);

    >>
    >> Is this somehow better than clock() ("man clock")? How?

    >
    > You trimmed the part where I stated my assumption that the original
    > poster wanted wall-clock time, not CPU time.


    Ah, sorry, I had myself missed the fact that clock() tracks CPU time. I
    had always assumed it measured elapsed (wall-clock) time.

    HT

  13. Re: Time measurements

    On 2007-10-10, openjaf wrote:
    [...]
    > To do my timing loop i am using something based on the following.
    >
    > #include
    > /* This gets time based on CLOCK_REALTIME */
    > struct timespec ts1, ts2, difference;
    > clock_gettime( CLOCK_REALTIME, &ts1);
    > do_foo();
    > clock_gettime( CLOCK_REALTIME, &ts2);
    >
    > /* Version of difference based off the "Date and Time --> Elapsed
    > Time" section of `info libc' */
    > timespec_difference(&difference, &ts2, &ts1); /* subtracts ts1 from
    > ts2 and stores in difference */

    [...]

    Interesting. How does your code handles time changes? The man page for
    these functions have the following statement

    All implementations support the system-wide realtime clock,
    which is identified by CLOCK_REALTIME. Its time represents
    seconds and nanoseconds since the Epoch. When its time is
    changed, timers for a relative interval are unaffected, but
    timers for an absolute point in time are affected.

    But it's not clear for me what do they mean under "timers for a relative
    interval". Looks like the code marks one absolute point, then another
    one, and then takes the difference. This will bring problems when the
    time changes (Daylight saving for example). Are they talking about
    CLOCK_MONOTONIC when they refer to relative interval timers?


    --
    Minds, like parachutes, function best when open

  14. Time measurements

    AV> The man page for these functions have the following statement
    AV>
    AV> All implementations support the system-wide realtime
    clock,
    AV> which is identified by CLOCK_REALTIME. Its time represents
    AV> seconds and nanoseconds since the Epoch. When its time is
    AV> changed, timers for a relative interval are unaffected, but
    AV> timers for an absolute point in time are affected.
    AV>
    AV> But it's not clear for me what do they mean under "timers for a
    relative
    AV> interval". Looks like the code marks one absolute point, then
    another
    AV> one, and then takes the difference. This will bring problems when
    the
    AV> time changes (Daylight saving for example). [...]

    Changes to and from daylight savings time do not change the number of
    seconds and nanoseconds since the Epoch. If your Unix system is doing
    this, then it is broken. Changes to and from daylight savings time do
    not touch the system clock. These are library mechanisms. On a Unix
    system, potentially every individual process can operate in an
    individual timezone, with individual DST rules, should one so desire.


  15. Re: Time measurements

    Andrei Voropaev writes:

    [...]

    > All implementations support the system-wide realtime clock,
    > which is identified by CLOCK_REALTIME. Its time represents
    > seconds and nanoseconds since the Epoch. When its time is
    > changed, timers for a relative interval are unaffected, but
    > timers for an absolute point in time are affected.
    >
    > But it's not clear for me what do they mean under "timers for a relative
    > interval".


    Timers created by timer_create and armed using timer_settime without
    giving the TIMER_ABSTIME flag.

    [ BTW, 'all implementations' usually support gettimeofday. It is not
    really sensible to use calls which are optional features of UNIX(*) if
    non-optional features providing the necessary functionality do
    exist. ]

    > Looks like the code marks one absolute point, then another
    > one, and then takes the difference. This will bring problems when the
    > time changes (Daylight saving for example).


    UNIX(*) and similar systems keep the time internally in UTC.

  16. Re: Time measurements

    Rainer Weikusat wrote On 10/11/07 11:27,:
    >
    > UNIX(*) and similar systems keep the time internally in UTC.


    It might be better to say that they *state* the time
    in UTC, but that each system *keeps* it in an idiosyncratic
    time zone defined by its own internal ill-regulated clock
    that was probably initialized from somebody's sundial.
    Mechanisms like NTP improve the situation, but (in essence)
    by monitoring just how bad the local clock is and giving
    it a good swift kick in the pants every now and then.

    Humor aside, the practical import of the above is that
    you can very seldom rely on two different machines agreeing
    on exactly what time it is. The problem shows up, for
    example, when "make" running on System A finds that the
    modification time on a file NFS-mounted from System B is
    "in the future."

    --
    Eric.Sosman@sun.com

  17. Re: Time measurements

    Eric Sosman writes:
    > Rainer Weikusat wrote On 10/11/07 11:27,:
    >>
    >> UNIX(*) and similar systems keep the time internally in UTC.

    >
    > It might be better to say that they *state* the time
    > in UTC,


    I don't think so. The person I was replying to was speculating about
    time changes of the system clock because of daylight savings
    times. Since the system clock is kept in UTC, there is no daylight
    savings time.

    [...]

    > Humor aside, the practical import of the above is that
    > you can very seldom rely on two different machines agreeing
    > on exactly what time it is. The problem shows up, for
    > example, when "make" running on System A finds that the
    > modification time on a file NFS-mounted from System B is
    > "in the future."


    If this happens, the chances are 1000:1 that the other system is
    administered by another clown posing as UNIX(*) sysadmin who either
    didn't care about the clock at all or is running ntpdate (or even
    netdate) from a cronjob once every 3.14... fortnights or something
    like that.

    This is not rocket science and following the instructions really
    solves the problem. That lots and lots of people would rather have
    themselves cut in half than ever following an instruction is not a
    technical issue :->.

  18. Re: Time measurements

    Rainer Weikusat wrote On 10/11/07 12:36,:
    > Eric Sosman writes:
    >
    >>Rainer Weikusat wrote On 10/11/07 11:27,:
    >>
    >>>UNIX(*) and similar systems keep the time internally in UTC.

    >>
    >> It might be better to say that they *state* the time
    >>in UTC,

    >
    >
    > I don't think so. The person I was replying to was speculating about
    > time changes of the system clock because of daylight savings
    > times. Since the system clock is kept in UTC, there is no daylight
    > savings time.


    Was Andrei really speaking of DST and time zones and
    that sort of thing? I thought that by "time changes"
    he meant "adjustments to the system clock" (presumably
    because the damn thing's drifted again).

    It certainly seems to me that the text he quoted

    >>All implementations support the system-wide realtime clock,
    >>which is identified by CLOCK_REALTIME. Its time represents
    >>seconds and nanoseconds since the Epoch. When its time is
    >>changed, timers for a relative interval are unaffected, but
    >>timers for an absolute point in time are affected.


    .... doesn't use "its time is changed" to mean any kind of
    seasonal or local adjustment in representation, but a change
    to the actual count-since-the-Epoch measurement.

    Maybe we've been considering two entirely different
    questions.

    --
    Eric.Sosman@sun.com

  19. Re: Time measurements

    On 2007-10-11, Eric Sosman wrote:
    > Rainer Weikusat wrote On 10/11/07 12:36,:

    [...]
    > ... doesn't use "its time is changed" to mean any kind of
    > seasonal or local adjustment in representation, but a change
    > to the actual count-since-the-Epoch measurement.
    >
    > Maybe we've been considering two entirely different
    > questions.
    >


    Yep, you are right. My question was about any clock adjustments. I used
    DST as an example not realizing that this is not done by adjusting the
    clock. I'm asking this question because I was bitten one time by the
    situation when the admin set the time 10 minutes behind and my program
    that was using gettimeofday got really confused So, is the
    CLOCK_REALTIME immune to this? Or it is safer to rely on
    CLOCK_MONOTONIC?


    --
    Minds, like parachutes, function best when open

  20. Re: Time measurements

    Andrei Voropaev writes:
    > On 2007-10-11, Eric Sosman wrote:
    >> Rainer Weikusat wrote On 10/11/07 12:36,:

    > [...]
    >> ... doesn't use "its time is changed" to mean any kind of
    >> seasonal or local adjustment in representation, but a change
    >> to the actual count-since-the-Epoch measurement.
    >>
    >> Maybe we've been considering two entirely different
    >> questions.

    >
    > Yep, you are right. My question was about any clock adjustments. I used
    > DST as an example not realizing that this is not done by adjusting the
    > clock.


    Similar to a 'loaded term', this would be a 'loaded example', because
    DST adjustments vary wildly throughout different administrative units
    and change without a real reason whenever some politician feels the
    burning desire to ACT. Additionally, they are supposed to occur
    automatically and necessarily imply a forward or backward time jump.

    > I'm asking this question because I was bitten one time by the
    > situation when the admin set the time 10 minutes behind and my program
    > that was using gettimeofday got really confused .


    This should be 'some sysadmin once got bitten when he decided to break
    some part of the system for some weird reason'.

    > So, is the CLOCK_REALTIME immune to this? Or it is safer to rely on
    > CLOCK_MONOTONIC?


    Why do pretend to ask questions with implied, obvious answers?
    No amount of smoke and mirrors will ever protect a program from admin
    intervention intended to break it.

+ Reply to Thread
Page 1 of 2 1 2 LastLast