[Python-Dev] Re: Do we need to remove everything that's deprecated?

2021-11-23 Thread Petr Viktorin 

On 19. 11. 21 22:15, Mike Miller wrote:


This is the point where the pricey support contract comes in.  Would 
give options to those who need it and provide some revenue.


Not really; for a pricey support contract would need to freeze things 
for even longer -- *and* make it an actual contract :)



Changing working code just to make it continue to work with a newer 
Python version is boring. Companies might pay money to not have to do 
that. Or they might pay their employees to do the work. Either way it's 
money that could be spent on better things. (And hopefully, in some 
cases those things will be investing into Python and its ecosystem.)


But it's similar with volunteer authors and maintainers of various tools 
and libraries, who "pay" with their time that could be spent building 
something useful (or something fun). I believe that each time we force 
them to do pointless updates in their code, we sap some joy and 
enthusiasm from the ecosystem.
Of course, we need to balance that with the joy and enthusiasm (and yes, 
corporate money) that core devs pour into improving Python itself. But 
it's the users that we're making Python for.



Otherwise, the "there's no such thing as a free lunch," factor takes 
precedence.


That cuts both ways: deleting old ugly code is enjoyable, but it isn't 
free ;)




Full disclosure: I do work for Red Hat, which makes money on pricey 
support contracts. But Victor Stinner also works here.


This thread was motivated by watching rebuilds of Fedora packages with 
Python 3.11 (https://bugzilla.redhat.com/show_bug.cgi?id=2016048), and 
asking myself if all the work we're expecting people to do is worth it.



___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/DTORHHPWTK7DL35XTWOGD2SJE3EH5DBI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 670: Convert macros to functions in the Python C API

2021-11-23 Thread Victor Stinner 
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: 
https://github.com/python/peps/commit/570cea56c2fdb9f9b5873a0a83462816e641c52f

https://www.python.org/dev/peps/pep-0670/ will be updated soon.


>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 makes Python 1.04x
slower when the compiler **does not** inline static inline functions:
gcc -O0.

But developers using GCC and LLVM clang should get -Og when using
"./configure --with-pydebug".

(2) Python built with "gcc -O0" is 1.6x slower than Python built with "gcc -Og".

Well, don't use gcc -O0 if you care about performance :-)

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 between macros and static inline functions.


You can use my PR https://github.com/python/cpython/pull/29728 to run
your own benchmarks.

Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/THWYCMUEJHKHBQRP72OEUHTDFWYETV6P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 670: Convert macros to functions in the Python C API

2021-11-23 Thread Antoine Pitrou 
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 makes Python 1.04x
> slower when the compiler **does not** inline static inline functions:
> gcc -O0.

That is fine with me :-)

> 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 between macros and static inline functions.

That would actually be interesting, since there can be surprises
sometimes with compilers... (function inlining depends on heuristics,
for example, and there may be positive or negative interactions with
other optimizations)

Regards

Antoine.


___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/23YJMBAB4DQQJXY2XRB3ZDMBZU4GFCTD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 670: Convert macros to functions in the Python C API

2021-11-23 Thread Guido van Rossum 
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 between macros and static inline functions.
>
> That would actually be interesting, since there can be surprises
> sometimes with compilers... (function inlining depends on heuristics,
> for example, and there may be positive or negative interactions with
> other optimizations)
>

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
(and watch the Emery Berger video linked there if you haven't already).

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/TPUARSPZ7MLDHHWZKPO3FLMIEHMOM6SB/
Code of Conduct: http://python.org/psf/codeofconduct/