R on 64-bit ARM Windows - The R Blog (2024)

R for Windows/aarch64 is distributed separately from the primarydistribution for x86_64 (64-bit Intel machines). There is a specialinstaller of R for Windows/aarch64. From the user perspective it is almostidentical to the installer for x86_64. Windows 11 is required by R onaarch64.

The R installer builds are expected to appear on CRAN pages, but for now canbe downloaded from a temporarylocation, currentlyincluding R 4.4 pre-release builds and daily builds of R-devel.

The installer is itself an x86_64 application, which runs onWindows/aarch64, emulated by the OS transparently to the user. Thedirectory layout is slightly different, because R “sub-architectures” arenot used. Hence, e.g.Rgui.exe is located directly in bin, while it isin bin/x64 on x86_64.

The installer can be built natively on Windows/aarch64 from R sources thesame way that an installer for x86_64 can be build on x86_64. Theinstallers provided via the URL above are cross-compiled on existing x86_64infrastructure: the native code is cross-compiled using Rtools44 onLinux/x86_64, the rest including the installer is built on Windows/x86_64.

R is by default installed to Program Files/R-aarch64 (unlike Program Files/R with an x86_64 build) and the default library directory is namedaarch64-library (unlike win-library with an x86_64 build). This is toallow side-by-side installation with the x86_64 build, which can run onWindows/aarch64 via emulation.

The x86_64 version, at the time of this writing, didn’t pass itsinstallation tests when running in the emulator due to numericaldifferences. The aarch64 did and in addition to that it is indeed expectedto have better performance and lower power consumption than running in theemulator.

Using R on Windows/aarch64 should be considered experimental, both thenative version and the emulated x86_64 version. The native support forWindows/aarch64 is still limited in R packages (more below): some packagesand external software still need to be adapted. R isn’t tested with CRANnor Bioconductor packages on Windows/aarch64, neither natively nor viax86_64 emulation. This is unlike x86_64, where regular and frequent testingof R packages by CRAN also indirectly tests R itself.

Building of R on Windows/aarch64 is documented in Howto: Building R 4.4and packages onWindows.

Rtools44 includes an installer for Windows/aarch64 and toolchain/librariestarballs (full, base, cross-compiler, Tcl/Tk bundle), mirroring the usualcomponents provided for Windows/x86_64. They are available fromCRAN.Later versions of Rtools43 already included unreleased temporary builds foraarch64 for testing with the development version of R, which were availablefrom a temporary location.

Rtools44 is based on LLVM 17 and has almost all the libraries provided inthe Intel version. It uses LLVM linker (lld), resource compiler and C++library (libc++) instead of binutils and libstdc++. LLVM is needed becauseGCC does not support Windows/aarch64.

The Rtools44 installer is an x86_64 application, which runs onWindows/aarch64 in the emulator. Rtools44 is installed by default tortools44-aarch64 (unlike rtools44 with an x86_64 build) as to allow thetwo installations to coexist on Windows/aarch64. Having an x86_64 versionmay be useful for package developers with aarch64 as their main platform.The R installer build will use the correct Rtools automatically: R foraarch64 installed via the installer would use Rtools for aarch64, R forx86_64 will use Rtools for x86_64.

Note that in a side-by-side installation of Rtools from the installers, onewould have even the Msys2 part of Rtools twice, because the Rtoolsapplications are fully independent. The Msys2 part of Rtools consists ofbuild tools, which are currently built for x86_64 and run in the emulator.As is the case since Rtools42, users can also install Rtools from atoolchain+libraries tarball and maintain a separate, single Msys2installation with the build tools for use with different versions of Rtoolstoolchain+libraries (say for x86_64 Rtools43, x86_64 Rtools44 and aarch64Rtools44).

At the time of this writing, CRAN does not distribute binary packages foraarch64. All packages have to be installed from source as they are on Linux.That is also the default when R is built on macOS from source (CRAN buildsof R use binary packages from CRAN).

This makes little difference for packages implemented solely in R: onlyinstallation takes slightly longer, because packages are byte-compiled andprepared for lazy loading. A binary package only has to be decompressed,which would typically be faster.

