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

Auto multithreaded build limiting #270

Open
henryiii opened this issue Dec 2, 2019 · 2 comments
Open

Auto multithreaded build limiting #270

henryiii opened this issue Dec 2, 2019 · 2 comments
Labels
enhancement New feature or request

Comments

@henryiii
Copy link
Member

henryiii commented Dec 2, 2019

If NPY_NUM_BUILD_JOBS is unset, we could try to estimate the total memory and limit the number of jobs to 1 if it might fail multithreaded.

@henryiii henryiii changed the title Auto multithreaded builds Auto multithreaded build limiting Dec 2, 2019
@henryiii henryiii added this to the 0.7.0 milestone Dec 13, 2019
@henryiii henryiii modified the milestones: 0.7.0, 1.0.0 Mar 11, 2020
@henryiii henryiii added the enhancement New feature or request label Mar 11, 2020
@LovelyBuggies
Copy link
Collaborator

If threads are unset, shouldn't it be 1 by default? I think you are worried about the insufficient memory issue. If so, resetting jobs to 1 might not be the best solution.

We can get the available system memory using psutil. But how could we estimate the memory we will use in those threads (and it varies in different systems, doesn't it)? Plus, it's unreasonable to reset h.fill(vals, threads=64) to h.fill(vals, threads=1) once you realize this might cause memory problem. It might be okay for threads=32 or 16, and hence saving time.

I think maybe a good way is to monitor the total memory usage, and exit/kill some threads when it reaches the warning line.

@henryiii
Copy link
Member Author

henryiii commented Sep 4, 2020

Sorry for missing this - the issue is building, not histogramming. pip install boost-histogram is very slow if you need to build and you don't multithread by default. You can roughly guess how much memory a system has available or total (via psutil), divide that by roughly the amount you think it takes to build per thread (probably varies a bit per system, but is on order 1-2GB), then limit the automatic selection threads via that. That's the idea, anyway,.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants