abies
Sr. Member  Posts: 456
|
 |
«
on:
2003-10-08 12: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
JGO Kernel Posts: 4575
http://t-machine.org
|
|
«
Reply #1 on:
2003-10-08 12: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
Sr. Member Posts: 456
|
|
«
Reply #2 on:
2003-10-08 14: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! Go get 'em! 
|
|
Orangy Tang
JGO Kernel Posts: 2960 Medals: 37
Monkey for a head
|
|
«
Reply #3 on:
2003-10-08 14: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
Sr. Member Posts: 300
There is nothing Nu under the sun
|
|
«
Reply #4 on:
2003-10-08 15: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
JGO Wizard Posts: 1257
Who, me?
|
|
«
Reply #5 on:
2003-10-09 03: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
Full Member Posts: 136
why does the chicken cross the road?
|
|
«
Reply #6 on:
2003-10-10 03: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
JGO Kernel Posts: 3438 Medals: 4
Where's the Kaboom?
|
|
«
Reply #7 on:
2003-10-10 09: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
Sr. Member Posts: 300
There is nothing Nu under the sun
|
|
«
Reply #8 on:
2003-10-10 10: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
JGO Kernel Posts: 3438 Medals: 4
Where's the Kaboom?
|
|
«
Reply #9 on:
2003-10-10 12: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! Go get 'em!
|
|
princec
« League of Dukes » JGO Kernel  Posts: 8089 Medals: 96
Eh? Who? What? ... Me?
|
|
«
Reply #10 on:
2003-10-11 07: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 on:
2003-10-15 12: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
JGO Wizard Posts: 1257
Who, me?
|
 |
«
Reply #12 on:
2003-10-15 14: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 on:
2003-10-16 12: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 on:
2003-10-19 15: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
JGO Kernel Posts: 1837 Medals: 5
Fire at will
|
|
«
Reply #15 on:
2003-10-19 20:11:41 » |
|
nice going! Thank you, Will. |
|
|
|
oNyx
JGO Kernel Posts: 2943 Medals: 5
pixels! :x
|
|
«
Reply #16 on:
2003-10-20 00:07:37 » |
|
You da man Jeff  1.5! |
|
|
|
aikarele
JGO n00b Posts: 39
|
|
«
Reply #17 on:
2003-10-26 07: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
JGO Kernel Posts: 1866 Medals: 5
falling into the abyss of reality
|
|
«
Reply #18 on:
2003-10-28 03: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
Full Member Posts: 136
why does the chicken cross the road?
|
|
«
Reply #19 on:
2003-10-29 02:35:43 » |
|
When will JDK 1.5 released ?
|
|
|
|
|
|
Jeff
|
|
«
Reply #20 on:
2003-10-29 16: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
JGO n00b Posts: 28
games rock!
|
|
«
Reply #21 on:
2003-10-30 00: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. |
|
|
|
|
|
