vacp2p
ARM64/aarch64 support
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:
- [x] Apple Silicon M1
- [ ] Amazon Graviton2
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
Not sure about Nim 2.0, but I believe Nim 1.6 runs on my Apple M1 with amd64 emulation.
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.
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
How did you install Nim?
brew install nim https://formulae.brew.sh/formula/nim
This defaults to 2.0
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?
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.
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.
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.
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
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.
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.
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 ?
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.
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 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.
nimble will be installing nim too, after https://github.com/nim-lang/nimble/pull/1131 is merged
@dryajov ah you mean using package managers like brew and apt. Thanks.
@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
I think we can close the issue. The issue is choosenim doesn't support ARM.
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.
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?
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.