(RS) hi-res clock function

  • The following code snippet reveals that the time elapsed between one
    invocation of [NSDate date] and an immediately following one can be
    as little as 2 usec (on my Powerbook G4).

    A related experiment shows that the resolution of the GNU clock()
    function on the PowerBook is no less than 16 usec.

    Is there a function like clock() that returns time (since some
    origin) directly to a finer resolution than clock does?

    NSDate *start, *stop;
    start = [NSDate date];
    stop = [NSDate date];
    NSTimeInterval elapsed = [stop timeIntervalSinceDate:start];;
    NSLog(@"elapsed=%g", elapsed);
  • On Oct 25, 2006, at 12:48 PM, Roland Silver wrote:

    > A related experiment shows that the resolution of the GNU clock()
    > function on the PowerBook is no less than 16 usec.

    You mean the ISO C clock() function.  It isn't a GNU function.

    > Is there a function like clock() that returns time (since some
    > origin) directly to a finer resolution than clock does?

    Take a look at the man page for gettimeofday(2).

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • On Oct 25, 2006, at 1:00 PM, Alastair Houghton wrote:

    > On Oct 25, 2006, at 12:48 PM, Roland Silver wrote:
    >
    >> A related experiment shows that the resolution of the GNU clock()
    >> function on the PowerBook is no less than 16 usec.
    >
    > You mean the ISO C clock() function.  It isn't a GNU function.
    >
    >> Is there a function like clock() that returns time (since some
    >> origin) directly to a finer resolution than clock does?
    >
    > Take a look at the man page for gettimeofday(2).

    Just to add to that, you might find that it doesn't have a higher
    resolution, in which case you might need to use something system
    dependent.  (The PowerPC timebase register, for instance).  It might
    be worth checking the Mach APIs to see if there's something that lets
    you do that kind of thing in a non-system-specific manner (you'll
    need to download xnu and look in the osfmk/man folder for the docs).

    Of course, I'm sure someone else will point out some other time API
    any minute now that fits the bill :-)

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • On 25-Oct-06, at 5:07 AM, Alastair Houghton wrote:

    > On Oct 25, 2006, at 1:00 PM, Alastair Houghton wrote:
    >
    >> On Oct 25, 2006, at 12:48 PM, Roland Silver wrote:
    >>
    >>> Is there a function like clock() that returns time (since some
    >>> origin) directly to a finer resolution than clock does?
    >>
    >> Take a look at the man page for gettimeofday(2).
    >
    > Just to add to that, you might find that it doesn't have a higher
    > resolution, in which case you might need to use something system
    > dependent.  (The PowerPC timebase register, for instance).  It
    > might be worth checking the Mach APIs to see if there's something
    > that lets you do that kind of thing in a non-system-specific manner
    > (you'll need to download xnu and look in the osfmk/man folder for
    > the docs).
    >
    > Of course, I'm sure someone else will point out some other time API
    > any minute now that fits the bill :-)
    >

    In addition, keep in mind that all time functions are only as
    accurate as the kernel scheduler anyways -  For instance if you call
    gettimeofday or get the ppc tb reg you may get a very accurate count
    - But then before you even get to use the time value your application
    may get pre-empted by some higher priority function.  When it is
    scheduled back again in may be 5 or 10 or more milliseconds later
    than your accurate value specifies.

    So be sure to make your algorithms allow for this...

    Jeff Koftinoff
  • On Oct 25, 2006, at 7:01 AM, Jeff Koftinoff wrote:

    > In addition, keep in mind that all time functions are only as
    > accurate as the kernel scheduler anyways -  For instance if you
    > call gettimeofday or get the ppc tb reg you may get a very accurate
    > count - But then before you even get to use the time value your
    > application may get pre-empted by some higher priority function.
    > When it is scheduled back again in may be 5 or 10 or more
    > milliseconds later than your accurate value specifies.
    >
    > So be sure to make your algorithms allow for this...
    >
    > Jeff Koftinoff

    I DID allow for that by running the [NSDate date] code 1000 times,
    taking the minimum of the 1000 elapsed times.

    --Roland Silver
  • On Oct 25, 2006, at 4:48 AM, Roland Silver wrote:

    > The following code snippet reveals that the time elapsed between
    > one invocation of [NSDate date] and an immediately following one
    > can be as little as 2 usec (on my Powerbook G4).
    >
    > A related experiment shows that the resolution of the GNU clock()
    > function on the PowerBook is no less than 16 usec.
    >
    > Is there a function like clock() that returns time (since some
    > origin) directly to a finer resolution than clock does?

    Not clear what exactly you are asking for but... <http://
    developer.apple.com/qa/qa2004/qa1398.html>

    -Shawn
  • You may want to try the following code with the %F option which gives
    time down to milliseconds.

    [[NSCalendarDate calendarDate] descriptionWithCalendarFormat:@"%F"]

    Chris
  • That gives the time in milliseconds, but I wouldn't call it extremely
    accurate that far down over a given period of time.

    --
    m-s

    On 26 Oct, 2006, at 19:47, Chris wrote:

    > You may want to try the following code with the %F option which
    > gives time down to milliseconds.
    >
    > [[NSCalendarDate calendarDate] descriptionWithCalendarFormat:@"%F"]
    >
    > Chris
    > _______________________________________________
    > Do not post admin requests to the list. They will be ignored.
    > Cocoa-dev mailing list      (<Cocoa-dev...>)
    > Help/Unsubscribe/Update your Subscription:
    > http://lists.apple.com/mailman/options/cocoa-dev/mikey-san%
    > 40bungie.org
    >
    > This email sent to <mikey-san...>
previous month october 2006 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today