1. Euphoria Code Optimiser
Has anyone written / does anyone fancy writing a code optimiser ?
There have been at least a couple of things mentioned on the listserv which
Robert does not think are suitable for inclusion in ex and exw which would
work very nicely in an optimiser.
The two I am thinking of are :
If <cond1> and <cond2> and <cond3>
and :
for a=1 to very_big do
x[a] = things[a][PROPERTIES][SPEED][X]
y[a] = things[a][PROPERTIES][SPEED][Y]
end for
Pretty trivial examples but I hope you get the idea.
What the optimiser could do (I am sure this list is not conclusive) is to
simply replace the
"if and and and"'s
with
"if then if then if then end if end if end if"
type statements and multiple lookups with a temporary variable. This is shown
more clearly below.
Example 1.
if x>y and length(p)>0 and update_sprites() and x != 2 and check_keyboard()
then
do_foo()
end if
Now this is not completely straightforward as some functions are called, so
the first thing the optimiser does is put the function in an *if* statement :
if update_sprites() and check_keyboard() then
...
note that length() is excluded because the optimiser knows that it is a built-
in function and has no effect on the state of the world.
Then the rest of the conditions are nested (very messy, but nobody has to read
it except the interpreter)
if update_sprites() and check_keyboard() then
if x>y then
if length(p)>0 then
if x != 2 then
do_foo()
end if
end if
end if
end if
Of course the user has to put the conditions in an appropriate order unless
the optimiser can figure out which are most likely to be false.
In this case the conditions would have to be least_likely to most_likely (to
be true) for maximum speed.
Example 2.
In the second example (this is something that I find happening a lot)
for a=1 to very_big do
x[a] = things[a][PROPERTIES][SPEED][X]
y[a] = things[a][PROPERTIES][SPEED][Y]
end for
I could have written :
sequence temp
for a=1 to very_big do
temp=things[a][PROPERTIES][SPEED]
x[a] = temp[X]
y[a] = temp[Y]
end for
(I usually do more than two slices per loop, so do not be speed-cynical)
This is horrible to read and would definitely scare me away from my code in a
few months.
So, following all that does anybody feel up to it ? (I think David Cuny did a
lot of this sort of thing before but he seems busy enough on Win32 stuff now.
I consider it beyond myself.)
By the way Rob (if you are still reading) are calculations with constants in
optimised at compile-time ?
eg
constant my_num=396
sequence bar
for a=1 to very_big do
bar={1,2,3}/my_num
grill(bar)
end for
compiles
<snip>
bar={ 0.002525252525253, 0.005050505050505, 0.007575757575758}
<end snip>
??
Sorry if I bored you.
Daniel
2. Re: Euphoria Code Optimiser
Daniel writes:
> By the way Rob (if you are still reading)
> are calculations with constants in
> optimised at compile-time ?
> eg
> constant my_num=396
> sequence bar
> for a=1 to very_big do
> bar={1,2,3}/my_num
> grill(bar)
> end for
> compiles
> <snip>
> bar={ 0.002525252525253, 0.005050505050505,
> 0.007575757575758}
> <end snip>
It would be easy to add "constant folding" into
Euphoria's optimizer, but it hasn't been done yet
because I rarely see a time-critical section of code
where a programmer repeatedly calculates with
constant values. People are smart enough to perform
the calculation once and assign the result to a
variable or constant, or at least move the calculation
out of an inner loop.
I've been tempted many times in the past to add this,
but there just don't seem to be enough cases in practice
where it actually matters. Before adding any optimization
to Euphoria, I like to scan through my directory of user
contributions to see how often the optimization would
actually pay off. That way I avoid making the compiler
more complicated without any real benefit.
Your other idea of making a pre-processor that converts
inefficient Euphoria code into efficient Euphoria code
sounds interesting.
Regards,
Rob Craig
Rapid Deployment Software
P.S. The 2.0 Official Release will be out in
less than a week. Please send any last-minute bug reports
to: rds at msn.com Thanks.
3. Re: Euphoria Code Optimiser
|It would be easy to add "constant folding" into
|Euphoria's optimizer, but it hasn't been done yet
|because I rarely see a time-critical section of code
|where a programmer repeatedly calculates with
|constant values. People are smart enough to perform
|the calculation once and assign the result to a
|variable or constant, or at least move the calculation
|out of an inner loop.
Because we know Euphoria doens't handle it yet.
Althrough code could be a lot more readable when we needed to do these
tricks..
|I've been tempted many times in the past to add this,
|but there just don't seem to be enough cases in practice
|where it actually matters. Before adding any optimization
|to Euphoria, I like to scan through my directory of user
|contributions to see how often the optimization would
|actually pay off. That way I avoid making the compiler
|more complicated without any real benefit.
1) Readablity
2) Errors and mistakes are easier caught.
3) You needed to optimize your own program and can spent more developping
time on more important stuff
|Your other idea of making a pre-processor that converts
|inefficient Euphoria code into efficient Euphoria code
|sounds interesting.
More than interesting, it could be done by another Euphoria program..
Or by the program itself using an extended form of built-in macro's. (we do
want and need that, don't we ?)
Ralf
nieuwen at xs4all.nl
icq: 93889920
'Democracy means a government is choses by those with the least objectivism
and with the least ability to make the right choice. How much do I or You
know about the arguments we base our choice on ?'
4. Re: Euphoria Code Optimiser
> More than interesting, it could be done by another Euphoria program..
This was the idea. Nobody seems willing to write it as yet. How about you Rob
? 2.0 Final will be out soon and you complain that you do not get to do enough
in Euphoria...
And about the constant pre-calculating : I agree with Ralf. Programmers work
to a language's limitations. If you are a speed freak then you substitute
readability for efficiency. Also, I have noticed an awful lot of similarities
between Euphoria and Java - interpreted, extensive checking, non-square arrays
and semi-compiling. While Euphoria is far superior in terms of simplicity,
flexibility (MAIN selling point) and also has a higher interpreter efficiency,
it is lacking in the garbage collection and compiler options (by this I refer
to Java byte codes), which I kind of assumed would come too.
Remember, no compiler or interpreter is too fast, too memory-stingy or too
easy to use.
Daniel
