chromatic wrote:
On Monday 27 September 2010 at 12:03, Jonathan Worthington wrote:
However, at this point I'd be very surprised if we're
still using (in Rakudo) the Integer/Float PMCs for our Int/Num types
after the meta-model replacement lands.
What do Parrot's Int and Float PMCs need to be useful to Rakudo?
Sorry, I shoulda been a bit more explicit on the reasoning. The issue
isn't that they're not good enough, or that they need to change. Rather,
it's that as the meta-model design has started to come together, I've
mostly concluded they don't really fit in.
The Rakudo Int and Num objects need to be full-blown Perl 6-y objects.
They are today, but we do that by wrapping Integer and Float PMCs up.
(Sometimes we also create Integer and Float PMCs directly and stuff
works because we evilly poke extra methods into global namespaces -
something not sustainable in the long run). However, PMC inheritance
today is really implemented as delegation - something not in itself a
problem [1], but a bit too heavyweight for things as fundamental as Int
and Num. The upshot today is that for an Int we have:
* The object PMC
* The RPA it references. Granted with some work this could go away in
the current Object implementation.
* The Integer PMC
That's 3 gc-able objects, plus their storage space = 6 allocations. We
can't go on like this.
While we could solve that in many ways, this wasn't the issue that
actually tipped me (it's just helpful to describe the present before the
future). Rather, it's the much more general issue is that I need to
support inlining of types within the memory allocation of other types
anyway (for the compact structs part of S09), and in that sense just
having a native integer living in the object's chunk of memory is a
de-generate, easy case of that (I expect it to fall out of exactly the
same mechanism).
Thus, just by implementing what Perl 6 needs, I can have one Perl 6
object allocated with a slot to store a native int/double - a big
efficiency win on the allocations, not to mention we can stop polluting
global namespaces. Furthermore, our implementation of e.g. infix:<+>
today in Rakudo is e.g.
pir::add__NNN($a, $b)
That is, we're not using the PMC's add v-tables at all, so it's not
really even a painful change to make.
So really, this isn't a "the Float and Integer PMCs suck!" issue. It's
simply that I'd have to go out of my way to use them, when a much more
natural - and as a bonus, memory efficient - option is at hand.
Hope this makes some kinda sense. :-)
Thanks,
Jonathan
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
