[R-pkg-devel] Too many cores used in examples (not caused by data.table)
Chapter 15 in Wickham and Bryan, R Packages, discuss "Advanced
Testing Techniques". Their current section "15.4.1 Skip a test" includes
the following:
test_that("some long-running thing works", {
skip_on_cran()
# test code that can potentially take "a while" to run
})
Have you tried writing directly to Jennifer Bryan
<jenny at rstudio.com>? She and Hadley might be able to get help from the
CRAN maintainers in getting help with this particular problem AND
getting more documentation on this in their book ;-)
hope this helps.
spencer graves
On 10/24/23 6:03 AM, Greg Hunt wrote:
In my case recently, after an hour or so?s messing about I disabled some tests and example executions to get rid of the offending times. I doubt that i am the only one to do that. On Tue, 24 Oct 2023 at 9:38 pm, Helske, Jouni <jouni.helske at jyu.fi> wrote:
Thanks for the help, I now tried resubmitting with
Sys.setenv("OMP_THREAD_LIMIT" = 2) at the top of the exchange example, but
I still get the same note:
Examples with CPU time > 2.5 times elapsed time
user system elapsed ratio
exchange 1.196 0.04 0.159 7.774
Not sure what to try next.
Best,
Jouni
________________________________
From: Ivan Krylov <krylov.r00t at gmail.com>
Sent: Friday, October 20, 2023 16:54
To: Helske, Jouni <jouni.helske at jyu.fi>
Cc: r-package-devel at r-project.org <r-package-devel at r-project.org>
Subject: Re: [R-pkg-devel] Too many cores used in examples (not caused by
data.table)
? Thu, 19 Oct 2023 05:57:54 +0000
"Helske, Jouni" <jouni.helske at jyu.fi> ?????:
But I just realised that bssm uses Armadillo via RcppArmadillo, which
uses OpenMP by default for some elementwise operations. So, I wonder
if that could be the culprit?
I wasn't able to reproduce the NOTE either, despite manually setting
the environment variable
_R_CHECK_EXAMPLE_TIMING_CPU_TO_ELAPSED_THRESHOLD=2 before running R CMD
check, but I think I can see the code using OpenMP. Here's what I did:
0. Temporarily lower the system protections against capturing
performance traces of potentially sensitive parts:
echo -1 | sudo tee /proc/sys/kernel/perf_event_paranoid
(Set it back to 3 after you're done.)
1. Run the following command with the development version of the
package installed:
env OPENBLAS_NUM_THREADS=1 \
perf record --call-graph drawf,4096 \
R -e 'library(bssm); system.time(replicate(100, example(exchange)))'
OPENBLAS_NUM_THREADS=1 will prevent OpenBLAS from spawning worker
threads if you have it installed. (A different BLAS may need different
environment variables.)
2. Run `perf report` and browse collected call stack information.
The call stacks are hard to navigate, but I think they are not pointing
towards Armadillo. At least, setting ARMA_OPENMP_THREADS=1 doesn't
help, but setting OMP_THREAD_LIMIT=1 does.
--
Best regards,
Ivan
[[alternative HTML version deleted]]
______________________________________________
R-package-devel at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[[alternative HTML version deleted]]
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel