High-resolution timer

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

High-resolution timer

foxua
Is there platforn-independent high-resolution Timer in JOGL (like the Timer class in LWJGL)?
Reply | Threaded
Open this post in threaded view
|

Re: High-resolution timer

gouessej
Administrator
Hi!

foxua wrote
Is there platforn-independent high-resolution Timer in JOGL (like the Timer class in LWJGL)?
As far as I know, there is no plan for such a feature in JOGL but feel free to contribute.

If you really need an high-resolution timer, maybe look at the one used in Java3D (com.sun.j3d.utils.timer.J3DTimer) or in java.util.concurrent.locks.LockSupport (parkNanos uses a native high-resolution timer under the hood). Is System.nanoTime() accurate enough for your needs?
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: High-resolution timer

foxua
Thanks for the reply
AFAIK nanotime() implementation has a bug - on some multicore systems it behaves incorrectly.
I'll try to use nanotime() - maybe Oracle fixed it - I don't know.
Reply | Threaded
Open this post in threaded view
|

Re: High-resolution timer

gouessej
Administrator
foxua wrote
Thanks for the reply
AFAIK nanotime() implementation has a bug - on some multicore systems it behaves incorrectly.
I'll try to use nanotime() - maybe Oracle fixed it - I don't know.
I know this bug, I use a small workaround in TUER to detect when the time "seems" to come back :s It concerns only AMD microprocessors as far as I know.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: High-resolution timer

Sven Gothel
Administrator
On Tuesday, November 16, 2010 12:36:49 gouessej [via jogamp] wrote:

>
> foxua wrote:
> >
> > Thanks for the reply
> > AFAIK nanotime() implementation has a bug - on some multicore systems it
> > behaves incorrectly.
> > I'll try to use nanotime() - maybe Oracle fixed it - I don't know.
> >
> I know this bug, I use a small workaround in TUER to detect when the time
> "seems" to come back :s It concerns only AMD microprocessors as far as I
> know.

We may add something in gluegen Platform class:
        long getNanoTime(); // @return >=0 supported, <0 unsupported

just tell me where to fetch your implementation .. thank you.
Other ideas welcome, but I won't do it myself now, no time.


~Sven

Reply | Threaded
Open this post in threaded view
|

Re: High-resolution timer

gouessej
Administrator
Sven Gothel wrote
On Tuesday, November 16, 2010 12:36:49 gouessej [via jogamp] wrote:
>
> foxua wrote:
> >
> > Thanks for the reply
> > AFAIK nanotime() implementation has a bug - on some multicore systems it
> > behaves incorrectly.
> > I'll try to use nanotime() - maybe Oracle fixed it - I don't know.
> >
> I know this bug, I use a small workaround in TUER to detect when the time
> "seems" to come back :s It concerns only AMD microprocessors as far as I
> know.

We may add something in gluegen Platform class:
        long getNanoTime(); // @return >=0 supported, <0 unsupported

just tell me where to fetch your implementation .. thank you.
Other ideas welcome, but I won't do it myself now, no time.
The native high-resolution timer used in LockSupport is not concerned by this bug. I have looked at my source code, I don't find the hack I used. Actually, I called very often System.nanoTime() and when 2 successive calls gave absurd result, I used the Olympic average to compute the elapsed time.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: High-resolution timer

Michael Bien

On 11/16/2010 04:38 PM, gouessej [via jogamp] wrote:
Sven Gothel wrote:
On Tuesday, November 16, 2010 12:36:49 gouessej [via jogamp] wrote:
>
> foxua wrote:
> >
> > Thanks for the reply
> > AFAIK nanotime() implementation has a bug - on some multicore systems it
> > behaves incorrectly.
> > I'll try to use nanotime() - maybe Oracle fixed it - I don't know.
> >
> I know this bug, I use a small workaround in TUER to detect when the time
> "seems" to come back :s It concerns only AMD microprocessors as far as I
> know.

We may add something in gluegen Platform class:
        long getNanoTime(); // @return >=0 supported, <0 unsupported

just tell me where to fetch your implementation .. thank you.
Other ideas welcome, but I won't do it myself now, no time.
The native high-resolution timer used in LockSupport is not concerned by this bug. I have looked at my source code, I don't find the hack I used. Actually, I called very often System.nanoTime() and when 2 successive calls gave absurd result, I used the Olympic average to compute the elapsed time.


View message @ http://jogamp.762907.n3.nabble.com/High-resolution-timer-tp1901680p1911462.html
To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.


btw AMD provides an "optimizer" to workaround the multicore timing issues:
http://support.amd.com/us/Pages/dynamicDetails.aspx?ListID=c5cd2c08-1432-4756-aafa-4d9dc646342f&ItemID=153

i am not aware of any timing issues regarding System.nanotime() on other multicore CPUs.

regards,
michael

-- 
http://michael-bien.com/