We have managed a fairly complete check run with natively-compiled R and
packages, and a full one with x86_64 R and packages running under
Rosetta (mainly using CRAN binary distributions).
The bottom line is that running under Rosetta works really well.
Although relative speeds vary widely, using the native build was
1.3-1.5x faster for the central 50% of the distribution. And a MacBook
Air is remarkably capable for a lightweight laptop.
x86_64 tests
------------
I compared the check output to that from my 2012 iMac: typically this
was 1.7x faster than the iMac (and benchmarks have current iMac/MacMini
about that much faster than mine).
A couple of packages ran much slower than on the iMac and hit their
check limits, and one fails because it checks elapsed time (and was
slower than on the iMac).
10 packages segfaulted in their checks (but most of those are known to
segfault intermittently on other platforms).
There were issues with packages attempting to work with Python, which
may be Big Sur differences.
Given that I have 58 packages failing their checks on the iMac under
High Sierra this was a very small amount of degradation.
native tests
------------
Currently I have 57 CRAN packages failing to install, but 650 others
require those or BioC packages which fail to install (the most commonly
required being rgl and V8 [*]). And ca 120 packages are not using
conditionally Suggests packages which fail to install.
There are segfaults from ca 150 packages using minpack.lm::nls.lm,
deSolve::lsoda, rootSolve::stode ... all of which use Fortran.
That platform does not have long doubles nor extended precision but the
CRAN checking on Linux and Sparc with --disable-long-doubles has paid
off: only a handful of check results show numerical differences.
Quite a lot of external software and several packages have had to be
patched, and it is early days for the former (and the Fortran compiler)
- for example I was able to build v8, but V8 segfaulted in its checks.
Currently ca 400 packages which install fail their checks.
Note that all these checks were done with enough parallelism to have the
machine 80-90% loaded, which it managed for days at a time without even
getting warm. However (not just on this machine) running multiple tasks
in parallel takes more CPU time for each. To illustrate that, I re-ran
the native Matrix check on its own: the CPU time decreased from 185s to
120s.
[*] But many of the packages requiring them to install do not actually
use them in their checks so fake installs would do. The results
reported here were without fake installs.
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford
_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
