search

arvindm95 / unladen-swallow

Automatically exported from code.google.com/p/unladen-swallow
Other
0 stars 0 forks source link

Re-add one-off optimizations from eval loop #17

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
We've currently dropped optimizations like BINARY_ADD's special case for
PyInts and PyStrings. We'll want to add them back before doing real
performance comparisons.

Original issue reported on code.google.com by jyass...@gmail.com on 21 Apr 2009 at 10:03

GoogleCodeExporter commented 8 years ago

Original comment by collinw on 27 May 2009 at 9:44

GoogleCodeExporter commented 8 years ago

Original comment by collinw on 27 May 2009 at 10:16

GoogleCodeExporter commented 8 years ago 
A possible implementation of (most of) them: http://codereview.appspot.com/63159

Original comment by thomaswout@gmail.com on 27 May 2009 at 10:59

GoogleCodeExporter commented 8 years ago

Original comment by collinw on 30 May 2009 at 6:35

GoogleCodeExporter commented 8 years ago 
It may not be worth doing this, according to Thomas's patch/benchmarks for the
BINARY_ADD, BINARY_SUBTRACT and BINARY_MODULO specializations:

$ ./perf.py -m -a -L2  ../builds/trunk-opt/python ../builds/trunk-wip-opt/python

[...]
Report on Linux atlas 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC
2009 i686

2to3:
79.24 -> 79.38: 0.18% slower
Mem max: 100708.000 -> 106220.000: 5.19% bigger
Usage over time: http://tinyurl.com/l5sbgr

django:
Min: 1.010 -> 1.025: 1.49% slower
Avg: 1.048 -> 1.058: 0.93% slower
Not significant

Mem max: 98572.000 -> 104244.000: 5.44% bigger
Usage over time: http://tinyurl.com/lye7je

pickle:
Min: 0.850 -> 0.854: 0.53% slower
Avg: 0.929 -> 0.904: 2.78% faster
Not significant

Mem max: 99464.000 -> 105232.000: 5.48% bigger
Usage over time: http://tinyurl.com/n4c73r

slowspitfire:
Min: 0.751 -> 0.731: 2.71% faster
Avg: 0.784 -> 0.774: 1.28% faster
Not significant

Mem max: 143828.000 -> 148944.000: 3.43% bigger
Usage over time: http://tinyurl.com/lnfdbp

unpickle:
Min: 0.650 -> 0.657: 1.14% slower
Avg: 0.665 -> 0.669: 0.54% slower
Not significant

Mem max: 99528.000 -> 105228.000: 5.42% bigger
Usage over time: http://tinyurl.com/net85t

Original comment by collinw on 12 Jun 2009 at 10:16

GoogleCodeExporter commented 8 years ago

Original comment by collinw on 19 Jun 2009 at 7:17

GoogleCodeExporter commented 8 years ago 
Since Thomas's patch didn't really help, I'm going to officially punt this 
until we 
have type feedback and can inline the one-off optimizations directly from the 
implementations of PyNumber_Add, etc.

Original comment by jyass...@gmail.com on 22 Jun 2009 at 6:25

GoogleCodeExporter commented 8 years ago 
Reid is going to take another look at this, but not inlining the 
specializations into the IR. 
Given our experience optimizing UNPACK_SEQUENCE, these binary operators may 
have 
similar properties.

Original comment by collinw on 15 Jul 2009 at 10:49

GoogleCodeExporter commented 8 years ago 
We looked at this again, and the performance benefits were still negligible.  
I'm
closing this in favor of the FDO bugs.

Original comment by reid.kle...@gmail.com on 29 Jul 2009 at 7:01