Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Thread-local limits for OpenBLAS with pthreads

Abierto
  • ¿Algo no está bien?
#220 4 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
python
Área
backend, performance

Línea de trabajo

Start by reading the issue’s discussion of OpenBLAS with pthreads and how threadpoolctl currently applies limits; the payload names no source files or tests. The proposed behavior is still undecided, including when to run inline or use all cores, so first establish the intended policy with maintainers. Done would mean an agreed policy and a defined way to verify thread limits across Python threads.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

The problem

OpenBLAS with pthreads is widely used: a billion downloads of NumPy from PyPI a month; 400 million for SciPy. Not all are Linux, but most are. Not all of them use BLAS, of course, but some do. It adds up!

The API limit for threads is process-wide. This is annoying, but not the worst part.

The worst part is that it has a process-wide shared pool. Consider a CPU with 32 cores, and a Python thread pool with 4 threads, each of which wants to do some OpenBLAS work. A user whose code needs to run with a variety of BLAS libraries (e.g. sklearn committer) sets a limit 32 // 4 == 8 cores. For many setups this is fine; for OpenBLAS with pthreads, it means 24 cores sit idle.

Potential solutions

  • Change this upstream in OpenBLAS.
  • Get PyPI packages to stop shipping pthreads version and instead use OpenMP version. So far all OpenMP libraries I've seen don't have process-wide shared thread pool, so this will make things better in most cases.
  • Turning https://github.com/itamarst/openblas-tod/ into a real project, and having its own thread-local-scoped limiting API.
  • Rethink scope limiting in threadpoolctl in this case.

To expand on the last point—

Maybe threadpoolctl should do something different for OpenBLAS with pthreads (or more broadly APIs affecting a process-wide thread pool)

A user might set three different settings:

  1. All cores. "All" means... all cores if it's a top-level process, or whatever share of cores were assigned to this process if it's a worker in a process pool.
  2. Run inline/sequentially, without a thread pool, typically set via 1 or 0.
  3. A number in between.

Typically the first case will be used when there are no Python threads, so it should be exactly the right number. The second case will be used when there is a Python thread per-core, so again exactly the right number.

The only problems occur, then, in the third case. As we saw in the example above, you may end up with a bunch of cores sitting idle. So maybe in the third case it's worth changing the user limit to something better.

To make this concrete, imagine 16 cores, and a Python thread pool that calls BLAS but also does other work, perhaps in a single thread, perhaps in additional thread pools (Python thread pools, OpenMP, etc, who can say...).

Python thread pool size Naive OpenBLAS limit Better OpenBLAS limit
2 8 All cores might be better, 16 instead of 8, but risks oversaturation
3 5 All cores might be better, 16 instead of 5, but risks oversaturation
4 4 All cores might be better, 16 instead of 4, but risks oversaturation
5 3 1 is somewhat better, since then it runs inline and uses 5 cores instead of 3. since it is inline there is no risk of oversaturation
6 2 or 3 1 is much better, since then it runs inline and uses 6 cores instead of 2 or 3. since it is inline there is no risk of oversaturation
7 2 1 is much better
8 2 1 is much better
9-16 1 1 is fine

With 64 cores:

Python thread pool size Naive OpenBLAS limit Better OpenBLAS limit
2 32 Maybe better unchanged? Depends if there are other nested thread pools
4 16 ?
8 8 ?
9 7 ?
10 6 1 might be better, depending on if there are other nested thread pools there are that might end up running in parallel to BLAS and thus utilizing more cores.
16-31 3 or 4 1 is vastly better. alternatively, all cores... maybe viable for smaller number of python threads?
32-63 2 1 is vastly better

Conclusions:

  • If you limit the number of BLAS threads below a certain threshold, you typically want to just set it to 1. E.g. if you set it to 2, better to just run inline. Will have to think about heuristic thresholds; one potential one is BLAS limit being lower than square root of available cores for the process, since that means parent Python thread pool has higher number of threads than the BLAS limit so running inline will use more cores.
  • There may be some cases where it's probably better to use all cores instead of the set limit?
Lenguaje dominante
Python
Estrellas
434
Forks
38
Merge medio
2 d 14 h
PR fusionados (30 d)
8

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de joblib/threadpoolctl

Todos los issues de joblib/threadpoolctl

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.