[issue42693] "if 0:" lines are traced; they didn't use to be

Change by Mark Shannon : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: Unless anyone objects, I'm going to close this issue. -- ___ Python tracker ___ ___

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: I'll briefly answer the above questions, but we could we close this issue? If there are specific issues regarding PEP 626, please make a new issue. Feel free to +nosy me on those issues. I intend to review all the recent changes to the compiler in the new

[issue42693] "if 0:" lines are traced; they didn't use to be

Serhiy Storchaka added the comment: If the NOP is outside of the loop, then what is the reason of adding it? You cannot set a breakpoint on "while True:" which stops on every iteration. The goal "tracing every line of code" is incompatible with code optimization. It would be better to add a

[issue42693] "if 0:" lines are traced; they didn't use to be

Benjamin Peterson added the comment: Maybe sys.settrace() is not ultimately the best tool for coverage reporting? If the bytecode compiler natively supported coverage instrumentation, source semantics would be easier to respect. A nice implementation could use Knuth & Stevenson "Optimal

[issue42693] "if 0:" lines are traced; they didn't use to be

Ned Batchelder added the comment: This seems like a perspective that needs a wider audience. PEP 626 says there will be no performance slowdown: > Performance Implications > > In general, there should be no change in performance. When tracing, > programs should run a little faster as the

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: There isn't much of a plan. https://github.com/python/cpython/pull/23896 makes the optimizer respect PEP 626 w.r.t. jumps-to-jumps. >From the point of view of optimization, there is nothing special about >jumps-to-jumps. Any optimization that offers a speed

[issue42693] "if 0:" lines are traced; they didn't use to be

Ned Batchelder added the comment: Specifically, for jumps to jumps, what is the plan? -- ___ Python tracker ___ ___

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: Are you interested in the "what" or the "how"? The "what": PEP 626 defines what CPython must do in terms of tracing lines executed. The "how": Obviously, we want to execute Python as efficiently as possible. To do so, we use a series of "peephole"

[issue42693] "if 0:" lines are traced; they didn't use to be

Change by Batuhan Taskaya : -- nosy: +BTaskaya ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42693] "if 0:" lines are traced; they didn't use to be

Ned Batchelder added the comment: Mark, I'm trying to follow along with your ideas, but it's hard to piece together the implications. Is there a way to have a discussion about where you are headed? https://github.com/python/cpython/pull/23896 "fixes" the jump to jump problems by no longer

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: The fix, which explains the bug: https://github.com/python/cpython/pull/23896 -- ___ Python tracker ___

[issue42693] "if 0:" lines are traced; they didn't use to be

Ned Batchelder added the comment: > According to that definition, there are still bugs in the optimizer relating > to jumps-to-jumps. I plan to fix them Can you say more about that? What is the bug? How will you fix it? -- ___ Python tracker

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: Ned, I agree that up until 3.9, it is wasn't that simple. But from 3.10 onward, it should be that simple. That's the point of PEP 626. If a transformation changes observable behavior within the scope of language specification, then it is not an optimization

[issue42693] "if 0:" lines are traced; they didn't use to be

Change by Ned Batchelder : -- nosy: +pablogsal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42693] "if 0:" lines are traced; they didn't use to be

Ned Batchelder added the comment: Mark said: > An optimization (CS not math) is a change to the program such that it has the > same effect, according to the language spec, but improves some aspect of the > behavior, such as run time or memory use. > > Any transformation that changes the

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: What is the problem with NOPs? If there are performance regressions in real code, then that needs to be addressed. If only in a few toy examples, then that is (IMO) a price worth paying for predictable debugging and profiling. Raymond: Effectively it does

[issue42693] "if 0:" lines are traced; they didn't use to be

Serhiy Storchaka added the comment: I just noticed that "while True:" is now compiled to NOP. It is clearly a regression which affects performance. -- ___ Python tracker ___

[issue42693] "if 0:" lines are traced; they didn't use to be

Raymond Hettinger added the comment: > But why remove it? It is in the source code. Because traditionally, "if 0: " has been used as a way to comment out code while leaving syntax highlighting in place. The expectation is all the code effectively ceases to exist, just like a comment.

[issue42693] "if 0:" lines are traced; they didn't use to be

Ned Batchelder added the comment: This feels like a recurring debate. I will need some time to lay out my case. Perhaps it needs a wider audience than a bpo issue? -- ___ Python tracker

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: You should never have to disable optimizations. Let's be clear about what an optimization is. An optimization (CS not math) is a change to the program such that it has the same effect, according to the language spec, but improves some aspect of the behavior,

[issue42693] "if 0:" lines are traced; they didn't use to be

Ned Batchelder added the comment: > PEP 626 states that *all* executed code gets traced. Yes, but reading the PEP now, it's not clear what "executed" means. Do we mean "conceptually executed", or, "executed as compiled by the optimizing compiler"? > In fact this NOP can be removed by

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: But why remove it? It is in the source code. Do we want tracing and profiling to depend on what transformations the optimizer does or does not make? What lines are to be traced here? What is the last line executed? def no_code(): if 0: some_code

[issue42693] "if 0:" lines are traced; they didn't use to be

Ned Batchelder added the comment: Previous versions of Python completely removed the "if 0:" statement, because it would have no effect. The condition was checked at compile time, effectively. It seems odd for 3.10 to add it back in. -- ___

[issue42693] "if 0:" lines are traced; they didn't use to be

Mark Shannon added the comment: Yes, this is change is deliberate. PEP 626 states that *all* executed code gets traced. Occasionally that will result in NOPs in the code, that are necessary for correctness, but cannot be removed by the optimizer. Is this a problem in practice? In fact this

[issue42693] "if 0:" lines are traced; they didn't use to be

Raymond Hettinger added the comment: Confirmed. There is bogus NOP in the code. === Python 3.10.0a3+ (heads/master:17ef4319a3, Dec 18 2020, 09:35:26) [Clang 12.0.0 (clang-1200.0.32.28)] on darwin Type "help", "copyright",

[issue42693] "if 0:" lines are traced; they didn't use to be

Serhiy Storchaka added the comment: All NOP bytecodes should be removed. If any is left it is a regression. -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue42693] "if 0:" lines are traced; they didn't use to be

New submission from Ned Batchelder : (Using CPython commit c95f8bc270.) This program has an "if 0:" line that becomes a NOP bytecode. It didn't used to in Python 3.9 print(1) if 0: # line 2 print(3) print(4) Using a simple trace program