Add ARM binaries to releases

[cor]

Currently, there are only X86 binaries available on the releases page. This is a problem for our team as some people are developing on M1 Macs. Can you please also release ARM binaries?

[chevdor]

The reason why we release only X86 binaries is that validators usually don't run nodes on anything else than Linux servers.
That being said, many devs are using Intel Mac and Mx Mac machines but usually build the binaries they need.

When building a node is an annoyance (it takes a while) and devs just need to run a node, there is also the option to use the Docker image we provide.

Could you provide details if your use case does not fall in the categories above ?

[coderobe]

Note that the linux x64 docker image should also run fine on m1 macs (tested with a current dev build of podman w/ qemu)

[shawntabrizi]

I just came back from the Parachains Summit, and there were others asking for ARM builds, specifically to speed up development, since you need a polkadot binary to run a test relay chain

[xlc]

AWS Graviton arm server is getting popular and it will be great if we can run polkadot nodes with it.

[kianenigma]

+1

[bkchr]

@chevdor compiling the binary for arm64 should work without any problems and it gets more and more popular as @xlc. Please prepare the necessary steps that we can have arm64 builds in the next release.

[johnmela]

Any idea when the next release containing the arm64 binaries will come out? Will it target v0.9.30?

[coderobe]

We are looking into it.

Will it target v0.9.30?

no.

[andreclaro]

+1

"Our latest cost analysis and performance benchmarks show that customers can realize cost savings of up to 23% and performance gains of up to 36% by deploying the GitLab application and GitLab Runner on the Arm-based Graviton2 when compared to the x86 based M5/C5 EC2 instances." - https://about.gitlab.com/blog/2021/08/05/achieving-23-cost-savings-and-36-performance-gain-using-gitlab-and-gitlab-runner-on-arm-neoverse-based-aws-graviton2-processor/

[bredamatt]

+1

[ggwpez]

I think its being worked on here paritytech/polkadot#6108 @chevdor

[chevdor]

Indeed, I am on the topic atm. If someone wants to test, feel free to ping me, I can provide an unofficial yet built in production profile for polkadot v0.9.37. For now I am testing it and working on the integration with our release process.
The PR mentioned above should also provide everything allowing to build such a binary already today.

[davedomainx]

@chevdor I am quite interested in testing out this arm64 image. Can you please let me know how get this image (is there a docker image available?)

[chevdor]

There is no docker image yet.

I can provide a production build of an early RC of v0.9.38 for aarch64-unknown-linux-gnu but I don't have the latest/final build yet and no recent one for M1s.

The version linked below is:

• really only for testing
• do NOT run a validator on it, there are several reasons not to do so that I will cover when we publish those binaries
• NOT the final v0.9.38 (it was RC5 if I recall and we added several fixes to the final)

You can get the build here: https://github.com/chevdor/polkadot/releases/tag/v0.9.38-beta

That being said, I would definitely recommend against considering the arm64 binary for a validator.
The binary itself is fine but I ran the benchmarks on various providers and machines and all the results were showing major weaknesses related to the single core performance, making those unsuitable for a validator. Nothing near the ...performance gains of up to 36%.

If you find a provider with good specs and price, please share your findings (I checked GCP and AWS).

Besides that, the build did work fine. I tested mostly wrap syncs with ParityDB and upgrading from v0.9.37 as well.
It all went fine and the nodes were running "solid" :)

[polkalegos]

Thanks for your work @chevdor. Do you plan to publish another build for M2/M2Pro?

[kogeler]

You can try to use my scripts to build an aarch64 binary that is optimized for your CPU.

Of course they are not suitable for production builds.

[okalenyk]

Hi everyone! Any updates or approximate ETA on this? Found out that it would be great to have an ability to launch zombienet kubernetes configuration locally having the Mac M1 with Docker Desktop based kubernets that runs ARM64 node. Currently I was able to make changes to Parity base-ci-linux and ci-linux Dockerfile to build them for ARM64 and succeded.

Here are the links to images:

base-ci-linux - required a single line of code to make it work cross-platform
ci-linux - same thing here

I can provide PRs if someone interested - just don't want to litter parity github repos.

I don't recommend to use the in production for sure, but for local development might be helpful.

[chevdor]

There is some work probably interesing following in https://github.com/paritytech/release-engineering/issues/194
I am also trying to dissociate bin and docker images which require some work in other areas. More on that once it becomes usable.

Atm, if this is just to make it convenient, you could make a build or used one of those I published.
If this is for local dev, you may also skip the docker part entirely (unless you need/want it).

[frisitano]

Hi everyone! Any updates or approximate ETA on this? Found out that it would be great to have an ability to launch zombienet kubernetes configuration locally having the Mac M1 with Docker Desktop based kubernets that runs ARM64 node. Currently I was able to make changes to Parity base-ci-linux and ci-linux Dockerfile to build them for ARM64 and succeded.

Here are the links to images:

base-ci-linux - required a single line of code to make it work cross-platform ci-linux - same thing here

I can provide PRs if someone interested - just don't want to litter parity github repos.

I don't recommend to use the in production for sure, but for local development might be helpful.

Could you share the code changes with me please?

[okalenyk]

