Build and release on aarch64

[DazWorrall]

Closes #6311

Build aarch64 as well as x86_64 on linux using qemu in the release step. Being emulated this is of course pretty slow - ~90m to build, ~45m to test - so it's not practical to run on every push during CI. Some options which may be available in future to improve this:

• Hosted arm runners are in private preview at the moment, if these are ever available to public repos then they would be ideal
• If Apple Silicon based MacOS runners ever support nested virtualisation - which they do not currently - then we run could these builds in that environment instead (this is how I iterated on this PR and the previous aarch64 build issues)

I tested this on my fork by removing the tags push condition, and it worked as intended.

[kripken]

This makes sense to me: it adds little complexity to the release script, and even if it is quite slow, we release rarely enough that it won't make much of a difference to our total usage of CI.

However, I am a little worried about timeouts... though the github docs say the default limit is 6 hours (!) which should be enough.

@sbc100 what do you think?

[sbc100]

I wonder if we should simply wait for github to make the arm64 runners public? I guess it depends how long we think that will be. We could also join the waitlist here: https://resources.github.com/devops/accelerate-your-cicd-with-arm-and-gpu-runners-in-github-actions/

Is there any serious urgency around us providing these prebuilt binaries upstream? I assume that folks who need arm64 images today can simply using the distro packaged versions or build from source? Is this currently not possible for anyone?

[DazWorrall]

I wonder if we should simply wait for github to make the arm64 runners public? I guess it depends how long we think that will be.

There is the time until they are made public - for which the answer is probably 'foreseeable future' - and when they are made available for free/open source, to which I expect the answer is 'probably not in the foreseeable future' 😅 The docs suggest this will launch initially only for paid plans.

Is this currently not possible for anyone?

In our environment binaryen is not packaged by the distro. Building ourselves is not impossible of course, but upstream support is much more convenient and we can share that work, hence this PR. Not life or death, but a big quality of life improvement for those running arm on the backend. There are examples of others asking for this e.g. #6311 and #4135

[sbc100]

I wonder if we should simply wait for github to make the arm64 runners public? I guess it depends how long we think that will be.

There is the time until they are made public - for which the answer is probably 'foreseeable future' - and when they are made available for free/open source, to which I expect the answer is 'probably not in the foreseeable future' 😅 The docs suggest this will launch initially only for paid plans.

Is this currently not possible for anyone?

In our environment binaryen is not packaged by the distro. Building ourselves is not impossible of course, but upstream support is much more convenient and we can share that work, hence this PR. Not life or death, but a big quality of life improvement for those running arm on the backend. There are examples of others asking for this e.g. #6311 and #4135

Out of interest what distro are you using that doesn't contain binaryen? Can we ask them to add it?

[DazWorrall]

Sorry, wasn't precise enough there, it's more that specific versions(s) aren't always available. There is also a use case like binaryen-rb, which vendors binaryen for ease of use from Ruby irrespective of the distro/environment.

[sbc100]

Sorry, wasn't precise enough there, it's more that specific versions(s) aren't always available. There is also a use case like binaryen-rb, which vendors binaryen for ease of use from Ruby irrespective of the distro/environment.

So binaryen-rb pulls down binaries from our upstream github releases?

In general my inclination is not to spend too much time upstream creating binaries for all different architectures but instead ask downstream folks like distros (and binaryen-rb potentially) to build their own binaries in accordance to their needs.

However, it does seems reasonable to provide some binary builds as part of our release process. I'm just not sure where to draw the line. Perhaps arm64 linux is such a popular platform now that its worth spending these extra cycles on?

[DazWorrall]

So binaryen-rb pulls down binaries from our upstream github releases?

Yes exactly.

Perhaps arm64 linux is such a popular platform now that its worth spending these extra cycles on?

I am of course not an impartial commenter (😅) but I think it's fair to say arm64 on linux is a growing platform, you need only look at AWS and GCP's compute offerings for evidence of that (4 generations of Graviton, new hardware in preview on GCP...).

[kripken]

Another option, I realized, is to provide a wasm build for platforms we don't have native builds for. That is, we can build wasm-opt.wasm as part of our releases, and people could run that on any architecture (that has a wasm VM, which should be everyone).

We didn't do this in the past because it was way too slow (10x, see next link), but I checked now and with the recent mimalloc port in Emscripten, performance is not terribly far from native. It can use all CPU cores properly, and is just 2x slower.

2x is not ideal, obviously, but it would be very simple to add this build on our CI, and pretty simple for users to run: in that link, just nodejs wasm-opt.js (we can also make a pure wasm build once wasi-libc has full exceptions and threads support, but for now node.js etc. would be necessary).

With that said, I don't want to block this PR on that. While the aarch64 build is slow, it is just on releases, and a 2x faster build might be worth it. But if we set up the wasm build then we'd have support for basically all architectures at once, and maybe that would be good enough until we get native aarch64 support here - I'm curious what people think about that?

edit: Update on speed of the wasm build, it is 1.5x slower than native, not 2x (see #6338).

[sbc100]

Yay for smaller diff

[kripken]

lgtm as well.

I do think it's worth looking into a wasm build as well, but this seems independently worthwhile.

[DazWorrall]

Thanks for merging! Any thoughts on when you will cut a new release?

[kripken]

I'll try to get a new release out this week.

[kripken]

Release 117 is almost ready, all built so far except for the aarch64 one:

https://github.com/WebAssembly/binaryen/releases/tag/version_117