Support major Linux distros on arm64 hardware

[znmeb]

I'm in the process of porting the open source version of RStudio Server 1.4 to NVIDIA Jetsons, which are arm64 CPUs with attached NVIDIA GPUs. The OS is Ubuntu 18.04 LTS "Bionic Beaver" with some extra repositories for the NVIDIA packages.

What I've discovered is that there are a few places where the build breaks because arm64 binaries aren't readily available. The most glaring example is pandoc. I'm building that from source, which is an overnight process on an eight-core developer kit with 16 GB of RAM and won't even run on a four-core 4 GB developer kit.

I have the steps worked out for Ubuntu 18.04; I haven't tried it on other distros but the process is fully Dockerized and should work with any distro that has an arm64 base image. It does not require any NVIDIA hardware or software; that's just what I have available. And I haven't been able to find a CI/CD platform with the hardware required to automate all of this.

[ronblum]

@znmeb Thank you for the request! I'll mark it for review as part of our ongoing development of RStudio Server.

[jmcphers]

See also adjacent issue #8652 which tracks adding arm64 support for Apple silicon.

[znmeb]

See also adjacent issue #8652 which tracks adding arm64 support for Apple silicon.

Is the new Apple silicon significantly more powerful than an equivalent priced x86-64? My Xavier has 8 2.26 GHz cores and the pandoc build takes several hours, mostly single-threaded. If I could afford it I'd move to an AWS Graviton CI/CD platform.

If you want to look over my shoulder, the hacks to the install scripts are all here: https://github.com/edgyR/edgyR-containers/tree/rstudio-1.4/build-scripts/internal-ubuntu-builder/dependencies. That will be moving into the main branch in about a week.

[elbamos]

@znmeb This is off-topic, but you may encounter issues with GHC compiling pandoc on arm64. See Homebrew/homebrew-core#65997 (comment) for discussion.

And to answer your question, yes, the Apple silicon is significantly more powerful than x86. On my cheap laptop, x86 applications run as fast under emulation as they do on a state-of-the-art laptop from six months ago. For native applications, the jump in performance reminds me of the jumps we got used to getting every 18 months in the 90s. The jump is larger for things like Apple's build of tensorflow that have been optimized for the chips.

With R, benchmarks are dramatically improved for everything except some matrix operations, which I assume is because they don't take advantage of a natively-optimized BLAS.

[znmeb]

@znmeb This is off-topic, but you may encounter issues with GHC compiling pandoc on arm64. See Homebrew/homebrew-core#65997 (comment) for discussion.

It's not off-topic as long as the Pandoc team doesn't provide binaries for arm64 and we're talking about porting RStudio. :-)

I'll take a look at that - the GHC in Bionic is 8.0; I tried a few more recent ones and they were better but they take time to recompile themselves.

And to answer your question, yes, the Apple silicon is significantly more powerful than x86. On my cheap laptop, x86 applications run as fast under emulation as they do on a state-of-the-art laptop from six months ago. For native applications, the jump in performance reminds me of the jumps we got used to getting every 18 months in the 90s. The jump is larger for things like Apple's build of tensorflow that have been optimized for the chips.

With R, benchmarks are dramatically improved for everything except some matrix operations, which I assume is because they don't take advantage of a natively-optimized BLAS.

Hmmm ... I'm still using the BLAS in R source. At some point I'll get around to experimenting with other ones.

[elbamos]

@znmeb The BLAS issue is that the M1 processor has "tensor cores" for accelerating matrix operations, as well as its own extended instruction set for vectorized operations. I believe the R built-in BLAS includes optimizations that take advantage of the x86 extended instruction set, and in any case it was easily replaced by native BLAS that did.

[znmeb]

@znmeb The BLAS issue is that the M1 processor has "tensor cores" for accelerating matrix operations, as well as its own extended instruction set for vectorized operations. I believe the R built-in BLAS includes optimizations that take advantage of the x86 extended instruction set, and in any case it was easily replaced by native BLAS that did.

I'd have to go look at the code but my recollection is that the optimizations for R's included BLAS were done with the compiler, which for Fortran is probably gcc. It does sound like it's worth picking up a Mac Mini once it's supported by Ubuntu for dual-booting.

[elbamos]

@znmeb Have you made any progress? A (perhaps dockerized) rstudio server build for arm would be a good interim step for those of us with M1s. I looked through your repositories but couldn't find the Dockerfile to build rstudio server on arm.

[znmeb]

Sorry - I got caught up in a new project. I'm going to push out the release documentation as soon as possible, but here are the Docker contexts:

