ARM64/aarch64 support

[romanzac]

ARM64 is recently gaining ground on the formerly leading AMD64 architecture due to its greater efficiency, offering better performance per watt.

Adding support for ARM64 would enable operators, developers, and researchers to:

• Run on more cost-efficient cloud instances.
• Develop and test using the powerful Apple M series chip-based laptops.

Actual steps to resolve this issue:

• Add CI/test coverage of selected ARM64 platforms to the existing test matrix.

Selected platforms:

• Apple Silicon M1
• Amazon Graviton2

[romanzac]

Issue is related to #978

[diegomrsantos]

Does Nim itself support it?

[romanzac]

Does Nim itself support it?

Yes, it is on the list of supported platforms and I myself was able to compile and run tests with Nim 2.0 on Apple M1.
https://nim-lang.org/docs/packaging.html

[diegomrsantos]

Not sure about Nim 2.0, but I believe Nim 1.6 runs on my Apple M1 with amd64 emulation.

[mratsim]

How did you install Nim?

[dryajov]

Not sure about Nim 2.0, but I believe Nim 1.6 runs on my Apple M1 with amd64 emulation.

libp2p and nim both run on native apple m series chips without a hitch and people have been running it on RasPi as part of nimbus for at least a couple of years now.

Support for an arm64 CI, is a different matter altogether, if this is what this issue is about, it should be clarified, otherwise it gives the impression that arm support is missing, which is definitely not the case.

[arnetheduck]

Nimbus' CI indirectly covers mac/arm64: https://ci.status.im/job/nimbus-eth2/job/platforms/job/macos/job/aarch64/ - a similar job can be set up for libp2p itself trivially

[romanzac]

How did you install Nim?

brew install nim
https://formulae.brew.sh/formula/nim

This defaults to 2.0

[romanzac]

Not sure about Nim 2.0, but I believe Nim 1.6 runs on my Apple M1 with amd64 emulation.

libp2p and nim both run on native apple m series chips without a hitch and people have been running it on RasPi as part of nimbus for at least a couple of years now.

Support for an arm64 CI, is a different matter altogether, if this is what this issue is about, it should be clarified, otherwise it gives the impression that arm support is missing, which is definitely not the case.

It's great to see that Nimbus benefits from nim-libp2p and also serves as the reference application. As contributors to nim-libp2p, we develop our own tests, and we aim to provide factual evidence that it can run independently on modern platforms. When we build enough knowledge about platforms specifics, we might show case optimized use cases, perhaps with Waku?

[dryajov]

How did you install Nim?

brew install nim https://formulae.brew.sh/formula/nim

This defaults to 2.0

It's usually not a good idea to use os level pre-build packages, neither for local development, nor for CI. For CI, you want to build from source (as we should be already doing, if not it should be fixed), for local development use one of the provided environment managers, currently I'm aware of two https://github.com/dom96/choosenim which seems to have been recently abandoned and is not shipping arm builds and a nim plugin for asdf https://github.com/asdf-community/asdf-nim, which does install/ship arm supported binaries.

I do not think we yet support nim 2.0, so we should not be using it until we deem the release 2.0 stable.

[dryajov]

Not sure about Nim 2.0, but I believe Nim 1.6 runs on my Apple M1 with amd64 emulation.

libp2p and nim both run on native apple m series chips without a hitch and people have been running it on RasPi as part of nimbus for at least a couple of years now.
Support for an arm64 CI, is a different matter altogether, if this is what this issue is about, it should be clarified, otherwise it gives the impression that arm support is missing, which is definitely not the case.

It's great to see that Nimbus benefits from nim-libp2p and also serves as the reference application. As contributors to nim-libp2p, we develop our own tests, and we aim to provide factual evidence that it can run independently on modern platforms. When we build enough knowledge about platforms specifics, we might show case optimized use cases, perhaps with Waku?

Yes, I'm well aware, my team (and @arnetheduck ) wrote most of the initial implementation.

