-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Reintroduce the feature of n_jobs (multi-thread) #2937
Comments
I'm wondering if process-based (by multiprocessing module) would be an option as well. |
Update the description. |
@keisuke-umezawa What other documentation needs to be enhanced besides the API reference and FAQ? (The |
Maybe, nothitng. |
Let me close this issue since all tasks have done. Please feel free to reopen if you have any problems. |
Motivation
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
.TODOs
If not,[ ] Create a plan to provide alternative solutions and documentation[ ] Make a consensus for Optuna's data structuresReference
The text was updated successfully, but these errors were encountered: