On 9/9/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote: > On 9/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On 9/9/07, Nicholas Bastin <[EMAIL PROTECTED]> wrote: > > > I'm not suggesting that Python handle small ints itself and then farm > > > out large integer computations, I'm suggesting that since we've > > > already coalesced small ints into 'large' ones, we might want to > > > review the performance implications of that decision, and possibly > > > consider that other people have already solved this problem. Clearly > > > GMP appears to fail on a technical level, but there might be other > > > options worth investigating. > > > > The performance problems that are affecting us most are for > > small-value ints. The old PyInt type has many custom optimizations to > > help. I think we could do worse than re-introducing some of the same > > tricks, retargeted to PyLong (which never got much attention for > > small-value performance). > > I did redo my benchmark using 200 as the increment number instead of > 1, to duck any impact from the interning of small value ints in 2.6, > and it made no discernible difference in the results.
I'm sorry, I've lost context. I'm not at all clear at this point what benchmark you might have ran. Note that when I said "small values" I meant (in part) anything that fits in a Python long -- while there's a special cache in 2.x for ints < 100, there's also a special allocator that outperforms the obmalloc allocator. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
