Slim down selection of mathematics vtables #495

Open
Whiteknight opened this Issue Feb 11, 2010 · 4 comments

Comments

Projects
None yet
4 participants
Contributor

Whiteknight commented Feb 11, 2010

We have far too many mathematics vtables for too many combinations of input arguments. I would like to make the following suggestions:

  • Convert all "3-argument" VTABLEs to "2-argument" ones. These are of the form "PMC * foo(PMC *value, PMC *dest)". VTABLEs of this form are extremely inconsistent throughout the codebase for the handling of the third "dest" argument. In many implementations the third argument is completely unused. I suggest they should all be changed to "PMC *foo(PMC *value)", and always return a new PMC that contains the resultant value.
  • Remove all "i_*" vtables. These are less frequently used and tend to be implemented internally in terms of the 3-argument vtables.

These changes will signficantly reduce bloat of the VTABLE structure and decrease Parrot's memory footprint and startup times. We'll also be able to have more consistent implementations of the math ops across all core types, and will have a much lower maintenance burden if we need to make changes to these operations.

Originally http://trac.parrot.org/parrot/ticket/1434

Owner

pmichaud commented Feb 12, 2010

- Remove all "i_*" vtables. These are less frequently used and tend to be implemented internally in terms of the 3-argument vtables.

As noted in #1433, I disagree with the notion that Parrot should completely do away with the optimization possibilities provided by having separate "inplace" versus "create a new value" operations available to PMCs. It's not just the core PMCs at issue here, but also the PMC types that other HLLs may choose to use or implement.

Pm

Member

bacek commented Nov 25, 2010

Hello.

-1 from me. I think it should be other way around. Implement 3-args math ops in terms of i_* ops. E.g. $a := $b + $c is same as $a := $b; $a += $c . Core PMCs can always fallback 3-args ops to 2-args. HLL can choose different implementation.

OTOH, current 3-args ops with $dest _should_ always allocate new PMC for $dest without reusing old PMC. It's closely related to "lvalue semantics" ticket.

-- Bacek.

Owner

pmichaud commented Nov 26, 2010

On Thu, Nov 25, 2010 at 01:46:02PM -0000, Parrot wrote:
>  Hello.
>
>  -1 from me. I think it should be other way around. Implement 3-args math
>  ops in terms of i_* ops. E.g. {{{ $a := $b + $c }}} is same as {{{ $a :=
>  $b; $a += $c }}}. Core PMCs can always fallback 3-args ops to 2-args. HLL
>  can choose different implementation.
Please, no.  An 3-argument inplace add is *not* always the same as
a 2-argument inplace add.  In particular, adding two very large Integers
could result in a BigInt, and I definitely think we should not be morphing
PMCs to achieve that.
Put another way, over time I've come to realize that immutable values
are a good thing, and inplace operations are the antithesis of that.
Please don't make them the core/default.
Pm
Contributor

chromatic commented Nov 26, 2010

On Thursday 25 November 2010 at 09:48, Patrick R wrote:
> Put another way, over time I've come to realize that immutable values
> are a good thing, and inplace operations are the antithesis of that.
> Please don't make them the core/default.
+1.  It's the optimizer's job to cheat by removing temporaries and coalescing
multiple resources, not the programmer's.
-- c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment