At 09:38 PM 8/4/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > $foo = 12;
> > $bar = something();
> > $bar = $foo;
> >
> > could work out to:
> >
> > $foo = $bar = 12;
> > something();
>
>If $foo is a lexical variable and it hasn't been aliased then
>you might be able to do that optimization. The following is just
>as good and safer:
>
>$foo = 12;
>scalar(something());
>$bar = $foo;
Integer constant assignment may well be cheaper than scalar copies. You're
right about the scalar bit, though, since it's not the same as void context.
> > Where if you tie, we have *no* idea what you're doing. This:
> >
> > tie $foo, SomeModule;
> > $foo = 12;
> >
> > could well reboot some server in outer mongolia for all we know. Tied
> > variable access counts as a function call, which smacks optimization all by
> > itself.
>
>Do we have to worry about pass-by-ref semantics and @_ assignments
>too? This is a weird edge case that I've never ran into. That's going
>to put a big damper on optimization with subs.
Probably not with tie, but with function calls in general, sure. We can do
some flow control analysis on the subs and propagate it outwards so we
might know, for example, that:
sub foo {
my (@vars) = @_;
return scalar @vars;
}
doesn't change its args or any globals, so can be safely optimized around
to some extent.
>Actually, we have this problem without tie if we allow external
>code to register new primitive types. For example, we assume that +
>is commutative so that we can re-order expressions and fold constants.
>That would break a module that implemented some weird + that wasn't
>commutative.
Yup. It's an issue for things that implement any non-standard semantics for
existing ops, especially if those ops are overridden at runtime so the
optimizer doesn't know. It's one thing to mess with tied variables, its
another entirely to make + behave differently.
I think we'll need to get a ruling from Larry at some point on this one.
>Anybody that does this has to define a new operator, i.e. if they
>use the standard operators, they have to live with the standard
>semantics. (This is why string concatentation should never use +!)
That works for me.
>I really need to start playing with a parser and dataflow analysis
>before thinking too much more about this. It might be that we need
>something *way* more strict than use strict before aggresive
>optimization is possible.
Well, we can still do some pretty aggressive things, but there will be some
significant limits to code movement and such. Luckily (?) perl's not fast
enough that rescheduling's a big deal--it's not like with machine code
where you want to reorder to avoid cache misses and pipeline stalls and
such. Hoisting code out of a loop, like so:
foreach (1..10) {
$i = $_;
print $i;
}
to
foreach (1..10) [
print $_;
}
$i = 10;
Or, I suppose, this:
print "12345678910";
$i=10;
will be a win, but when exactly assignments happen isn't nearly as big a
deal. I think. Maybe.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