Users however now have to install Rtools whenever they need to install anypackage that “needs compilation” (so includes C, Fortran or C++ code).Installation of these packages will take much longer than when installingbinary versions. Still, it should not make the use any harder: Rtools canbe installed accepting the defaults, with no configuration necessary. Baseand recommended packages are already part of the R binary distribution, soone does not need Rtools for those. Parallel installation provides asignificant performance boost on multi-core systems.

Expect, though, that some packages will fail to install from source eitherbecause they need to be adapted or they require some external software notavailable yet for the platform.

In an ideal case, even packages needing compilation would not need anychanges: portable, standards-compliant C, Fortran and C++ code should justwork and in many cases, CRAN and Bioconductor packages just do. Also, CRANpackages are already tested with LLVM clang on macOS and Linux and with LLVMflang-new on Linux, so code accidentally making assumptions about theplatform/compiler should has mostly been detected. A number of GCC compilerextensions is supported by LLVM as well.

In an ideal case, packages carefully written to follow Writing RExtensions and theCRAN repositorypolicy in linking toexternal libraries should also work without changes even to the linking/makefiles, and many do. Such packages use libraries from Rtools (rather thandownloading pre-compiled versions), and the names of these libraries arealmost always the same as for x86_64. The names differ where R alreadyprovides macros (BLAS, LAPACK, OpenMP, Fortran runtime) abstracting out thedifferences. The macros are documented and recommended for use in Writing RExtensions, so portable packages have already been using those. Packagescan use pkg-config in Rtools, which should reduce the maintenance cost forpackage authors on Rtools updates, but it is not related to nor needed bythe aarch64 support.

In practice, it is easy to overlook some portability issues when testing ona single architecture - and some package code is Windows-specific, so onlygot tested with GCC and for Intel CPUs so far. Close to 100 patches havebeen provided to CRAN and Bioconductor package maintainers to fix theirpackages to build and pass checks on Windows/aarch64. Many of these wereeasy-to-fix issues of the kinds described above (C++ features removed fromcurrent/corresponding standards, GCC-specific compiler options, explicitlynaming OpenMP runtime used with GCC, naming conflicts due to using R headersbefore system headers, the C/C++ compilers being stricter than GCC andspotting issues hence not found before). Some of the cases required morework.

A long-lasting problem of the R ecosystem is R packages downloadingpre-compiled code (static libraries) at build time (R CMD INSTALL). Somepackages are doing this despite Rtools has the required libraries, some evenwhen Rtools has newer versions. On CRAN, this is not allowed (it is aviolation of the CRAN repository policy). Clearly, such code definitelywon’t work on aarch64 when pre-compiled for x86_64. Some of the providedpatches have been just emergency hot-fixes disabling the downloads onnon-Intel platforms and falling back to compilation from source or to usinglibraries from Rtools. The recommended way is to use libraries from Rtools,and if they are not there, provide build configurations via upstream MXE.

A number of packages don’t work on Windows/aarch64 because they link tolibraries provided by externally installed software, and such softwaresometimes isn’t yet readily available (ported or packaged). At the time ofthis writing, this includes important software like Java, MPI (Microsoft MPIdoesn’t support aarch64) and JAGS. This is likely to improve as theplatform becomes more popular, and indeed R is not alone, other open-sourceprojects are being adapted to support Windows/aarch64 as well.

This progress also sometimes drives the need to upgrade, some Rtoolslibraries had to be updated to newer versions that support Windows/aarch64.One case that will require cooperation from CRAN package authors is IntelTBB (Threading Building Blocks). It is part of Rtools (both x86_64 andaarch64), but a number of CRAN packages use an older version that isembedded in another CRAN package. That older version, however, cannot bebuilt for Windows/aarch64. The new version made several breaking changes inthe API and packages will have to be updated.

Another case was MinGW-W64: the experimentally built Rtools43 versions foraarch64 conditionally used a newer version of MinGW-W64 to avoid some issueson aarch64, but this required debugging and fixing naming conflicts inpackages. These conflicts would have had to be fixed regardless of aarch64.Rtools44 now uses the newer version of MinGW-W64 on both platforms.

