Front page | perl.perl6.internals |
Postings from July 2002
Re: [PATCH] Reduce array.pmc keyed code
From: Scott Walters
July 25, 2002 07:19
Re: [PATCH] Reduce array.pmc keyed code
Message ID: Pine.NEB.4.20.0207250648160.4620-100000@straylight
Part of the beauty of PMCs is that you can have very compact
storage given a dedicated eg int array type. Generating these
would not be a bad thing. The typical case still remains, that
arrays will contained mixtures of all datatypes.
On Wed, 24 Jul 2002, Mike Lambert wrote:
> This patch is rather questionable, and thus I did not commit it
> directly. However, it illustrates a point I wanted to make.
> As mentioned in my recent PARROT QUESTIONS email, a lot of the clutter in
> the PMC aggregates can be removed with the use of redirecting functions.
> The below patch reduces the resulting array.c from 40K to 20K, and the
> ..obj file from 25K to 33K (not that much).
> It introduces another layer of recursion into the code, while at the same
> time eliminating lots of duplicate code. If we disallow subclassing of the
> PMC, a lot of the vtable redirects in this code could be replaced with
> straight function calls (and those function calls could subsequently be
> inlined within the same .c file).
Please, please take a moment to review my earlier posts about refactoring
the PMC API. Cleaning up the code isn't a bad thing, but I think there is
a deeper problem.
I proposed several approaches. Taking just one of them:
Requests to operate on PMCs should not be propogated down to the PMC
through one of dozens of methods. Instead, the PMC should be fetched
into a scratch register and operated on directly. In the case of
primitive atomic datatypes, the recurisve multiply, add, div, etc
operations should be disposed of, and references to the atomic types
should be fetched to a scratch register, where they are operated on
directly (as a reference).
This would require more .ops permutations, but would grossly simplify
the PMC API and shrink the code dramatically. Other proposals were
slightly more complicated but avoided the permutations of ops problem.
Restating, if you're going to work on this, please work with me. I'd be
glad to help whatever you're doing, but I *hate* duplication of effort.
I've got plenty of other things I should be working on.
> After doing this, I wonder if it's not useful to allow an aggregate PMC to
> declare its inner type (in this case, PMC). The pmc2c.pl would then
> generate stub functions which converted from that base type to each of the
> requested types. This would allow PerlIntArraty to be a base of INT, yet
> perform auto-conversions to num, string, pmc, etc in the generated code.
> Is the patch here too recursive to be efficient, despite the reduction in
> actual code? Should all SELF->vtable methods on *.pmc files be made to
> call the appropriate function directly, and assume no subclassing?
I know its hard to get a yes/no opinion on a patch. People always want
to "address the bigger issue". I'd love to hash this out with you.
However, my reaction would be, yes, we should have IntArray, NumArray,
PMCArray generated from a template, I personally would avoid more
levels of function nesting, but I feel much more strongly about
seperating lookup and the operation.
> Another possibility is to regenerate the functions for the subclasses, so
> that parent inlinings of SELF->vtable->get_pmc_keyed will not interfere
> with a child's redefinition of their own get_pmc_keyed ?
The 33k implementation of Array is less then 1/4 complete. This beast
will be 125k before its done, mark my words. Low power chips have
quarter meg or half meg L2 caches. I'm a firm believer that a VM should fit
in cache and leave room for some data to be cached, too. A seperate
fetch and operation would add a few more instructions to the implementation,
but compared to the cost of a cache stall, this is beans. The best thing we
could do is remove some of this bloat now.
> Thoughts, comments?
> Mike Lambert
Mike, I can't mail you directly. I'm sharing a netblock with a known spammer
and you're using spews.org. I didn't mean to send my rant to the entire list
again. Sorry, folks =(