[Python-Dev] stackable ints [stupid idea (ignore) :v]
arw at ifu.net
Thu Jun 10 15:40:51 CEST 1999
While we're talking about stacks...
I've always considered it a major shame that Python ints and floats
and chars and stuff have anything to do with dynamic allocation, and I
always suspected it might be a major speed performance boost if there
some way they could be manipulated without the need for dynamic
One conceivable alternative approach would change the basic manipulation
objects so that instead of representing objects via pyobject pointers
represent them using two "slots" in a structure for each object,
one of which is a type descriptor pointer and the other
being a (void *) which could contain the data directly for small objects
such as ints, floats, chars. In this case, for example, integer
never require any memory management, as it shouldn't, I think, in a
IE instead of
C-stack or static: Heap:
(pyobject *) ------------> (refcount, typedescr, data ...)
in general you get
repr* ----------------------> (refcount, data, ...)
or for small objects like ints and floats and chars simply
with no dereferencing or memory management required. My feeling is
that common things like arithmetic and indexing lists of integers and
be much faster under this approach since it reduces memory management
overhead and fragmentation, dereferencing, etc...
One bad thing, of course, is that this might be a drastic assault on the
way existing code works... Unless I'm just not being creative enough
with my thinking. Is this a good idea? If so, is there any way to add
to the interpreter without breaking extension modules and everything
If Python 2.0 will break stuff anyway, would this be an good change
to the internals?
Curious... -- Aaron Watters
ps: I suppose another gotcha is "when do you do increfs/decrefs?"
they no longer make sense for ints in this case... maybe add a flag
type descriptor "increfable" and assume that the typedescriptors are
in the CPU cache (?). This would slow down increfs by a couple
Would it be worth it? Only the benchmark knows... Another fix would
to put the refcount in the static side with no speed penalty
repr* ----------------------> data
but would that be wasteful of space?
More information about the Python-Dev