Luckily it is extremely uncommon for CRAN and Bioconductor R packages toinclude (and unconditionally use) Intel assembly code. Such cases shouldhave an automatic fallback to portable C code for platforms that are notsupported. A number of Rtools libraries themselves are built for aarch64thanks to opting-out from hand-written assembly code, not available foraarch64.

Some CRAN packages cannot be compiled for Windows/aarch64 because oflimitations of the flang-new compiler from LLVM.

There are no powerful 64-bit ARM laptops to run Windows natively, but inOctober 2023, Qualcomm announced their new 64-bit ARM “Snapdragon Elite X”platform with integrated “Oryon”, with an expectation of PCs to be availablein mid-2024. The company is to provide a further statement on April 24 (theday when R 4.4 is to be released). It is not hard to find articlesspeculating about upcoming systems based on this platform. It is not hardto find benchmark results measured on test systems against Apple M3,generally claiming comparable performance, so there seems to be someprogress.

64-bit ARM processors for server systems have been available for 3 years(Ampere Altra from Ampere Computing). One can also buydeveloper/prototyping workstations based on these processors (AADP). Still,while there is some server hardware available to run Windows on ARM,Microsoft has not, yet, released a Windows server OS. Currently, one wouldhave to use Windows 11 (and probably figure out how to do that in line withthe license in case of a server system).

R package developers who work on Apple Silicon machines can already testtheir packages on Windows 11 running in UTM/QEMU (or Parallels). Suchdevelopers probably want to test and debug their packages on Windows, andusing the aarch64 version of Windows on their machines would be natural (theOS emulator, at the time of this writing, doesn’t support full virtualmachines, and, running natively would be preferred, anyway). Regular macOSR users would naturally run R natively on macOS, but if for some reason theywere forced to use Windows, it would again be Windows on aarch64.

It is common and necessary that software for new platforms is developedbefore the platforms actually become generally available, because, thedevelopment simply takes too long. This is why this work on R and Rtoolshas been started as soon as compilers for the platform became available,particularly when the LLVM flang-new compiler became stable enough to buildbase R and recommended packages. R is not alone, there is clearly an effortto make open-source software support Windows/aarch64, e.g.there is alreadyPython for the platform.

R for Windows/aarch64 and Rtools is now stable enough to allow fordevelopment/porting of R packages to the platform and this is what needs tohappen if R should be a viable option also on this platform. Most of thefixes would entail making the packages more portable andstandards-compliant, which is a good thing on its own and would simplifymaintenance and potential support for other future platforms or compilers.This is particularly important for maintainers of packages with a largenumber of reverse dependencies.

The easiest way of testing packages for Windows/aarch64 is probably still torun Windows 11 in a virtual machine on Apple Silicon hardware. This is evenrecommended by Microsoft, it is documented to work in Parallels and QEMU(UTM). The work on R/Rtools has been done via UTM/QEMU. Using Windowsnatively this way should be easy for R package developers: the OS and Rworks almost identically to what they have been used for. Performance iscomparable to doing similar work natively on an Intel laptop.

An indirect alternative to cover some cases, but more technically involved,is to use Rtools44 cross-compilers to test compilation on Linux/x86_64.This will only work for packages with a simple installation process, but theapproach has been used before when looking for issues in code detected byLTO. The cross-compilers in Rtools themselves should be sufficiently tested,because Rtools libraries themselves are cross-compiled. Also now Rinstallers for aarch64 are cross-compiled, even though minimally tested.However, the limitation is in R packages that were not designed forcross-compilation. Also, this would only test compilation of native code.

The aarch64 support has been partially integrated into the infrastructureused for testing development versions of Rtools (“ucrt3”) and package buildoutputs from this areavailable for CRAN andsome Bioconductor packages. These tests patch packages using patchesavailable also at that site, which have been provided to package maintainersand will be removed from the site as they are incorporated into packages.The installation tests are only ran occasionally and may be well behind thecurrent CRAN source package repository.

At the time of this writing, there is no GitHub Actions runner support forWindows/aarch64, which can be trackedhere.