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?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4