[Rd] rhub vs. CRAN fedora-*-devel, using armadillo & slapack

Serguei Sokol @oko| @end|ng |rom |n@@-tou|ou@e@|r
Tue Jan 10 18:10:12 CET 2023


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<sokol using insa-toulouse.fr>  
> Envoyé : mardi 10 janvier 2023 11:41
> À : RICHET Yann<yann.richet using irsn.fr>;R-devel using r-project.org
> Cc : Pascal Havé<pascal using 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 using r-project.org  mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>

	[[alternative HTML version deleted]]



More information about the R-devel mailing list