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

Use available cores count as default threads number #926

Closed
wants to merge 1 commit into from

Conversation

jbd
Copy link

@jbd jbd commented Jan 7, 2025

Use only Util::omp_thread_count() to get the number of accessible cores to the process and its children.

sysconf(_SC_NPROCESSORS_ONLN) gets the hardware core count that could be different if mmseqs2 is running within a constrained environmenet (taskset, cgroups, slurm...).

Resolve #925

Use only Util::omp_thread_count() to get the number of accessible cores to the process and its children.

sysconf(_SC_NPROCESSORS_ONLN) gets the hardware core count that could be different if mmseqs2 is running within a constrained environmenet (taskset, cgroups, slurm...).

Resolve soedinglab#925
@milot-mirdita
Copy link
Member

I liked the suggestion to use affinity explicitly better, since triggering the count loop with openmp will actually start the threads and introduce some latency.

Additional latency is an issue for our webserver uses of mmseqs and foldseek

@jbd
Copy link
Author

jbd commented Jan 10, 2025

It makes sense, I'll close this PR.

@jbd jbd closed this Jan 10, 2025
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.

Default threads number value should use sched_getaffinity
2 participants