arm64 sans QEMU
Créations d'images multi-architectures
Créez chaque architecture sur du matériel natif et publiez une liste de manifestes. Aucune pénalité d'émulation.
Natif partout
amd64 s'appuie sur amd64, arm64 s'appuie sur arm64. Comme cela aurait dû être.
Un manifeste
Les résumés fusionnent en une seule balise que les consommateurs tirent normalement.
5×–40× plus rapide
Cela dépend exactement de la quantité de compilation de votre image.
L'émulation QEMU est le chemin par défaut pour les builds multi-arch et c'est la raison pour laquelle tant d'équipes ont discrètement abandonné la prise en charge d'arm64. L'émulation d'une chaîne d'outils de compilateur entière est aussi lente qu'il y paraît.
Questions fréquentes
- Pourquoi QEMU est-il tellement plus lent ?
- Il traduit chaque instruction arm64 en x64 au moment de l'exécution, de sorte que la pénalité varie en fonction du nombre d'instructions exécutées par votre build. Une image de copie de fichier est environ 3 fois plus lente ; une version Rust ou C++ est 35 à 40 fois plus lente.
- Comment publier une balise pour les deux architectures ?
- Construisez chaque architecture sur son propre exécuteur natif, poussez par résumé, puis fusionnez avec Docker buildx imagetools create. Les consommateurs tirent normalement l'étiquette.
- Ai-je besoin de caches séparés par architecture ?
- Oui, et ils sont automatiquement séparés. Incluez également runner.arch dans n'importe quelle action/clé de cache, ou un cache x64 restauré sur arm64 produit des erreurs d'éditeur de liens déroutantes plutôt qu'un échec net.
Votre prochain build pourrait être deux fois plus rapide, pour moitié prix
Commencez gratuitement. Repartir tient à la même ligne, et nous publions ce diff aussi.