Excellent Larry - thanks for the explanations (although the GetSystemTime() vs. time() one still baffles me - I'll dig into the assembly code when I get some time). It's good to know that Rebol is probably a (nearly) pure interpreter especially when dealing with loop calculations. The fact that 'repeat and 'loop should be used when at all possible will hopefully be documented at some point because I can see unsuspecting C programmers thinking like I did. (In fact, a few pages on how to optimize common operations would eventually be appropriate). Thanks again, Rodney -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 20, 2000 1:33 PM To: [EMAIL PROTECTED] Subject: [REBOL] teeny-bits-of-time/2 Re:(4) 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
