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

[Jeroen Ooms]

On Sun, Dec 13, 2020 at 6:45 AM Prof Brian Ripley <ripley using stats.ox.ac.uk> wrote:
>
> 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.

Thank you for these fantastic efforts. I have added a binary for
libv8, so it works on arm64 now.

Re: the more general problem of external software, are there any
details available on how the external software on your server was
built/configured? For example I don't see libv8 on
https://github.com/R-macos/recipes or
https://mac.r-project.org/libs-arm/ so this makes it difficult for
package authors to debug a problem.

FWIW, Homebrew is quickly catching up on M1 support. Many people are
contributing patches, and François-Xavier Coudert (the same person who
is publishing the gfortran binaries) is publishing the homebrew arm64
binaries (aka bottles), hundreds over the past weekend:
https://github.com/Homebrew/homebrew-core/commits?author=fxcoudert

It is recommended to install homebrew on ARM in /opt/homebrew, and not
/usr/local, to prevent binaries from getting mixed up
(https://github.com/mikelxc/Workarounds-for-ARM-mac ). Using these
standard instructions, I was able to check many R packages that are
flagged on CRAN. For example:

    brew install --build-from-source libgit2

Will make it possible to install gert and git2r. And:

    brew install --build-from-source imagemagick using 6

Will work for 'magick' and:

    brew install protobuf

For protolite.

The main bottlenecks are libraries that depend (indirectly) on gcc
(fortran) or rust. FXCoudert is working on gcc, and for Rust, support
for apple-arm is available starting rust 1.49, which will be released
on Jan 1.