OpenEuphoria

Re: type string

• Posted by Roderick Jackson <rjackson at CSIWEB.COM> Mar 19, 1999
• 489 views

Ralf wrote:

>> Changing those variables to real expressions had
>> a curious impact.Replacing T with (T = 1) and F
>> with (F = 1) reversed the results. Now the second
>> example was consistently *faster*; in fact, the
>> speed change was hardly noteworthy. Example #1,
>> on the other hand, had enough of a speed decrease
>> to make it the undesirable choice; about a 50%
>> drop. (All of this was done under version 2.1.)
>
>Robert, what precizely is the interpreter doing ?
>I mean, this suprises me. This doesnt not need to be off course.
>
>> BTW - I ran both types of tests under 2.0 as
>> well. When simple integer variables were used,
>> example 1 was still faster, which is what prompted
>> me to think there was only a simple calculation
>> being performed. When using (T = 1) and (F = 1) as
>> expressions, example 2 won without ANY difficulty.
>
>Why is there a difference between an expression and a variable ?
>There needn't to be any.

Well, if the interpreter sees:

   if (real_expr1) or (real_expr2) then
      code
   end if

it knows that the results of two expressions are being
used. I would think it wouldn't actually check at
compile-time to see how complex the expressions are. It
just knows that it has to perform at least one arbitrary
computation before it can find out the truth value of
each expression. It might compile this 'if' statement,
knowing it contains an 'or', to a tokenized form similar
to the following (assuming short-circuiting is
implemented):

       compute expr. #1    -- arbitrary code for expr. #1;
        ...                -- may span several commands.
    jump-if-not-zero L1 -- if TRUE result, goto LABEL1.
    compute expr. #2    -- arbitrary code for expr. #2;
     ...                -- may span several commands.
    jump-if-zero L2     -- if FALSE result, goto LABEL2.
L1:  code               -- the code to be exectued.
L2:  ...                -- code after the 'if-then'.

On the other hand, if the interpreter sees:

   if (integer1) or (integer2) then
      code
   end if

it knows that the "expressions" really don't take any
work to evaluate... they already contain truth values.
Even if the language supports short-circuting, ignoring
it in this case wouldn't disturb anything, and would
actually speed things up, by tokenizing into somthing
like:

       or int1, int2   -- result = int1 or int2;
                       -- a fast bitwise calculation.
       jump-if-zero L1 -- if FALSE, goto LABEL1.
        code           -- the code to be executed.
   L1:  ...            -- everything after the 'if-then'.

Understand, I'm not saying this is exactly how the
Euphoria interpreter works. But I suspect it's very
close. 

Moral of the story: in Euphoria, integer values in an
'if' statement (and presumably a 'while' statement)
are faster than even simple expressions.

Of course, eventually I'll have to see if storing the
result of two expressions before using them (once) in
an 'if' statement actually speeds things up... 


Rod Jackson