CPU overuse(?)

[HenrikBengtsson]

Hi,

while reverse-dependency checking parallelly and future, I noticed that several packages (e.g. DALEXtra, flashlight, mlr3cluster, and mlr3fselect) use looots of (all?) cores. I noticed that they all depend on mlr3. I know you're using parallelly::availableCores(), so I think it's something else. Maybe, it's unrelated to ml3r itself, and it's some of its dependencies that run lots of processes/threads (from a quick look, it looks like it's either threads or forked processes).

Have you looked at this when you run revdep checks? Could it some multi-threading that defaults to all hardware CPU cores?

[pat-s]

Hi Henrik,

DALEXtra and flashlight do not directly belong to the mlr3 ecosystem so I can't comment for these.

I've just run the tests of {mlr3fselect} sequentially to check the core usage and I did not see (extensive) multicore usage.
Is {mlr3fselect} definitely an issue or how can I best reproduce this?

By default everything runs sequentally by default in the mlr3 ecosystem AFAIK but @mllg surely has a better overview - maybe he even has a direct idea what might be causing what you describe.

Also adding @damirpolat (mlr3cluster maintainer) and @be-marc (mlr3fselect)

[HenrikBengtsson]

I check with revdepcheck. I ran:

$ git clone git@github.com:mlr-org/mlr3.git
$ cd mlr3
$ R --quiet
> res <- revdepcheck::revdep_check(quiet = FALSE, num_workers = 4L)

and tried to catch an example in the wild by monitoring htop. Here's one I just caught. Output from pstree --unicode --arguments --compact --long --show-pgids "$USER":

├─sh,234598 /software/c4/cbi/software/R-4.1.3-gcc8/lib64/R/bin/Rcmd check mlr3viz_0.5.8.tar.gz --no-manual --no-build-vignettes -o /c4/home/henrik/repositories/others/mlr3/revdep/checks/mlr3viz/old
│   └─R,234598 --no-restore --no-echo --args nextArgmlr3viz_0.5.8.tar.gznextArg--no-manualnextArg--no-build-vignettesnextArg-onextArg/c4/home/henrik/repositories/others/mlr3/revdep/checks/mlr3viz/old
│      └─sh,234598 -c LANGUAGE=en _R_CHECK_INTERNALS2_=1 '/software/c4/cbi/software/R-4.1.3-gcc8/lib64/R/bin/R' --vanilla  > 'mlr3viz-Ex.Rout' 2>&1 < 'mlr3viz-Ex.R'
│          └─R,234598 --vanilla
│             ├─{R},234598
│             ├─{R},234598
│             ├─{R},234598
│             ├─{R},234598
│             ├─{R},234598
│             ├─{R},234598
│             ├─{R},234598
│             ├─{R},234598
│             ├─{R},234598
│             ├─{R},234598
│             ├─{R},234598
│             ├─{R},234598
│             ├─{R},234598
│             ├─{R},234598
│             └─{R},234598

[pat-s]

I could reproduce the overuse when {mlr3fselect} was being checked even though my machine has 8 cores and I used only 4 within {revdepcheck}.

We don't have any explicit parallelization in the package. Neither in {mlr3} by default.

I suspect it might be because we are using {testthat} in parallel. I think {revdepcheck} might not account for it and just execute devtools::test() (within rcmdcheck::rcmd_check()) or similar on the package source which then executes the tests in parallel.

https://github.com/r-lib/revdepcheck/blob/main/R/check.R#L29-L32

Given that {revdepcheck} uses the CRAN source of the packages, we cannot easily patch this for local testing. And it might only really have an effect if tests in parallel take some seconds so they really consume so much CPU that it results in a particular overload.
Not sure if my assumption is right but it might be worth discussing this in {revdepcheck} to be better understand what is happening?