Re: optimizing with === immutable comparitor
On Fri, Jul 14, 2006 at 00:30:20 -0700, Darren Duncan wrote: > This may go without saying, but ... ... This is a VM issue. It clarifies semantics, and the runtime VM may choose to do this freely for simple values (but not for objects which just pretend using .id). In short: yes, the semantics allow that, but it has nothing to do with the language it might not even be faster. -- Yuval Kogman <[EMAIL PROTECTED]> http://nothingmuch.woobling.org 0xEBD27418 pgp2roLoyDefj.pgp Description: PGP signature
Re: CORRECTION: optimizing with === immutable comparitor
Darren Duncan schreef: > What I propose concerning non-premature === optimizing is a system > where, at any time that two appearances of the same immutable value > are compared with ===, they are immediately consolidated into a > single appearance. That should only be done voluntarily. A bit like memoization. Something else: An immutable composite value can have unfinalized parts. Finalizing them for the sake of a deep comparison, can hurt performance. Does a lazy system need something like 'undecided' or 'NaB' (not-a-boolean)? -- Groet, Ruud
CORRECTION: optimizing with === immutable comparitor
At 12:30 AM -0700 7/14/06, Darren Duncan wrote: If $a === $b means what I think it does, then I believe that a not-premature implementation optimization of === would be that it always $a := $b if it was returning true, so that any future === of $a and $b or aliases thereof could short-circuit with a =:= test even if they weren't created as aliases, and Perl would be automatically more memory efficient without those extra storage copies. Sorry, I stated some things badly in that previous email, mainly the "$a := $b" part, which is technically incorrect, so I will try and clarify what I meant to say. What I propose concerning non-premature === optimizing is a system where, at any time that two appearances of the same immutable value are compared with ===, they are immediately consolidated into a single appearance. Or at least $a.value := $b.value occurs immediately, and garbage collection of the second and now unreferenced copy happens whenever it would happen. For illustration: $a = 'hello'; # one copy of the value 'hello' in memory $b = 'hello'; # a second copy of the value 'hello' elsewhere in memory $c = 'world'; # one copy of 'world' in memory $a === $b; # now only one copy of 'hello' is in memory, $a and $b point to $a === $c; # nothing changes, as values are different $b = $c; # now only $a points to 'hello', $b and $c point to one 'world' I of course did not mean for the actual symbol $a := $b to happen, only what they point to internally. Of course, the above example could be constant folded to one copy of 'hello' at compile time, but my illustration is meant to be for situations where $a and $b are declared or set far apart, possibly from run-time input values, so the folding happens at run time. What I meant with the =:= shortcut then, is that $a.value =:= $b.value could return true following the above run of $a === $b. Sorry for any confusion. FYI, I plan to explicitly illustrate the principle in my next Set::Relation update, since its types are immutable, so that any operations which involve comparing two relations or tuples or headings or values therein with === will have a side-effect of consolidating them if they are equal. Later on, if this happens at the language level, I would less likely have to do it myself. -- Darren Duncan
Re: optimizing with === immutable comparitor
On Friday 14 July 2006 00:30, Darren Duncan wrote: > This may go without saying, but ... > > If $a === $b means what I think it does, then I believe that a > not-premature implementation optimization of === would be that it > always $a := $b if it was returning true, so that any future === of > $a and $b or aliases thereof could short-circuit with a =:= test even > if they weren't created as aliases, and Perl would be automatically > more memory efficient without those extra storage copies. > > I know that was an implementation issue, but I think that it stands > to be explicitly stated anyway, as it is a very simple and effective > way to make Perl programs more resource efficient, possibly by orders > of magnitude, over not doing so. First there was copy-on-write and now there's share-on-compare? > (The only time this may not work is if so-called immutable types are > tied to external resourses, but then I'm not sure how often this > would happen in practice so it could just be an exception if > necessary. The above-stated rule would still stand for any resources > managed by Perl itself.) In the absence of much Perl 6 code either way, I wonder at the value of adding such an extreme side effect to a simple comparison operation. This goes way beyond loop hoisting and constant folding. I can understand singleton value types (even Perl 5 does that with PL_undef), but ... wow, you have a lot more faith in local code analysis than I do. -- c
optimizing with === immutable comparitor
This may go without saying, but ... If $a === $b means what I think it does, then I believe that a not-premature implementation optimization of === would be that it always $a := $b if it was returning true, so that any future === of $a and $b or aliases thereof could short-circuit with a =:= test even if they weren't created as aliases, and Perl would be automatically more memory efficient without those extra storage copies. I know that was an implementation issue, but I think that it stands to be explicitly stated anyway, as it is a very simple and effective way to make Perl programs more resource efficient, possibly by orders of magnitude, over not doing so. (The only time this may not work is if so-called immutable types are tied to external resourses, but then I'm not sure how often this would happen in practice so it could just be an exception if necessary. The above-stated rule would still stand for any resources managed by Perl itself.) -- Darren Duncan
