search

python / cpython

The Python programming language
https://www.python.org
Other
62.7k stars 30.06k forks source link

`nogil` multi-threading is slower than multi-threading with gil for CPU bound #118749

Open Venkat2811 opened 4 months ago

Venkat2811 commented 4 months ago

Bug report

Bug description:

Hello Team,

Thanks for the great work so far and recent nogil efforts. I wanted to explore performance of asyncio with CPU-GPU bound multi-threading in nogil setup. So, started with simple benchmark as seen below:

import sys
from concurrent.futures import ThreadPoolExecutor
def fib(n):
    if n < 2: return 1
    return fib(n-1) + fib(n-2)

threads = 8
if len(sys.argv) > 1:
    threads = int(sys.argv[1])

with ThreadPoolExecutor(max_workers=threads) as executor:
    for _ in range(threads):
        executor.submit(lambda: print(fib(34)))

Original Source

Results:

$ time /usr/bin/python3.13 fib.py      
9227465
9227465
9227465
9227465
9227465
9227465
9227465
9227465
/usr/bin/python3.13 fib.py  6,46s user 0,04s system 100% cpu 6,447 total

So looks like there is overhead when using multiple cores. Is this expected with this version ? Are results similar with Intel & M1 CPUs as well ?

Results documented here in version 3.9.12 on Intel is better.

CPython versions tested on:

3.13

Operating systems tested on:

Linux

corona10 commented 4 months ago

FYI, the performance issue is not a surprise because we turned off the specialization, and deferred reference counting is not yet implemented for free-threading version.

But worth to checkout if there is unexpected bottleneck here.

colesbury commented 4 months ago

Please use 3.13 beta 1. There were a number of scaling bottlenecks fixed between 3.13 alpha 6 and beta 1 (https://github.com/python/cpython/issues/118527).

On my machine, I see a speedup in the free-threaded build vs. the default bulid (2.4s vs. 8.2s)

corona10 commented 4 months ago

out

With ed2b0fb04474725a38312784e1695a1cd7c0cce1 number of thread: os.cpu_count() task: fib(5)

Venkat2811 commented 4 months ago

Thanks for confirming that things have been fixed in beta1 @colesbury

I'm waiting for beta1 build to be available on deadsnakes. I tried building from source, but unfortunately after trying several --with-ssl solutions, still getting not found errors.

Venkat2811 commented 4 months ago

@colesbury I installed 3.13.0b1 via pyenv.

env PYTHON_CONFIGURE_OPTS='--disable-gil' pyenv install 3.13.0b1

Is this the way to create free-threaded build ?

On my M1 MBP: --disable-gil vs default build: 15.5s vs 5.26s

On my AMD Ryzen 7 5800X 8-Core Processor, Ubuntu: --disable-gil vs default build: 10.5s vs 6.4s

It has improved since 3.13.a06 for sure

stonebig commented 4 months ago

cpython-3.13.0b1 on Windows 11, for 20 threads, on a 4 cores/8 threads intel cpu: (faster is better)

FeldrinH commented 4 months ago

This is a slightly different benchmark, but there are some potentially useful data points about the speedup with free-threading here: https://github.com/winpython/winpython/issues/1339.

ArtemIsmagilov commented 2 months ago

CPython3.13-b3 without GIL is slower in 2x than with GIL.

System Ubuntu24. python3.13.b03-nogil was downloaded from apt.

The program actually works in multi-core mode with nogil.

I'm doing true concurrency testing for Python3.13.0b3. And according to my results, the result is deplorable. Let me know if I'm not testing multithreading correctly. What could be the problem with reduced productivity?

from array import array
from concurrent.futures import ThreadPoolExecutor
from time import time

array_size = 100_000
a = array('b', [0 for i in range(array_size)])

def write_by_index(array, indx):
    array[indx] = 1

start = time()
with ThreadPoolExecutor(max_workers=6) as executor:
    for index in range(array_size ):
        executor.submit(write_by_index, a, index)
end = time() - start
print(end)

My results.

python3.13 main.py 
>>>1.0930209159851074
python3.13-nogil main.py
>>>1.9819214344024658

Next test where array_size = 10_000_000

python3.13 main.py 
>>>117.05215215682983
python3.13-nogil main.py 
>>>211.70072531700134

PS.

There's a funny moment here. It seems I was using global data, which may have entailed locking overhead, mutexes, if I can judge correctly. I tried testing with local data with my scope. This is where I got a 3x performance increase without GIL.

from concurrent.futures import ThreadPoolExecutor
from time import time

array_size = 1_000_000
count_tasks = 100

def write_by_index(size):
    # some working with local data
    array = [0 for i in range(size)]
    return array

start = time()
with ThreadPoolExecutor(max_workers=6) as executor:
    for index in range(count_tasks):
        executor.submit(write_by_index, array_size)
end = time() - start
print(end)
time python3.13 main.py
>>>2.7294483184814453

real    0m2.782s
user    0m2.798s
sys 0m0.095s
time python3.13-nogil main.py
>>>1.062140703201294

real    0m1.154s
user    0m5.511s
sys 0m0.674s
ArtemIsmagilov commented 2 months ago

It looks like it really works, you just need to wait for stable versions. It is also necessary to know well what exactly is happening under the hood in order to use this feature and thus get the maximum benefit. issue pep