[Python-3000] C API for ints and strings (original) (raw)

Nicholas Bastin nick.bastin at gmail.com
Mon Sep 10 19:58:47 CEST 2007

On 9/10/07, Guido van Rossum <guido at python.org> wrote:

On 9/9/07, Nicholas Bastin <nick.bastin at gmail.com> wrote: > On 9/9/07, Guido van Rossum <guido at python.org> wrote: > > On 9/9/07, Nicholas Bastin <nick.bastin at gmail.com> 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.

I posted a tiny snippet of code earlier in the thread that was a sortof silly benchmark of integer math operations.

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.

Yeah, my point was mostly an aside to anyone that might have questioned my earlier results of a 2.3x slowdown on integer-sized values because I used 1. A quick switch to 200 netted the exact same results, and a more extensive refactoring to get the same number of operations on a random set of larger numbers netted the same result as well.

-- Nick

More information about the Python-3000 mailing list