[Python-Dev] Re: Moving towards Python 3.0

[Michael Hudson]

Evan Jones <ejones at uwaterloo.ca> writes:

> On Jan 31, 2005, at 0:17, Guido van Rossum wrote:
>> The "just kidding" applies to the whole list, right? None of these
>> strike me as good ideas, except for improvements to function argument
>> passing.
>
> Really? You see no advantage to moving to garbage collection, nor
> allowing Python to leverage multiple processor environments? I'd be
> curious to hear your reasons why not.

Obviously, if one could wave a wand and make it so, we would.  The
argument about whether the cost (in backwards compatibility,
portability, uniprocessor performace, developer time, etc) outweighs
the benefit.

> My knowledge about garbage collection is weak, but I have read a
> little bit of Hans Boehm's work on garbage collection. For example,
> his "Memory Allocation Myths and Half Truths" presentation
> (http://www.hpl.hp.com/personal/Hans_Boehm/gc/myths.ps) is quite
> interesting. On page 25 he examines reference counting. The biggest
> disadvantage mentioned is that simple pointer assignments end up
> becoming "increment ref count" operations as well, which can "involve
> at least 4 potential memory references." The next page has a
> micro-benchmark that shows reference counting performing very
> poorly.

Given the current implementations *extreme* malloc-happyness I posit
that it would be more-or-less impossible to make any form of
non-copying garabage collector go faster for Python that refcounting.
I may be wrong, but I don't think so and I have actually thought about
this a little bit :)

The "non-copying" bit is important for backwards compatibility of C
extensions (unless there's something I don't know).

> Not to mention that Python has a garbage collector *anyway,* so
> wouldn't it make sense to get rid of the reference counting?

Here you're confused.  Python's cycle collector depends utterly on
reference counting.

(And what is it with this "let's ditch refcounting and use a garbage
collector" thing that people always wheel out?  Refcounting *is* a
form of garbage collection by most reasonable definitions, esp. when
you add Python's cycle collector).

> My only argument for making Python capable of leveraging multiple
> processor environments is that multithreading seems to be where the
> big performance increases will be in the next few years. I am
> currently using Python for some relatively large simulations, so
> performance is important to me.

I'm sure you're tired of hearing it, but I think processes are your
friend...

Cheers,
mwh

-- 
  It is time-consuming to produce high-quality software. However,
  that should not alone be a reason to give up the high standards
  of Python development.              -- Martin von Loewis, python-dev