- Why is there only the rpart learner?
- How can I use parallelization?
- Why is the parallelization with the future package slow?
- Why is the parallelization of tuning slow?
- Why are the CPUs on my system not fully utilized when using parallelization?
- How can I use time constraints when tuning?
- Why is method X slower when used via
mlr3?
Why is there only the rpart learner?
The base package mlr3 ships only with regression and classification trees from the rpart package and some learners for debugging. A selection of popular learners can be found in the extension package mlr3learners. Survival learners are provided by mlr3proba, cluster learners via mlr3cluster. Additional learners can be found in the extension packages mlr3extralearners. If your favorite learner is missing, please open a learner request. An overview of all learners can be found on our website.
How can I use parallelization?
Parallelization is supported when training learners, resampling, tuning and predicting. We recommend reading the section about Parallelization in the mlr3book.
Why is the parallelization with the future package slow?
Starting and terminating workers as well as possible communication between workers comes at a price in the form of additionally required runtime which is called parallelization overhead. This overhead strongly varies between parallelization backends and must be carefully weighed against the runtime of the sequential execution to determine if parallelization is worth the effort. When resampling or tuning a fast-fitting learner, it helps to chunk multiple resampling iterations into a single computational job. The option mlr3.exec_chunk_bins determines the number of chunks to split the resampling iterations into. For example, when running a benchmark with 100 resampling iterations, options("mlr3.exec_chunk_bins" = 4) creates 4 computational jobs with 25 resampling iterations each. This reduces the parallelization overhead and speeds up the execution.
Why is the parallelization of tuning slow?
Tuning can also suffer from the parallelization overhead described above. Additionally, the batch size of the tuner can have a large impact on the runtime. Setting an optimal batch size is explained in the section Parallelization of Tuning of the mlr3book.
Why are the CPUs on my system not fully utilized when using parallelization?
If there are few jobs with dissimilar runtimes, the system may end up waiting for the last chunk to finish, while other resources are idle. This is referred to as synchronization overhead. When minimizing the synchronization overhead, a too large chunk size can lead to a situation where the last chunk takes much longer than the others. This can be avoided by setting mlr3.exec_chunk_bins to a smaller value than the number of cores available on the system.
How can I use time constraints when tuning?
Time constraints can be set for individual learners, tuning processes, and nested resampling. The gallery post Time constraints in the mlr3 ecosystem provides an overview of the different options.
Why is method X slower when used via mlr3?
By default, we set the number of threads of learners to 1 to avoid conflicts with parallelization. Therefore, the default configuration of a learner may be significantly slower than the default configuration of the method when used directly.