Hi all, between some interesting and a lot of not-so-interesting talks here at oospla, I also find the time to hack a bit on pypy :-). Yesterday I tried the hand-written optimization attached to this mail; it seems to make pystone about 6% faster; it's not much, but it's not even so few not to take into account, IMHO. Btw, richards does not show any improvement, as expected. Also, it seems that it makes pypy-cli slower, at least on mono; this is somewhat surprising, because IronPython entirely relies on this kind of if-else if tests to dispath all operations... I would have bet that our multimethod dispatching was slower, but it does not seems so. I should try also on MS .NET, though. I know that this is not the way to do such an optimization; I guess that the correct way would be to teach the mutlimethod installer which are the "hot" cases to test first, before going for a full dispatch; I've not clue how to do it, though. :-) ciao Anto Index: objspace/descroperation.py =================================================================== --- objspace/descroperation.py (revision 47491) +++ objspace/descroperation.py (working copy) @@ -413,6 +413,19 @@ def _make_binop_impl(symbol, specialnames): left, right = specialnames def binop_impl(space, w_obj1, w_obj2): + if symbol == '+': + from pypy.objspace.std.intobject import W_IntObject, wrapint + from pypy.objspace.std.longobject import add__Long_Long, delegate_Int2Long + from pypy.rlib.rarithmetic import ovfcheck + if isinstance(w_obj1, W_IntObject) and isinstance(w_obj2, W_IntObject): + x = w_obj1.intval + y = w_obj2.intval + try: + z = ovfcheck(x + y) + except OverflowError: + return add__Long_Long(space, delegate_Int2Long(space, w_obj1), delegate_Int2Long(space, w_obj2)) + return wrapint(space, z) + w_typ1 = space.type(w_obj1) w_typ2 = space.type(w_obj2) w_left_src, w_left_impl = space.lookup_in_type_where(w_typ1, left)
On Wed, 24 Oct 2007 14:37:07 +0200, Antonio Cuni
Hi all,
between some interesting and a lot of not-so-interesting talks here at oospla, I also find the time to hack a bit on pypy :-).
Yesterday I tried the hand-written optimization attached to this mail; it seems to make pystone about 6% faster; it's not much, but it's not even so few not to take into account, IMHO. Btw, richards does not show any improvement, as expected.
Also, it seems that it makes pypy-cli slower, at least on mono; this is somewhat surprising, because IronPython entirely relies on this kind of if-else if tests to dispath all operations... I would have bet that our multimethod dispatching was slower, but it does not seems so. I should try also on MS .NET, though.
I know that this is not the way to do such an optimization; I guess that the correct way would be to teach the mutlimethod installer which are the "hot" cases to test first, before going for a full dispatch; I've not clue how to do it, though. :-)
Does this break (by ignoring) custom __add__ implementations on int subclasses? Jean-Paul
Antonio Cuni wrote:
Jean-Paul Calderone wrote:
Does this break (by ignoring) custom __add__ implementations on int subclasses?
uh, right! :-/
Well, that means that we should check for the exact classes/python type instead for subclasses, but I think the optimization is still worth of.
Isn't this the optimization that Michael already tried? See objspace/std/objspace.py line 65. command line option is --objspace-std-withsmallint I turned out to not be worth it in many cases. Cheers, Carl Friedrich
Carl Friedrich Bolz wrote:
Antonio Cuni wrote:
Jean-Paul Calderone wrote:
Does this break (by ignoring) custom __add__ implementations on int subclasses?
uh, right! :-/
Well, that means that we should check for the exact classes/python type instead for subclasses, but I think the optimization is still worth of.
Isn't this the optimization that Michael already tried? See objspace/std/objspace.py line 65. command line option is --objspace-std-withsmallint
I turned out to not be worth it in many cases.
But it is known as a useful special case in the CPython interpreter loop. ciao - chris -- Christian Tismer :^) mailto:tismer@stackless.com tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
Christian Tismer wrote:
Isn't this the optimization that Michael already tried? See objspace/std/objspace.py line 65. command line option is --objspace-std-withsmallint
I turned out to not be worth it in many cases.
But it is known as a useful special case in the CPython interpreter loop.
Well, read our D7.1 report for details. One reason why it didn't help could be that our multimethod implementation is very good already, so special cases don't help it (but make the generic case slower). Cheers, Carl Friedrich
Christian Tismer wrote:
Isn't this the optimization that Michael already tried? See objspace/std/objspace.py line 65. command line option is --objspace-std-withsmallint
I turned out to not be worth it in many cases.
But it is known as a useful special case in the CPython interpreter loop.
moreover, according to Jim Hugunin, it's also an useful optimization in IronPython, that's why I decided to try it. Btw, I choose int+int for the example but in theory we could apply the same technique to other cases, says getitem on list and int or getattr on instances and string. I mean, they are the common cases so it might be worth of special casing them; of course not manually, that's not the pypy way :-). ciao Anto
On 24/10/2007, Antonio Cuni
Christian Tismer wrote:
Isn't this the optimization that Michael already tried? See objspace/std/objspace.py line 65. command line option is --objspace-std-withsmallint
I turned out to not be worth it in many cases.
But it is known as a useful special case in the CPython interpreter loop.
moreover, according to Jim Hugunin, it's also an useful optimization in IronPython, that's why I decided to try it.
Btw, I choose int+int for the example but in theory we could apply the same technique to other cases, says getitem on list and int or getattr on instances and string. I mean, they are the common cases so it might be worth of special casing them; of course not manually, that's not the pypy way :-).
As Carl Friedrich said, I went down this route a bit before, and didn't get very much. Maybe you will have a happier time of it! Cheers, mwh
Hi, On Wed, Oct 24, 2007 at 03:44:16PM +0200, Carl Friedrich Bolz wrote:
Isn't this the optimization that Michael already tried? See objspace/std/objspace.py line 65. command line option is --objspace-std-withsmallint
No, it's --objspace-std-optimized_int_add. You're reading the code too fast :-) Armin
Hi Armin,
2007/10/27, Armin Rigo
On Wed, Oct 24, 2007 at 03:44:16PM +0200, Carl Friedrich Bolz wrote:
Isn't this the optimization that Michael already tried? See objspace/std/objspace.py line 65. command line option is --objspace-std-withsmallint
No, it's --objspace-std-optimized_int_add. You're reading the code too fast :-)
Argh, indeed. That was complete nonsense, thanks for noticing. Cheers, Carl Friedrich
participants (6)
-
Antonio Cuni -
Armin Rigo -
Carl Friedrich Bolz -
Christian Tismer -
Jean-Paul Calderone -
Michael Hudson