[Python-Dev] stackable ints [stupid idea (ignore) :v]

[Aaron Watters]

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
was
some way they could be manipulated without the need for dynamic
memory management.

One conceivable alternative approach would change the basic manipulation
of
objects so that instead of representing objects via pyobject pointers
everywhere
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
addition would
never require any memory management, as it shouldn't, I think, in a
perfect
world.

IE instead of

      C-stack or static:                      Heap:
     (pyobject *)     ------------>   (refcount, typedescr, data ...)

in general you get

     (typedescr
      repr* ----------------------> (refcount, data, ...)
     )

or for small objects like ints and floats and chars simply

    (typedescr,
     value)

with no dereferencing or memory management required.  My feeling is
that common things like arithmetic and indexing lists of integers and
stuff could
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
it
to the interpreter without breaking extension modules and everything
else?
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?"
because
  they no longer make sense for ints in this case...  maybe add a flag
to the
  type descriptor "increfable" and assume that the typedescriptors are
always
  in the CPU cache (?). This would slow down increfs by a couple
cycles...
  Would it be worth it?  Only the benchmark knows...  Another fix would
be
  to put the refcount in the static side with no speed penalty

     (typedescr
      repr* ----------------------> data
      refcount
     )

  but would that be wasteful of space?