Nimbus' CI indirectly covers mac/arm64: https://ci.status.im/job/nimbus-eth2/job/platforms/job/macos/job/aarch64/ - a similar job can be set up for libp2p itself trivially

Seems like there is a solution that already exists as part of the Nimbuis build, we should try to use it here as well. We've been also looking into building on arm as part of Codex, perhaps @veaceslavdoina might be of assistance here as well.

[veaceslavdoina]

Seems like there is a solution that already exists as part of the Nimbuis build, we should try to use it here as well. We've been also looking into building on arm as part of Codex, perhaps @veaceslavdoina might be of assistance here as well.

Codex builds now done using GitHub Actions and we are using BuildJet for ARM, because ARM runners support will be added just in 2024, in private beta.

[diegomrsantos]

How did you install Nim?

I used choosenim. Installed 1.6.16 today:

Nim Compiler Version 1.6.16 [MacOSX: amd64]
Compiled at 2023-11-15
Copyright (c) 2006-2023 by Andreas Rumpf

active boot switches: -d:release

[diegomrsantos]

I asked cause I also didn't find arm images here https://hub.docker.com/r/nimlang/nim/tags?page=1

[romanzac]

Seems like there is a solution that already exists as part of the Nimbuis build, we should try to use it here as well. We've been also looking into building on arm as part of Codex, perhaps @veaceslavdoina might be of assistance here as well.

Codex builds now done using GitHub Actions and we are using BuildJet for ARM, because ARM runners support will be added just in 2024, in private beta.

This is valuable piece of information. Thanks a lot.

[romanzac]

How did you install Nim?

I used choosenim. Installed 1.6.16 today:

Nim Compiler Version 1.6.16 [MacOSX: amd64]
Compiled at 2023-11-15
Copyright (c) 2006-2023 by Andreas Rumpf

active boot switches: -d:release

I asked cause I also didn't find arm images here https://hub.docker.com/r/nimlang/nim/tags?page=1

Your are right. Once this issues is in full motion, we would need to figure out how to build Nim and Nimble from sources on ARM. If we follow our current CI workflow practice.

[romanzac]

How did you install Nim?

brew install nim https://formulae.brew.sh/formula/nim
This defaults to 2.0

It's usually not a good idea to use os level pre-build packages, neither for local development, nor for CI. For CI, you want to build from source (as we should be already doing, if not it should be fixed), for local development use one of the provided environment managers, currently I'm aware of two https://github.com/dom96/choosenim which seems to have been recently abandoned and is not shipping arm builds and a nim plugin for asdf https://github.com/asdf-community/asdf-nim, which does install/ship arm supported binaries.

I do not think we yet support nim 2.0, so we should not be using it until we deem the release 2.0 stable.

Thanks for sharing. What makes you think Nim 2.0 is not stable ?

[dryajov]

How did you install Nim?

brew install nim https://formulae.brew.sh/formula/nim
This defaults to 2.0

It's usually not a good idea to use os level pre-build packages, neither for local development, nor for CI. For CI, you want to build from source (as we should be already doing, if not it should be fixed), for local development use one of the provided environment managers, currently I'm aware of two https://github.com/dom96/choosenim which seems to have been recently abandoned and is not shipping arm builds and a nim plugin for asdf https://github.com/asdf-community/asdf-nim, which does install/ship arm supported binaries.
I do not think we yet support nim 2.0, so we should not be using it until we deem the release 2.0 stable.

Thanks for sharing. What makes you think Nim 2.0 is not stable ?

Its a new release and usually things take time to stabilize, status projects tend to run on older versions that are battle tested, which isn't the case with 2.0.

That is not to say that we don't want to test it with 2.0, but instead run against different nim versions.

Btw, have you looked into how the current build system is setup? It already supports building from a compiled version of nim - https://github.com/status-im/nim-libp2p/blob/unstable/.github/actions/install_nim/action.yml

I used choosenim. Installed 1.6.16 today:

