[Python-3000] C API for ints and strings
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