[issue24014] Second pass of PyCode_Optimize
Yury Selivanov added the comment: Is there any noticeable performance increase with the patch? Please attach results from https://hg.python.org/benchmarks -- nosy: +yselivanov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24014 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24014] Second pass of PyCode_Optimize
Eric Snow added the comment: Also, Python/importlib.h blew up in the diff; should this be included in the patch? Yes. It is the frozen bytecode for bootstrapping importlib as the import system. So changes to bytecode generation like this will propagate there. -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24014 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24014] Second pass of PyCode_Optimize
New submission from Joe Jevnik: There are a lot of optimizations that are being missed by only running a single pass of PyCode_Optimize. I originally started by trying to optimize for De Morgan's Laws in if tests; however, I realized that the issue actually went away if you run the optimizer twice. I imagine that this would provide a lot of other performance increases because some of the patterns don't show up until the optimizer has already run once. For example: def f(a, b): ... if not a and not b: ... return True ... return False ... On default, this generates: dis(f) 2 0 LOAD_FAST0 (a) 3 UNARY_NOT 4 POP_JUMP_IF_FALSE 18 7 LOAD_FAST1 (b) 10 UNARY_NOT 11 POP_JUMP_IF_FALSE 18 3 14 LOAD_CONST 1 (True) 17 RETURN_VALUE 418 LOAD_CONST 2 (False) 21 RETURN_VALUE If we run the optimizer again, we can collapse some of the UNARY_NOT - POP_JUMP_IF_FALSE back into POP_JUMP_IF_TRUE, like this: dis(f) 2 0 LOAD_FAST0 (a) 3 POP_JUMP_IF_TRUE16 6 LOAD_FAST1 (b) 9 POP_JUMP_IF_TRUE16 3 12 LOAD_CONST 1 (True) 15 RETURN_VALUE 416 LOAD_CONST 2 (False) 19 RETURN_VALUE Also, Python/importlib.h blew up in the diff; should this be included in the patch? -- components: Interpreter Core files: secondpass.patch keywords: patch messages: 241626 nosy: ll priority: normal severity: normal status: open title: Second pass of PyCode_Optimize type: performance versions: Python 3.5 Added file: http://bugs.python.org/file39144/secondpass.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24014 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24014] Second pass of PyCode_Optimize
Raymond Hettinger added the comment: I would like to keep the time spent in the optimizer itself to a minimum. Also, it should keep focused on patterns that actually occur in code as opposed to contrived bits of code. Tim and Guido let us put it the optimizer only on the condition that it be kept simple and with low overhead. The work that has been needed for a long time was to move a number of the optimizations (such as constant folding) out of the peepholer optimizer and replace them with AST manipulations just upstream from code generation (to reduce the need for the peepholer to partially disassemble and re-interpret the bytecode). -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24014 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24014] Second pass of PyCode_Optimize
Christian Heimes added the comment: How about restricting double pass optimization to code objects that have the CO_OPTIMIZED bit set? It doesn't affect normal code execution. -- nosy: +christian.heimes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24014 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24014] Second pass of PyCode_Optimize
Brett Cannon added the comment: Just FYI, http://bugs.python.org/issue11549 can act as a tracking issue for an AST optimization path that runs prior to the peepholer. -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24014 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24014] Second pass of PyCode_Optimize
Joe Jevnik added the comment: I tried bumping the magic number; however, I still cannot get consistent results when running benchmark locally. I guess I will close this as I cannot consistently show an improvement. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24014 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24014] Second pass of PyCode_Optimize
Yury Selivanov added the comment: Does the benchmark tool recompile the code every run? Make sure you've bumped magic number in importlib/bootstrap; then make clean; make -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24014 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24014] Second pass of PyCode_Optimize
Joe Jevnik added the comment: I am actually getting inconsistent results from running benchmark; I am pretty surprised by this. I could look into making the second pass only happen if the code has the CO_OPTIMIZED bit set; however, based on the results I am seeing from the benchmark runs, I am not sure it is worth it. Does the benchmark tool recompile the code every run? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24014 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
