Looks like there is a kind of misunderstanding... Le 10/01/2023 à 17:27, RICHET Yann a écrit : > Thank you for your answer. > In facts, 10 threads are asked by armadillo for some LinAlg, which backs to > two threads as warned. But I cannot imagine this costs so much time just for > that... Excessive thread number is a problem per se. I did not say that it was responsible for excessive test time. It's up to you to configure armadillo to use no more then 2 threads when run on CRAN. May be, setting environment variable OPENBLAS_NUM_THREADS=2 could help.
> > A deeper analysis of time spent seems to point that a large time was mainly > spent on testthat and Rcpp dependencies compilation... Normally, compilation time is not accounted in the quota of 15 min dedicated to tests. I would just focus on reducing this time, e.g. by running tests on smaller cases or skipping time-consuming tests conditionally when on CRAN. Serguei. > But other recent packages depending on these also are not spending so much > time. > > CRAN team, as I failed to reproduce the issue with rhub dockers, > - is there any reason that could explain that fedora-*-devel is so slow for > this package or compilation of Rcpp/testthat ? > - is our slapack a possible source of... anything ? > - are we the only package which embeds "standard armadillo" and tries to deal > with simple precision lapack issues on fedora ? > - is there any chance that I can get a deeper log of what happened ? > > Best regards, > > Yann > > -----Message d'origine----- > De : Serguei Sokol<so...@insa-toulouse.fr> > Envoyé : mardi 10 janvier 2023 11:41 > À : RICHET Yann<yann.ric...@irsn.fr>;R-devel@r-project.org > Cc : Pascal Havé<pas...@haveneer.com> > Objet : Re: [Rd] rhub vs. CRAN fedora-*-devel, using armadillo & slapack > > Le 10/01/2023 à 11:37, Serguei Sokol a écrit : >> Le 10/01/2023 à 10:44, RICHET Yann a écrit : >>> Dear R-devel people, >>> >>> We are working to submit a package which is mainly a binding over a >>> C++ lib (https://github.com/libKriging) using armadillo. >>> It is _not_ a standard RcppArmadillo package, because we also had to >>> provide a python binding... so there is a huge layer of cmake & >>> scripting to make it work with a standard armadillo (but using same >>> version that RcppArmadillo). >>> It seems now working with almost all CRAN targets, but a problem >>> remains with fedora (clang & gcc) devel. >>> >>> Our issue is that the rhub docker is not well sync with the CRAN >>> fedora-clang-devel config: >>> - failing on CRAN (without clear reason): >>> https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-c >>> lang/rlibkriging-00check.html >> I see 2 candidates for reasons of failing on CRAN: >> 1. test time is 30 min while 15 min are allowed; >> 2. your code try to get 30 threads > Oops, it was 10 threads not 30 but it does not change the nature of a > possible issue. > >> while CRAN limits them to 2; >> >> Try to make your tests shorter ( < 15 min) on 2 threads. May be it >> will help. >> >> Best, >> Serguei. >> >>> - passing on rhub: >>> https://builder.r-hub.io/status/rlibkriging_0.7-3.tar.gz-20f7dc756272 >>> 6497af7c678ab41f4dea >>> >>> So we cannot investigate and fix the problem. >>> >>> Note that we did quite strange things with the fedora platforms: >>> include explicitely slapack to provide simple precision for our >>> (vanilla) armadillo... >>> >>> Do you have any idea, or even known problem in mind, that could be >>> related to this ? >>> >>> Best regards, >>> >>> -- >>> Dr. Yann Richet >>> Institute for Radiological Protection and Nuclear Safety >>> (https://www.irsn.fr), >>> Department of Characterization of Natural Unexpected Events and >>> Sites Office : +33 1 58 35 88 84 >>> >>> ______________________________________________ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >> [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