1. Pandoc 2.11.2: https://github.com/edgyR/edgyR-containers/tree/main/build-scripts/internal-pandoc. This runs off the Ubuntu arm64 image, i.e., no NVIDIA dependencies. It takes a long time to build and uses a lot of RAM.
2. R, RStudio Server 1.4, and the libnode-dev package that the R V8 package requires: https://github.com/edgyR/edgyR-containers/tree/main/build-scripts/internal-ubuntu-builder. This builds on the first image and also has no NVIDIA dependencies.
3. The edgyR image: https://github.com/edgyR/edgyR-containers/tree/main/build-scripts/edgyr. This is the end-user image, which only runs on an NVIDIA Jetson. There are some things on there you might want on an Apple Silicon Mac, like MiniForge (https://github.com/conda-forge/miniforge) and Julia.

[elbamos]

I built a working docker based on @znmeb 's work and the Rocker scripts. I was able to get the size down to 1.8GB, which is still too big, but workable I guess: https://hub.docker.com/r/amoselb/rstudio-m1

[znmeb]

I built a working docker based on @znmeb 's work and the Rocker scripts. I was able to get the size down to 1.8GB, which is still too big, but workable I guess: https://hub.docker.com/r/amoselb/rstudio-m1

For what platform? And how does your Docker build differ from what ships with the RStudio source tree?

The Apple Silicon users should probably also open an issue for native binary builds on https://github.com/jgm/pandoc. That's a lengthy compile and uses a bunch of RAM and is mostly single-threaded.

[elbamos]

For what platform? And how does your Docker build differ from what ships with the RStudio source tree?

It runs R and RStudio Server with native ARM code rather than rosetta2 emulation. The performance difference is noticeable and significant.

The Apple Silicon users should probably also open an issue for native binary builds on https://github.com/jgm/pandoc. That's a lengthy compile and uses a bunch of RAM and is mostly single-threaded.

I linked you above to the discussion taking place among the homebrew and ghc folks regarding this. The issue has to do with the ghc compiler not supporting apple silicon yet. Once ghc supports apple silicon, binary distributions of pandoc will become available quickly.

[znmeb]

I linked you above to the discussion taking place among the homebrew and ghc folks regarding this. The issue has to do with the ghc compiler not supporting apple silicon yet. Once ghc supports apple silicon, binary distributions of pandoc will become available quickly.

How much difference is there between Apple Silicon as a compile target and the arm64 target GHC already uses? In other words, is this a technical issue or a marketing one? :-)

[elbamos]

How much difference is there between Apple Silicon as a compile target and the arm64 target GHC already uses? In other words, is this a technical issue or a marketing one? :-)

I'm not a Haskell person. I really have no idea, except I periodically check into that link to see if they've made any progress. Given that there are multiple people working on it who seem quite intelligent and diligent, I trust that the technical issues they describe in that thread are legitimate.

[storopoli]

pandoc is ALMOST done. follow this issue here on home-brew: Homebrew/homebrew-core#65997 (comment)

[znmeb]

Thanks! I am considering a Mac Mini - if I can dual-boot Linux on it, anyhow :-)

[storopoli]

I am using VS Code with native arm R (homebrew) in my M1. Enjoying the experience. If the guys at RStudio give support for arm in the near future, I might make the full switch to VS Code as IDE. Only thing that I am missing right now is pandoc to knit rmarkdown documents.

[znmeb]

@elbamos I'm going to be rebuilding the images either today or tomorrow to pick up R 4..0.4. Also, I plan to do a formal release as soon as I get the documentation updated and then I am going to pause enhancements indefinitely.

I still will do bug fixes, tracking R and RStudio Server versions, and documentation enhancements but I don't want to add features until I have some kind of CI/CD infrastructure that doesn't involve overnight runs on my AGX Xavier. :-)

[elbamos]

@jmcphers perhaps you could consider whether an incremental path to Apple Silicon support for RStudio Desktop could start with an ARM linux RStudio Server debian package, then the ability to build RStudio Server on OS X with Apple Silicon, and then the required changes to the desktop front-end?

[znmeb]

@elbamos @jmcphers That would solve my edgyR issue too ... once there's an arm64 pandoc I can get rid of my builder images.

[znmeb]

Good news! The Pandoc team is now making arm64 binaries! See closed issue jgm/pandoc#5450 for the details. I'll be testing out my build process with the release at https://github.com/jgm/pandoc/releases/tag/2.12 sometime before the weekend; the plan is to use the binary tarball in the RStudio builder and then symlink to it on the end-user image.

[znmeb]

I've been away from this for weeks but will be doing what I hope is the last build of RStudio for arm64 either this weekend or next week. I have RStudio Server v1.4.1717 working but I have still been unable to line up a reasonably priced / free arm64 CI / CD environment and I have quite a few other projects that need attention.

