Scott David Daniels <[EMAIL PROTECTED]> writes: > > I think most of the time, branch prediction will prevent the cache > > flush. > But, branch prediction is usually a compiler thing, based on code > that is, in this case, a spot in the interpreter that is actually > taking both sides of the branch quite often. If you split the > interpreter to have a "presumed int" side, you might do OK, but > that is not how the code works at the moment.
Yes, I'm hypothesizing a native-code compiler as might come out of the PyPy project. > > if you have two tagged integers, > > you can add and subtract them without having to twiddle the tags. > You can do so only once you discover you have two tagged integers. > The test for tagged integers (rather, the subsequent branch) is the > thing that blows the pipe. I mean in cases where the compiler can determine that it's dealing with small ints. That might be harder in Python than in Lisp, given how dynamic Python is. > > The alternative (tag==1 means integer) means you don't have to mask > > off the tag bits to dereference pointers, and you can still add a > > constant to a tagged int by simply adjusting the constant > > appropriately. > And this presumes an architecture which byte-addresses and only > uses "aligned" addresses. Yes, that would describe just about every cpu for the past 30 years that's a plausible Python target. -- http://mail.python.org/mailman/listinfo/python-list
