optimizing with === immutable comparitor
Darren Duncan
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
Chromatic
> 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
Darren Duncan
>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
Ruud H.G. van Tol
> 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
Yuval Kogman
> 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 <nothi...@woobling.org>
http://nothingmuch.woobling.org 0xEBD27418