For those interested in the rest of the project (Jetson oriented, especially computer music), that will proceed. It's just the RStudio Server piece I'm freezing.

[dsanmiguel]

I've been away from this for weeks but will be doing what I hope is the last build of RStudio for arm64 either this weekend or next week. I have RStudio Server v1.4.1717 working but I have still been unable to line up a reasonably priced / free arm64 CI / CD environment and I have quite a few other projects that need attention.

For those interested in the rest of the project (Jetson oriented, especially computer music), that will proceed. It's just the RStudio Server piece I'm freezing.

Can you tell us the procedure for how to get RStudio Server v1.4.1717 working on arm64?

[znmeb]

@eitsupi Thanks! I'll test these on my 64-bit Pi if I can run Docker on it. I know it'll run on the Jetsons. I actually prefer Docker to native hosting; it's less stuff running as root on the host.

[jmcphers]

Moving this to test for Elsbeth Geranium. Plan of record is to release the arm64 platforms as a Preview for the Elsbeth Geranium release, then formally add them to the support matrix for the release following ("Cherry Blossom")

[znmeb]

Cool! How do you come up with release code names?

[jmcphers]

That's a good question! There's no overarching theme or progression aside from "names of flowers". Usually someone involved in driving the release proposes a flower name for an upcoming release, and then the team votes on it in a very democratic manner.

[ronblum]

@jmcphers Next time we're bringing in election observers from The Nature Conservancy to ensure that the voting is sufficiently democratic.

[e-clin]

Moving this to test for Elsbeth Geranium. Plan of record is to release the arm64 platforms as a Preview for the Elsbeth Geranium release, then formally add them to the support matrix for the release following ("Cherry Blossom")

Great news - thanks! Will the arm64 version be released as Docker images via the Rocker project, too?

[jmcphers]

The Rocker project is not an official RStudio endeavor so you'll need to ask them! Here's the tracking issue: rocker-org/rocker#429

[e-clin]

Ah, OK - thanks very much!

[cboettig]

@eitsupi has worked out the details on this, rocker images already build with arm64 support (in console mode) so I think we're looking forward to being able to pick up arm support in the standard rstudio images too. Huge thanks to @jmcphers and team for all the work!

[e-clin]

Indeed - thanks a million to the team for listening to the request and making the efforts!

[ronblum]

@jmcphers I changed the milestone to Cherry Blossom for formal certification during it, since Elsbeth Geranium's versions are previews.

[andresrcs]

I have managed to install quarto on arm64, but the RStudio builds for arm64 come with quarto capabilities disabled, is there any way to configure RStudio to use a system installation of quarto and enable quarto integration features?

[andresrcs]

Why are there no longer Ubuntu 20 arm64 builds for RStudio 2023.05? This is a shame since we can no longer use them on Debian 11 derivatives.

[andresrcs]

I have been trying the arm64 builds for a while and they seem as stable as the x86_64 ones, is there any estimate for an official release?

[znmeb]

I've been away from frequent Linux use for a while, but on returning I've discovered that both RStudio Desktop and RStudio server are now packaged for arm64 / aarch64 in Fedora 39. I think they're also packaged in openSUSE Tumbleweed but I don't use that daily. I haven't seen it in Debian or Ubuntu though.

[benz0li]

I haven't seen it in Debian or Ubuntu though.

@znmeb See https://dailies.rstudio.com for the latest builds (and https://dailies.rstudio.com/rstudio for RStudio branches under active development).

• Debian 12 (bookworm): Use RStudio Server for Ubuntu 22
• Debian 11 (bullseye): Use RStudio Server for Ubuntu 20

[znmeb]

Cool! Is it in testing for when Ubuntu 24.04 LTS comes out next month? I have two 4 GB Raspberry Pi CM4s running 22.04 LTS for a non-R project, but running RStudio on them would be a bonus. I'll be upgrading at least one of them to 24.04 as soon as I get a break in testing.

[benz0li]

Is it in testing for when Ubuntu 24.04 LTS comes out next month?

It might take some time until RStudio is released for Ubuntu 24.04.

Cross references:

• Ubuntu 24.04 plans? rocker-org/rocker-versioned2#767
• Swich the base image to Ubuntu 22.04 LTS rocker-org/rocker-versioned2#282

[ronblum]

@znmeb Ubuntu 24.04 LTS will be tested and certified in the next release, which is targeted for sometime in the summer. The release currently in progress, targeted for mid-April, will continue to support Ubuntu 20.04 and 22.04.

FWIW, there will be some work needed to support 24.04—right now, RStudio Desktop doesn't yet run on it. #14336