Re: Imrpoving tie() (Re: RFC 15 (v1) Stronger typing through tie.)
Dan Sugalski writes: I don't mind if someone overrides the vtable functions for a variable of a built-in type--a standard declaration of: my $foo; is really shorthand for: my generic_scalar $foo; more or less. If a variable gets its vtable functions messed with, well, that's OK. If + doesn't actually add, well, no biggie. I'd like to have the optimizer not assume functionality on variables that have been overridden somehow. (So if $foo gets tied we stop assuming we know what + does, for example) The bigger thing I worry about is if someone does something odd like make + short-circuit, or not short-circuit. That's the sort of base behaviours I'd like written in stone someplace. Would that really be a problem? Damian is writing an RFC that will propose allowing '?' in a function prototype to indicate a lazily evaluated parameter. If someone overloaded C+ with a function that had a prototype where the 2nd parameter was evaluated lazily, couldn't Perl notice this and do the right thing?
Re: Imrpoving tie() (Re: RFC 15 (v1) Stronger typing through tie.)
At 12:48 PM 8/13/00 +1000, Jeremy Howard wrote: Dan Sugalski writes: I don't mind if someone overrides the vtable functions for a variable of a built-in type--a standard declaration of: my $foo; is really shorthand for: my generic_scalar $foo; more or less. If a variable gets its vtable functions messed with, well, that's OK. If + doesn't actually add, well, no biggie. I'd like to have the optimizer not assume functionality on variables that have been overridden somehow. (So if $foo gets tied we stop assuming we know what + does, for example) The bigger thing I worry about is if someone does something odd like make + short-circuit, or not short-circuit. That's the sort of base behaviours I'd like written in stone someplace. Would that really be a problem? Damian is writing an RFC that will propose allowing '?' in a function prototype to indicate a lazily evaluated parameter. If someone overloaded C+ with a function that had a prototype where the 2nd parameter was evaluated lazily, couldn't Perl notice this and do the right thing? Yeah, but we can't guarantee that the function doing the overriding is one written in perl. (Tying and overriding may share an underlying implementation, though I'm not sure yet) Regardless, we can't always tell at compile time if a variable is tied or not, so we'd actually need to have both code paths available with some sort of 'ifweird' opcode that chose the path based on the variables involved. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Imrpoving tie() (Re: RFC 15 (v1) Stronger typing through tie.)
At 12:23 PM 8/12/00 -0700, Larry Wall wrote: Dan Sugalski writes: : 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. I haven't been terribly happy with tie for some time. I'd rather we had more type-based approach, which could: 1) factor the work out to one spot so you wouldn't have to call tie on every element of an array, for instance. 2) let us tie lexically scoped variables that don't leak out to the surrounding program. I'm hoping for both. Playing vtable games should help with it. And even if we keep the current tie interface (and we probably have to, even if we add a better way), we can probably limit the damage other ways. If we see a declaration like: my int $foo; we can decide either that $foo will never be tied, or that it will never be tied to an implementation that violates the standard meaning of +. I don't mind if someone overrides the vtable functions for a variable of a built-in type--a standard declaration of: my $foo; is really shorthand for: my generic_scalar $foo; more or less. If a variable gets its vtable functions messed with, well, that's OK. If + doesn't actually add, well, no biggie. I'd like to have the optimizer not assume functionality on variables that have been overridden somehow. (So if $foo gets tied we stop assuming we know what + does, for example) The bigger thing I worry about is if someone does something odd like make + short-circuit, or not short-circuit. That's the sort of base behaviours I'd like written in stone someplace. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Imrpoving tie() (Re: RFC 15 (v1) Stronger typing through tie.)
At 12:35 PM 8/4/00 -0400, Chaim Frenkel wrote: "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS The language semantics of tie strongly impact the internals. tie() is DS basically a declaration that the rules are completely different (and DS unknown at compile time) for the tied variable. Shoots down optimization a DS bunch, since access to a tied varible has to be treated as a function call DS rather than as access to data with known behaviours. Why? The vtbl for a tied variable would do all the work. Either the pointer is to a springboard into perl code, or internal code, or the XS replacement code. It's more than that. If the optimizer does code flow, it can know that $foo's been assigned an integer, for example, and maybe even that that variable's never been changed, so this: $foo = 12; $bar = something(); $bar = $foo; could work out to: $foo = $bar = 12; something(); 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. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Imrpoving tie() (Re: RFC 15 (v1) Stronger typing through tie.)
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS The language semantics of tie strongly impact the internals. tie() is DS basically a declaration that the rules are completely different (and DS unknown at compile time) for the tied variable. Shoots down optimization a DS bunch, since access to a tied varible has to be treated as a function call DS rather than as access to data with known behaviours. Why? The vtbl for a tied variable would do all the work. Either the pointer is to a springboard into perl code, or internal code, or the XS replacement code. We might be able to add a hint hook to the module (or the vtbl) that would help optimization and the compiler. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Imrpoving tie() (Re: RFC 15 (v1) Stronger typing through tie.)
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
