[R-SIG-Mac] CRAN package checks on M1 Mac

[Prof Brian Ripley]

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,                  ripley using stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford