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
Change by neonene :
--
nosy: +neonene
nosy_count: 5.0 -> 6.0
pull_requests: +30375
pull_request: https://github.com/python/cpython/pull/32313
___
Python tracker
<https://bugs.python.org/issu
Change by neonene :
--
nosy: +neonene
nosy_count: 4.0 -> 5.0
pull_requests: +30226
pull_request: https://github.com/python/cpython/pull/32146
___
Python tracker
<https://bugs.python.org/issu
Change by neonene :
--
nosy: +neonene
nosy_count: 7.0 -> 8.0
pull_requests: +30111
pull_request: https://github.com/python/cpython/pull/32023
___
Python tracker
<https://bugs.python.org/issu
Change by neonene :
--
nosy: +neonene, pablogsal
nosy_count: 8.0 -> 10.0
pull_requests: +30112
pull_request: https://github.com/python/cpython/pull/32023
___
Python tracker
<https://bugs.python.org/issu
neonene added the comment:
UNPACK_SEQUENCE's slowdown is already filed?
https://speed.python.org/timeline/#/?exe=12=unpack_sequence=4=50=off=on=on
I hit the gap at 424ecab on Windows.
--
nosy: +neonene
___
Python tracker
<https://bugs.python.
Change by neonene :
--
pull_requests: +29588
pull_request: https://github.com/python/cpython/pull/31459
___
Python tracker
<https://bugs.python.org/issue45
Change by neonene :
--
pull_requests: +29570
pull_request: https://github.com/python/cpython/pull/31436
___
Python tracker
<https://bugs.python.org/issue45
neonene added the comment:
> +
This is bad if ARM64 machine takes the blank value as not "ARM64" but "ARM", as
"ARM" tools are not necessary to install. Then, I agree with the proposal of
the OP (PR28491) below:
> Would it be acceptable if a
neonene added the comment:
> When cross-compiling, tools that are executed as part of the build need to be
> built for the tool platform, not the target platform.
My PR does not against that at this point, as proposed codes are based on your
PR28322 (09b4ad11f323f8702cde795e345b75e0fb
neonene added the comment:
Defenition in general_advanced.xml
These options above are corresponded to the following folders in my case:
Microsoft Visual Studio\.\VC\Tools\MSVC\\bin\Hostx86
Microsoft Visual Studio\.\VC\Tools\MSVC\\bin\Hostx64
neonene added the comment:
>This also rolls _freeze_module.exe's architecture back to x64
Correcting: from x86 back to x64
In my recognition, only Win32 _freeze_module.exe is built currently and run on
non-ARM machines to generate the code for Win32/x64/ARM/ARM64 targ
Change by neonene :
--
keywords: +patch
pull_requests: +28873
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30673
___
Python tracker
<https://bugs.python.org/issu
New submission from neonene :
In pcbuild.proj, "PreferredToolArchitecture" property looks misused, which I
think is useful giving us two selections of a compiler (32bit or 64bit) for any
target architecture (Win32/x64/ARM/ARM64).
I think the property can be unused there. This means
Change by neonene :
--
pull_requests: +28793
pull_request: https://github.com/python/cpython/pull/30595
___
Python tracker
<https://bugs.python.org/issue46
neonene added the comment:
Basically, PR30571 aims for compatibility with 3.10 and earlier. Using Windows
API is the easiest and the same way as them:
import os.path
paths = [
r'C:\CON',
r'C:\PRN',
r'C:\AUX',
r'C:\NUL',
r'C:\COM1',
r'C:\COM2',
r'C:\COM3',
r'C
neonene added the comment:
> PathCchSkipRoot() doesn't recognize forward slash as a path separator,
I opened issue46362 and PR30571 about the mentioned abspath() behaviors.
--
___
Python tracker
<https://bugs.python.org/issu
Change by neonene :
--
keywords: +patch
pull_requests: +28772
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30571
___
Python tracker
<https://bugs.python.org/issu
New submission from neonene :
3.11a3+ introduced the C version of abspath(), which shows incompletely
normalized absolute path (see msg410068):
>>> os.path.abspath(r'\\spam\\eggs. . .')
'spameggs. . .'
>>> os.path.abspath('C:\\spam. .
neonene added the comment:
Regarding https://github.com/python/cpython/pull/30362#issuecomment-1005496892
_Py_abspath/_getfullpathname does not always call GetFullPathNameW on 3.11.
Python 3.10.1
>>> nt._getfullpathname('.\\C:spameggs. . .')
'.\\C:\\spam\\eggs
neonene added the comment:
>Here's a branch with a passing ntpath.normpath test and a failing
>posixpath.normpath test:
I took the test cases for my PR, thanks.
On Windows machine, ntpath fails and posixpath passes. It seems that the
passing one is tested with pure pytho
Change by neonene :
--
keywords: +patch
nosy: +neonene
nosy_count: 3.0 -> 4.0
pull_requests: +28576
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30362
___
Python tracker
<https://bugs.python.org/i
neonene added the comment:
The flag is not for Win8.1 and available starting in Win10 1703 with
v10.0.15021 SDK.
--
nosy: +neonene
___
Python tracker
<https://bugs.python.org/issue46
Change by neonene :
--
keywords: +patch
pull_requests: +28400
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/30181
___
Python tracker
<https://bugs.python.org/issu
New submission from neonene :
In Makefile.pre.in, LTO is disabled when building _freeze_module. MSVC can also
cut the build time of _freeze_module.exe in half without the optimization.
--
components: Build, Windows
messages: 408841
nosy: neonene, paul.moore, steve.dower, tim.golden
Change by neonene :
--
nosy: +neonene
nosy_count: 6.0 -> 7.0
pull_requests: +28391
pull_request: https://github.com/python/cpython/pull/30175
___
Python tracker
<https://bugs.python.org/issu
Change by neonene :
--
pull_requests: +28238
pull_request: https://github.com/python/cpython/pull/30014
___
Python tracker
<https://bugs.python.org/issue45
Change by neonene :
--
pull_requests: +28166
pull_request: https://github.com/python/cpython/pull/29941
___
Python tracker
<https://bugs.python.org/issue45
Change by neonene :
--
pull_requests: +28154
pull_request: https://github.com/python/cpython/pull/29930
___
Python tracker
<https://bugs.python.org/issue45
neonene added the comment:
PGO-instrumented binary seems not to specify the stdlib directory on PR29041. I
can run it with PYTHONPATH set.
Python path configuration:
PYTHONHOME = 'C:\Py311\'
PYTHONPATH = (not set)
program name = 'C:\Py311\PCbuild\amd64\instrumented\python.exe
Change by neonene :
--
nosy: +neonene
nosy_count: 6.0 -> 7.0
pull_requests: +28130
pull_request: https://github.com/python/cpython/pull/29906
___
Python tracker
<https://bugs.python.org/issu
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
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_fu
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 woul
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
neonene added the comment:
I still have the issue in current main and PR29565 with msvc2022 (v142 or v143
toolset).
--
___
Python tracker
<https://bugs.python.org/issue45
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) {
...
DISPA
neonene added the comment:
3.10.0 official binary is as slow as rc2.
Many files are not updated in the source archive or
b494f5935c92951e75597bfe1c8b1f3112fec270, so I'm not sure if the delay is
intentional or not.
We have no choice except waiting for 3.10.1
neonene added the comment:
PR28475 is not in the official source archive.
https://www.python.org/ftp/python/3.10.0/Python-3.10.0.tar.xz
I'll check later whether official binary has the fix.
--
___
Python tracker
<https://bugs.python.
neonene added the comment:
_PyEval_EvalFrameDefault() may also need to be divided.
--
___
Python tracker
<https://bugs.python.org/issue45116>
___
___
Python-bug
neonene added the comment:
@pablogsal
I'm OK with more effective fixes in 3.10.1 and later.
Thanks all, thanks kj and malin for many help.
--
___
Python tracker
<https://bugs.python.org/issue45
neonene added the comment:
I submitted 2 drafts in a hurry. Sorry for short explanations.
I'll add more reports.
--
___
Python tracker
<https://bugs.python.org/issue45
Change by neonene :
--
pull_requests: +27001
pull_request: https://github.com/python/cpython/pull/28631
___
Python tracker
<https://bugs.python.org/issue45
Change by neonene :
--
pull_requests: +27000
pull_request: https://github.com/python/cpython/pull/28630
___
Python tracker
<https://bugs.python.org/issue45
neonene added the comment:
I have another fix.
--
___
Python tracker
<https://bugs.python.org/issue45116>
___
___
Python-bugs-list mailing list
Unsubscribe:
neonene added the comment:
3.10rc2 Python/ceval.c
1306: #define DISPATCH() \
1307: { \
1308: if (trace_info.cframe.use_tracing OR_DTRACE_LINE OR_LLTRACE) { \
1309: goto tracing_dispatch; \
Among the 44 pgo-tests, only test_patma.TestTracing hits the condition above
neonene added the comment:
PR28475 PGO is 2% slower than the patch I pasted on msg401743.
The function sizes are almost the same (+1:goto,+1:label), and there is no
performance gap between release builds.
I suspect the following.
1. PGO is too sensitive to a function size at near the limit
neonene added the comment:
To be fair, the slowdowns between PR25244 and b1 seems to be an accumulation of
"1.00x slower" of every commit. I don't know after b1.
--
___
Python tracker
<https://bugs.python.o
neonene added the comment:
I built 3.10rc2 PGO with PR28475 applied, and posted the inliner's log.
In the log, the 4-callees mentioned above are now inlined, which were "hard
reject"ed before.
As for the performance, a few reporters may be needed, but it's not necessary
for th
neonene added the comment:
>release with the performance regression
I'm OK with the option. The limitation of PGO seems to me a bit weird and it
might be unexpected for MSVC team.
--
___
Python tracker
<https://bugs.python.org/issu
neonene added the comment:
> (32-bit: "1.07", 64-bit: "1.14": "higher the slower" wrote neonene)
32-bit and 64-bit are in reverse. I compared b1 and a7 because this can be
confirmed by anyone with official binary. If 7% of my patch has little to do
w
neonene added the comment:
I reported this issue to developercommunity of microsoft.
https://developercommunity.visualstudio.com/t/1531987
--
___
Python tracker
<https://bugs.python.org/issue45
neonene added the comment:
With msvc 16.10.3 and 16.11.2 (latest),
PR25244 told me the amount of code in _PyEval_EvalFrameDefault() is over the
limit of PGO.
In the old version of _PyEval_EvalFrameDefault (b98eba5), the same issue can be
caused adding any-code anywhere with more than 20
neonene added the comment:
According to:
https://docs.microsoft.com/en-us/cpp/build/profile-guided-optimizations?view=msvc-160
PGO seems to override /Ob3.
Around this issue, I posted benchmark on issue44381.
On python building, /Ob3 works for only non-pgo-supported dlls like,
_ctypes_test
Change by neonene :
Added file: https://bugs.python.org/file50276/x64_b98e.log
___
Python tracker
<https://bugs.python.org/issue45116>
___
___
Python-bugs-list mailin
Change by neonene :
Added file: https://bugs.python.org/file50275/x64_28d2.log
___
Python tracker
<https://bugs.python.org/issue45116>
___
___
Python-bugs-list mailin
Change by neonene :
Added file: https://bugs.python.org/file50274/pyproject_inlinestat.patch
___
Python tracker
<https://bugs.python.org/issue45116>
___
___
Python-bug
Change by neonene :
Added file: https://bugs.python.org/file50273/b98e-no-inline-in-the-others.diff
___
Python tracker
<https://bugs.python.org/issue45116>
___
___
Pytho
neonene added the comment:
Thanks for all suggestions. I focused on my bisected commit and the previous.
I run pyperformance with 4 functions never inlined in the sections below.
_Py_DECREF()
_Py_XDECREF()
_Py_IS_TYPE()
_Py_atomic_load_32bit_impl()
are
(1) never inlined
Change by neonene :
Added file: https://bugs.python.org/file50272/b98e-no-inline-in-eval.diff
___
Python tracker
<https://bugs.python.org/issue45116>
___
___
Python-bug
neonene added the comment:
@vstinner: __forceinline suggestion
Since PR25244 (mentioned above), it seems link.exe has got to get stuck on
python310.dll.
Before the PR, it took 10x~ longer to link than without __forceinline function.
I can confirm with _Py_DECREF() and _Py_XDECREF() and one
Change by neonene :
Added file: https://bugs.python.org/file50264/ceval_310rc1_patched.c
___
Python tracker
<https://bugs.python.org/issue45116>
___
___
Python-bug
New submission from neonene :
pyperformance on Windows shows some gap between 3.10a7 and 3.10b1.
The following are the ratios compared with 3.10a7 (the higher the slower).
-
Windows x64 | PGO release official-binary
neonene added the comment:
I'd like to leave my pyperformance (x64) results here.
cpython: ae5259171b8ef62165e061b9dea7ad645a5131a2 (2021-8-23)
1) release + CFG : 1.00x
2) release + CFG,/Ob3 : 1.05x faster | 41 faster
| 9 slower
neonene added the comment:
FYI, PR27727 ("Remove loop...") seems to be a bit slower than the previous
commit (f08e6d1bb3c5655f184af88c6793e90908bb6338) on my Windows build
(msvc14.29.16.10). pyperformance shows that
Windows x64 PGO: 34 slower, 11 faster, 13 not significant, Geom
neonene added the comment:
When building, some pull-requests invoke regeneration of test_frozenmain.h.
On PGO mode, MSVC tries to call instrumented python and stops with
"pgort140.dll not found" error.
Would it be OK to run python in externals fold
Change by neonene :
--
nosy: +neonene
nosy_count: 7.0 -> 8.0
pull_requests: +25688
pull_request: https://github.com/python/cpython/pull/27146
___
Python tracker
<https://bugs.python.org/issu
neonene added the comment:
To debug pure python, use embeddable pythons in different folders and copy Lib
folder from source archive instead of using python3.9.zip.
When using msvc (python3*.lib), I think it's enouth to install python as
follows or build from source.
1.Copy Installed
neonene added the comment:
After this contribution, when using module at the root dir (maybe bad manners),
the followings are expected behaviors?
(1) relative drive in sys.path -> bytecode is not put in __pycache__ folder.
>>> import sys
>>> sys.path.append('F:')
neonene added the comment:
For me, I confirmed no crash with PR 24279.
Thanks for the fix in no time.
--
___
Python tracker
<https://bugs.python.org/issue42
New submission from neonene :
On Windows, Python master crashes using f-string (which has an invalid char
with braces) on line 3 and after.
It seems the issue is from commit (e5fe509054183bed9aef42c92da8407d339e8af8).
I tried
1) exec("f'{.}'")
2) exec("\nf'{.}'&q
New submission from neonene :
After
https://github.com/python/cpython/commit/0b858cdd5d114f0890b11b6c4d6559d0ceb468ab
(bpo-1635741: Convert _multibytecodec to multi-phase init),
On Windows x64/x86 with chinese/japanese/korean system-locale,
MultibyteCodec_Check() in multibytecodec.c returns
neonene added the comment:
I applied PR 21961 to master and comfirmed no crash.
I'll close this issue. Thanks　for your quick reply.
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Change by neonene :
--
nosy: +pablogsal, vstinner -paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker
<https://bugs.python.org/issue41766>
___
___
New submission from neonene :
On Python3.10(64bit only) for Windows,
flake8 (with .pyc cache) frequently crashes after output.
e.g:
python -m flake8 c:/Python3/Lib/turtle.py
python -m pyflakes c:/Python3/Lib/turtle.py
I think I encountered the crash after PR21293 applied.
(bpo-41194
Change by neonene :
--
nosy: +christian.heimes -neonene
___
Python tracker
<https://bugs.python.org/issue40958>
___
___
Python-bugs-list mailing list
Unsub
neonene added the comment:
FYI, since PR 20875/20919, msvc(x64) has warned C4244 (conversion from
'Py_ssize_t' to 'int', possible loss of data).
parse.c especially gets more than 700.
--
nosy: +neonene -christian.heimes, miss-islington
___
Python
neonene added the comment:
On Windows, PyGILState_GetThisThreadState() returns NULL when ^C-interrupt
occurs. It is from TlsGetValue() winAPI and I don't think the os's behevior is
wrong.
In trip_signal(), crash can be avoided by skipping PyEval_SignalReceived() if
tstate is invalid
neonene added the comment:
I raised another PR(15632), which keeps the changes to a minimum.
I hope either PR would be in the 3.7.5 / 3.8.0 official.
--
___
Python tracker
<https://bugs.python.org/issue37
Change by neonene :
--
pull_requests: +15300
pull_request: https://github.com/python/cpython/pull/15632
___
Python tracker
<https://bugs.python.org/issue37
New submission from neonene :
Windows10/7(x86/x64)
After issue35941 (any PR merged)
In https-access, memory usage increases by about 200KB per urlopen()
and easily reach to giga bytes.
I found out leak of certificate-store-handles in _ssl.c and made patch,
which works fine for my pc.
I guess
neonene added the comment:
I meant 12609. (x86,x64 Py374rc1,Py380a4 and later)
And though I tried merging 12610 and Py374, memory usage still increases.
Sorry, I can't find out the cause.
--
___
Python tracker
<https://bugs.python.org/issue35
neonene added the comment:
issue35941
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
neonene added the comment:
After this patch applied, memory usage increases every https-access and is not
released in my Win7x64SP1.
I hope this will be fixed or reverted.
(case sample)
from urllib import request
from time import sleep
import gc
while True:
request.urlopen
New submission from neonene :
Python3.8.0a4,b1,b2(x64,x32)
Python3.7.4rc1,rc2 (x64,x32)
In Windows7 SP1(x64), memory usage keep increasing by the following code.
---
from urllib import request
from time import sleep
while True:
req = request.Request('https://www.python.org
85 matches
Mail list logo
