|
»
« Return to Thread: Accurate CPU timing on Windows -- How?
Re: Accurate CPU timing on Windows -- How?
by Jess Holle
::
Rate this Message:
Michele Mazzucco wrote:
> Jess,
>
> you didn't get my point. What I'm saying is that the values you get are
> not accurate.
>
>
> >From the javadoc you can see:
> public static long currentTimeMillis()
> Returns the current time in milliseconds. *Note that while the
> unit of time of the return value is a millisecond, the
> granularity of the value depends on the underlying operating
> system and may be larger*. For example, many operating systems
> measure time in units of tens of milliseconds.
>
> Returns the current value of the most precise available system timer, in
> nanoseconds.
>
> This method can only be used to measure elapsed time and is not related
> to any other notion of system or wall-clock time. The value returned
> represents nanoseconds since some fixed but arbitrary time (perhaps in
> the future, so values may be negative). This method provides nanosecond
> precision, *but not necessarily nanosecond accuracy*. No guarantees are
> made about how frequently values change. Differences in successive calls
> that span greater than approximately 292 years (2^63 nanoseconds) will
> not accurately compute elapsed time due to numerical overflow.
>Yes, but as per my previous point you can relate nanoTime() results to
wall clock time via some simple math on startup. Thus the only reason
not to rework System.currentTimeMillis() to do so and guarantee
millisecond accuracy [barring a nanoTime() timer that is not even that
accurate] is if nanoTime() [plus the conversion necessary to relate to
wall clock time] is too expensive. Otherwise System.currentTimeMillis()
should go the way of the dinosaur.
Unfortunately I had done some testing and found System.nanoTime() to be
significantly more expensive than System.currentTimeMillis() -- which
leads to a tradeoff between great numbers and great speed. To date I'm
going with speed, which I guess means it all comes down to a choice
between really inaccurate results and paying a bit more for nanoTime()
results.
--
Jess Holle
===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM". For general help, send email to
listserv@... and include in the body of the message "help".
> Jess,
>
> you didn't get my point. What I'm saying is that the values you get are
> not accurate.
>
>
> >From the javadoc you can see:
> public static long currentTimeMillis()
> Returns the current time in milliseconds. *Note that while the
> unit of time of the return value is a millisecond, the
> granularity of the value depends on the underlying operating
> system and may be larger*. For example, many operating systems
> measure time in units of tens of milliseconds.
>
> Returns the current value of the most precise available system timer, in
> nanoseconds.
>
> This method can only be used to measure elapsed time and is not related
> to any other notion of system or wall-clock time. The value returned
> represents nanoseconds since some fixed but arbitrary time (perhaps in
> the future, so values may be negative). This method provides nanosecond
> precision, *but not necessarily nanosecond accuracy*. No guarantees are
> made about how frequently values change. Differences in successive calls
> that span greater than approximately 292 years (2^63 nanoseconds) will
> not accurately compute elapsed time due to numerical overflow.
>
wall clock time via some simple math on startup. Thus the only reason
not to rework System.currentTimeMillis() to do so and guarantee
millisecond accuracy [barring a nanoTime() timer that is not even that
accurate] is if nanoTime() [plus the conversion necessary to relate to
wall clock time] is too expensive. Otherwise System.currentTimeMillis()
should go the way of the dinosaur.
Unfortunately I had done some testing and found System.nanoTime() to be
significantly more expensive than System.currentTimeMillis() -- which
leads to a tradeoff between great numbers and great speed. To date I'm
going with speed, which I guess means it all comes down to a choice
between really inaccurate results and paying a bit more for nanoTime()
results.
--
Jess Holle
===========================================================================
For information on the Java Management extensions (JMX), please visit
our home page at http://java.sun.com/products/JavaManagement/
The JMX-FORUM archives are accessible at http://archives.java.sun.com
To unsubscribe, send email to listserv@... and include in the body
of the message "signoff JMX-FORUM". For general help, send email to
listserv@... and include in the body of the message "help".
« Return to Thread: Accurate CPU timing on Windows -- How?
| Free embeddable forum powered by Nabble | Forum Help |
