Brandt looked at coz for Python but it didn't seem to find anything useful
-- it singled out random lines in the code. :-(
On Wed, Nov 24, 2021 at 10:13 AM Terry Reedy wrote:
> On 11/23/2021 6:21 PM, Guido van Rossum wrote:
>
> > Thanks Antoine. We definitely need to push back on such
On 11/23/2021 6:21 PM, Guido van Rossum wrote:
Thanks Antoine. We definitely need to push back on such "expectations"
and turn them into facts by performing careful measurements. Surprises
lurk everywhere. See e.g.
https://github.com/faster-cpython/ideas/issues/109#issuecomment-975619113
I ran the Python test suite to compare macros versus static inline
functions (using PR 29728). I built Python with gcc -O3, LTO and PGO
optimizations.
=> There is *no* significant performance difference.
I understand that static inline functions are inlined by the C
compiler (GCC) as expected.
On 24. 11. 21 15:32, Victor Stinner wrote:
On Wed, Nov 24, 2021 at 2:18 PM Petr Viktorin wrote:
The "Backwards Compatibility" section is very small. Can you give a list
of macros which lost/will lose "return values"?
https://bugs.python.org/issue45476 lists many of them. See also:
On 24. 11. 21 15:22, Victor Stinner wrote:
On Wed, Nov 24, 2021 at 10:59 AM Petr Viktorin wrote:
Since this is about converting existing macros (and not writing new
ones), can you talk about which of the "macro pitfalls" apply to the
macros in CPython that were/will be changed?
The PEP
On Wed, Nov 24, 2021 at 2:18 PM Petr Viktorin wrote:
> >> The "Backwards Compatibility" section is very small. Can you give a list
> >> of macros which lost/will lose "return values"?
> >
> > https://bugs.python.org/issue45476 lists many of them. See also:
> >
On Wed, Nov 24, 2021 at 10:59 AM Petr Viktorin wrote:
> Since this is about converting existing macros (and not writing new
> ones), can you talk about which of the "macro pitfalls" apply to the
> macros in CPython that were/will be changed?
The PEP 670 lists many pitfalls affecting existing
On 24. 11. 21 13:20, Victor Stinner wrote:
On Wed, Nov 24, 2021 at 10:59 AM Petr Viktorin wrote:
Are there more macros that are yet to be converted to macros,
I suppose that you mean "to be converted to functions". Yes, there are
many, it's the purpose of the PEP.
I didn't provide a list.
On Wed, Nov 24, 2021 at 10:59 AM Petr Viktorin wrote:
> Are there more macros that are yet to be converted to macros,
I suppose that you mean "to be converted to functions". Yes, there are
many, it's the purpose of the PEP.
I didn't provide a list. I would prefer to do it on a case by case
On 23. 11. 21 18:00, Victor Stinner wrote:
I completed the PEP: https://python.github.io/peps/pep-0670/
What I don't like about this PEP is that it documents changes that were
already pushed, not planned ones. But, what's done is done...
Are there more macros that are yet to be converted to
On Tue, Nov 23, 2021 at 3:15 PM Antoine Pitrou wrote:
> On Tue, 23 Nov 2021 18:00:28 +0100
> Victor Stinner wrote:
>
> > I didn't run benchmarks on Python built in release mode, since gcc -O3
> > with LTO and PGO should inline all static inline functions and I don't
> > expect any difference
On Tue, 23 Nov 2021 18:00:28 +0100
Victor Stinner wrote:
>
> From what I understood, debug builds are mostly used by Python core
> developers to develop Python and so an important use case for
> performance is running the Python test suite.
>
> (1) Replacing macros with static inline functions
Hi Antoine,
I completed the PEP: https://python.github.io/peps/pep-0670/
* Add benchmarks on a Python debug build: (1) macros vs static inline
functions and (2) gcc -O0 vs gcc -Og
* Elaborate the Debug Build section
* Explain why the "keep macros" idea was rejected
Diff:
On Wed, 20 Oct 2021 02:55:52 +0200
Victor Stinner wrote:
>
> Debug build
> ---
>
> When Python is built in debug mode, most compiler optimizations are
> disabled. For example, Visual Studio disables inlining. Benchmarks must
> not be run on a Python debug build, only on release build:
Well, I discussed this issue hundreds of times with Victor Stinner.
I believe that this is what we have to go even if there is a very
little minor performance issue, it will be not a big hurdle.
we can see the benchmark from https://speed.python.org/ and CPython become
faster and faster.
On Wed, Oct 20, 2021 at 10:58 AM Petr Viktorin wrote:
> I think this info should be in the PEP.
Ok, we added (and completed) the list to the PEP:
https://www.python.org/dev/peps/pep-0670/#macros-converted-to-functions-since-python-3-8
> If the PEP is rejected, would all these previous changes
On 20. 10. 21 3:15, Victor Stinner wrote:
Extra info that I didn't put in the PEP to keep the PEP short.
Since Python 3.8, multiple macros have already been converted,
including Py_INCREF() and Py_TYPE() which are very commonly used and
so matter for Python performance.
Macros converted to
One of my motivation to write this PEP was decide how to solve the
issue: "[C API] Disallow using PyFloat_AS_DOUBLE() as l-value"
https://bugs.python.org/issue45476
I proposed two fixes:
* Convert macros to static inline functions:
https://github.com/python/cpython/pull/28961
* Fix the macro,
Extra info that I didn't put in the PEP to keep the PEP short.
Since Python 3.8, multiple macros have already been converted,
including Py_INCREF() and Py_TYPE() which are very commonly used and
so matter for Python performance.
Macros converted to static inline functions:
* Py_INCREF(),
19 matches
Mail list logo
