
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. * Macros: 361 sec +- 1 sec * Static inline functions: 361 sec +- 1 sec $ python3 -m pyperf compare_to pgo-lto_test_suite_macros.json pgo-lto_test_suite_static_inline.json Benchmark hidden because not significant (1): command I built Python with: $ ./configure --with-lto --enable-optimizations --prefix $PWD/install $ taskset --cpu-list 2,3,6,7 make $ make install And I ran the following benchmark, run the test suite 5 times using pyperf which pin the process to isolated CPUs: $ python3 -m pyperf command -p1 --warmups=0 --loops=1 --values=5 -v -o ../pgo-lto_test_suite_macros.json -- ./bin/python3.11 -m test -j5 I isolated 4 logical CPUs (2, 3, 6 and 7) on 8: physical CPU cores 2 and 3 (cores 0 and 1 are not isolated). -- Right now, I cannot use pyperformance: it fails to create a virtual environment because greenlet fails to build with Python 3.11. On speed.python.org, the benchmark are still running only because... pyperformance uses a cached binary wheel of greenlet. It looks dangerous to use a cached wheel, since the Python ABI (PyThreadState) changed! Help is welcomed to repair pyperformance: https://github.com/python/pyperformance/issues/113 Victor On Wed, Nov 24, 2021 at 12:27 AM Guido van Rossum <guido@python.org> wrote:
On Tue, Nov 23, 2021 at 3:15 PM Antoine Pitrou <antoine@python.org> wrote:
On Tue, 23 Nov 2021 18:00:28 +0100 Victor Stinner <vstinner@python.org> 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 -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TPUARSPZ... Code of Conduct: http://python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death.