Hi everyone! Any updates or approximate ETA on this? Found out that it would be great to have an ability to launch zombienet kubernetes configuration locally having the Mac M1 with Docker Desktop based kubernets that runs ARM64 node. Currently I was able to make changes to Parity base-ci-linux and ci-linux Dockerfile to build them for ARM64 and succeded.
Here are the links to images:
base-ci-linux - required a single line of code to make it work cross-platform ci-linux - same thing here
I can provide PRs if someone interested - just don't want to litter parity github repos.
I don't recommend to use the in production for sure, but for local development might be helpful.

Could you share the code changes with me please?

@frisitano,

Sure, here are the links:

• *base-ci-linux docker multi platform support
• *ci-linux docker arm64 support

[shawntabrizi]

We really need this. 99% of our devs are probably using a Mac to develop on Polkadot-SDK.

Developer experiences are worse because of lacking native binaries:

./zombienet setup polkadot polkadot-parachain


------------------------------------------------------------------------

Note:  You are using MacOS. Please, clone Polkadot SDK from https://github.com/paritytech/polkadot-sdk 
 in order to build the polkadot and/or polkadot-parachain locally.
 At the moment there is no binaries for MacOs as releases.

------------------------------------------------------------------------

[th7nder]

We really need this. 99% of our devs are probably using a Mac to develop on Polkadot-SDK.

Developer experiences are worse because of lacking native binaries:

./zombienet setup polkadot polkadot-parachain


------------------------------------------------------------------------

Note:  You are using MacOS. Please, clone Polkadot SDK from https://github.com/paritytech/polkadot-sdk 
 in order to build the polkadot and/or polkadot-parachain locally.
 At the moment there is no binaries for MacOs as releases.

------------------------------------------------------------------------

@shawntabrizi
As a workaround for this situation, we're using nix flake which provides polkadot built on ARMs.

{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    rust-overlay = {
      url = "github:oxalica/rust-overlay";
      inputs = {
        nixpkgs.follows = "nixpkgs";
       };
    };
    zombienet = {
      url = "github:paritytech/zombienet/dfc0f2e02dbab2361c3f2f983fe6e0f32261cc73"; # last known working version, because of: https://github.com/paritytech/zombienet/issues/1858
      inputs = {
        nixpkgs.follows = "nixpkgs";
      };
    };
  };
  outputs = { self, nixpkgs, flake-utils, rust-overlay, zombienet }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        overlays = [ (import rust-overlay) zombienet.overlays.default ];
        pkgs = import nixpkgs {
          inherit system overlays;
        };
        rustToolchain = pkgs.pkgsBuildHost.rust-bin.fromRustupToolchainFile ./rust-toolchain.toml;
        buildInputs = with pkgs; [
          # Building Docker images and publishing to Azure Container Registry
          azure-cli
          # cargo-llvm-cov
          cargo-expand
          clang
          pkg-config
          rustToolchain
          subxt
          just
          taplo
          polkadot
          mdbook
          # Due to zombienet's flake.nix, needs to be prefixed with pkg.zombienet
          pkgs.zombienet.default
        ]
        ++ (lib.optionals stdenv.isDarwin [
          darwin.apple_sdk.frameworks.Security
          darwin.apple_sdk.frameworks.CoreServices
          darwin.apple_sdk.frameworks.SystemConfiguration
        ])
        ++ (lib.optionals stdenv.isLinux [
          cargo-llvm-cov
        ]);
      in
      with pkgs;
      {
        devShells.default = mkShell {
          inherit buildInputs;

          LIBCLANG_PATH = "${llvmPackages.libclang.lib}/lib";
          PROTOC = "${protobuf}/bin/protoc";
          RUST_SRC_PATH = "${rustToolchain}/lib/rustlib/src/rust/library/";
          ROCKSDB_LIB_DIR = "${rocksdb}/lib";
        };
      }
    );
}

^ this flake allows you to run zombienet natively on MacOS with running command like:

zombienet -p native spawn zombienet/local-testnet.toml

[kianenigma]

Worth noting this is no2 in the developer wishlist :) #3900

[shawntabrizi]

what is the blocker? i dont get how this isn't just done.

[kianenigma]

Would be great if we know if this is addressed by the next stable release or not. Given the 3 months release cadence, if the effort needed for it is minimal, I think it is reasonable to prioritize it in the next 2 weeks.

[KarimJedda]

I just had a chat with @EgorPopelyaev , the team has some capacity to take care of it next week. CI/CD ARM runner is in place, what is left is to add step to the binary build pipeline which is going to do an ARM build.

@EgorPopelyaev would this fit in the timeline set by Kian? Let me know anything you need for this and I'll check with other teams who can assist.

[iulianbarbu]

We merged recently #6427, which brings support for releasing Apple Silicon ARM node binaries (polkadot, polkadot-prepare/execute-worker, polkadot-parachain & polkadot-omni-node) which will be part of the release pages artifacts section with the next release.

The initial request of this issue was for Apple Silicon ARM binaries for development, and the node binaries should be sufficient I think, but please create a more specific issue if something is missing.

Other than this, request for ARM Linux binaries was also mentioned (and got some likes), so I opened a dedicated issue here: #6678.