[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Serhiy Storchaka added the comment: Finally it is merged, and seems successfully. Thank you all involved, and first at all Mark, the original author. This unblocked further changes, issue32489 and issue32949. And we can try implement other ideas. Changes in the

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Serhiy Storchaka added the comment: New changeset 520b7ae27e39d1c77ea74ccd1b184d7cb43f9dcb by Serhiy Storchaka in branch 'master': bpo-17611. Move unwinding of stack for "pseudo exceptions" from interpreter to compiler. (GH-5006)

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Change by Serhiy Storchaka : -- versions: +Python 3.8 -Python 3.7 ___ Python tracker ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: Simplifying "with"-related opcodes (and perhaps "finally" ones) sounds nice. "try" blocks are already zero-overhead for practical purposes (i.e. I don't think I've met any workload where moving a "try" around did improve performance

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: Apparently PR 5006 has a conflict. Otherwise, is it ready for review? -- ___ Python tracker ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Serhiy Storchaka added the comment: What should be done for PR 5006? Changes of this PR have been minimized for easier review. But many interesting things can made after merging it. For example simplify 'with'-related opcodes. Or implement static blocks (this will

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Change by Serhiy Storchaka : -- pull_requests: -4951 ___ Python tracker ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: Please let's stick with PR 5006. -- ___ Python tracker ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Mark Shannon added the comment: Can we stick to the one PR, please? Once it is merged then we can improve things. Also, I don't like leaving NULLs on the stack, they are an invitation to seg-fault. PR 5143 leaves more NULLs on the stack for longer. --

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Serhiy Storchaka added the comment: PR 5143 is yet one alternative. It is a variant of PR 5006 that restores SETUP_EXCEPT and gets rid of the new opcode BEGIN_FINALLY. SETUP_FINALLY, SETUP_WITH and SETUP_ASYNC_WITH now push NULL on the stack instead. PR 5143

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Change by Serhiy Storchaka : -- pull_requests: +5002 ___ Python tracker ___ ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: On 2017-12-29, Mark Shannon wrote: > One point I didn't cover is jumping to a new line in the debugger. > Implementing that reliably for finally blocks with code > duplication is tricky and would mean adding a number of marker >

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: Le 02/01/2018 à 18:13, Mark Shannon a écrit : > > Rather than go around in circles any more, I suggest that we merge Serhiy's > PR (PR 5006). I can then cherry-pick my commits to clean up the > implementation of the `with` statement (as a new

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Mark Shannon added the comment: > It looks like the build core dumped on Travis-CI I failed to account for the extra stuff left on the stack when handling exceptions and jumping out of a finally block due to a `break`. Caught by Serhiy's tests in

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Mark Shannon added the comment: I've added a commit to compute the stack size. It should compute the exact stack size in all cases, and thus fix bpo-24340. -- ___ Python tracker

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: > With fixed deltas, it is not too hard to construct an algorithm to determine the correct stack size. The presence of JSR-style finally blocks complicates things a little, but not that much. Any chance you can put that patch somewhere to get

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Mark Shannon added the comment: On 01/01/18 17:54, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > I took a quick look at Mark's PR. The main thing going for it IMHO is that > it produces simpler bytecode: it removes the complicated

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Change by Serhiy Storchaka : -- pull_requests: +4951 ___ Python tracker ___ ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: > I just worked on it. I meant Mark's PR :-) -- ___ Python tracker ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Serhiy Storchaka added the comment: > It would be nice to know if it's able to fix the stack size issues as in the > following tests: I just worked on it. See issue24340. -- dependencies: +co_stacksize estimate can be highly off

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: I took a quick look at Mark's PR. The main thing going for it IMHO is that it produces simpler bytecode: it removes the complicated with/finally-related opcodes, while Serhiy's has non-trivial END_FINALLY and POP_FINALLY. It would be nice to

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Serhiy Storchaka added the comment: New opcodes in PR 5071 look interesting, but I think it is better to leave this experiment for a separate issue. Complexities of PRs (ignoring tests, documentation, and generated files): PR 4682: Include/opcode.h | 12 +-

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Mark Shannon added the comment: It shouldn't be a surprise that I have submitted a PR. The original patch was my work and a month ago I said I would update it over the Christmas break. To avoid "competing" PRs in future, simply asking before appropriating other peoples work

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: So we now have three competing PRs... each of which is not trivial. It would be nice if somehow there could be some conciliation, or at least a synthetic comparison. I don't think I want to review all three proposals (and I already spent time

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Change by Mark Shannon : -- pull_requests: +4945 ___ Python tracker ___ ___ Python-bugs-list

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Nick Coghlan added the comment: Another point in favour of the JSR approach is that it should make it easier for tools like coverage.py to continue mapping opcode coverage to line coverage. I also like Serhiy's proposed strategy of separating the initial introduction of the

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Serhiy Storchaka added the comment: I consider PR 5006 as just a first step. I had two goals: 1) Fix all regressions in PR 2827. First at all the regression in the f_lineno setter. 2) Simplify the patch. This is critically important for getting the review. And

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: I apologize if my extra PR is causing confusion. My original intention was to merely forward port Antoine changes so they could compile with the 'master' version of Python. Over time I have made some fixes to it. I have kept it

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: > Whether the small speed difference is worth worrying about is a different > matter. I don't think so. Though one could run the benchmarks suite to get an idea of the impact on real-world code. --

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Mark Shannon added the comment: When I said "significant", I meant from a statistically, not as a judgement meaning "useful" or "worthwhile". The code duplication approach is significantly faster in the tests. Whether the small speed difference is worth worrying about is a

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: Le 29/12/2017 à 12:48, Mark Shannon a écrit : > > Why all these competing pull requests? It does feel like my original patch > has been hijacked. The original patch had a number of issues which needed to be fixed (in addition to forward-port

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Mark Shannon added the comment: Why all these competing pull requests? It does feel like my original patch has been hijacked. Also, before any more PRs, we need to decide whether to use subroutines or code duplication for finally blocks. Here is my attempt at an objective

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: Le 29/12/2017 à 06:26, Neil Schemenauer a écrit : > > I wonder if I should drop PR 4682. My main criterion (apart from performance issues which don't seem to exist) for choosing between the two PRs would be implementation complexity. I find

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: I wonder if I should drop PR 4682. I spent some more time working on it today. I switched to the same scheme as Serhiy for the no-exception case, i.e. push a single NULL value, rather than six NULLs. In ceval, we need to handle

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Serhiy Storchaka added the comment: I don't expect any differences in macrobenchamrks. try/except/finally are rarely used in tight loops. -- ___ Python tracker

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: Yes, those benchmarks look fine. Have you tried with the benchmarks suite? -- ___ Python tracker ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Serhiy Storchaka added the comment: Results of microbenchmarks: $ ./python -m perf timeit -s 'a = list(range(1000))' -- 'for i in a: pass' Mean +- std dev: 6.31 us +- 0.09 us $ ./python -m perf timeit -s 'a = list(range(1000))' -- ' for i in a: try: pass

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Serhiy Storchaka added the comment: The main problem was with the frame.f_lineno setter. I have finally solved it in PR 5006. It solves also the regression in the with statement mentioned in msg307577 (by just restoring the original SETUP_WITH), and some other

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Change by Serhiy Storchaka : -- pull_requests: +4895 ___ Python tracker ___ ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: Ho ho ho! I spent some time to try to resolve the remaining issues with PR 4682. I think everything now works. Returns from a final body of a try/finally was the remaining issue. I've solved it by introducing the POP_NO_EXCEPT

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Change by Serhiy Storchaka : -- dependencies: +Refactor and add new tests for the f_lineno setter ___ Python tracker ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: Hello Raymond, I don't have anything ready to go. PR 4682 has some major outstanding issues. Specifically, exits from finally bodies did not cleanup the fblock stack correctly. I still think this patch is a good idea and that it

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Raymond Hettinger added the comment: Are one of the variants of this patch ready to apply? I'm hoping that the window for 3.7 isn't missed. -- ___ Python tracker

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Mark Shannon added the comment: Thanks, that example shows the essence of the problem. I understand you perfectly now. -- ___ Python tracker

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: def func(): try: try: raise RuntimeError except: return 1 finally: return 3 func() Sorry, I've been collecting a whole slew of code snippets that cause issues with the

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Mark Shannon added the comment: 0610860 doesn't include any tests. What is it fixing? 3794016 passes the same set of tests. Do have an actual code example that produces erroneous behaviour? -- ___ Python tracker

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: There is some more explanation in the PR and sample code. We unwind, if we hit a finally fblock, we emit code of the body of it. If inside the block, there is another return statement, we unwind again. That causes an infinite loop

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Mark Shannon added the comment: On 04/12/17 17:53, Neil Schemenauer wrote: > There is a bug with the PR regarding the final bodies. Exits from the final > body cause the whole fblock stack to unwind, not just the blocks enclosing > the final body. Unwind looks at 'c' to get

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: After studying the patch and doing some reading, I prefer the finally-block duplication approach as well. Java does it that way as well and it works for them. It would be be interesting to compile a large body of packages and see

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Mark Shannon added the comment: Actually looking back at the original patch, the gap between __enter__ and SETUP_FINALLY *was* in the original patch. My mistake. The fix would to be restore SETUP_WITH. The complexity we really want to get rid of is at the end of the with

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Mark Shannon added the comment: On 04/12/17 16:56, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > Right, this is similar to how the JSR/RET pair was used in for calling the > finally block. > > It seems the main drawback of

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Serhiy Storchaka added the comment: Right, this is similar to how the JSR/RET pair was used in for calling the finally block. It seems the main drawback of duplicating of the finally code is not increasing the code size (which can be exponential in degenerate

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: Le 04/12/2017 à 16:21, Mark Shannon a écrit : > > My reasons for preferring the finally-block duplication approach is that it > keeps the interpreter simpler and minimises the amount work done when no > exception is raised. As demonstrated,

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Mark Shannon added the comment: Serhiy, I assume that you plan to use something like the JVM's JSR/RET instruction pair. https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-6.html Is that right? My reasons for preferring the finally-block duplication approach is that it

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Serhiy Storchaka added the comment: > The problem is that makes the stack consumption of END_FINALLY variable. > How about always consuming 6 items, even when most of them are unused > padding? Right. Though the value of the stack increment makes sense only for the

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: Le 04/12/2017 à 13:25, Serhiy Storchaka a écrit : > > I started on Antoine's PR and work on different approach > (https://github.com/serhiy-storchaka/cpython/pull/1) which don't duplicate > the code for continue/break/return. Instead it uses

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Serhiy Storchaka added the comment: I started on Antoine's PR and work on different approach (https://github.com/serhiy-storchaka/cpython/pull/1) which don't duplicate the code for continue/break/return. Instead it uses some kind of subroutines. END_FINALLY

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: Le 04/12/2017 à 12:46, Mark Shannon a écrit : > > I plan to start from > https://github.com/python/cpython/pull/2827/commits/693b9398b5fd202fa5864f9cc76fa1bc7f84f62e > as that adheres to the original design, but cleans up the code. > Antoine

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Mark Shannon added the comment: I plan to resurrect my original design over the Christmas break. The reason that I want to get back to the original design is its consistency and relative simplicity. Duplicating the finally block for every exit from the try body might sound

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: I would point out that Serhiy posted some comments in the followup PR which aren't addressed by Neil's followup PR. They relate to tracing. -- ___ Python tracker

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Nick Coghlan added the comment: While there are some good comments in line in the PR, I think it would be helpful if these changes were accompanied by some additions to https://devguide.python.org/compiler/ that explain how the various pieces of the solution work together

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Raymond Hettinger added the comment: At this point in the release cycle, it would be nice to get this PR applied soon so that there is more time see if there are any minor follow-on issues. -- ___ Python tracker

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Nick Coghlan added the comment: I like this change, and think we should go ahead with it, but just wanted to note that I suspect it may make the "Badly timed signals may lead to __exit__ being skipped even after __enter__ succeeded" problem slightly easier to hit:

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Change by Neil Schemenauer : -- pull_requests: +4594 ___ Python tracker ___ ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: The attached pyperformance report compares cpython:master to nascheme:unwind_stack. If I've done the tests correctly, the unwind_stack version is slightly faster. -- Added file:

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Change by Neil Schemenauer : ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Changes by Serhiy Storchaka : -- pull_requests: -3290 ___ Python tracker ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Changes by Serhiy Storchaka : -- pull_requests: +3290 ___ Python tracker ___ ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Changes by Serhiy Storchaka : -- pull_requests: -3288 ___ Python tracker ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Changes by Serhiy Storchaka : -- pull_requests: +3288 ___ Python tracker ___ ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Changes by Raymond Hettinger : -- Removed message: http://bugs.python.org/msg185785 ___ Python tracker ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: Ok, I've now gotten rid of END_ITER. -- ___ Python tracker ___ ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: > I don't like the new END_ITER instruction. This complicates (and slows down) > the evaluation loop and the peepholer. I don't think it slows down anything in the eval loop. I agree it adds a bit of complexity. > This also adds a limitation on the

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Changes by STINNER Victor : -- nosy: -haypo ___ Python tracker ___ ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Serhiy Storchaka added the comment: Great! I tried to update the patch myself, but there were too much conflicts. Thank you very much Antoine for taking this! Seems there are bugs in frame_setlineno() related to code duplications. And deduplicating the 'finally' blocks doesn't solve all of

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: Ok, I've pushed an update with removes the finally block duplication. -- ___ Python tracker ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: For example we could generate the following bytecode: SETUP_FINALLY L1 // ... stmt1 POP_BLOCK JUMP_FINALLY L1 L1: // ... stmt2 RERAISE JUMP_FORWARD L2 L2: JUMP_FINALLY would push 3 Nones on the stack. RERAISE would raise only if

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: So, the approach of duplicating finally blocks tends to lead to a non-trivial bytecode increase. There is even a potential combinatorial explosion with nested "try..finally" block: def f(): try: ... finally: try: ...

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Changes by Serhiy Storchaka : -- stage: needs patch -> patch review ___ Python tracker ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou added the comment: I updated the patch for git master. Some cleanup is in order. -- ___ Python tracker ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Changes by Antoine Pitrou : -- pull_requests: +2879 ___ Python tracker ___ ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Changes by Antoine Pitrou : -- versions: +Python 3.7 -Python 3.6 ___ Python tracker ___ ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer added the comment: This looks to be a good idea and a good time to merge it now the bytecode has changed to 16-bit. The increase in complexity to compile.c is not bad and reducing the complexity of the eval loop is worth it, IMHO. -- nosy: +nascheme

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Changes by Serhiy Storchaka : -- stage: patch review -> needs patch ___ Python tracker ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Serhiy Storchaka added the comment: The patch no longer applied cleanly. Mark, can you please update your patch? -- ___ Python tracker ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Changes by Christian Heimes : -- nosy: +christian.heimes ___ Python tracker ___ ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Demur Rumed added the comment: Java duplicates finally bytecode too: http://cliffhacks.blogspot.ca/2008/02/java-6-tryfinally-compilation-without.html Tho they avoid jsr instruction because it causes non trivial bytecode validation. Still, they would've had to concluded that finally blocks are

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Changes by Serhiy Storchaka : -- versions: +Python 3.6 -Python 3.5 ___ Python tracker ___

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

STINNER Victor added the comment: FYI The issue #26107 changed code.co_lnotab to support negative line number deltas. -- nosy: +haypo ___ Python tracker

[issue17611] Move unwinding of stack for pseudo exceptions from interpreter to compiler.

Serhiy Storchaka added the comment: I like the idea. I have not make faultfinding review yet, but one thing is questionable to me. Is it necessary to get rid of the END_FINALLY opcode? Currently Python code try: stmt1 finally: stmt2 is compiled to: SETUP_FINALLY

[issue17611] Move unwinding of stack for pseudo exceptions from interpreter to compiler.

Changes by Stefan Krah stefan-use...@bytereef.org: -- nosy: -skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17611 ___ ___ Python-bugs-list

[issue17611] Move unwinding of stack for pseudo exceptions from interpreter to compiler.

Antoine Pitrou added the comment: END_ITER is a synonym for JUMP_ABSOLUTE. It is needed so that frame.set_lineno() can identify loop blocks. I was thinking about this. Isn't it enough to consider all backwards edges as ending a loop block? --

[issue17611] Move unwinding of stack for pseudo exceptions from interpreter to compiler.

Antoine Pitrou added the comment: Ah, no, I guess continue would also create a backwards edge. Nevermind, sorry. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17611 ___

[issue17611] Move unwinding of stack for pseudo exceptions from interpreter to compiler.

Changes by Antoine Pitrou pit...@free.fr: -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17611 ___ ___ Python-bugs-list

[issue17611] Move unwinding of stack for pseudo exceptions from interpreter to compiler.

Antoine Pitrou added the comment: Here is an updated patch keeping up with recent changes in the source tree. -- Added file: http://bugs.python.org/file35094/unwinding.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17611

[issue17611] Move unwinding of stack for pseudo exceptions from interpreter to compiler.

Antoine Pitrou added the comment: Simplifying the eval loop is a rather good thing. Could you post examples of bytecode disassembly before and after the patch? -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org

[issue17611] Move unwinding of stack for pseudo exceptions from interpreter to compiler.

Stefan Krah added the comment: The change seems to slow down the pi float benchmark. Run this and hit Ctrl-C after the first decimal result appears: ./python Modules/_decimal/tests/bench.py I've run the benchmark seven times and the average for float is something like 8-10% slower (64-bit

[issue17611] Move unwinding of stack for pseudo exceptions from interpreter to compiler.

Mark Shannon added the comment: Stefan, I tried running your pi_bench (increasing the numer of iterations by x10 to reduce jitter). The run to run variation exceed the difference between the two versions. Here are the fastest of 7 runs on my machine. i3-2370M CPU @ 2.40GHz × 4. linux 64bit.

[issue17611] Move unwinding of stack for pseudo exceptions from interpreter to compiler.

Mark Shannon added the comment: Antoine, Two bytecode examples. For the following function: def f(x): ... try: ... return x ... except: ... pass Without the patch: 2 0 SETUP_EXCEPT 8 (to 11) 3 3 LOAD_FAST0 (x)

[issue17611] Move unwinding of stack for pseudo exceptions from interpreter to compiler.

Changes by Benjamin Peterson benja...@python.org: -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17611 ___ ___

  1   2   >