Andrew MacIntyre wrote: > So I've been testing with the freelists ripped out and ints and floats > reverted to fairly standard PyObject_New allocation (retaining the small > int interning) and thus relying on PyMalloc to do any compaction.
Nice! What do you mean with int interning? Are you talking about the small int cache? > The results have been somewhat surprising... > > The short version is that: > - for ints, the freelist is ahead of PyMalloc by a very small margin > (<4%) > - for floats, the freelist is a long way behind PyMalloc (>35% slower) > > This without invoking freelist compaction by the way (though PyMalloc > is releasing empty arenas). > > I don't know what's pessimising the float freelist, but the results are > similar on 2 boxes: > - AMD Athlon XP-1600+, 512MB RAM, FreeBSD 6.1, gcc 3.4.4 > (~27k pystones) > - AMD Athlon XP-2500+, 512MB RAM, OS/2 v4 with EMX, gcc 2.8.1 > (~38k pystones) That's interesting. I wouldn't have thought that floats are much faster with pymalloc. I'd bet that pymalloc is a tiny bit slower until the new free list is filled. > If there's interest in following this up, I can put my patches to > intobject.c and floatobject.c into the tracker. I've uploaded my patch at http://bugs.python.org/issue2039. It keeps a standard free list with 8192 elements for floats and ints. Does your patch also use a free list or does it alloc/free directly? Can your profile my patch and compare it to your results? It may be a bit faster if your patch doesn't use a free list. Christian _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
