Hi Rodney
I found your test results interesting.
> I don't quite understand a couple of things. The first is how
> GetSystemTime() can be faster than time() (since it is splitting
> out all the fields year, day, etc.). The second is why it takes
> Rebol so long. I of course would expect Rebol to take a longer
> time but it seems a little excessive on the outset. Maybe Rebol
> has no way of "compiling" a statement and interprets it each time?
My guess is that REBOL is a (nearly) pure interpreter, so no "compiling" to
byte-code or equivalent is involved.
> Note that just comparing a C example of incrementing an integer
> a million times vs the Rebol equivalent shows that Rebol is about
> 4 times slower with this task - again, not totally unexpected but
> it does seem like a lot slower.
Actually pretty fast for an interpreted language. But see below for a more
realistic comparison.
> Another wierd thing I don't understand is if I replace the
> 'while loop in the Rebol example with a 'for loop, the result
> is around 20 seconds! Thus, using a 'for loop in Rebol is
> slower than using a 'while loop which doesn't seem right to
> me. I tried the same thing with the C examples and for loops
> are a little faster than while loops, but not much. Maybe
> Carl and Co. have some clue about this.
Yes, there are differences in the speed of various simple looping constructs
in REBOL. On 450MHz Win 98 machine with Viewbeta 4.1, I get:
>> t1: now/time loop 10'000'000 [] t2: now/time t2 - t1
== 0:00:01
>> t1: now/time repeat j 10'000'000 [] t2: now/time t2 - t1
== 0:00:01
>> t1: now/time j: 0 while [j < 10'000'000] [j: j + 1] t2: now/time t2 - t1
== 0:00:21
>> t1: now/time for j 1 10'000'000 1 [] t2: now/time t2 - t1
== 0:00:50
LOOP is the fastest method, closely followed by REPEAT, WHILE is the next
fastest, and FOR is very slow. The reason FOR is so slow is that unlike the
others which are NATIVE's, FOR is a function written in REBOL. You can use
"source for" in order to see the code. WHILE is slower because it needs to
increment the index using REBOL and also evaluate the REBOL termination
condition. With REPEAT the incrementing of the index is done by the
underlying C-code. There is no connection between the C FOR and the REBOL
FOR.
> So, not sure what all this means or if there is any way to optimize
> the Rebol operations. My main concern is that the only way
> to have a timer in Rebol and still perform other processing is
> to loop and call 'now each time which obviously takes a big chunk
> of time.
I think RT should either increase the accuracy of NOW or create a timer
function, in either case returning a result with millisecond precision (the
least significant digits may be inaccurate or set to zero on some systems).
The Command version allows you to directly call the C-runtime library
functions for timing if you wish.
> One bug I saw, even though the users-guide says that refinement of /second
> should work on a date! type, it does not in Rebol/Core. Maybe
> this is fixed in /View?
The docs are misleading. Actually, /second is a refinement for the time!
datatype:
>> t: now/time
== 13:27:44
>> type? t
== time!
>> t/second
== 44
One needs to exercise caution in interpreting the simple loop timings above
because in many cases the operations in the loop block will require enough
time to make the overhead insignificant. If not, then use LOOP or REPEAT
when possible.
In December 99, I ran a lot of timings for linear algebra operations in
REBOL, for instance matrix multiplication, matrix inversion, LU
decomposition, etc. on 100x100 randomly generated matrices. The bottom line
was that REBOL was about 80-300 times slower than MATLAB which uses highly
optimised C-code for the same operations. This is a more realistic
comparison for numerics intensive work. These REBOL times are comparable
with those achieved in other interpreted languages, indeed much better than
some.
-Larry
> Rodney
