World: r3wp

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.

this does not have anything in common with resolution, this is about 
interpretation speed, Max

and how do you measure the execution?  by accessing some form of 
timing or time information.

so what?

if OSX has ten times the resolution, it will give you the impression 
that its ten times faster.

wrong

how so?

Of course, the evaluation time of NOW/TIME may be operating system 
dependent, but it is still interpretation time (of the above expression)

Peter, how about this one?

>> time-block [] 0,05
== 7.80820846557617E-9

Max: "how so?" - I suppose, that you do see, that the TIME-BLOCK 
function is able to measure evaluation time even if it is shorter 
than the system clock resolution?

(the "trick" is pretty simple, everybody knows how to do that, check 
the source)

finding out it is so obvious, I should probably patent the idea, 
shouldn't I?

My system is Windows 7 Business 64-bit, AMD Athlon X2 250 at 3GHz

>> time-block [] 0.05
== 1.45263671875E-8

Yes, certainly faster

, so, it looks, that the time the system spends in NOW/PRECISE is 
nonnegligible

what does this do in the time-block  while condition?

(3 * tick-time / time)

adds the relative error possibly caused by clock resolution to the 
figure to make sure we achieve the desired accuracy

I'm curious as to why the resolution is multiplied by 3?

because we have two measurements, the previous one using two times 
less cycles, i.e. possibly having twice the influence of the resolution

ok makes sense.

:-)