Repository navigation
Potential performance regression with Python 3.14 bench_mp_pool on Linux #139881
Description
Activity
Maybe it's because we are changing the default start method? we switched from fork to forkserver on Linux in Python 3.14. Could you try to alter the benchmark and explicitly call
multiprocessing.set_start_method("fork")to see what happens? (I don't know where you should put that call though...)We don't see that much drop of performance on bench_mp_pool on the main branch:
@LamentXU123 That's not a comparison between 3.14 and 3.13.
Reacted by Weilin Du@picnixz I think you're right, 3.14 matches 3.13 after adding
multiprocessing.set_start_method("fork").btw, I'm running benchmarks on a small Ubuntu VM with a few cores, 3.14 is only a few times slower than 3.13.
Without
multiprocessing.set_start_method("fork"),+-------------------+---------+-----------------------+ | Benchmark | py313 | py314 | +===================+=========+=======================+ | bench_mp_pool | 15.6 ms | 43.1 ms: 2.77x slower | +-------------------+---------+-----------------------+With
multiprocessing.set_start_method("fork"),+-------------------+------------+-----------------------+ | Benchmark | py313_fork | py314_fork | +===================+============+=======================+ | bench_mp_pool | 16.6 ms | 16.3 ms: 1.02x faster | +-------------------+------------+-----------------------+Reacted by msmojtabafarTwo issues w/ forkserver, but it may be distinct from these:
- multiprocessing forkserver main contains dead main_path= handling code #126631 multiprocessing forkserver does not flush output before fork (was: preloading '__main__' with forkserver has been broken for a long time) #98552 (gh-126631: fix pre-loading of __main__ #135295)
- forkserver not reused in child processes #86354 (gh-86354: Fix child processes not reusing forkserver created by parent #139537)
The PR introducing the slowdown is #101556. But according to the python speed center python 3.15 will have a speedup again:
Reacted by Sergey MiryanovYeah, that's basically what @LamentXU123 has posted above #139881 (comment), but it got hidden. Looking what happened around that time in September it must have been #135295 (commit 0912b3a) that cured it. @thesamesam already mentioned the related issue #126631.
#137996 got closed as duplicate of this issue, so most probably this issue here can be closed as duplicate as well?
Since the associated PR got also backported to 3.14 #138607 (commit 64f0e2d) and thus will be part of 3.14.1.
And it was also backported to 3.13 #138609 (commit 9a6137a) and is part of 3.13.8 and 3.13.9. It had less effect on speed there, since, as mentioned above, the default start method on 3.13 is still
fork. I am quite confident, that 3.13 without that fix would show worse performance forforkserveras well?Reacted by Gregory P. Smith and Sam JamesThe default start method change was intentional and long planned. I don't think it is very useful for that benchmark to focus on the default start method. Explicitly benchmarking each one is a more interesting comparison.
Reacted by Sam Jamesanyways I agree that we can close this as (a) it was planned and (b) the bugfix for
__main__preloading being in 3.14.1 happens to make it happier.Reacted by Chris Eibl
Bug report
Bug description:
Hi team, I was running pyperformance and found that the
bench_mp_poolin 3.14 was way more slower than in 3.13.I uses pyperformance-1.11.0 installed from master branch and conda-forge Python builds, the system is Ubuntu 22.04.
I also tried it on another Ubuntu 22.04 box, it was better but still tens of times slower,
CPython versions tested on:
3.14
Operating systems tested on:
Linux