Following up on this -- on my system, I have 69 packages installed that appear to provide something like a confint() method:

h <-  help.search("confint", agrep = FALSE)
p <- sort(unique(h$matches$Package))
length(p)
## [1] 69

p

[1] "bamlss" "bbmle" "binom" "brglm2" [5] "broom" "caper" "car" "CDM" [9] "CLME" "coin" "crosstable" "dclone"
[13] "doBy"            "drc"             "Ecfun"           "emmeans"
[17] "epigrowthfit"    "evd"             "Exact"           "fitode"
[21] "fixest"          "ggfortify"       "ggplot2"         "GLMMadaptive"
[25] "glmmTMB"         "gratia"          "hdm"             "JMbayes"
[29] "JointAI"         "lava"            "lme4"            "lmeresampler"
[33] "lmtest"          "logistf"         "MASS"            "maxLik"
[37] "metafor"         "mitml"           "MKmisc"          "mmrm"
[41] "mosaic"          "MplusAutomation" "multcomp"        "ordinal"
[45] "papaja"          "parsnip"         "prodlim"         "R2admb"
[49] "rethinking"      "riskRegression"  "RSA"             "rstanarm"
[53] "rxode2"          "segmented"       "simr"            "sirt"
[57] "sn"              "spaMM"           "stats"           "stats4"
[61] "strucchange"     "survey"          "survival"        "systemfit"
[65] "TMB"             "unmarked"        "vegan"           "VGAM"
[69] "zipfR"

If a confint() method were actually included in the package test suite, I would expect this kind of problem to be caught by CRAN checks (which look for code that is being greedy with parallelization). But it's perfectly possible that a package maintainer neglected to include such tests ...


On 2024-05-21 6:00 a.m., Ivan Krylov via R-devel wrote:
В Tue, 21 May 2024 08:00:11 +0000
Dario Strbenac via R-devel <r-devel@r-project.org> пишет:

Would a less resource-intensive value, such as 1, be a safer default
CPU value for confint?

Which confint() method do you have in mind? There is at least four of
them by default in R, and many additional classes could make use of
stats:::confint.default by implementing vcov().

Also, there is no mention of such parallel processing in ?confint, so
it was not clear at first where to look for performance degradation.
It could at least be described in the manual page so that users would
know that export OPENBLAS_NUM_THREADS=1 is a solution.

There isn't much R can do about the behaviour of the BLAS, because
there is no standard interface to set the number of threads. Some BLASes
(like ATLAS) don't even offer it as a tunable number at all [*].

A system administrator could link the installation of R against
FlexiBLAS [**], provide safe defaults in the environment variables and
educate the users about its tunables [***], but that's a choice just
like it had been a choice to link R against a parallel variant of
OpenBLAS on a shared computer. This is described in R Installation and
Administration, section A.3.1 [****].


______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to