@diegomrsantos - choose nim doesn't support arm binaries and has been largely abandoned, I've since switched to https://github.com/asdf-community/asdf-nim which does support apple silicon.

[diegomrsantos]

@dryajov thanks! Does it install nimble too?

[diegomrsantos]

It's usually not a good idea to use os level pre-build packages, neither for local development, nor for CI.

@dryajov could you please elaborate more on this?

[dryajov]

@dryajov thanks! Does it install nimble too?

yes

[dryajov]

@dryajov thanks! Does it install nimble too?

yes

It's usually not a good idea to use os level pre-build packages, neither for local development, nor for CI.

@dryajov could you please elaborate more on this?

Its harder (if not impossible) to switch versions with os level installations. Usually if the language ecosystem provides an environment manager, it is much more practical to use with difference language versions. This is usually what you want when developing software.

[arnetheduck]

nimble will be installing nim too, after nim-lang/nimble#1131 is merged

[diegomrsantos]

@dryajov ah you mean using package managers like brew and apt. Thanks.

[dryajov]

@romanzac can we clarify this issue a bit more.

Adding support for ARM64 would enable operators, developers, and researchers to:

As mentioned previously, libp2p supports (many) arm chips out of the box, this issue gives the impression that it doesn't, which is certainly not the case.

Can you clarify in the description:

• What is this issue for
• What outcomes we expect from it
• What are the steps involved in getting there

[mratsim]

I think we can close the issue. The issue is choosenim doesn't support ARM.

[romanzac]

I welcome any proposal which positively impacts adoption of nim-libp2p. Feel free to propose your own view and steps how this issue should be resolved. There will be daily tests using CI workfows at very minimum.

[dryajov]

I welcome any proposal which positively impacts adoption of nim-libp2p. Feel free to propose your own view and steps how this issue should be resolved. There will be daily tests using CI workfows at very minimum.

That's kind of a non answer, could you provide the details I requested?

[romanzac]

I welcome any proposal which positively impacts adoption of nim-libp2p. Feel free to propose your own view and steps how this issue should be resolved. There will be daily tests using CI workfows at very minimum.

That's kind of a non answer, could you provide the details I requested?

At this time I see my answers sufficient. Thanks for your comment.

[diegomrsantos]

@dryajov I believe this issue is for having arm support on CI.

[dryajov]

@dryajov I believe this issue is for having arm support on CI.

Thanks for clarifying @diegomrsantos. It would still be great to add a bit more context, I think there's been sufficient feedback to be able to substantially improve the issue.

For clarity and consistency, I would still suggest we add something that resembles #980 (comment).

[diegomrsantos]

@romanzac could you please update the issue description with the points below?

What is this issue for
What outcomes we expect from it
What are the steps involved in getting there

[kaiserd]

The main purpose of the issue is to add CI/test coverage of these platforms (only with that we can really claim support). @romanzac let's make this explicit in the OP.
Regarding concrete plans: The issue was mainly meant as an abstract description of the matter.
Vac P2P will be prioritize nim-libp2p issues and new features based on their necessity / urgency for Nimbus and Logos projects. So, if you are not interested in this now, we will prioritize other issues. Sorry for the confusion here.
We'd add more context and specific action items to this issue, once projects show interest, or there is no other high prio task at the moment and we can work on it in the background.

@arnetheduck
Thank you for:

Nimbus' CI indirectly covers mac/arm64: https://ci.status.im/job/nimbus-eth2/job/platforms/job/macos/job/aarch64/ - a similar job can be set up for libp2p itself trivially

We will do this as a simple solution for now.

Also thanks to @dryajov , @mratsim , @veaceslavdoina for your input on this issue 🙏 .

I'd prefer to leave this issue open, and link it on the roadmap, to track full arm64 test and CI coverage.

We will refine the OP to avoid confusion:

• make explicit that this mainly about CI
• we'd like to only declare arm64 support, if we also have the respective CI pipelines running.
  Still, libp2p is already usable on arm (ideally list specific arm platforms).

[romanzac]

Related to #993