Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > RE: Python's biggest compromises

Reply
Thread Tools

RE: Python's biggest compromises

 
 
Brian Quinlan
Guest
Posts: n/a
 
      08-01-2003
> Reference counting spreads the speed hit over the entire program,
while
> other techniques tend to hit performance hard every so often. But all
> together I think reference counting is usually slower than a good GC
> algorithm, and incremental garbage collection algorithms can avoid
> stalling. And I'm sure that the current state -- references counting
> plus another kind of garbage collection for circular references --

must
> be worse than either alone.


I'm not sure that I believe this. In Python, everything is an object
that participates in GC including integers and other light-weight types.
Imagine that you have a mathematic expression that creates a dozen
floats objects as part of its evaluation. Do you believe that it is
faster to add those dozen floats to a list for later collection than to
decrement an integer, notice that the decremented value is 0 and
immediately reclaim the memory? That would not be my intuition (but my
intuition is often wrong ).

Cheers,
Brian


 
Reply With Quote
 
 
 
 
Paul Rubin
Guest
Posts: n/a
 
      08-01-2003
Brian Quinlan <(E-Mail Removed)> writes:
> I'm not sure that I believe this. In Python, everything is an object
> that participates in GC including integers and other light-weight types.
> Imagine that you have a mathematic expression that creates a dozen
> floats objects as part of its evaluation. Do you believe that it is
> faster to add those dozen floats to a list for later collection than to
> decrement an integer, notice that the decremented value is 0 and
> immediately reclaim the memory? That would not be my intuition (but my
> intuition is often wrong ).


In a fast GC system you would just allocate the floats from a
contiguous block. Later you would copy the reachable floats from that
block to another block. If no floats are reachable, you don't copy
anything. There are all kinds of optimizations you can use, including
making clever use of memory protection hardware to notice when your
allocator has run over the end of a block so you don't have to even
make an explicit pointer comparison, that can make all this run very fast.

Andrew Appel has a book about garbage collection where he discusses
these methods in detail.
 
Reply With Quote
 
 
 
 
Terry Reedy
Guest
Posts: n/a
 
      08-02-2003

"Paul Rubin" <http://(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Brian Quinlan <(E-Mail Removed)> writes:
> > I'm not sure that I believe this. In Python, everything is an

object
> > that participates in GC including integers and other light-weight

types.
> > Imagine that you have a mathematic expression that creates a dozen
> > floats objects as part of its evaluation. Do you believe that it

is
> > faster to add those dozen floats to a list for later collection

than to
> > decrement an integer, notice that the decremented value is 0 and
> > immediately reclaim the memory? That would not be my intuition

(but my
> > intuition is often wrong ).

>
> In a fast GC system you would just allocate the floats from a
> contiguous block. Later you would copy the reachable floats from

that
> block to another block. If no floats are reachable, you don't copy
> anything. There are all kinds of optimizations you can use,

including
> making clever use of memory protection hardware to notice when your
> allocator has run over the end of a block so you don't have to even
> make an explicit pointer comparison, that can make all this run very

fast.

The proof of such assertions, either way, is in real code. Before
circular ref GC was added, at least one person tried replacing ref
count GC with 'real' GC. The resulting benchmarks were about the
same. So Guido stuck with what was familiar, simpler to understand,
and seemed less likely to interfere with other improvements. The type
of GC didn't seem to matter too much. But anyone is welcome to prove
this wrong. However, acceptance into the core requires some degree of
system/hardware independence.

As I understand it, Psyco unboxes some types and does away with some
of the need for any GC. *That* does seem to make a difference.

Terry J. Reedy


 
Reply With Quote
 
Paul Rubin
Guest
Posts: n/a
 
      08-02-2003
"Terry Reedy" <(E-Mail Removed)> writes:
> The proof of such assertions, either way, is in real code. Before
> circular ref GC was added, at least one person tried replacing ref
> count GC with 'real' GC. The resulting benchmarks were about the
> same. So Guido stuck with what was familiar, simpler to understand,
> and seemed less likely to interfere with other improvements. The type
> of GC didn't seem to matter too much. But anyone is welcome to prove
> this wrong. However, acceptance into the core requires some degree of
> system/hardware independence.


I think ref counting pervades CPython so thoroughly that it would be
ridiculous to try to change it. However, in a complete re-implementation,
different GC schemes should be considered.

I also don't think traditional GC is harder to understand than ref
counting. I think Guido once mentioned that he chose ref counting
because it was what he was used to. Having implemented GC by both
mark-sweep (for a Lisp interpreter) and ref counting (in GNU Awk), I'd
say that mark-sweep is easier to keep straight.

> As I understand it, Psyco unboxes some types and does away with some
> of the need for any GC. *That* does seem to make a difference.


I think very large performance improvements can come from changing the
language semantics in ways that would cause some backwards
incompatibility. But I think that should be considered for Python
3000 which should be implemented with a native-code compiler from the
very outset. I don't see why a good Python system can't have the
performance of a good Lisp system.
 
Reply With Quote
 
Michael Hudson
Guest
Posts: n/a
 
      08-04-2003
Paul Rubin <http://(E-Mail Removed)> writes:

> > As I understand it, Psyco unboxes some types and does away with some
> > of the need for any GC. *That* does seem to make a difference.

>
> I think very large performance improvements can come from changing the
> language semantics in ways that would cause some backwards
> incompatibility. But I think that should be considered for Python
> 3000 which should be implemented with a native-code compiler from the
> very outset. I don't see why a good Python system can't have the
> performance of a good Lisp system.


I can think of a few reasons, actually, with Python as it is today,
mostly along the lines of things like "you can't extend at runtime the
functionality of #'cl:=".

Tangentially, I'm not aware of any work that does Pysco-style dynamic
specialization in a Common Lisp environment, which surprises me to the
extent that I suspect I just don't know about it. Can anyone provide
a pointer?

Cheers,
mwh

--
... with these conditions cam the realisation that ... nothing
turned a perfectly normal healthy individual into a great political
or military leader better than irreversible brain damage.
-- The Hitch-Hikers Guide to the Galaxy, Episode 11
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
CrossFire: The Biggest Vaporware of the Year? Silverstrand Front Page News 0 10-05-2005 02:03 PM
Biggest cisco based networks Ivan Ostres Cisco 7 07-08-2004 02:52 AM
Python's biggest compromises Anthony_Barker Python 65 08-10-2003 11:31 PM
Re: Python's biggest compromises Gerrit Holl Python 7 08-10-2003 07:28 PM



Advertisments