[Rd] confint Attempts to Use All Server CPUs by Default
Ben Bolker
bbo|ker @end|ng |rom gm@||@com
Thu May 23 00:45:30 CEST 2024
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 using 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 [****].
>
More information about the R-devel
mailing list