On Sun, Dec 13, 2020 at 6:45 AM Prof Brian Ripley <rip...@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@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. _______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
