RetroSearch Browse

Mon Nov 3 09:52:28 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-November/039909.html

Chris Ryland <cpr at emsoftware.com> writes:

> Michael Hudson wrote:
>> Remove the ob_type field from all PyObjects.  Make pymalloc mandatory,
>> make it use type specific pools and store a pointer to the type object
>> at the start of each pool.
>>
>> So instead of
>>   p->ob_type
>> it's
>>   *(p&MASK)
>>
>> I think having each type in its own pools would also let you lose the
>> gc_next & gc_prev fields.
>>
>> Combined with a non-refcount GC, you could hammer sizeof(PyIntObject)
>> down to sizeof(long)!
>
> Yes, this is a variant of an implementation technique used in early
> Lisp and Lisp-like language systems with types (e.g., Harvard's EL-1)
> back in the early 70's (at least--that's when I first encountered
> it). In those systems, you'd use the "page #" (higher-order bits) of a
> pointer to reference a type table.

Heh, that's interesting to know.  Nothing new under the sun & all
that.

> Good idea, but perhaps less effective these days where memory isn't
> quite so dear. (Back then, a large system was a PDP-10 with 256K
> 36-bit words, or around 1MB.)

Cache memory is still expensive: if we can get more PyObjects into
each cache line, we still win (at least, that's what I was thinking).

Also, for say small tuples, the overhead of gc fields, refcount and
type pointer is really frightening.  Yes, memory is cheap, but using 3
or so times as much as we need to is still excessive.

Cheers,
mwh

-- 
  If trees could scream, would we be so cavalier about cutting them
  down? We might, if they screamed all the time, for no good reason.
                                                        -- Jack Handey

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-November/039909.html below:

[Python-Dev] Looking for master thesis ideas involving Python