Official precise timer in 1.5

[abies]

I have found it

In System class, according to JSR 166 (strange place for such thing...)

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19

nanoTime public static long nanoTime()     Returns the current value of the 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 (263 nanoseconds) will not accurately compute elapsed time due to numerical overflow.     For example, to measure how long some code takes to execute:    long startTime = System.nanoTime();    // ... the code being measured ...    long estimatedTime = System.nanoTime() - startTime;       Returns:         The current value of the system timer, in nanoseconds.     Since:         1.5

[blahblahblahh]

I have found it

1   2   3

public static long nanoTime()  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 (263 nanoseconds) will not accurately compute elapsed time due to numerical overflow.

Oh gawd, I hope that doesn't make it in as final documentation - I didn't think it could get any worse than it is now, but...

292 years == 263 nanoseconds is clearly a typo (I hope!), but "not necessarily nanosecond accuracy...no guarantees are made about how frequently values change". Doesn't that mean it's completely useless? It may return a difference of 5 after 240 nanoseconds have elapsed (no guarantee, etc)?

[abies]

It is about same useless as currentTimeMillis() as far as specificiation is concerned. It is just system dependent. What we can hope for, is that on most systems it will be implemented using high precision timers, as there are no technical reasons to not use them. And I think that they will just use same thing which was available in java3d, so I'm not afraid about the details.

Games published by our own members! Check 'em out!

[Orangy Tang]

Well I'd assume its just the timer from  sun.misc.Perf.* renamed and made official, in which case the accuracy seems to be pretty good.

Heres hoping at any rate

[rreyelts]

I have found it

Darn - you beat me to it.

I'm very happy to see the new system timer. I'm also very happy to see all of Doug Lea's multithreading library making it into Java. I've been using it for years now, but it really is the kind of thing that should have been a part of the core library since the beginning.

God bless,
-Toby Reyelts

[cfmdobbie]

Differences in successive calls that span greater than approximately 292 years [...] will not accurately compute elapsed time due to numerical overflow.

Damn!  My application needs to stay up for more that 300 years at a time.  Where do I submit an RFE to get this fixed?

A long time ago, someone I worked with became concerned with a particular counter's potential to roll over and cause havoc with our system.  I did a few calculations, and related the happy news that we were safe for the next 280 million years, or so...

[...] but "not necessarily nanosecond accuracy...no guarantees are made about how frequently values change". Doesn't that mean it's completely useless? It may return a difference of 5 after 240 nanoseconds have elapsed (no guarantee, etc)?

No worse than what we've already got.  I'd still prefer a way of querying the timer's actual accuracy, if only for use as a guideline.

[MGodehardt]

Great, this will end the high performance discussions and problems.

But ITS NOT OVER UNTIL ITS OVER.

I hope we get 1.5 in the next 2 months

[swpalmer]

I'd still prefer a way of querying the timer's actual accuracy, if only for use as a guideline.

Yes... this is important.  Is there such an API? or do I have to go vote on a bug ?

[rreyelts]

You can't create a bug, because it's just a JSR in public review. You can give your feedback on it there, although, I don't know how receptive they will be considering the JSR is on multi-threaded programming, and not system timers.

God bless,
-Toby Reyelts

[swpalmer]

I asked the Spec lead about providing a method to query the resolution, here is his response:

We considered options along these lines, but none of them work out
very well. Among the problems are:

1. The update frequency need not be constant, including on some
versions of Windows.

2. The returned value may be synthetic, as it is on most
multiprocesors, that use ntp-like adjustments to keep processor clocks
in sync, so there is no meaningful granularity to report.

3. The internal granularities governing delay/wait times (especially
in JSR166 timeout methods) may be different than elapsed-time
granularities.

Of course, these kinds of problems can also hit you if you use
internal loops to estimate. In either case you are left with the
best-effort intent of nanoTime: It is the most precise timer available
on the platform.

Any further ideas or suggestions would be welcome!

-Doug

Games published by our own members! Check 'em out!

[princec]

Although it's not perfect (like our API ) it'll do for all  gaming applications so best just get on with diverting our attention to more meaningful requirements.

Cas

[Jeff]

Hmm,

I'm not sure this is really our timer.

let me ask around.

As already pointed out it suffers from the same alck of gaurantees that got us in trouble with currentTimeMillis...

JK

[cfmdobbie]

Have we now got a multitude of different timers from Sun as well?

Ahh, all good entertainment...!

[Jeff]

Okay,
Well, this IS what became of our timer.

Right now I'm pushing for inlcusion in the docs of language such as:
"The VM is required to return this time to the best possible precision on the platform."

The idea being that this way, if an implementation sucks, its an inarguable bug.

We'll see how far I get...

JK

[Jeff]

Okay, i got this change. Thank Josh Block and Doug Lea:

"We replaced first sentence of nanoTime spec with:

    * Returns the current value of the most precise available system
    * timer, in nanoseconds.

Which ought to have the right effect."

Its now *required* to be the best precision possible.  If its not, and you can show a way to get higher precision, you can log it as a bug against the VM  (Ours or anyone elses  )

JK

 

[William Denniss]

nice going!

Thank you,

Will.

[oNyx]

You da man Jeff

1.5!

[aikarele]

Now Sun has officially closed Bug 4478186, a.k.a. "Add a high-resolution timer to the API":

Release Fixed: tiger-beta

This RFE has been addressed in the context of JSR-166 (java.util.concurrent).

Use java.lang.System.nanoTime

xxxxx@xxxxx 2003-10-24

[Abuse]

Now Sun has officially closed Bug 4478186, a.k.a. "Add a high-resolution timer to the API":

Release Fixed: tiger-beta

This RFE has been addressed in the context of JSR-166 (java.util.concurrent).

Use java.lang.System.nanoTime

xxxxx@xxxxx 2003-10-24

hehe, u got the email as well?

[MGodehardt]

When will JDK 1.5 released ?

[Jeff]

When will JDK 1.5 released ?

There is no announced date.  Therefore I cannort answer your question.

In general there has been a pretty obvious pattern the past few releases, with no promise that it will be the same this time, I suggest you take a look at those and extrapolate.

JK

[Smoke]

last i heard was beta coming out early 2004 and release mid 2004.


*sigh* finally a timer and you don't even have to distribute a dll.