Paul Rubin wrote: > "Diez B. Roggisch" <[EMAIL PROTECTED]> writes: > >>That particular implementation used 3 or 4 tag-bits. Of course you are >>right that nowadays python won't notice the difference, as larger nums >>get implicitely converted to a suitable representation. But then the >>efficiency goes away... Basically I think that trying to come up with >>all sorts of optimizations for rather marginal problems (number >>crunching should be - if a python domain at all - done using Numarray) > > > I don't think it's necessarily marginal. Tagged ints can be kept in > registers, which means that even the simplest code that does stuff > with small integers becomes a lot more streamlined, easing the load on > both the Python GC and the cpu's memory cache. Right now with the > bytecode interpreter, it probably doesn't matter, but with Pypy > generating native machine code, this kind of thing can make a real > difference.
Until someone does the experiment this stuff is bound to be speculation (what's that saying about "premature optimization"?). But I can foresee that there'd be problems at the outer edges of the language: for example, sys.maxint would have to be reduced, and this in turn would lead to reduction in, for example, the theoretical maximum length of sequences. Even if it reduced the average execution time of the "average" program, this will involve trade-offs which can only be fully appreciated in the light of practical experience. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list