About time spent have big difference in two running

Discussion in 'C Programming' started by xianwei, Sep 25, 2007.

  1. xianwei

    xianwei Guest

    #include <stdio.h>
    #include <stdlib.h>
    #include <time.h>

    int
    main ( int argc, char *argv[] )
    {
    long i = 10000000L;
    clock_t start, end;
    double duration;

    printf("Time do %ld loop spent ", i);
    start = clock();
    while (i--);
    end = clock();

    duration = (double)(end - start) / CLOCKS_PER_SEC;
    printf("%f seconds\n", duration);

    return EXIT_SUCCESS;
    } /* ---------- end of function main ---------- */

    I run the above the program,
    The first time I spent 0.031000 seconds.
    The second time I spent 0.015000 seconds
    If I try again and again, the time spent on will 0.031 or 0.015
    seconds
    Why have such big difference?

    thank you!!!
    xianwei, Sep 25, 2007
    #1
    1. Advertising

  2. xianwei

    CBFalconer Guest

    xianwei wrote:
    >

    .... snip ...
    >
    > I run the above the program,
    > The first time I spent 0.031000 seconds.
    > The second time I spent 0.015000 seconds
    > If I try again and again, the time spent on will 0.031 or 0.015
    > seconds. Why have such big difference?


    Because the resolution of your clock is obviously roughly 0.0155 S.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>


    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Sep 25, 2007
    #2
    1. Advertising

  3. xianwei

    Eric Sosman Guest

    xianwei wrote:
    > #include <stdio.h>
    > #include <stdlib.h>
    > #include <time.h>
    >
    > int
    > main ( int argc, char *argv[] )
    > {
    > long i = 10000000L;
    > clock_t start, end;
    > double duration;
    >
    > printf("Time do %ld loop spent ", i);
    > start = clock();
    > while (i--);
    > end = clock();
    >
    > duration = (double)(end - start) / CLOCKS_PER_SEC;
    > printf("%f seconds\n", duration);
    >
    > return EXIT_SUCCESS;
    > } /* ---------- end of function main ---------- */
    >
    > I run the above the program,
    > The first time I spent 0.031000 seconds.
    > The second time I spent 0.015000 seconds
    > If I try again and again, the time spent on will 0.031 or 0.015
    > seconds


    Have you ever seen a hummingbird, and wondered
    how fast its wings flutter? You might try to find
    an answer by measuring the time for ten million beats.
    So you set up your highly accurate wingbeat counter,
    and then you start your timer: an hourglass ...

    --
    Eric Sosman
    lid
    Eric Sosman, Sep 25, 2007
    #3
  4. "xianwei" <> a ¨¦crit dans le message de news:
    ...
    > #include <stdio.h>
    > #include <stdlib.h>
    > #include <time.h>
    >
    > int
    > main ( int argc, char *argv[] )
    > {
    > long i = 10000000L;
    > clock_t start, end;
    > double duration;
    >
    > printf("Time do %ld loop spent ", i);
    > start = clock();
    > while (i--);
    > end = clock();
    >
    > duration = (double)(end - start) / CLOCKS_PER_SEC;
    > printf("%f seconds\n", duration);
    >
    > return EXIT_SUCCESS;
    > } /* ---------- end of function main ---------- */
    >
    > I run the above the program,
    > The first time I spent 0.031000 seconds.
    > The second time I spent 0.015000 seconds
    > If I try again and again, the time spent on will 0.031 or 0.015
    > seconds
    > Why have such big difference?


    I suspect the clock() function on your system has a granularity of around 15
    milliseconds. If this is the case, the clock() function will return the
    same value for all calls during each 15 millisecond interval. Depending on
    when exactly you start your measurements within that interval, a task
    lasting cloless than 15ms can be "clocked" as lasting 0ms or 15ms.
    Similarly, one that takes between 15 and 30 might be reposted as taking
    exactly 15ms or exactly 30ms.

    On top of this granularity issue, you should look into the clock() function.
    Does it measure elapsed time? total processor time? processor time spent in
    your program vs time spent in the system? or something else even... Your
    "timings" will also be affected by other tasks the computer performs while
    your program executes, and many other characteristics of you system (cache
    memory, bus sharing with i/o devices, etc.)

    For your peticular concern, I suggest you try and synchronize your timing
    efforts with this small loop:

    clock_t last, start;

    last = start = clock();
    while (start == last) {
    start = clock();
    }

    You should try and measure longer computations, by repeating them in a loop
    or increasing the constants.

    You should consider using more accurate timing functions such as
    non-standard gettimeofday in Linux.

    You should repeat the tests many many times, and average the results,
    discarding extreme values.

    Effective code profiling is *very* difficult. Drawing conclusions or making
    changes from profiling data is not easy either: what holds on one
    architecture does not necessarily on another one, even just slightly
    different. There is no definitive truth in this domain.

    --
    Chqrlie
    Charlie Gordon, Sep 25, 2007
    #4
  5. xianwei

    xianwei Guest

    On Sep 25, 8:15 pm, Eric Sosman <> wrote:

    > Have you ever seen a hummingbird, and wondered
    > how fast its wings flutter? You might try to find
    > an answer by measuring the time for ten million beats.


    Thank you, you are right, I should replace one millions to ten
    millions.
    When I do that, the time keep in 0.285 - 0.231 seconds, I think this
    is
    well.

    To test how fast humming wings flutter sound not like a good
    idea !! :)
    xianwei, Sep 25, 2007
    #5
  6. xianwei

    xianwei Guest

    On Sep 25, 8:18 pm, "Charlie Gordon" <> wrote:
    > "xianwei" <> a ¨¦crit dans le message de news:
    > ...
    >
    >
    >
    > > #include <stdio.h>
    > > #include <stdlib.h>
    > > #include <time.h>

    >
    > > int
    > > main ( int argc, char *argv[] )
    > > {
    > > long i = 10000000L;
    > > clock_t start, end;
    > > double duration;

    >
    > > printf("Time do %ld loop spent ", i);
    > > start = clock();
    > > while (i--);
    > > end = clock();

    >
    > > duration = (double)(end - start) / CLOCKS_PER_SEC;
    > > printf("%f seconds\n", duration);

    >
    > > return EXIT_SUCCESS;
    > > } /* ---------- end of function main ---------- */

    >
    > > I run the above the program,
    > > The first time I spent 0.031000 seconds.
    > > The second time I spent 0.015000 seconds
    > > If I try again and again, the time spent on will 0.031 or 0.015
    > > seconds
    > > Why have such big difference?

    >
    > I suspect the clock() function on your system has a granularity of around 15
    > milliseconds. If this is the case, the clock() function will return the
    > same value for all calls during each 15 millisecond interval. Depending on
    > when exactly you start your measurements within that interval, a task
    > lasting cloless than 15ms can be "clocked" as lasting 0ms or 15ms.
    > Similarly, one that takes between 15 and 30 might be reposted as taking
    > exactly 15ms or exactly 30ms.


    Thank you for you explanation about the question.

    > You should repeat the tests many many times, and average the results,
    > discarding extreme values.


    Yes, when I larger the loop times, the spent times differs in a small
    point.
    Thanks you enthusiasm.
    xianwei, Sep 25, 2007
    #6
  7. xianwei

    Eric Sosman Guest

    xianwei wrote On 09/25/07 08:42,:
    > On Sep 25, 8:15 pm, Eric Sosman <> wrote:
    >
    >
    >> Have you ever seen a hummingbird, and wondered
    >>how fast its wings flutter? You might try to find
    >>an answer by measuring the time for ten million beats.

    >
    >
    > Thank you, you are right, I should replace one millions to ten
    > millions.
    > When I do that, the time keep in 0.285 - 0.231 seconds, I think this
    > is
    > well.
    >
    > To test how fast humming wings flutter sound not like a good
    > idea !! :)


    The point is that the "granularity" of your measuring
    instrument influences how precisely you can measure. An
    hourglass is fine for measuring durations on the order of,
    well, hours, but is not well suited for measuring milliseconds.
    There are ways to improve the measurement precision of a
    "coarse" clock; one of them is to measure more repetitions
    of the activity whose duration interests you.

    --
    Eric Sosman, Sep 25, 2007
    #7
  8. CBFalconer <> writes:
    > xianwei wrote:
    > ... snip ...
    >>
    >> I run the above the program,
    >> The first time I spent 0.031000 seconds.
    >> The second time I spent 0.015000 seconds
    >> If I try again and again, the time spent on will 0.031 or 0.015
    >> seconds. Why have such big difference?

    >
    > Because the resolution of your clock is obviously roughly 0.0155 S.


    Most likely 1/60 second, but that's just a semi-educated guess.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Sep 25, 2007
    #8
  9. xianwei

    CBFalconer Guest

    Keith Thompson wrote:
    > CBFalconer <> writes:
    >> xianwei wrote:
    >>
    >> ... snip ...
    >>>
    >>> I run the above the program,
    >>> The first time I spent 0.031000 seconds.
    >>> The second time I spent 0.015000 seconds
    >>> If I try again and again, the time spent on will 0.031 or 0.015
    >>> seconds. Why have such big difference?

    >>
    >> Because the resolution of your clock is obviously roughly 0.0155 S.

    >
    > Most likely 1/60 second, but that's just a semi-educated guess.


    PCs can have some peculiar number, tied back to the old XT.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net>



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Sep 25, 2007
    #9
  10. On 2007-09-25 21:40, CBFalconer <> wrote:
    > Keith Thompson wrote:
    >> CBFalconer <> writes:
    >>> Because the resolution of your clock is obviously roughly 0.0155 S.

    >>
    >> Most likely 1/60 second, but that's just a semi-educated guess.

    >
    > PCs can have some peculiar number, tied back to the old XT.


    That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
    seconds). Was CLOCKS_PER_SEC actually a floating point constant on
    MS-DOS compilers? I don't remember but I guess it must have been.

    hp

    --
    _ | Peter J. Holzer | I know I'd be respectful of a pirate
    |_|_) | Sysadmin WSR | with an emu on his shoulder.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
    Peter J. Holzer, Sep 26, 2007
    #10
  11. "Peter J. Holzer" <> a écrit dans le message de news:
    ...
    > On 2007-09-25 21:40, CBFalconer <> wrote:
    >> Keith Thompson wrote:
    >>> CBFalconer <> writes:
    >>>> Because the resolution of your clock is obviously roughly 0.0155 S.
    >>>
    >>> Most likely 1/60 second, but that's just a semi-educated guess.

    >>
    >> PCs can have some peculiar number, tied back to the old XT.

    >
    > That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
    > seconds). Was CLOCKS_PER_SEC actually a floating point constant on
    > MS-DOS compilers? I don't remember but I guess it must have been.


    For those who wonder why 18.2 Hz, that makes 64K ticks per hour.
    This may be the very reason for the rather odd original PC frequency:
    65536 * 65536 * 4 / 3600 = 4.772185 MHz

    --
    Chqrlie.
    Charlie Gordon, Sep 26, 2007
    #11
  12. xianwei

    Sjouke Burry Guest

    Charlie Gordon wrote:
    > "Peter J. Holzer" <> a écrit dans le message de news:
    > ...
    >> On 2007-09-25 21:40, CBFalconer <> wrote:
    >>> Keith Thompson wrote:
    >>>> CBFalconer <> writes:
    >>>>> Because the resolution of your clock is obviously roughly 0.0155 S.
    >>>> Most likely 1/60 second, but that's just a semi-educated guess.
    >>> PCs can have some peculiar number, tied back to the old XT.

    >> That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
    >> seconds). Was CLOCKS_PER_SEC actually a floating point constant on
    >> MS-DOS compilers? I don't remember but I guess it must have been.


    No. CLOCKS_PER_SEC is (mostly) an int.


    Watcom compiler:
    #define CLOCKS_PER_SEC 100

    Microsoft C Compiler Version 2.00.000 V 6.00A
    #define CLOCKS_PER_SEC 1000

    Borland BC5 however disagrees.
    #define CLOCKS_PER_SEC 1000.0

    Digital Mars compiler:
    #define CLOCKS_PER_SEC ((clock_t)1000)
    Sjouke Burry, Sep 26, 2007
    #12
  13. In article <46fa7e61$0$26056$>,
    Charlie Gordon <> wrote:
    >This may be the very reason for the rather odd original PC frequency:
    >65536 * 65536 * 4 / 3600 = 4.772185 MHz


    No, that comes from the 4/3 the frequency of an NTSC colour
    sub-carrier oscillator. I'm not sure if the PC had one of these
    anyway and it was reused, or if they were just cheap.

    -- Richard

    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
    Richard Tobin, Sep 26, 2007
    #13
  14. "Richard Tobin" <> a écrit dans le message de news:
    fde2v7$1rt1$...
    > In article <46fa7e61$0$26056$>,
    > Charlie Gordon <> wrote:
    >>This may be the very reason for the rather odd original PC frequency:
    >>65536 * 65536 * 4 / 3600 = 4.772185 MHz

    >
    > No, that comes from the 4/3 the frequency of an NTSC colour
    > sub-carrier oscillator. I'm not sure if the PC had one of these
    > anyway and it was reused, or if they were just cheap.


    I am positive it did not, since the graphics was done on a separate adapter
    board.
    But you are right, these oscillators were common and cheap, and the
    frequency may not have been exactly what I stated. The BIOS did take
    advantage of the 64K ticks in an hour, but there might have been an
    adjustment, I'll take a look.

    --
    Chqrlie.
    Charlie Gordon, Sep 27, 2007
    #14
  15. CLOCKS_PER_SEC (was: About time spent have big difference in tworunning)

    On 2007-09-26 16:17, Sjouke Burry <> wrote:
    > Charlie Gordon wrote:
    >> "Peter J. Holzer" <> a écrit dans le message de news:
    >> ...
    >>> On 2007-09-25 21:40, CBFalconer <> wrote:
    >>>> PCs can have some peculiar number, tied back to the old XT.
    >>> That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
    >>> seconds). Was CLOCKS_PER_SEC actually a floating point constant on
    >>> MS-DOS compilers? I don't remember but I guess it must have been.

    >
    > No. CLOCKS_PER_SEC is (mostly) an int.
    >
    >
    > Watcom compiler:
    > #define CLOCKS_PER_SEC 100
    >
    > Microsoft C Compiler Version 2.00.000 V 6.00A
    > #define CLOCKS_PER_SEC 1000
    >
    > Borland BC5 however disagrees.
    > #define CLOCKS_PER_SEC 1000.0
    >
    > Digital Mars compiler:
    > #define CLOCKS_PER_SEC ((clock_t)1000)


    These examples are rather irrelevant since the clock frequency in these
    cases is (presumably) exactly 100 Hz or 1000 Hz. But in MS-DOS the
    frequency was 18.2 Hz. If CLOCKS_PER_SEC was defined as 18, that would
    have caused an error of about 1.1%, which I think would have been
    noticable. (Maybe I should get out my old Turbo-C++ 1.0 disks and have a
    look).

    hp

    --
    _ | Peter J. Holzer | I know I'd be respectful of a pirate
    |_|_) | Sysadmin WSR | with an emu on his shoulder.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
    Peter J. Holzer, Sep 27, 2007
    #15
  16. xianwei

    Sjouke Burry Guest

    Re: CLOCKS_PER_SEC

    Peter J. Holzer wrote:
    > On 2007-09-26 16:17, Sjouke Burry <> wrote:
    >> Charlie Gordon wrote:
    >>> "Peter J. Holzer" <> a écrit dans le message de news:
    >>> ...
    >>>> On 2007-09-25 21:40, CBFalconer <> wrote:
    >>>>> PCs can have some peculiar number, tied back to the old XT.
    >>>> That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
    >>>> seconds). Was CLOCKS_PER_SEC actually a floating point constant on
    >>>> MS-DOS compilers? I don't remember but I guess it must have been.

    >> No. CLOCKS_PER_SEC is (mostly) an int.
    >>
    >>
    >> Watcom compiler:
    >> #define CLOCKS_PER_SEC 100
    >>
    >> Microsoft C Compiler Version 2.00.000 V 6.00A
    >> #define CLOCKS_PER_SEC 1000
    >>
    >> Borland BC5 however disagrees.
    >> #define CLOCKS_PER_SEC 1000.0
    >>
    >> Digital Mars compiler:
    >> #define CLOCKS_PER_SEC ((clock_t)1000)

    >
    > These examples are rather irrelevant since the clock frequency in these
    > cases is (presumably) exactly 100 Hz or 1000 Hz. But in MS-DOS the
    > frequency was 18.2 Hz. If CLOCKS_PER_SEC was defined as 18, that would
    > have caused an error of about 1.1%, which I think would have been
    > noticable. (Maybe I should get out my old Turbo-C++ 1.0 disks and have a
    > look).
    >
    > hp
    >

    Pardon me??? That whole list is from dos computers.
    However they all do modify their clockticks in some way.
    I have never seen a clocktick to have a one to one relation
    to the 18.2 HZ clock, they all modify that to give a
    "decimal" clocktick.
    When however you print all clockchanges,you can recognize the
    relation to the systemclock.
    Sjouke Burry, Sep 27, 2007
    #16
  17. Re: CLOCKS_PER_SEC (was: About time spent have big difference in two running)

    "Peter J. Holzer" <> writes:
    > On 2007-09-26 16:17, Sjouke Burry <> wrote:
    >> Charlie Gordon wrote:
    >>> "Peter J. Holzer" <> a écrit dans le message de news:
    >>> ...
    >>>> On 2007-09-25 21:40, CBFalconer <> wrote:
    >>>>> PCs can have some peculiar number, tied back to the old XT.
    >>>> That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
    >>>> seconds). Was CLOCKS_PER_SEC actually a floating point constant on
    >>>> MS-DOS compilers? I don't remember but I guess it must have been.

    >>
    >> No. CLOCKS_PER_SEC is (mostly) an int.
    >>
    >>
    >> Watcom compiler:
    >> #define CLOCKS_PER_SEC 100
    >>
    >> Microsoft C Compiler Version 2.00.000 V 6.00A
    >> #define CLOCKS_PER_SEC 1000
    >>
    >> Borland BC5 however disagrees.
    >> #define CLOCKS_PER_SEC 1000.0
    >>
    >> Digital Mars compiler:
    >> #define CLOCKS_PER_SEC ((clock_t)1000)

    >
    > These examples are rather irrelevant since the clock frequency in these
    > cases is (presumably) exactly 100 Hz or 1000 Hz. But in MS-DOS the
    > frequency was 18.2 Hz. If CLOCKS_PER_SEC was defined as 18, that would
    > have caused an error of about 1.1%, which I think would have been
    > noticable. (Maybe I should get out my old Turbo-C++ 1.0 disks and have a
    > look).


    CLOCKS_PER_SEC doesn't necessarily match the actual clock frequency.
    It just gives you the factor by which you need to scale the value
    returned by the clock() function.

    For example, a physical clock frequency of 18.2 Hz and a
    CLOCKS_PER_SEC value of 1000 would be consistent. Successive calls to
    clock() might return
    0
    55
    110
    165
    ...
    989
    1044
    and so forth; each result exceeds the prievous one by 54 or 55.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Sep 27, 2007
    #17
  18. xianwei

    Ben Pfaff Guest

    Re: CLOCKS_PER_SEC

    Keith Thompson <> writes:

    > CLOCKS_PER_SEC doesn't necessarily match the actual clock frequency.
    > It just gives you the factor by which you need to scale the value
    > returned by the clock() function.


    And in fact, CLOCKS_PER_SEC has the same value on all
    XSI-conformant UNIX systems, even though such systems are not
    required to have a clock that ticks at any particular frequency.
    --
    Ben Pfaff
    http://benpfaff.org
    Ben Pfaff, Sep 27, 2007
    #18
  19. Re: CLOCKS_PER_SEC

    On 2007-09-27 17:34, Sjouke Burry <> wrote:
    > Peter J. Holzer wrote:
    >> On 2007-09-26 16:17, Sjouke Burry <> wrote:
    >>> Charlie Gordon wrote:
    >>>> "Peter J. Holzer" <> a écrit dans le message de news:
    >>>> ...
    >>>>> On 2007-09-25 21:40, CBFalconer <> wrote:
    >>>>>> PCs can have some peculiar number, tied back to the old XT.
    >>>>> That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
    >>>>> seconds). Was CLOCKS_PER_SEC actually a floating point constant on
    >>>>> MS-DOS compilers? I don't remember but I guess it must have been.
    >>> No. CLOCKS_PER_SEC is (mostly) an int.
    >>>
    >>>
    >>> Watcom compiler:
    >>> #define CLOCKS_PER_SEC 100
    >>>
    >>> Microsoft C Compiler Version 2.00.000 V 6.00A
    >>> #define CLOCKS_PER_SEC 1000
    >>>
    >>> Borland BC5 however disagrees.
    >>> #define CLOCKS_PER_SEC 1000.0
    >>>
    >>> Digital Mars compiler:
    >>> #define CLOCKS_PER_SEC ((clock_t)1000)

    >>
    >> These examples are rather irrelevant since the clock frequency in these
    >> cases is (presumably) exactly 100 Hz or 1000 Hz. But in MS-DOS the
    >> frequency was 18.2 Hz. If CLOCKS_PER_SEC was defined as 18, that would
    >> have caused an error of about 1.1%, which I think would have been
    >> noticable. (Maybe I should get out my old Turbo-C++ 1.0 disks and have a
    >> look).
    >>

    > Pardon me??? That whole list is from dos computers.
    > However they all do modify their clockticks in some way.

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    That's the crux. If they modify the clockticks, they aren't the same any
    more. If a program does NOT modify the clock ticks, the frequency is
    18.2 Hz, which is not an integral number.

    > I have never seen a clocktick to have a one to one relation
    > to the 18.2 HZ clock, they all modify that to give a
    > "decimal" clocktick.


    I am positive that Turbo C (up to and including Turbo-C++ 1.0, which
    was the last version I've used) did not modify the clock rate, because
    on ocassion I needed a higher resolution and had to reprogram the timer
    chip myself. It is possible that clock did the conversion internally,
    as Keith suggests, but I doubt that, because:

    * I think I would remember it

    * I found some old benchmark code of mine, which contains a comment
    on the granularity of the times() function on Ultrix, but none on the
    granularity of clock on MS-DOS. I think I would have added a comment
    if granularity of clock was worse than CLOCKS_PER_SEC suggested.

    So, I think that CLOCKS_PER_SEC should have been 18.2 on Turbo-C, but I
    don't remember if they actually defined it as 18.2 or approximated it
    with 18. However, I notice that in your examples the Borland compiler is
    the only one which defines CLOCKS_PER_SEC as a floating point constant,
    which strongly suggests that it was 18.2 in earlier versions and when
    they changed it to 1000, they didn't want to break programs which
    (erroneously) assumed that CLOCKS_PER_SEC was of type double.

    hp


    --
    _ | Peter J. Holzer | I know I'd be respectful of a pirate
    |_|_) | Sysadmin WSR | with an emu on his shoulder.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
    Peter J. Holzer, Sep 29, 2007
    #19
  20. Re: CLOCKS_PER_SEC (was: About time spent have big difference in tworunning)

    On 2007-09-27 22:34, Keith Thompson <> wrote:
    > "Peter J. Holzer" <> writes:
    >> On 2007-09-26 16:17, Sjouke Burry <> wrote:
    >>> Charlie Gordon wrote:
    >>>> "Peter J. Holzer" <> a écrit dans le message de news:
    >>>> ...
    >>>>> On 2007-09-25 21:40, CBFalconer <> wrote:
    >>>>>> PCs can have some peculiar number, tied back to the old XT.
    >>>>> That would be 1/18.2 seconds (or rather 1 / (4.77E6 / 4 / 65536)
    >>>>> seconds). Was CLOCKS_PER_SEC actually a floating point constant on
    >>>>> MS-DOS compilers? I don't remember but I guess it must have been.
    >>>
    >>> No. CLOCKS_PER_SEC is (mostly) an int.
    >>>
    >>> Watcom compiler:
    >>> #define CLOCKS_PER_SEC 100
    >>>
    >>> Microsoft C Compiler Version 2.00.000 V 6.00A
    >>> #define CLOCKS_PER_SEC 1000
    >>>
    >>> Borland BC5 however disagrees.
    >>> #define CLOCKS_PER_SEC 1000.0
    >>>
    >>> Digital Mars compiler:
    >>> #define CLOCKS_PER_SEC ((clock_t)1000)

    >>
    >> These examples are rather irrelevant since the clock frequency in these
    >> cases is (presumably) exactly 100 Hz or 1000 Hz. But in MS-DOS the
    >> frequency was 18.2 Hz. If CLOCKS_PER_SEC was defined as 18, that would
    >> have caused an error of about 1.1%, which I think would have been
    >> noticable. (Maybe I should get out my old Turbo-C++ 1.0 disks and have a
    >> look).

    >
    > CLOCKS_PER_SEC doesn't necessarily match the actual clock frequency.


    I know, I have used systems where they didn't match (in fact I'm using
    one right now). I am quite sure that they did match on MS-DOS with the
    Turbo-C compilers, though. I should have written "... the unit of time
    returned by clock is exactly 1/100 or 1/1000 second" instead of "...
    clock frequency ...".

    hp


    --
    _ | Peter J. Holzer | I know I'd be respectful of a pirate
    |_|_) | Sysadmin WSR | with an emu on his shoulder.
    | | | |
    __/ | http://www.hjp.at/ | -- Sam in "Freefall"
    Peter J. Holzer, Sep 29, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Shaguf
    Replies:
    0
    Views:
    329
    Shaguf
    Dec 24, 2008
  2. Shaguf
    Replies:
    0
    Views:
    432
    Shaguf
    Dec 26, 2008
  3. Shaguf
    Replies:
    0
    Views:
    219
    Shaguf
    Dec 26, 2008
  4. Shaguf
    Replies:
    0
    Views:
    203
    Shaguf
    Dec 24, 2008
  5. Mario Ruiz
    Replies:
    4
    Views:
    82
    Mario Ruiz
    Feb 24, 2009
Loading...

Share This Page