Naar inhoud springen

benchmarks

Waarom uw QEMU arm64-build 40× langzamer is

Een gemeten uitsplitsing van de geëmuleerde versus de oorspronkelijke arm64 Docker bouwt op over vijf echte werklasten, en waarom de straf zo varieert.

{auteur} · {rol} · {datum} · {minuten} min leestijd

Het toevoegen van linux/arm64 aan een Docker-build is één regel. Het gevolg is soms een vertraging van 3× en soms een vertraging van 40×, en het verschil brengt mensen in verwarring. Het is niet willekeurig.

Het mechanisme

QEMU in gebruikersmodus-emulatie vertaalt arm64-instructies naar x64-instructies tijdens runtime. De vertaling heeft een vaste overhead per instructie. De straf wordt dus berekend op basis van het aantal instructies dat uw build uitvoert – niet op basis van hoe lang het duurt, en niet op basis van de afbeeldingsgrootte.

Een build die bestanden kopieert en apt-get uitvoert, voert relatief weinig instructies uit. Een build waarop een compiler draait, voert een enorm aantal uit.

Gemeten

Het patroon is schoon: hoe meer je build compileert, hoe slechter de emulatie wordt. Als uw Dockerfile een compiler aanroept, is QEMU geen haalbare strategie.

De oplossing

Bouw elke architectuur op zijn eigen hardware en voeg de samenvattingen samen tot een manifestlijst. Het is meer YAML dan een enkele platformlijn, en het is het verschil tussen drie minuten en twee uur.

yaml
strategy:
matrix:
include:
- platform: linux/amd64
runner: runnerhut-8vcpu-ubuntu-2404
- platform: linux/arm64
runner: runnerhut-8vcpu-ubuntu-2404-arm
runs-on: ${{ matrix.runner }}

Je volgende build kan twee keer zo snel zijn, voor de halve prijs

Begin gratis. Weggaan is dezelfde ene regel, en die diff publiceren we ook.