Re: [Python-Dev] Benchmarking "fun" (was Re: Python 2.1 slower than 2.0)
"M.-A. Lemburg" <mal@lemburg.com> writes:
My conclusion? Python 2.1 is slower than Python 2.0, but not by enough to care about.
What compiler did you use and on which platform ?
Argh, sorry; I meant to put this in! $ uname -a Linux atrus.jesus.cam.ac.uk 2.2.14-1.1.0 #1 Thu Jan 6 05:12:58 EST 2000 i686 unknown $ gcc --version 2.95.1 It's a Dell Dimension XPS D233 (a 233MHz PII) with a reasonably fast hard drive (two year old 10G IBM 7200rpm thingy) and quite a lot of RAM (192Mb). [snip]
AFAIR, Vladimir's malloc implementation favours small objects. All number objects (except longs) fall into this category.
Well, longs & complex numbers don't do any free list handling (like floats and int do), so I see two conclusions: 1) Don't add obmalloc to the core, but do simple free list stuff for longs (might be tricky) and complex nubmers (this should be a no-brainer). 2) Integrate obmalloc - then maybe we can ditch all of that icky freelist stuff.
Perhaps we should think about adding his lib to the core ?!
Strikes me as the better solution. Can anyone try this on Windows? Seeing as windows malloc reputedly sucks, maybe the differences would be bigger. Cheers, M. -- Our lecture theatre has just crashed. It will currently only silently display an unexplained line-drawing of a large dog accompanied by spookily flickering lights. -- Dan Sheppard, ucam.chat (from Owen Dunn's summary of the year)
[Michael Hudson]
... Can anyone try this on Windows? Seeing as windows malloc reputedly sucks, maybe the differences would be bigger.
No time now (pymalloc is a non-starter for 2.1). Was tried in the past on Windows. Helped significantly. Unclear how much was simply due to exploiting the global interpreter lock, though. "Windows" is also a multiheaded beast (e.g., NT has very different memory performance characteristics than 95).
Tim Peters wrote:
[Michael Hudson]
... Can anyone try this on Windows? Seeing as windows malloc reputedly sucks, maybe the differences would be bigger.
No time now (pymalloc is a non-starter for 2.1). Was tried in the past on Windows. Helped significantly. Unclear how much was simply due to exploiting the global interpreter lock, though. "Windows" is also a multiheaded beast (e.g., NT has very different memory performance characteristics than 95).
We're still in alpha, no ? Adding pymalloc is not much of a deal since it fits nicely with the Python malloc macros and giving the package a nice spin by putting it into a Python alpha release would sure create more confidence in this nice piece of work. We can always take it out again before going into the beta phase. Or do we have a 2.1 feature freeze already ? -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
"MAL" == M -A Lemburg <mal@lemburg.com> writes:
MAL> Tim Peters wrote:
[Michael Hudson]
... Can anyone try this on Windows? Seeing as windows malloc reputedly sucks, maybe the differences would be bigger.
No time now (pymalloc is a non-starter for 2.1). Was tried in the past on Windows. Helped significantly. Unclear how much was simply due to exploiting the global interpreter lock, though. "Windows" is also a multiheaded beast (e.g., NT has very different memory performance characteristics than 95).
MAL> We're still in alpha, no ? The last planned alpha is going to be released tonight or early tomorrow. I'm reluctant to add a large patch that I'm unfamiliar with in the last 24 hours before the release. MAL> Or do we have a 2.1 feature freeze already ? We aren't adding any major new features that haven't been PEPed. I'd like to see a PEP on this subject. Jeremy
Jeremy Hylton wrote:
"MAL" == M -A Lemburg <mal@lemburg.com> writes:
MAL> Tim Peters wrote:
[Michael Hudson]
... Can anyone try this on Windows? Seeing as windows malloc reputedly sucks, maybe the differences would be bigger.
No time now (pymalloc is a non-starter for 2.1). Was tried in the past on Windows. Helped significantly. Unclear how much was simply due to exploiting the global interpreter lock, though. "Windows" is also a multiheaded beast (e.g., NT has very different memory performance characteristics than 95).
MAL> We're still in alpha, no ?
The last planned alpha is going to be released tonight or early tomorrow. I'm reluctant to add a large patch that I'm unfamiliar with in the last 24 hours before the release.
MAL> Or do we have a 2.1 feature freeze already ?
We aren't adding any major new features that haven't been PEPed. I'd like to see a PEP on this subject.
I don't see a PEP for your import patch either ;-) Seriously, I am viewing the addition of pymalloc during the alpha phase or even the betas as test for the usability of such an approach. If it fails, fine, then we take it out again. If nobody notices, great, then leave it in. There would be a need for a PEP if we need to discuss APIs, interfaces, etc. but all this has already been done by Valdimir a long time ago. He put much effort into getting the Python malloc macros to work in the intended way so that pymalloc only has exchange these macro definitions. I don't understand why we cannot take the risk of trying this out in an alpha version. Besides, Vladimir's malloc patch is opt-in: you have to compile Python using --with-pymalloc to enable it, so it doesn't really harm anyone not knowing what he/she is doing. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
On Fri, Feb 02, 2001 at 11:00:28AM +0100, M.-A. Lemburg wrote:
There would be a need for a PEP if we need to discuss APIs, interfaces, etc. but all this has already been done by Valdimir a long time ago. He put much effort into getting the Python malloc macros to work in the intended way so that pymalloc only has exchange these macro definitions.
I don't understand why we cannot take the risk of trying this out in an alpha version. Besides, Vladimir's malloc patch is opt-in: you have to compile Python using --with-pymalloc to enable it, so it doesn't really harm anyone not knowing what he/she is doing.
+1 on putting it in, in alpha2 or beta1, on an opt-in basis. +0 on putting it in *now* (alpha2, not beta1) and on by default. -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Thomas Wouters wrote:
On Fri, Feb 02, 2001 at 11:00:28AM +0100, M.-A. Lemburg wrote:
There would be a need for a PEP if we need to discuss APIs, interfaces, etc. but all this has already been done by Valdimir a long time ago. He put much effort into getting the Python malloc macros to work in the intended way so that pymalloc only has exchange these macro definitions.
I don't understand why we cannot take the risk of trying this out in an alpha version. Besides, Vladimir's malloc patch is opt-in: you have to compile Python using --with-pymalloc to enable it, so it doesn't really harm anyone not knowing what he/she is doing.
+1 on putting it in, in alpha2 or beta1, on an opt-in basis. +0 on putting it in *now* (alpha2, not beta1) and on by default.
Anyone else for adding it now on an opt-in basis ? BTW, here is the URL to the pymalloc page: http://starship.python.net/~vlad/pymalloc/ -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
On Fri, 02 Feb 2001 13:14:33 +0100, "M.-A. Lemburg" <mal@lemburg.com> wrote:
Anyone else for adding it now on an opt-in basis ?
Add it on opt-out basis, and if it causes trouble, revert to opt-in in beta/final. Alphas are supposed to be buggy <0.7 wink> -- Moshe Zadka <sig@zadka.site.co.il> This is a signature anti-virus. Please stop the spread of signature viruses! Fingerprint: 4BD1 7705 EEC0 260A 7F21 4817 C7FC A636 46D0 1BD6
Moshe Zadka wrote:
On Fri, 02 Feb 2001 13:14:33 +0100, "M.-A. Lemburg" <mal@lemburg.com> wrote:
Anyone else for adding it now on an opt-in basis ?
Add it on opt-out basis, and if it causes trouble, revert to opt-in in beta/final. Alphas are supposed to be buggy <0.7 wink>
Ok, that makes +5 on including it, no negative response so far. We'll only have to sort out whether to make it opt-in (the current state of the patch) or opt-out. The latter would certainly enable better testing of the code, but I understand that Jeremy doesn't want to destabilize the release just now. Perhaps we'll need a third alpha release ?! (the weak reference implementation and the other goodies need much more testing IMHO than just one alpha cycle) -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
mal wrote:
We'll only have to sort out whether to make it opt-in (the current state of the patch) or opt-out. The latter would certainly enable better testing of the code, but I understand that Jeremy doesn't want to destabilize the release just now.
Perhaps we'll need a third alpha release ?! (the weak reference implementation and the other goodies need much more testing IMHO than just one alpha cycle)
+1 on opt-out and an extra alpha to hammer on weak refs, nested namespaces, and pymalloc. +0 on pymalloc opt-in and no third alpha -1 on function attri, oops, to late. Cheers /F
MAL> Anyone else for adding it now on an opt-in basis ? +1 from me. Skip
"M" == M <mal@lemburg.com> writes:
M> I don't understand why we cannot take the risk of trying this M> out in an alpha version. Logistically, we probably need BDFL pronouncement on this and if we're to get alpha2 out today, that won't happen in time. If we don't get the alpha out today, we probably will not get the first beta out by IPC9, and I think that's important too. So I'd be +1 on adding it opt-in for beta1, which would make the code available to all, and allow us the full beta cycle and 2.2 development cycle to do the micro benchmarks and evaluation for opt-out (or simply always on) in 2.2. -Barry
"Barry A. Warsaw" wrote:
"M" == M <mal@lemburg.com> writes:
M> I don't understand why we cannot take the risk of trying this M> out in an alpha version.
Logistically, we probably need BDFL pronouncement on this and if we're to get alpha2 out today, that won't happen in time. If we don't get the alpha out today, we probably will not get the first beta out by IPC9, and I think that's important too.
With the recent additions of rather important changes I see the need for a third alpha, so getting the beta out for IPC9 will probably not work anyway. Let's get the alpha 2 out today and then add pymalloc to alpha 3.
So I'd be +1 on adding it opt-in for beta1, which would make the code available to all, and allow us the full beta cycle and 2.2 development cycle to do the micro benchmarks and evaluation for opt-out (or simply always on) in 2.2.
-- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
"M" == M <mal@lemburg.com> writes:
M> With the recent additions of rather important changes I see the M> need for a third alpha, so getting the beta out for IPC9 will M> probably not work anyway. M> Let's get the alpha 2 out today and then add pymalloc to alpha M> 3. It might be fun <wink>, then to have a bof or devday discussion about some of the new features. bringing-my-asbestos-longjohns-ly y'rs, -Barry
participants (9)
-
barry＠digicool.com -
Fredrik Lundh -
Jeremy Hylton -
M.-A. Lemburg -
Michael Hudson -
Moshe Zadka -
Skip Montanaro -
Thomas Wouters -
Tim Peters