# -----Original Message-----
# From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]]
# Sent: Saturday, September 01, 2001 3:01 PM
# To: Brent Dax; [EMAIL PROTECTED]
# Subject: Re: Deoptimizations
#
#
# On Saturday 01 September 2001 05:07 pm, Brent Dax wrote:
# > Of course, the hard part is detecting when the optimization
# is invalid.
# > While there are simple situations:
# >
# > sub FOO {"foo"}
# >
# > print FOO;
# >
# > evaluating to:
# >
# > /-no------"foo"-----\
# > opt: FOO redefined? -< >---print
# > \-yes-----call FOO--/
# >
# > there could also be some more complicated situations, in which the
# > situations where the optimizations are invalid are harder to define.
#
# Granted, code can always be written more complexly than our
# ability to
# understand it, in which case we very well may throw out the
# warnings that
# Thou Shall Not (if thou wants consistant, accurate results).
#
# But for many optimizations, although perhaps more with peephole
# optimizations than with full code analysis type of
# optimizations, simply
# identifying a possible optimization usually identifies its
# potential undoing
# as well.
#
# After all, optimizations don't just happen. They are, more
# or less, a set
# of known patterns that you look for. For a dynamic language,
# part of the
# original identification of those patterns may very well be
# the additional
# identification of what pieces are critical to the optimization.
#
# Of course, with as *highly* a dynamic language as Perl, there
# may be several
# hundred things that could invalidate a given optimization -
# it would be less
# optimal to detect all those things that to simply run the
# unoptimized code!
#
# But in many cases, it may only be one or two.
You'd be surprised how quickly the possibilities pile up:
sub FOO {"FOO"}
sub BAR {"BAR"}
sub BAZ {"BAZ"}
sub QUUX ("QUUX")
print FOO.BAR.BAZ.QUUX;
When you try to do inlining and constant folding, you end up with
something like this:
OPT:
Redefined FOO or BAR or BAZ or QUUX?
/ \
no yes
/ \
/ \
/ \
/ \
"FOOBARBAZQUUX" OPT:
| Redefined FOO?
| / \
| yes no
| / \
| call FOO "FOO"
| \ /
| \ /
| \ /
| \ /
| \/
| OPT:
| Redefined BAR?
| / \
| yes no
| / \
| call BAR "BAR"
| \ /
| \ /
| \ /
| \ /
| \/
| Concatenate
| ||
| OPT:
| Redefined BAZ?
| / \
| yes no
| / \
| call BAZ "BAZ"
| \ /
| \ /
| \ /
| \ /
| \/
| Concatenate
| ||
| OPT:
| Redefined QUUX?
| / \
| yes no
| / \
| call QUUX "QUUX"
| \ /
| \ /
| \ /
| \ /
| \/
| Concatenate
\ /
\ /
\ /
\ /
\ /
\ /
Print
(Yes, I have _way_ too much time on my hands...)
Actually, even this structure is sub-optimal--if only one of the subs is
redefined, you may go through three unnecessary OPT opcodes. However, I
would probably go nuts if I tried to work out the optimal optree for
this one.
Of course, the other question is, can we optimize pp_opt (or its
equivalent) so that it's one of the fastest ops? Otherwise, the OPT
opcodes may take so much time that we could have done the suboptimal
thing more quickly than checking to see if it's safe to do the optimal
thing!
Probably the best thing to do would be to estimate whether
timetoexecute(OPT)+timetoexecute(OPTIMIZED_CODE) >
timetoexecute(SUBOPTIMAL_CODE) and act accordingly. However, this could
take significant amounts of time; we probably would want this in the
optional part of the optimizer. That means that inlining and other
similar operations can only be done (safely) if we're in the optional
part of the optimizer, which usually means we're compiling, not
interpreting in the next step.
Don't get me wrong--I think this is a good idea. However, we'd probably
need some numbers to determine if it would really help much.
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
