numba.prange pinning CPU to 100% seemingly for no reason when function is called repeatedly in a loop

[mohammed5920]

Reporting a bug

• [✅] I have tried using the latest released version of Numba (most recent is visible in the release notes (https://numba.readthedocs.io/en/stable/release-notes-overview.html).
• [✅] I have included a self contained code sample to reproduce the problem. i.e. it's possible to run as 'python bug.py'.

i'm writing a program that draws video to the screen that the user can interact with, the core draw loop of the program uses numba to accelerate the iteration over all of the pixels - however, numba seems to waste cpu for no reason after the function is already done

code example:

import numba
import numpy as np
import time
from tqdm import tqdm #not related to the bug

@numba.jit(nopython=True, parallel=True)
def waste(image):
    result = np.zeros_like(image)
    for y in numba.prange(image.shape[0]):
        for x in range(image.shape[1]):
            result[y,x] = image[y,x]
    return result

def main():
    image = np.array([[[np.random.randint(0, 255) for colour in range(3)] for x in range(1440)] for y in tqdm(range(1080))]).astype(np.uint8)
    while True:
        start = time.perf_counter()
        waste(image)
        print(f"function took {(time.perf_counter() - start)*1000:.2f} milliseconds") 
        time.sleep(0.1)

if __name__ == "__main__":
    main()

the simple act of copying bytes from one array to the other takes 1.6ms on my ryzen 5600, which means over 90% of the loop is spent sleeping not doing any work. however, cpu usage will still be at 100% leading to high temperatures for seemingly no reason.

i think maybe it's spawning some threads that stay alive in some sort of busy loop even after the function returns? i'm honestly not quite sure - but this exact same code does not reproduce the same wasteful CPU usage on Linux, so i'm convinced it's not intended behaviour

[wuaogsueigwuan]

I meet the same question, cpu busy with this.

[wuaogsueigwuan]

I solve this question by use version: 0.57.0

[mohammed5920]

issue goes away when specifically setting numba.config.THREADING_LAYER = "workqueue"

[sklam]

The script is measuring compile-time, and dispatch overhead. Numba is best used with a function with a lot of compute work for optimal trade off between overhead and runtime.

What is the other platform beside Linux that the code is measured on. The observed difference can also be an artifact of different granularity of the profiling/monitoring tool.

Regarding thread staying alive, that is the effect for certain threading backend (e.g. OpenMP or TBB) maintaining a threadpool.