Comments on: New Timebase
Some parts updated 2-Nov-2009
To allow more accurate timing in wait, R3 uses a different timebase than R2.
In R3, we use the QueryPerformanceCounter() method of timing and a continuous delta time is computed during the event processing of the wait.
The resolution of this timing method is about 1 microsecond (.000001). You can confirm the resolution of timing by calling stats/timer in a short loop.
However, we set the current time resolution for multitasking context switching within wait to 1 millisecond (0.001 sec). You can still call wait with values less than that, but depending on the situation, the CPU is not guaranteed to yield the processor.
Examples:
>> dt [wait 1]
== 0:00:01.007747
>> dt [wait .1]
== 0:00:00.102422
>> dt [wait .01]
== 0:00:00.009587
>> dt [wait .00001]
== 0:00:00.000013
The slight variation in timing is due to operating system variations in multitasking response and overhead.
More
We can change this resolution if we need to, but I don't see the benefit because most operating systems are not real-time. Between device overhead and timeslicing, we are lucky to get within a millisecond at all. (However, I should note that the R3 event/timer design is much more efficient and streamlined compared to R2.)
The code that handles timing is in the open source R3 API, so it can be adjusted as necessary. There are a few items we will need to consider:
- An equivalent of QueryPerformanceCounter will be needed for non MS systems such as OSX, Linux, cellphones, etc. (At worst case, we can use tick time as in R2, which is only about .02 resolution).
- QueryPerformanceCounter may not exist on older hardware. So, #1 may be required if that condition is detected.
- Regardless, we assume the CPU overhead of whatever method is used is extremely low.
11 Comments Comments:
Brian Tiffin
25-Apr-2007 15:28:48 |
I'm not sure where things stand with POSIX compliance now-a-days, but the POSIX realtime extension spec uses
clock_getres() for getting at clock resolutions. It exists in Debian 4.0, my direct knowledge stops there. | Jeff M
25-Apr-2007 23:27:30 |
While for general purpose scripting and most of what REBOL would be used for I would agree, increasing the resolution only helps the programmer - it can't hurt.
There are *many* applications where microsecond timing resolution can be extremely beneficial. If REBOL 3 is to be embedded as well (ie REBOL/Embed) then this becomes even more important as REBOL may be used from within C/C++ applications that are performance critical and could use such information. | Anton Rolls
25-Apr-2007 23:56:52 |
This seems good. I was just reading about QueryPerformanceCounter the other day. | Rob Lancaster
26-Apr-2007 6:13 |
You might not be able to guarantee Millisecond timer accuracy for a function like wait, but I'd be more inclined to make the time! resolution as fine grained as possible... You may be hooked up to a GPS receiver... or some kind of data logger...
However, If time! can have differing resolution on different platforms... are you going to need a system for adding percentage errors when combining time! from different platforms... off at a random tangent.
| Scot
26-Apr-2007 12:27:59 |
Yes! Great decision. Couples the timing to the device rather than the system. This is very very good, IMO. | Anton Rolls
27-Apr-2007 1:57:10 |
You must have found this document:
http://www.geisswerks.com/ryan/FAQS/timing.html
| Maxim Olivier-Adlhoch
28-Apr-2007 20:08:24 |
if REBOL is to interface with things like Audio or video systems which want to update at EXACT rates or precise moments, the most precise you can make it, the better it is :-)
if an external device (lets say a realtime HD I/O framebuffer) is actually precisely syncing using an external source, then timing precision becomes very important and a millisecond is not such a minute amount anymore
ex: standard video and 1080i HD work at 60Hz... this means you must be able to time yourself at a minum of 0.016666666... ... in this case a millisecond is drastic... after a second, your already jerking a frame... and we really perceive this everytime it happens.
obviously I don't expect REBOL to be creating or processing Graphics at those rates, but its timing to interface external libs, should be able to react AT some precise moments. if only to send calls smoothly. | Maxim Olivier-Adlhoch
28-Apr-2007 20:20:35 |
btw, thanks for putting this in the open source part, so those with bigger needs can fullfill them, when the moment comes. :-) | Rob Lancaster
2-May-2007 5:27:14 |
Percentage Errors indeed! What I was trying to get at was the problems of inferred accuracy when time! measurements from Rebols running on a variety of machines with different time granularities are combined..
a: make time! 10.00001 ; from my pentium
b: make time! 10.00 ; from my C64
add a b
>> 20.00
Could be this be considered a little more safer? Maybe not mathmatically.. but engineering wise... If all measurements or other time! operation were conducted on the same machine... this wouldn't be an issue..
If I wanted the accuracy, then maybe...
add/extend a b
>> 20.00001
| Jorge Acereda
6-May-2007 6:01:15 |
For Mac OS X you can probably use mach/clock.h.
| Oldes
27-Oct-2010 5:33:55 |
Rob, you may already know it, because it's year 2010 now, but anyway:
>> a: make time! 10.00001
== 0:00:10.00001
>> b: make time! 10.00
== 0:00:10
>> add a b
== 0:00:20.00001
>> a + b
== 0:00:20.00001
|
Post a Comment:
You can post a comment here. Keep it on-topic.
|
