Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Set OPENBLAS_NUM_THREADS by default #7177

Merged
merged 1 commit into from
Oct 24, 2022

Conversation

jrbourbeau
Copy link
Member

In https://docs.dask.org/en/stable/array-best-practices.html#avoid-oversubscribing-threads we recommend setting

export OMP_NUM_THREADS=1
export MKL_NUM_THREADS=1
export OPENBLAS_NUM_THREADS=1

to avoid oversubscribing worker threads.

Today we set OMP_NUM_THREADS and MKL_NUM_THREADS by default (when using a nanny)

# Numpy configuration
OMP_NUM_THREADS: 1
MKL_NUM_THREADS: 1

So users get good defaults by default. Should we also set OPENBLAS_NUM_THREADS?

cc @crusaderky in case you have thoughts here

@github-actions
Copy link
Contributor

Unit Test Results

See test report for an extended history of previous test failures. This is useful for diagnosing flaky tests.

       15 files  ±0         15 suites  ±0   6h 23m 48s ⏱️ - 11m 3s
  3 153 tests ±0    3 060 ✔️  - 3    86 💤 +1    7 +2 
23 328 runs  ±0  22 391 ✔️  - 3  915 💤 +1  22 +2 

For more details on these failures, see this check.

Results for commit 07c1fb4. ± Comparison against base commit 8f25111.

@jrbourbeau jrbourbeau self-assigned this Oct 24, 2022
@crusaderky crusaderky merged commit 9148770 into dask:main Oct 24, 2022
@jrbourbeau jrbourbeau deleted the openblas-env branch October 24, 2022 23:25
fjetter added a commit that referenced this pull request Oct 23, 2023
In #5098 we set a malloc trim threshold by default to more aggressively control memory trimming.
also related #7177

At the same time, we included these default settings but didn't have incredibly solid arguments for it. It's been a long standing best practice when using dask to disable this nested parallelism.

We haven't received a lot of user feedback about this. However, we had some internal reports of users who were struggling with this because this was quite unexpected behavior for them and non-trivial to debug for the ordinary end user.

In apache/arrow#38389 (comment) this also suggests to negatively impact read performance of parquet tables.

We should consider removing this again
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants