World: r3wp

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.

:-)

so, I should definitely have it patented ;-)

>> time-block [ ] 0,05
== 1.251220703125E-8

Yes, interesting, so, even though your processor is a bit slower 
than mine, the NOW/PRECISE evaluation is significantly faster

Couldn't that be influenced by the underlying system calls

sure

I wouldn't be surprised that just about all system calls are faster 
on OSX

my mac mini is a super chitty system HW, but its still faster at 
editing video than PCs four times as capable.

chitty = shitty... hehhe

Nevertheless, taking into account, that the clock resolution is better, 
it looks like the OSX actually does more (useful) work than Windows 
7

Out of interest, I ran the same tests in  Windows/XP running under 
Virtual Box:

>> do http://www.fm.tul.cz/~ladislav/rebol/timblk.r
== 1.00330578512397E-2
>>  time-block [now/precise] 0,05
== 7.59124755859375E-7
>> time-block [ ] 0,05
== 7.57351517677307E-9

hmm, this looks, that the "system clock" are quite inexact in your 
VirtualBox, I guess

That could well be the case - let me run them again

I think, that I read somewhere, that system clocks in virtual machines 
may be problematic...

The times for time-block [] and [now/precise] are quite consistent. 
The time for timblk.r improved to around 9.93E-3.
 

Windows may still have been completing its start-up when I ran the 
very first test.

Nevertheless, according to the results, your XP is not SP2 or later, 
I would say

XP SP3

hmm, surprising, normally you would obtain 15.5 milliseconds as the 
first value...

I've just run the timblk script another 5 times each time the result 
is ~9.937E-3

you do not have to run the script, it is the

    tick-time: time-tick 0.05

expression