[fwd as reply was intended for python-dev]
Christian Heimes wrote:
> Andrew MacIntyre wrote:
>> I tried a LIFO stack implementation (though I won't claim to have done it
>> well), and found it slightly slower than no freelist at all. The
>> advantage of such an approach is that the known size of the stack makes
>> deallocating excess objects easy (and thus no need for
>> sys.compact_free_list() ).
>
> I've tried a single linked free list myself. I used the ob_type field to
> daisy chain the int and float objects. Although the code was fairly
> short it was slightly slower than an attempt without a free list at all.
> pymalloc is fast. It's very hard to beat it though.
I'm speculating that CPU cache effects can make these differences. The
performance of the current trunk float freelist is depressing, given that
the same strategy works so well for ints.
I seem to recall Tim Peters paying a lot of attention to cache effects
when he went over the PyMalloc code before the 2.3 release, which would
contribute to its performance.
> A fixed size LIFO array like PyFloatObject
> *free_list[PyFloat_MAXFREELIST] increased the speed slightly. IMHO a
> value of about 80-200 floats and ints is realistic for most apps. More
> objects in the free lists could keep too many pymalloced areas occupied.
I tested the updated patch you added to issue 2039. With the int
freelist set to 500 and the float freelist set to 100, its about the same
as the no-freelist version for my tests, but PyBench shows the simple
float arithmetic to be about 10% better.
I'm inclined to set the int LIFO a bit larger than you suggest, simply as
ints are so commonly used - hence the value of 500 I used. Floats are
much less common by comparison. Even an int LIFO of 500 is only going to
tie up ~8kB on a 32bit box (~16kB on 64bit), which is insignificant
enough that I can't see a need for a compaction routine.
A 200 entry float LIFO would only account for ~4kB on 32bit (~8kB on
64bit).
I'd like to think that these changes could be considered fixes for
performance bugs so that they could be applied for 2.5.2, but I doubt
that will fly.
Cheers,
Andrew.
--
-------------------------------------------------------------------------
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370
[EMAIL PROTECTED] (alt) | Belconnen ACT 2616
Web: http://www.andymac.org/ | Australia
_______________________________________________
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
