Re: Accurate CPU timing on Windows -- How?

> 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