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
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
