[issue2459] speedup for / while / if with better bytecode
Mark Lawrence added the comment: As a lot of work has gone into this it saddens me to see it languishing. Surely if Python performance is to be improved the bytecode for conditionals and loops is one of the places if not the place to do it? Are there any names missing from the nosy list that ought to be there? -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Christian Heimes added the comment: Is this enhancement still relevant? -- nosy: +christian.heimes status: open - languishing versions: +Python 3.3, Python 3.4 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Changes by Giampaolo Rodola' g.rod...@gmail.com: -- nosy: +giampaolo.rodola ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Changes by Daniel Stutzbach dan...@stutzbachenterprises.com: -- nosy: +stutzbach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Dirkjan Ochtman dirk...@ochtman.nl added the comment: Is this still relevant / will it get some love in the future? -- nosy: +djc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Jeffrey Yasskin jyass...@gmail.com added the comment: Hold off on reviewing this. There's one bug around the peepholer not turning itself off when line numbers skip by more than 127, and another around the traceback generator still assuming line numbers are unsigned. I'll post another patch when those are fixed and tested. I may not get to it for a day or two, so someone else is welcome to update the patch instead. :) -- assignee: pitrou - jyasskin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Antoine Pitrou pit...@free.fr added the comment: I've updated for_iter.patch to the latest trunk, merging in issue 4715. I also changed tracing a bit so that the first line of a loop doesn't get traced twice in the first iteration, and added to test_dis to check that decreasing line numbers work there. Thanks a lot! By the way, why do you bench cPickle? Does your test call Python code significantly? Overall, the results look positive although not overwhelming. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Jeffrey Yasskin jyass...@gmail.com added the comment: No particular reason for cPickle. It sometimes shows when we've caused problems by increasing the code size, and shows the size of any random effects that the compiler causes by moving code around. Could you double-check the patch to see if I did anything dumb? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Jeffrey Yasskin jyass...@gmail.com added the comment: I've updated for_iter.patch to the latest trunk, merging in issue 4715. I also changed tracing a bit so that the first line of a loop doesn't get traced twice in the first iteration, and added to test_dis to check that decreasing line numbers work there. Review at http://codereview.appspot.com/20103 if you like. Performance: 32-bit gcc-4.3 Intel Core2: 2to3: 25.09 - 24.63: 1.87% faster Django: Min: 0.614 - 0.609: 0.86% faster Avg: 0.616 - 0.635: 3.09% slower Pickle: (cPickle) Min: 1.647 - 1.651: 0.21% slower Avg: 1.650 - 1.656: 0.39% slower PyBench: Min: 5341 - 5273: 1.29% faster Avg: 5450 - 5397: 0.98% faster SlowPickle: (pickle) Min: 1.384 - 1.341: 3.13% faster Avg: 1.385 - 1.343: 3.08% faster Spitfire: Min: 0.773 - 0.690: 11.97% faster Avg: 0.776 - 0.695: 11.62% faster Spitfire re-run: Min: 0.740 - 0.693: 6.81% faster Avg: 0.744 - 0.695: 6.93% faster SlowUnpickle: (pickle) Min: 0.645 - 0.668: 3.37% slower Avg: 0.646 - 0.670: 3.59% slower SlowUnpickle re-run: Min: 0.645 - 0.660: 2.31% slower Avg: 0.645 - 0.661: 2.32% slower Unpickle: (cPickle) Min: 1.015 - 1.006: 0.89% faster Avg: 1.021 - 1.009: 1.16% faster 64-bit gcc-4.3 Intel Core2 2to3: 22.31 - 21.97: 1.57% faster Django: Min: 0.577 - 0.564: 2.29% faster Avg: 0.579 - 0.566: 2.20% faster Pickle: Min: 1.162 - 1.178: 1.35% slower Avg: 1.166 - 1.183: 1.37% slower PyBench: Min: 4498 - 4193: 7.27% faster Avg: 4586 - 4276: 7.25% faster SlowPickle: Min: 1.212 - 1.133: 6.92% faster Avg: 1.213 - 1.135: 6.92% faster Spitfire: Min: 0.631 - 0.617: 2.32% faster Avg: 0.632 - 0.621: 1.75% faster SlowUnpickle: Min: 0.575 - 0.551: 4.31% faster Avg: 0.576 - 0.553: 4.14% faster Unpickle: Min: 0.708 - 0.722: 1.88% slower Avg: 0.745 - 0.736: 1.20% faster -- assignee: - pitrou Added file: http://bugs.python.org/file13227/trunk-opt-loop.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Collin Winter coll...@gmail.com added the comment: On Fri, Feb 13, 2009 at 3:23 PM, Collin Winter coll...@gmail.com wrote: On Fri, Feb 13, 2009 at 10:37 AM, Antoine Pitrou rep...@bugs.python.org wrote: Before committing I want to know what to do with the new jump opcodes, with respect to the alternative proposal I've made in #4715. Ideally, I should fold the #4715 patch back into the present patch, since I think the #4715 approach is more thought out. That sounds good, especially since Jeffrey and I have already reviewed #4715. If you don't have the bandwidth to integrate 4715 into this patch, I can do that, if you want. Collin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Antoine Pitrou pit...@free.fr added the comment: If you don't have the bandwidth to integrate 4715 into this patch, I can do that, if you want. Collin, that would be very nice from you. You could also apply Jeffrey's naming suggestions in #4715. Thanks! Antoine. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Collin Winter coll...@gmail.com added the comment: I don't see the changes to the lnotab format being a roadblock; just mention it in NEWS. Likewise, the pure-Python compiler package shouldn't be a high priority; your changes to that package look good enough. I'm seeing encouraging speed-ups out of this (with gcc 4.3.1 x86_64, compiling Python as 64-bit): Django templates (render a 150x150 table 100 times): Min: 0.595 - 0.589: 0.94% faster Avg: 0.599 - 0.591: 1.30% faster Spitfire templates (render a 1000x1000 table 100 times): Min: 0.751 - 0.729: 2.98% faster Avg: 0.753 - 0.730: 3.09% faster None of the apps I've benchmarked are negatively impacted. I only have two minor comments. Please commit this. Review comments: - The changes to Python/compile.c:compiler_if(), compiler_for(), compiler_while() have some indentation issues (tabs and such). - Functions like def foo(): while True: pass have a useless JUMP_FORWARD 0 instruction, but I don't think it's worth teaching the peepholer to remove them since it doesn't happen in other circumstances (that I can tell). ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Antoine Pitrou pit...@free.fr added the comment: Hello Collin, Thanks for taking a look. I don't see the changes to the lnotab format being a roadblock; just mention it in NEWS. Likewise, the pure-Python compiler package shouldn't be a high priority; your changes to that package look good enough. Well, I have good news: the fixes to the pure Python compiler have been accepted and committed by Neil Schemenauer in r69373. I'm seeing encouraging speed-ups out of this (with gcc 4.3.1 x86_64, compiling Python as 64-bit): Django templates (render a 150x150 table 100 times): Min: 0.595 - 0.589: 0.94% faster Avg: 0.599 - 0.591: 1.30% faster Spitfire templates (render a 1000x1000 table 100 times): Min: 0.751 - 0.729: 2.98% faster Avg: 0.753 - 0.730: 3.09% faster Not a tremendous speedup but not totally insignificant either. (I see you like Spitfire :-)) None of the apps I've benchmarked are negatively impacted. I only have two minor comments. Please commit this. Before committing I want to know what to do with the new jump opcodes, with respect to the alternative proposal I've made in #4715. Ideally, I should fold the #4715 patch back into the present patch, since I think the #4715 approach is more thought out. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Collin Winter coll...@gmail.com added the comment: On Fri, Feb 13, 2009 at 10:37 AM, Antoine Pitrou rep...@bugs.python.org wrote: Antoine Pitrou pit...@free.fr added the comment: Hello Collin, Thanks for taking a look. I don't see the changes to the lnotab format being a roadblock; just mention it in NEWS. Likewise, the pure-Python compiler package shouldn't be a high priority; your changes to that package look good enough. Well, I have good news: the fixes to the pure Python compiler have been accepted and committed by Neil Schemenauer in r69373. Yeah, I saw that. Fantastic. I'm seeing encouraging speed-ups out of this (with gcc 4.3.1 x86_64, compiling Python as 64-bit): Django templates (render a 150x150 table 100 times): Min: 0.595 - 0.589: 0.94% faster Avg: 0.599 - 0.591: 1.30% faster Spitfire templates (render a 1000x1000 table 100 times): Min: 0.751 - 0.729: 2.98% faster Avg: 0.753 - 0.730: 3.09% faster Not a tremendous speedup but not totally insignificant either. (I see you like Spitfire :-)) Well, Spitfire and Django represent very different ways of implementing a template system, so I like to measure both when doing application benchmarks. Template systems tend to be heavy CPU consumers for webapps, which is why I include them. None of the apps I've benchmarked are negatively impacted. I only have two minor comments. Please commit this. Before committing I want to know what to do with the new jump opcodes, with respect to the alternative proposal I've made in #4715. Ideally, I should fold the #4715 patch back into the present patch, since I think the #4715 approach is more thought out. That sounds good, especially since Jeffrey and I have already reviewed #4715. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Changes by Armin Rigo ar...@users.sourceforge.net: -- nosy: -arigo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Antoine Pitrou pit...@free.fr added the comment: Here is an updated patch against trunk. To be honest I don't think it has a lot of future: - it changes the lnotab format (to allow negative offsets) - it rewrites the buggy block reordering code in the pure Python compiler package, but nobody seems interested in maintaining that package (see #2472). Perhaps we should just declare the experiment failed and switch to something else. Added file: http://bugs.python.org/file12923/for_iter.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: I would like to see this go forward. It looks promising. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Changes by Collin Winter coll...@gmail.com: -- nosy: +collinwinter ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Reminder, make sure we can still break out of a while 1: pass. -- nosy: +rhettinger versions: +Python 2.7, Python 3.1 -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Antoine Pitrou pit...@free.fr added the comment: Reminder, make sure we can still break out of a while 1: pass. Yes, the patch takes care of that. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Antoine Pitrou pit...@free.fr added the comment: The patches don't apply cleanly anymore, I'll regenerate a new one. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Changes by Antoine Pitrou pit...@free.fr: Removed file: http://bugs.python.org/file10147/loops8.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Changes by Antoine Pitrou pit...@free.fr: Removed file: http://bugs.python.org/file9871/loops7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Changes by Antoine Pitrou pit...@free.fr: Removed file: http://bugs.python.org/file9863/loops5.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Changes by Antoine Pitrou pit...@free.fr: Removed file: http://bugs.python.org/file9832/loops4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Changes by Antoine Pitrou pit...@free.fr: Removed file: http://bugs.python.org/file9829/loops3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Χρήστος Γεωργίου (Christos Georgiou) [EMAIL PROTECTED] added the comment: A pointer to previous (minor) research: http://groups.google.com/group/comp.lang.python/browse_frm/thread/72505e3cb6d9cb1a/e486759f06ec4ee5 esp. after Terry Reedy's post -- nosy: +tzot ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2459 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2459] speedup for / while / if with better bytecode
Antoine Pitrou [EMAIL PROTECTED] added the comment: Finally I had to slightly change the lnotab format to have the right tracing semantics: the change is that line number increments are now signed bytes rather than unsigned. Still, there is a small change in tracing behaviour (see test_trace.py): the for statement is traced twice in the first loop iteration, that's because the iterator object is retrieved (GET_ITER) at the beginning of the loop while the next iterator value is fetched (FOR_ITER) at the end of the loop. I don't believe this is very painful. All in all, the whole test suite now passes fine. The performance numbers are the same as before. -- title: speedup loops with better bytecode - speedup for / while / if with better bytecode Added file: http://bugs.python.org/file10147/loops8.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2459 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
