World: r3wp

sorry, it's already in the file., And it's XP SP3

9.8876404494382E-4 Vista

XP x64
== 1.54678899082569E-2

thanks, I assume, Gregg, that your value is either for XP x64 SP2 
or SP3?

hmm, Paul's value is quite strange, taking into account, that Steeve 
measured it to be 1 ms

mine is on 32 bit Vista running AMD.

aha, OK, the difference is still just 1.12%, i.e. it is in the tolerance

Sorry, yes, SP2.

Btw, got the same results with R2 and R3

This test shows well why some graphical demos work bad on some systems 
even if the computers are faster than mine  (Vista with a tiny celeron).

hmm, I just checked a Vista Business 64 bit (not updated for quite 
some time), and it used 15.5 milliseconds too...

The same result with R2 and R3
 - of course, this value is a property of the operating system

it could have been that they use different timer libs.

or whatever lib the core uses to calculate time

well, this is not about "time calculation", it is about frequency 
of time update

but, certainly, it is possible to update the time every time the 
operating system is asked to provide the time. That way, the time 
can be updated as frequently, as the program is able to ask. I guess, 
that in Linux it works that way, any results?

Although I can only guess, I think the issue lies in that the actual 
os calls being used do not provide greater precision.


In R3 there are other means to get the time which do provide much 
greater precision, so its strange that they do not also apply to 
now/precise.

wrt "get the time"... I meant to say:

get timing information

...its strange that they do not also apply...

 - nothing strange, it is a different kind of counter, not the one 
 used to get the system time (that might mean, that it actually is 
 less precise, e.g.)

What I think too...


but if R3 can get precise timing info, it could arguably add this 
precise elapsed period since last *time* check and add it to the 
result when now/precise is called in a script. 

just an idea... thinking out loud.

even in R2, when you look at an event! object, the timing counter 
within is much more precise than now/precise...  which is why I can 
use mouse move events to check time elapsed much more precisely than 
the mediocre 'time event generating, OS timer which /view is using.

precise timing

 - that is exactly the opposite meaning than what I am using. Example:


clocks usually display time in seconds, using second as the smallest 
unit. That does not mean, clocks are imprecise, they may actually 
be more precise, than a counter counting every microsecond, e.g., 
but with a 0.1 % error, meaning, that in one day, such a counter 
may be e.g. one and a half minute slow in one day

well there are different precisions  ;-)


resolution and measure.  what we are measuring here is the resolution. 
 no?

yes, exactly

>> do http://www.fm.tul.cz/~ladislav/rebol/timblk.r

Warning: clock tick too short, the result is the loop body execution 
time!
== 5.53774319066148E-5


R2 2.7.7 on Linux, 64b (even though I guess the warning means the 
result is useless :)

hence the use of word "timing"  ;-P


adding timing resolution within the "passage of time" resolution 
would be arguably sufficient for me even if it meant we are ~0.1 
ms off, as long as we get a constant increment of milliseconds (or 
better) to use.


right now the time resolution is sooo poor (on windows) its often 
frustrating.

thanks, Andreas, it does not mean, that the result is useless, actually, 
it just means, that the resolution is finer than Rebol is able to 
measure

nevertheless, it means, that you may well use this value as the clock 
granularity for the profiling purposes, since the actual granularity 
is even better

so, we can say, that the clock resolution in Linux is better than 
55 microseconds

Script: "Time-block" (31-May-2010/11:01:46+2:00)

 Warning: clock tick too short, the result is the loop body execution 
 time!
== 2.09338521400778E-6

Rebol 2.7.5 on Mac OS X 10.64 bit

Script: "Time-block" (31-May-2010/11:01:46+2:00)

Warning: clock tick too short, the result is the loop body execution 
time!
== 3.37364341085271E-5

Rebol 2.7.6 on Ubuntu Hardy 64-bit

Peter - hmm, better resolution, than 2 microseconds, that is quite 
fast machine

but, generally, it looks, that Windows may well be the only operating 
system currently, that still has a detectable resolution time of 
operating system clock

REBOL/Core 2.7.6.4.2 (14-Mar-2008)
>> do http://www.fm.tul.cz/~ladislav/rebol/timblk.r
connecting to: www.fm.tul.cz
Script: "Time-block" (31-May-2010/11:01:46+2:00)

Warning: clock tick too short, the result is the loop body execution 
time!
== 2.48837209302326E-5

this is Linux Mint 7 64bit

Ladislav - It's a 2.5 year old MacBookPro with a 2.4GHz Core 2 Duo 
- I think there are much faster processors around these days.

OpenBSD.i386

REBOL/Core 2.7.7.9.4 (5-Apr-2010)
>> do http://www.fm.tul.cz/~ladislav/rebol/timblk.r
connecting to: www.fm.tul.cz
Script: "Time-block" (1-Jun-2010/13:40:09+2:00)

Warning: clock tick too short, the result is the loop body execution 
time!
== 2.94573643410853E-6

Well, Peter, that is possible, but it looks, that your processor 
is about ten times faster than the one Gabriele or Andreas use

Isn't it OS-dependent? BSD&OSX value seems to be about 2E-6, while 
Linux is around 2E-5 .

This entry at Wikipedia seems to suggest that is it OS dependent 
- http://en.wikipedia.org/wiki/System_time#Operating_systems

This is the result of speed.r on my machine under Rebol 2.7.5

Console:   0:00:00.150098 - 3372 KC/S

Processor: 0:00:00.249708 - 3460 RHz (REBOL-Hertz)

Memory:    0:00:00.468639 - 101 MB/S
Disk/File: 0:00:00.37127 - 82 MB/S

CPU[-Dual core Intel Core2 Duo E8135 (SMP) clocked at 2660.000 Mhz-] 
Kernel[-2.6.28-18-generic x86_64-] Up[-20 min-] Mem[-808.7/3615.9MB-] 
HDD[-640.1GB(9.1% used)-] Procs[-171-] Client[-Shell-] inxi[-1.1.13-]

So Gabriele's processor is faster than mine.

I tell you what is so surprising about the results:


Since the result is the loop body execution time, it looks, that 
the loop body in Peter's computer works ten times faster. Gabriele, 
Davide, and Peter, could you please post here your result of the 
following expression?:

>> time-block [now/precise] 0,05
== 2.3651123046875E-6


 it looks that your processor works faster, Peter: your result is 
 the loop body execution time, which is about ten times shorter, than 
 the loop body execution time Ga

sorry, disregard the last three lines above, please (wrong edit)

>>  time-block [now/precise] 0,05
== 9.0625E-7
 
OSX, [Core2Duo-:-2Ghz]

>> do http://www.fm.tul.cz/~ladislav/rebol/timblk.r
connecting to: www.fm.tul.cz
Script: "Time-block" (1-Jun-2010/13:40:09+2:00)

Warning: clock tick too short, the result is the loop body execution 
time!
== 1.78988326848249E-6

yes, your values correspond well to each other, the loop body calls 
now/precise and uses a comparison and IF

>>  time-block [now/precise] 0,05

== 7.1484375E-7

OSX, [Core2Duo-:-2-:-4GHz]

I wouldn't be surprised if OSX had an order of magnitude better resolution 
in all things related to time and its measurement.