[issue38015] inline function generates slightly inefficient machine code

2019-09-17 Thread Greg Price
Greg Price added the comment: See followup at https://bugs.python.org/issue38205 and https://bugs.python.org/issue37812#msg352670 . The patch in GH-15710 had a side effect of introducing a call to `Py_UNREACHABLE` inside a comma-expression. A subsequent commit 3ab61473b changed

[issue38015] inline function generates slightly inefficient machine code

2019-09-09 Thread Ma Lin
Ma Lin added the comment: PR 15710 has been merged into the master, but the merge message is not shown here. Commit: https://github.com/python/cpython/commit/6b519985d23bd0f0bd072b5d5d5f2c60a81a19f2 Maybe this issue can be closed. -- resolution: -> fixed stage: patch review ->

[issue38015] inline function generates slightly inefficient machine code

2019-09-09 Thread Benjamin Peterson
Benjamin Peterson added the comment: I agree with msg351348. The performance wins are very context-dependent and even then very small. It's not worth further disturbing the small int code. So, we should close this issue out. -- nosy: +benjamin.peterson

[issue38015] inline function generates slightly inefficient machine code

2019-09-08 Thread Greg Price
Greg Price added the comment: (Just to help keep discussions together: some earlier discussion was on GH-15216 .) Because is_small_int / IS_SMALL_INT is so small, there's not much cost in the source code to making it a macro (as GH-15710 did). But I think it'd be a mistake to go a lot

[issue38015] inline function generates slightly inefficient machine code

2019-09-07 Thread Sergey Fedoseev
Sergey Fedoseev added the comment: I use GCC 9.2. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38015] inline function generates slightly inefficient machine code

2019-09-07 Thread Ma Lin
Ma Lin added the comment: > This change produces tiny, but measurable speed-up for handling small ints I didn't get measurable change, I run this command a dozen times and take the best result: D:\dev\cpython\PCbuild\amd64\python.exe -m pyperf timeit -s "from collections import deque;

[issue38015] inline function generates slightly inefficient machine code

2019-09-06 Thread Ma Lin
Ma Lin added the comment: This range has not been changed since "preallocated small integer pool" was introduced: #define NSMALLPOSINTS 257 #define NSMALLNEGINTS 5 The commit (Jan 2007): https://github.com/python/cpython/commit/ddefaf31b366ea84250fc5090837c2b764a04102 Is it worth

[issue38015] inline function generates slightly inefficient machine code

2019-09-06 Thread Sergey Fedoseev
Sergey Fedoseev added the comment: I added similar patch that replaces get_small_int() with macro version, since it also induces unnecessary casts and makes machine code less efficient. Example assembly can be checked at https://godbolt.org/z/1SjG3E. This change produces tiny, but

[issue38015] inline function generates slightly inefficient machine code

2019-09-06 Thread Sergey Fedoseev
Change by Sergey Fedoseev : -- pull_requests: +15372 pull_request: https://github.com/python/cpython/pull/15718 ___ Python tracker ___

[issue38015] inline function generates slightly inefficient machine code

2019-09-05 Thread Ma Lin
Ma Lin added the comment: Revert commit 5e63ab0 or use PR 15710, both are fine. -- ___ Python tracker ___ ___ Python-bugs-list

[issue38015] inline function generates slightly inefficient machine code

2019-09-05 Thread Ma Lin
Change by Ma Lin : -- keywords: +patch pull_requests: +15365 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15710 ___ Python tracker ___

[issue38015] inline function generates slightly inefficient machine code

2019-09-02 Thread Ma Lin
Ma Lin added the comment: There will always be a new commit, replacing with a macro version also looks good. I have no opinion, both are fine. -- ___ Python tracker ___

[issue38015] inline function generates slightly inefficient machine code

2019-09-02 Thread Raymond Hettinger
Raymond Hettinger added the comment: Do you see a way to salvage the commit? If not, I'm fine with reverting it. Its benefit was only aesthetic. -- assignee: -> rhettinger ___ Python tracker

[issue38015] inline function generates slightly inefficient machine code

2019-09-02 Thread Ma Lin
New submission from Ma Lin : Commit 5e63ab0 replaces macro with this inline function: static inline int is_small_int(long long ival) { return -NSMALLNEGINTS <= ival && ival < NSMALLPOSINTS; } (by default, NSMALLNEGINTS is 5, NSMALLPOSINTS is 257) However, when