[Fwd: A couple garbage collector questions]

[Frank Mitchell]

Daniel Berlin wrote:
> 
> > OTOH, if the program *isn't* going to use the object right away, e.g. if
> > object A hands object B a referece to object C so that A can call C at a
> > later time, you're prefetching for no purpose.
> 
> Except, A had to store the object somewhere, and thus, used it.
> Even if it's a simple pointer assignment, A is still storing the object
> (or rather, a pointer to it) somewhere so it can all it later, and thus,
> you didn't prefetch for no  purpose.

The crucial question is how much later.  The cache is only so large, and
it contains both code and objects; by the time the program is ready to
use object C, it may already have been swapped out of the cache again.

So the argument that refcounting is cache-friendly applies only if one
knows the refcounted object will be used "soon" after its reference is
copied, if which isn't generally the case.  ("Soon" depends on the
caching stragegy and whether objects have been allocated in the same
memory block ... which isn't something *I* want to base portable
software on.)

Getting back to Python ... it looks like refcounting is here to stay,
and by this time it's probably tuned well enough, especially with the
cycle collector.  If it isn't broken, don't fix it.  However, it will be
interesting to compare Python's performance to a similar language with a
pure tracing language, such as Ruby, once Ruby matures.

-- 
Frank Mitchell (frankm at bayarea.net)

Ridiculous Lucky Captain Rabbit King!  Lucky Captain Rabbit King
Nuggets are only for the youth!
-- Powerpuff Girls, "Jewel of the Aisle"