Reintroduce the feature of n_jobs (multi-thread)
See original GitHub issueMotivation
The feature of n_jobs (multi-thread) was deprecated in this PR because it is impractical in most use cases and can be reproduced by writing a few lines of code if users want to reproduce the same thing. However, some people on Twitter and 3 people on the PR wanted to reintroduce the feature. Based on the above, it is necessary to consider whether to reintroduce n_jobs (multi-thread) or not.
Description
We would like to make a consensus whether to reintroduce n_jobs (multi-thread) or not. If reintroducing it, we will restore the n_jobs (multi-thread) argument. If not, we will consider appropriate alternatives and develop a plan for them. Also, we will decide that Optuna’s data structures may continue to support multi-threading.
Consensus for the solution (Added on Dec 17, 2011)
From the following reasons, we decided that we will continue to support the feature of n_jobs
.
- We observed that more people wish to reintroduce this feature than people who claimed for misusing the feature.
- Also, this feature can be useful for tasks not blocked by GIL.
TODOs
- Make a consensus for the solution in this issue
- If reintroducing it,
- Remove deprecate decorator
- Provide enough information to avoid misuse of the feature e.g.
- API reference
- FAQ
- etc
- ~If not,~
- ~[ ] Create a plan to provide alternative solutions and documentation~
- ~[ ] Make a consensus for Optuna’s data structures~
Reference
Issue Analytics
- State:
- Created 2 years ago
- Comments:6 (5 by maintainers)
Maybe, nothitng.
I’m wondering if process-based (by multiprocessing module) would be an option as well. This is the code that is for Scikit-Learn integration, but it would great if
n_jobs
is supported again globally.https://github.com/tsuga/optuna/blob/55d809f16baf824a758a7e242d7e78484d3541e3/optuna/integration/sklearn.py#L890-L906