[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

Steve Dower added the comment: > __assume(0) should be replaced with other function, inside the eval > switch-case or in the inlined paths of callees. This is critical with PGO. Out of interest, have you done other experiments confirming this? The reference linked is talking about compiler

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

neonene added the comment: >What exactly does "pgo hard reject" mean? In my recognition, "pgo hard reject" is based on the PGOptimizer's heuristic, "reject" is related to the probe count (hot/cold). https://developercommunity.visualstudio.com/t/1531987#T-N1535774 And there was a reply

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

Change by Guido van Rossum : -- pull_requests: +30425 pull_request: https://github.com/python/cpython/pull/32387 ___ Python tracker ___

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

Guido van Rossum added the comment: > -_Py_DECREF (pgo hard reject) What exactly does "pgo hard reject" mean? I Googled it and found no hits besides this very issue. I am trying to redefine the top three from this error log as macros, but since I still don't have stable benchmark results

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

Guido van Rossum added the comment: I can't yet confirm a regression in 3.11 (the main branch, currently) compared to 3.10. See my adventures in https://github.com/faster-cpython/ideas/discussions/315. -- ___ Python tracker

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

Change by neonene : -- pull_requests: +29588 pull_request: https://github.com/python/cpython/pull/31459 ___ Python tracker ___ ___

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

Change by neonene : -- pull_requests: +29570 pull_request: https://github.com/python/cpython/pull/31436 ___ Python tracker ___ ___

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

neonene added the comment: I requested the MSVC team to reconsider the inlining issues, including __forceinline. https://developercommunity.visualstudio.com/t/1595341 The stuck at link due to __forceinline can be avoided by completing the _Py_DECREF optimization outside

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

neonene added the comment: In the eval-loop of PR29565, inlining seems to be enabled within about 70 op-brahches, trained with 44 tests. log & source: ceval_PR29565_split_func.c (not for performance) -- Added file: https://bugs.python.org/file50452/ceval_PR29565_split_func.c

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

neonene added the comment: >This essentially disables PGO. Thank you for the suggestion. I'll take another experimental aproach to reduce the size of 3.11 evalfunc for stronger validation. >@neonene what's the importance of PR29565? While we are talking about function size, I would like

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

Guido van Rossum added the comment: @neonene what's the importance of PR29565? -- ___ Python tracker ___ ___ Python-bugs-list

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

Steve Dower added the comment: > -set pgo_job=-m test --pgo > +set pgo_job=-c"pass" This essentially disables PGO. You won't get anything valid or useful from analysing its results if you don't give it a somewhat reasonable profile (preferably one that exercises the interpreter loop, which

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

neonene added the comment: Here are the 3 steps to reproduce with minimal pgo training. (vs2019) 1. Download the source archive of PR29565 and extract. https://github.com/python/cpython/archive/6a84d61c55f2e543cf5fa84522d8781a795bba33.zip 2. Apply the following patch.

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

Guido van Rossum added the comment: I'd like to know how to reproduce this. @neonene can you write down the steps I should do to get the results you get? I have VS 2019, if I need VS 2022 I can install that. -- ___ Python tracker

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

Brandt Bucher added the comment: Hm. If removing 26 opcodes didn't fix this, then maybe the size of _PyEval_EvalFrameDefault isn't really the issue? -- ___ Python tracker

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

neonene added the comment: I still have the issue in current main and PR29565 with msvc2022 (v142 or v143 toolset). -- ___ Python tracker ___

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

Brandt Bucher added the comment: The total size of the main interpreter loop was recently reduced somewhat by an unrelated change: https://github.com/python/cpython/commit/9178f533ff5ea7462a2ca22cfa67afd78dad433b I wonder if this issue still exists? --

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

neonene added the comment: msg402954 >https://github.com/faster-cpython/tools According to the suggested stats and pgomgr.exe, I experimentally moved LOAD_FAST and LOAD_CONST cases out of switch as below. if (opcode == LOAD_FAST) { ... DISPATCH(); }

[issue45116] Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)

Change by STINNER Victor : -- title: Performance regression 3.10b1 and later on Windows: Py_DECREF() not inlined in PGO build -> Performance regression 3.10b1: inlining issue in the big _PyEval_EvalFrameDefault() function with Visual Studio (MSC)