abies
|
 |
«
Posted
2003-10-08 16:08:45 » |
|
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(); long estimatedTime = System.nanoTime() - startTime;
Returns: The current value of the system timer, in nanoseconds. Since: 1.5 |
|
Artur Biesiadowski
|
|
|
blahblahblahh
|
 |
«
Reply #1 - Posted
2003-10-08 16:36:26 » |
|
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)?
|
malloc will be first against the wall when the revolution comes...
|
|
|
abies
|
 |
«
Reply #2 - Posted
2003-10-08 18:15:22 » |
|
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.
|
Artur Biesiadowski
|
|
|
Games published by our own members! Check 'em out!
|
|
Orangy Tang
|
 |
«
Reply #3 - Posted
2003-10-08 18:40:08 » |
|
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
Junior Devvie  
There is nothing Nu under the sun
|
 |
«
Reply #4 - Posted
2003-10-08 19:02:33 » |
|
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
Senior Devvie    Medals: 1
Who, me?
|
 |
«
Reply #5 - Posted
2003-10-09 07:54:36 » |
|
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.
|
Hellomynameis Charlie Dobbie.
|
|
|
MGodehardt
Junior Devvie  
why does the chicken cross the road?
|
 |
«
Reply #6 - Posted
2003-10-10 07:39:36 » |
|
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
|
 |
«
Reply #7 - Posted
2003-10-10 13:54:32 » |
|
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
Junior Devvie  
There is nothing Nu under the sun
|
 |
«
Reply #8 - Posted
2003-10-10 14:01:54 » |
|
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
|
 |
«
Reply #9 - Posted
2003-10-10 16:57:16 » |
|
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
|
 |
«
Reply #10 - Posted
2003-10-11 11:29:05 » |
|
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
|
 |
«
Reply #11 - Posted
2003-10-15 16:07:19 » |
|
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
Senior Devvie    Medals: 1
Who, me?
|
 |
«
Reply #12 - Posted
2003-10-15 18:46:05 » |
|
Have we now got a multitude of different timers from Sun as well?  Ahh, all good entertainment...!
|
Hellomynameis Charlie Dobbie.
|
|
|
Jeff
|
 |
«
Reply #13 - Posted
2003-10-16 16:25:16 » |
|
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
|
 |
«
Reply #14 - Posted
2003-10-19 19:54:36 » |
|
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
|
 |
«
Reply #15 - Posted
2003-10-20 00:11:41 » |
|
nice going!  Thank you, Will.
|
|
|
|
oNyx
|
 |
«
Reply #16 - Posted
2003-10-20 04:07:37 » |
|
You da man Jeff  1.5! 
|
|
|
|
aikarele
Senior Newbie 
|
 |
«
Reply #17 - Posted
2003-10-26 12:23:09 » |
|
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
|
 |
«
Reply #18 - Posted
2003-10-28 08:04:14 » |
|
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
Junior Devvie  
why does the chicken cross the road?
|
 |
«
Reply #19 - Posted
2003-10-29 07:35:43 » |
|
When will JDK 1.5 released ?
|
|
|
|
Jeff
|
 |
«
Reply #20 - Posted
2003-10-29 21:11:17 » |
|
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
Senior Newbie 
games rock!
|
 |
«
Reply #21 - Posted
2003-10-30 05:47:46 » |
|
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. 
|
|
|
|
|