Python's biggest compromises

[Terry Reedy]

"Paul Rubin" <http://phr.cx@NOSPAM.invalid> wrote in message
news:7xr8456ote.fsf at ruckus.brouhaha.com...
> Brian Quinlan <brian at sweetapp.com> 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