Using High Cost-Performance and Power-Efficient Arm-Based GitHub Actions Runner

Arm-based Actions Runner has entered public beta. Arm-based Linux / Windows runners are now available.

Actions: Arm-based linux and windows runners are now in public beta

GitHub's blog mentions that Arm technology helps reduce data center power consumption. For Windows runners, it seems that GitHub and Arm are partnering to provide Windows VM images^[1].

Arm64 on GitHub Actions: Powering faster, more efficient build systems

The appeal for us users is its price, which is 37% cheaper compared to x64 runners. The pricing table is available below.

Per-minute rates | About billing for GitHub Actions - GitHub Docs

Arm-based Runner is available for organizations on paid plans (Team and above).

Select Organization Settings -> Actions -> Runners, and click the New runner button on the Runners page.

Click New GitHub-hosted runner.

The UI for creating a runner will be displayed. Linux ARM64 and Windows ARM64 can be selected as Beta.

For now, I set it to the minimum spec Linux ARM 64, Ubuntu 22.04, 2-core 8GB RAM machine, named it linux-arm64, and clicked Create runner.

The runner was set up and available immediately.

In addition to the above Arm Runner, I created a minimum configuration x64 Runner named linux-x64 for comparison.

I prepared the same workflow used in the previous article "Trying High-Spec Larger Runners in GitHub Actions" for benchmarking.

This workflow builds an Electron app. As in the previous article, it builds the Electron sample published by mamezou-tech and runs it on linux-x64 and linux-arm64 runners.

name: Build Electron App

on:
  workflow_dispatch:

jobs:
  build:

    runs-on: ${{ matrix.os }}

    strategy:
      fail-fast: false
      matrix:
        os: [linux-x64, linux-arm64]

    steps:
    - uses: actions/checkout@v4
      with:
        repository: 'mamezou-tech/electron-example-browserview'
        path: electron-example-browserview      
    - name: Setup nodejs
      uses: actions/setup-node@v4
      with:
        node-version: '20'
    - name: Install dependencies
      run: |
        cd electron-example-browserview
        npm install
    - name: Package
      run: |
        cd electron-example-browserview
        npx electron-builder --dir
      env:
        GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    - name: Upload artifacts
      uses: actions/upload-artifact@v4
      with:
        name: package-${{ matrix.os }}
        path: electron-example-browserview/dist/*

I tabulated the build times for the main steps. The average of two measurements (unit: seconds).

The time taken for packaging was almost equal, but there were differences in Node.js setup, npm install, and artifact upload, with the Arm version runner showing higher throughput overall.

This is a comparison of batch processing using sbgraph. It builds sbgraph, fetches page data from a Scrapbox project, and performs aggregation and graph structure generation. This was also run on both linux-x64 and linux-arm64 runners.

name: sbgraph benchmark

on:
  workflow_dispatch:

jobs:

  build:
    runs-on: ${{ matrix.os }}

    strategy:
      fail-fast: false
      matrix:
        os: [linux-x64, linux-arm64]

    steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-go@v5
      with:
        go-version: 1.22
    - name: Install sbgraph
      run: |
        go install github.com/mamezou-tech/sbgraph@latest
        sbgraph init
        sbgraph project -p help-jp
    - name: Fetch data
      run: sbgraph fetch
    - name: Aggregate
      run: sbgraph aggregate -s=true
    - name: Generate Graph data
      run: sbgraph graph -i=true -j=true
    - name: Upload result
      uses: actions/upload-artifact@v4
      with:
        name: help-jp-result-${{ matrix.os }}
        path: _work/help-jp*

Here is the comparison of the main steps. The average of two measurements (unit: seconds). Setup Go and data fetch were slightly faster on x64, but Arm was significantly faster for go install, resulting in higher throughput overall for the Arm runner.

Although it was a simple benchmark, the Arm runner performed comparably to (and sometimes better than) the x64 runner. Given its lower cost, it makes sense to adopt the Arm runner as much as possible.

There are some software that do not run on the Arm architecture, so not all workflows can be replaced, but I intend to use it where applicable.