> There's evidence in the 
> literature that switching from reference counting to a more sophisticated 
> GC scheme can also save us 5-10% in CPU overhead. (Though that's not a 
> guarantee--LISPlike languages likely have different GC performance 
> characteristics than perl does)

[warning: vague hand-waving follows.... ]

In a Perl context, I find it hard to believe that reference counting takes
up more than tiny fraction of total cycles. Consider that most SVs etc
will typically have a ref count of just 1 or 2 throughout their lifetime.
Now consider the code

{
        my $a = ....
        my $b = \$a;
        ....
}

and consider all the cycles taken up in allocating space for the 2 SVs,
initialising them, messing around with STABs/PADs, interpeting bytecodes,
calling assign methods, releasing the assigned space, etc etc,
then add to that the following bits of code:

sva->refcount=0;
sva->refcount++; // these first 2 combined if we get the implemention right
svb->refcount=0;
svb->refcount++; // ditto
...
if (--sva->refcount == 0) ...  // branch not taken
if (--svb->refcount == 0) ...  // branch taken, 
if (--sva->refcount == 0) ...  // branch taken

which I calculate as 7 writes and 5 reads.
Even a mark and sweep would presumably require at least 2 writes and 2 reads
just to manipulate the 'mark' word, plus more reads to work its way
through lists of things needing marking or sweeping

[ end of vague hand waving ]

I think that the main problem with ref counting is not the performance,
but that the house-keeping has to be done by the programmer (eg pity
the newbie XS coder trying to work out how to set the correct ref
count). On the other hand, the shiny new internals of perl6 are likely
to mean we can design it so that there are only a few well-defined
places where refcounts need to be worried about, preferably buried
behind an internal API that most internals coders never need to venture
into. (Oh, and I belive in World Peace too ;-)

Dave M.





Reply via email to