|
»
« Return to Thread: Accurate CPU timing on Windows -- How?
Re: Accurate CPU timing on Windows -- How?
by Michele Mazzucco-2
::
Rate this Message:
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.
Michele
On Thu, 2007-07-19 at 07:12 -0500, Jess Holle wrote:
> Michele Mazzucco wrote:
> > Jess,
> >
> > I'm saying (a), but it's not a windows only problem. It applies to linux
> > as well (I think it applies to all non-realtime os).
> >
> Actually a little experimentation shows (a) is *not* the case.
>
> Try:
> public class Test
> {
> public static void main( String args[] )
> throws Exception
> {
> for ( int ii = 0; ii < 20; ++ii )
> {
> final long start = System.nanoTime();
> Thread.sleep( 3L );
> final long end = System.nanoTime();
> System.out.println( (double) ( end - start ) / 1.0e9 );
> }
> }
> }
> When running this, I get:
> 0.002209499
> 0.003041727
> 0.002880813
> 0.002905955
> 0.003513295
> 0.002158934
> 0.00289562
> 0.002910706
> 0.002923277
> 0.002881372
> 0.002910984
> 0.002908471
> 0.002911264
> 0.002274591
> 0.003108216
> 0.002893664
> 0.002867683
> 0.002905676
> 0.002910984
> 0.002916013
> That is clearly *far* more accurate than using
> System.currentTimeMillis() [and switching the conversion factor],
> where I get:
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.01
> 0.0
> [The average of these does actually give exactly 0.003 seconds, which
> is correct.]
>
> This shows that either the issue is (b) or Sun's
> System.currentTimeMillis() is unnecessarily inaccurate (though this
> may well impact more than just Windows).
>
> --
> Jess Holle
> > On Thu, 2007-07-19 at 06:35 -0500, Jess Holle wrote:
> >
> > > Michele Mazzucco wrote:
> > >
> > > > On Wed, 2007-07-18 at 15:51 -0500, Jess Holle wrote:
> > > >
> > > > > * On Windows [at least], System.currentTimeMillis()'s resolution
> > > > > is not milliseconds but rather about 0.01 seconds.
> > > > > * We could use System.nanoTime() instead, but it appears
> > > > > that acquiring this takes a bit more time. Moreover,
> > > > > for the usages in question millisecond accuracy is
> > > > > sufficient, but 0.01 seconds is not always.
> > > > >
> > > > Jess,
> > > >
> > > > this is a kernel issue (kernel precision is typically 10/15 ms), it's
> > > > not related with java.
> > > >
> > > So are you saying that System.nanoTime() is:
> > > a. No more accurate than System.currentTimeMillis() on Windows
> > > *or*
> > > b. Is sufficiently costly that Sun doesn't want to implement
> > > System.currentTimeMillis() via System.nanoTime()'s internals?
> > > Clearly (b) is possible in that one can compute an offset by examining
> > > System.currentTimeMillis() and System.nanoTime() on startup, doing all
> > > timing via nanoTime() and then using the startup numbers to convert
> > > from nanoTime() results to currentTimeMillis() results. I do it in a
> > > few places to avoid having to obtain both types of times when I
> > > already have nanoTime() for some reason. I have to assume that (b) is
> > > more costly, though -- from my own results.
> > >
> > > While all this is annoying the bigger issue is thread CPU time...
> > >
> > > --
> > > 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".
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.
Michele
On Thu, 2007-07-19 at 07:12 -0500, Jess Holle wrote:
> Michele Mazzucco wrote:
> > Jess,
> >
> > I'm saying (a), but it's not a windows only problem. It applies to linux
> > as well (I think it applies to all non-realtime os).
> >
> Actually a little experimentation shows (a) is *not* the case.
>
> Try:
> public class Test
> {
> public static void main( String args[] )
> throws Exception
> {
> for ( int ii = 0; ii < 20; ++ii )
> {
> final long start = System.nanoTime();
> Thread.sleep( 3L );
> final long end = System.nanoTime();
> System.out.println( (double) ( end - start ) / 1.0e9 );
> }
> }
> }
> When running this, I get:
> 0.002209499
> 0.003041727
> 0.002880813
> 0.002905955
> 0.003513295
> 0.002158934
> 0.00289562
> 0.002910706
> 0.002923277
> 0.002881372
> 0.002910984
> 0.002908471
> 0.002911264
> 0.002274591
> 0.003108216
> 0.002893664
> 0.002867683
> 0.002905676
> 0.002910984
> 0.002916013
> That is clearly *far* more accurate than using
> System.currentTimeMillis() [and switching the conversion factor],
> where I get:
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.0
> 0.01
> 0.0
> 0.0
> 0.01
> 0.0
> [The average of these does actually give exactly 0.003 seconds, which
> is correct.]
>
> This shows that either the issue is (b) or Sun's
> System.currentTimeMillis() is unnecessarily inaccurate (though this
> may well impact more than just Windows).
>
> --
> Jess Holle
> > On Thu, 2007-07-19 at 06:35 -0500, Jess Holle wrote:
> >
> > > Michele Mazzucco wrote:
> > >
> > > > On Wed, 2007-07-18 at 15:51 -0500, Jess Holle wrote:
> > > >
> > > > > * On Windows [at least], System.currentTimeMillis()'s resolution
> > > > > is not milliseconds but rather about 0.01 seconds.
> > > > > * We could use System.nanoTime() instead, but it appears
> > > > > that acquiring this takes a bit more time. Moreover,
> > > > > for the usages in question millisecond accuracy is
> > > > > sufficient, but 0.01 seconds is not always.
> > > > >
> > > > Jess,
> > > >
> > > > this is a kernel issue (kernel precision is typically 10/15 ms), it's
> > > > not related with java.
> > > >
> > > So are you saying that System.nanoTime() is:
> > > a. No more accurate than System.currentTimeMillis() on Windows
> > > *or*
> > > b. Is sufficiently costly that Sun doesn't want to implement
> > > System.currentTimeMillis() via System.nanoTime()'s internals?
> > > Clearly (b) is possible in that one can compute an offset by examining
> > > System.currentTimeMillis() and System.nanoTime() on startup, doing all
> > > timing via nanoTime() and then using the startup numbers to convert
> > > from nanoTime() results to currentTimeMillis() results. I do it in a
> > > few places to avoid having to obtain both types of times when I
> > > already have nanoTime() for some reason. I have to assume that (b) is
> > > more costly, though -- from my own results.
> > >
> > > While all this is annoying the bigger issue is thread CPU time...
> > >
> > > --
> > > 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 |
