Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve speed of Docker container on (M+) macOS (and Windows?) #112

Open
hturner opened this issue May 31, 2024 · 4 comments
Open

Improve speed of Docker container on (M+) macOS (and Windows?) #112

hturner opened this issue May 31, 2024 · 4 comments

Comments

@hturner
Copy link
Member

hturner commented May 31, 2024

Using the Docker container locally on an M1 mac is painfully slow, whether you launch from clone of the repo or a copy extracted from zip.

Approx timings:

Action Local Codespaces
Configure R 5-10 min 1 min
Build R > 35 min* 5-10 min

*build did not complete, I forget why and not inclined to repeat experiment!

There is some discussion about this issue on Reddit and in the VSCode docs.

As our focus is on the codespace which is working well, this is low priority to fix, I am mainly creating this issue for reference.

For now we can put a note on the local setup documentation that its is not recommended to run the container locally on macOS or Windows.

@iaine
Copy link
Collaborator

iaine commented Aug 16, 2024

I was looking at another issue and chanced on this message in Docker Desktop which might shed some light on this issue:
Screenshot 2024-08-16 at 09 33 52

There's a Docker forum answer about it here: https://forums.docker.com/t/run-x86-intel-and-arm-based-images-on-apple-silicon-m1-macs/117123 and also there do seem to be blog/medium posts (though some use other tools as well). From the reading that I've done so far, it appears that Docker runs through an emulator on an M1/2/3 Mac and that might be the cause and I did notice the QEMU is running on my Mac without me starting it. Not sure yet how one gets a performant cross-platform engine.

@bobturneruk
Copy link

Hi! We (me, @ubdbra001, @annakrystalli) tried a few changes to the Dockerfile to try and get it to build on ARM. This may not be new information, but we found that the r-base-dev installation step was problematic, with errors like:

#0 994.0  r-base-dev : Depends: r-base-core (>= 4.4.1-1.2204.0) but it is not going to be installed

@ubdbra001
Copy link

Just to add a bit more info:

  • We identified the initial sticking point as lines 13-21 in the dockerfile and broke it down to work out what was going on
  • Line 19 (apt -y install r-base-dev) throws the first error, as it needs pkgconf but is not installed for some reason.
  • Adding a line to install pkgconf then produces the error @bobturneruk included above
  • Installing r-base-core manually doesn't work at it doesn't look like there is a recent arm build for it (the version installed by running apt install r-base-core is 4.1.2-1ubuntu2)

I don't think there are arm binaries for R through the ubuntu r-project repo, but there may be for debian. Using package source instead may solve the issues we found.

@hturner
Copy link
Member Author

hturner commented Oct 17, 2024

Thanks for this analysis, which was very informative. Searching for the error message posted by @bobturneruk led me to this Stackoverflow Q & A, which in turn led me to look at the rocker/r-ubuntu Dockerfile. There they use "ppa:marutter/rrutter4.0" as the repository vs "https://cloud.r-project.org/bin/linux/ubuntu jammy-cran40/" as we have been using. I tried building from the R Dev Container Dockerfile with Michael Rutter's base R PPA as the R repository and the build was successful on my ARM machine!

PR #197 updates the Dockerfiles with this change. I think we will now be able to get this working with buildx. Looking at the buildx docs it looks like we only need to set up Docker Buildx and not QEMU. @StarTrooper08 do you want to have a go at this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants