1. and...and...and

Einar Mogen writes:
> Then, I discovered something about speed last night. This could be old news
for
> all you, but of these two "if's":

> if ... and ... and ... and ... then
>        <...>
> end if

> if ... then
>        if ... then
>                if ... then
>                        if ... then
>                                <...>
>                        end if
>                end if
>        end if
> end if

> -the last one is the fastest. Shouldn't Euphoria just skip the rest of an
"if
> ... and" line if the first part checks false? It seems to me that all parts
of
> an "if ... and ... and" line is checked each time, which did result in a
> slowdown in my game.

You are correct. Euphoria does not do "short-circuit" evaluation of and/or/not
conditions.
I have this on my list of desirable features, but it might not happen for a
while,
if at all, because:

   1. It's hard to retrofit this in to ex.exe.

   2. It would break some people's existing code (only a tiny percentage I
would guess)
       in the case where there are side effects from evaluation (e.g. function
call sets a global variable)

   3. Euphoria's conditional expressions can involve sequences, as well as
atoms. e.g.
      if A and B then ..., where A is 1 and B is {0,1,2} is supposed to
evaluate to {0,1,1}
      which is supposed to cause an error when used in an if statement. We'd
have to
      accept A and B as being "true" without any error message.

> Do the rest of you know of other "trivial things" which could have a
> major impact on speed?

In Euphoria there are a surprising number (even to me)
of trivial things that can affect performance. This is generally due to the
fact that Euphoria does not map directly to machine code the way C does.
The Euphoria interpreter is doing "invisible" things, such as storage
allocation,
in order to give you a simple, safe, flexible world to program in.

Fortunately, in Euphoria you have the ability to profile your code using:

      with profile
or
      with profile_time

If you care about performance you really should profile
your code at least once. Do not assume that you "know" which
sections of code are consuming most of the time. You will *often*
be surprised.

You can also time small sections of code using:

     atom t
     t = time()
     for i = 1 to 1000000 do
         -- your code goes here
     end for
     ?(time()-t)/1000000

Regards,
   Rob Craig
   Rapid Deployment Software

new topic     » topic index » view message » categorize

2. Re: and...and...and

Robert Craig wrote:

> > -the last one is the fastest. Shouldn't Euphoria just skip the rest
> of an
> "if
> > ... and" line if the first part checks false? It seems to me that
> all parts
> of
> > an "if ... and ... and" line is checked each time, which did result
> in a
> > slowdown in my game.
>
> You are correct. Euphoria does not do "short-circuit" evaluation of
> and/or/not
> conditions.
> I have this on my list of desirable features, but it might not happen
> for a
> while,
> if at all, because:
>
>    1. It's hard to retrofit this in to ex.exe.

    Can't you put it in the precompiler as different if's

>    2. It would break some people's existing code (only a tiny
> percentage I
> would guess)
>        in the case where there are side effects from evaluation (e.g.
> function
> call sets a global variable)

    The precompiler makes a first if with only those evulations that
have a side effect. (That call another function or routine). After that
it can compile the rest of the evalutions on different (sub)-ifs

>    3. Euphoria's conditional expressions can involve sequences, as
> well as
> atoms. e.g.
>       if A and B then ..., where A is 1 and B is {0,1,2} is supposed
> to
> evaluate to {0,1,1}
>       which is supposed to cause an error when used in an if
> statement. We'd
> have to
>       accept A and B as being "true" without any error message.

    Have the objects also in the first if.

> > Do the rest of you know of other "trivial things" which could have a
>
> > major impact on speed?
>
> In Euphoria there are a surprising number (even to me)
> of trivial things that can affect performance. This is generally due
> to the
> fact that Euphoria does not map directly to machine code the way C
> does.
> The Euphoria interpreter is doing "invisible" things, such as storage
> allocation,
> in order to give you a simple, safe, flexible world to program in.

       I'll give you two examples that will show a weird speed
difference...

-- Example 1
    function my_func (sequence r)
    sequence s
        s = r[1][2][3][4]
        if s[1] = 1 then
        elsif s[2] = 2 then
        elsif s[3] = 3 then
        elsif s[4] = 4 then
        elsif s[5] = 5 then
        elsif s[6] = 6 then
        end if
        my_procedure (s+4+s)
        return s+ (s*2)
    end function

-- Example 2
    function my_func (sequence r)
        if r[1][2][3][4][1] = 1 then
        elsif r[1][2][3][4][2] = 2 then
        elsif r[1][2][3][4][3] = 3 then
        elsif r[1][2][3][4][4] = 4 then
        elsif r[1][2][3][4][5] = 5 then
        elsif r[1][2][3][4][6] = 6 then
        end if
        my_procedure (r[1][2][3][4]+4+r[1][2][3][4])
        return r[1][2][3][4]+ (r[1][2][3][4]*2)
    end function

-- End of examples

 The first code looks nicer, but declares a sequence and copy
r[1][2][3][4] to it.
            and that code is still faster (on my machine: p60, 24 mb,
win95)
I think it is because every time you use r[1][2][3][4], it looks up r[1]
then r[1][2] then r[1][2][3] then r[1][2][3][4]. (It will be passed
forwared 3 times)
However the other code doens't actually copy it. It only copies the
link/ the pointer to the sequence of r[1][2][3][4]. And when we change a
value in it, Then it will start copying the whole sequence. (But we
don't)

Ralf Nieuwenhuijsen
nieuwen at xs4all.nl

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu