Configuration de test
Tous les benchmarks ont été réalisés sur des serveurs dédiés MyRemoteMac dans des conditions identiques :
- M4 Pro : Mac Mini M4 Pro, CPU 14 cœurs / GPU 20 cœurs, 24 Go RAM, 512 Go SSD
- M4 : Mac Mini M4, CPU 10 cœurs / GPU 10 cœurs, 16 Go RAM, 256 Go SSD
- M2 Pro : Mac Mini M2 Pro, CPU 12 cœurs / GPU 19 cœurs, 16 Go RAM, 512 Go SSD
- Intel i9 : Mac Mini Intel Core i9 (2018), 6 cœurs, 32 Go RAM, 512 Go SSD
- macOS : Sequoia 15.2, Xcode 16.2, toutes les dernières mises à jour
Scores Geekbench 6
Geekbench 6 mesure les performances brutes du CPU. Le score single-core indique la réactivité pour les tâches courantes et les opérations IDE. Le score multi-core reflète les performances de compilation et de build.
| Puce | Single-Core | Multi-Core | vs Intel i9 |
|---|---|---|---|
| M4 Pro | 3,850 | 22,000 | +129% SC / +168% MC |
| M4 | 3,800 | 15,000 | +126% SC / +83% MC |
| M2 Pro | 2,750 | 14,500 | +64% SC / +77% MC |
| Intel i9 | 1,680 | 8,200 | Baseline |
Point clé : Le score multi-core du M4 Pro est 2,68x plus rapide que l'Intel i9, ce qui signifie que les builds qui prenaient 10 minutes sur Intel se terminent désormais en moins de 4 minutes. L'amélioration du single-core signifie que l'interface de Xcode, l'autocomplétion et l'indexation sont considérablement plus réactifs.
Temps de compilation Xcode
Nous avons testé des clean builds sur un grand projet iOS de production avec environ 500 000 lignes de code Swift, plus de 200 targets et des modules mixtes Swift/Objective-C.
| Puce | Temps de Clean Build | Build incrémentiel | Temps gagné vs Intel |
|---|---|---|---|
| M4 Pro | 4m 12s | 8s | 8m 18s saved (66%) |
| M4 | 5m 45s | 11s | 6m 45s saved (54%) |
| M2 Pro | 7m 15s | 14s | 5m 15s saved (42%) |
| Intel i9 | 12m 30s | 32s | Baseline |
Comment nous avons mesuré
# Clean build measurement xcodebuild clean time xcodebuild -workspace App.xcworkspace \ -scheme App \ -destination 'platform=iOS Simulator,name=iPhone 16' \ build 2>&1 | tail -1 # Incremental build (single file change) touch Sources/App/ContentView.swift time xcodebuild -workspace App.xcworkspace \ -scheme App \ -destination 'platform=iOS Simulator,name=iPhone 16' \ build 2>&1 | tail -1
Build Swift Package Manager (clean)
Nous avons testé un projet Swift Package Manager avec 50 dépendances, incluant de gros packages comme Alamofire, Kingfisher, SnapKit et Firebase SDK.
| Puce | Résolution des dépendances | Clean Build | Temps total |
|---|---|---|---|
| M4 Pro | 12s | 1m 38s | 1m 50s |
| M4 | 14s | 2m 15s | 2m 29s |
| M2 Pro | 15s | 2m 52s | 3m 07s |
| Intel i9 | 28s | 5m 45s | 6m 13s |
# SPM clean build measurement swift package clean time swift build -c release 2>&1 | tail -5 # With parallel jobs (default uses all cores) time swift build -c release -j $(sysctl -n hw.ncpu)
Performance des builds Docker
Nous avons testé la compilation d'une image Docker d'application Node.js de production (build multi-stage avec npm install, compilation TypeScript et configuration nginx) avec Docker Desktop pour Mac.
| Puce | Build Docker (sans cache) | Build Docker (couches en cache) | Taille de l'image |
|---|---|---|---|
| M4 Pro | 42s | 6s | 185MB |
| M4 | 58s | 7s | 185MB |
| M2 Pro | 1m 15s | 8s | 185MB |
| Intel i9 | 2m 38s | 12s | 192MB |
# Docker build benchmark docker system prune -af time docker build --no-cache -t benchmark-app . # Cached rebuild (change only app source, not dependencies) echo "// updated" >> src/index.ts time docker build -t benchmark-app .
Performance d'inférence LLM
L'architecture mémoire unifiée d'Apple Silicon en fait une plateforme excellente pour exécuter des grands modèles de langage en local. Nous avons testé la vitesse d'inférence avec llama.cpp et l'accélération Metal.
| Modèle | M4 Pro (tok/s) | M4 (tok/s) | M2 Pro (tok/s) | Intel i9 (tok/s) |
|---|---|---|---|---|
| Llama 3 8B (Q4_K_M) | 48.2 | 35.6 | 28.4 | 8.1 |
| Mistral 7B (Q4_K_M) | 52.7 | 38.9 | 31.2 | 9.3 |
| Llama 3 70B (Q4_K_M) | 8.5 | OOM | OOM | OOM |
| CodeLlama 13B (Q4_K_M) | 32.1 | 22.8 | 18.6 | 5.7 |
# Install llama.cpp with Metal support brew install llama.cpp # Run benchmark with Llama 3 8B llama-bench -m llama-3-8b-q4_k_m.gguf -n 512 -ngl 99 # Interactive chat llama-cli -m llama-3-8b-q4_k_m.gguf \ -n 512 -ngl 99 --color \ -p "You are a helpful coding assistant."
Note : Le M4 Pro avec 24 Go de mémoire unifiée peut exécuter des modèles jusqu'à environ 40 milliards de paramètres en quantification 4 bits. Pour le modèle 70B, il faut la configuration 48 Go ou 64 Go. L'Intel i9 avec 32 Go peut techniquement exécuter des modèles 7-13B mais à des vitesses inutilisables en raison de l'absence d'accélération GPU Metal.
Performance SSD
La vitesse du SSD impacte directement l'indexation Xcode, les temps d'ouverture de projet, le démarrage du Simulateur et la résolution des dépendances. Nous avons mesuré les vitesses de lecture/écriture séquentielles avec dd et Disk Speed Test.
| Puce | Lecture séquentielle | Écriture séquentielle | Lecture aléatoire 4K (IOPS) |
|---|---|---|---|
| M4 Pro | 7,400 MB/s | 6,200 MB/s | 1,200K |
| M4 | 6,800 MB/s | 5,100 MB/s | 1,050K |
| M2 Pro | 5,100 MB/s | 4,200 MB/s | 850K |
| Intel i9 | 2,800 MB/s | 2,300 MB/s | 350K |
# Quick SSD benchmark with dd # Write test dd if=/dev/zero of=./testfile bs=1G count=5 2>&1 | tail -1 # Read test (clear cache first) sudo purge dd if=./testfile of=/dev/null bs=1G count=5 2>&1 | tail -1 # Cleanup rm ./testfile
Débit réseau
Tous les serveurs MyRemoteMac sont connectés via un réseau 1 Gbps. Voici les débits réels que nous avons mesurés.
| Test | Vitesse | Notes |
|---|---|---|
| iperf3 (datacenter local) | 9,42 Gbps | Proche du débit maximal au sein du datacenter |
| Speedtest (internet) | 8,7 Gbps descendant / 8,2 Gbps montant | Vers les principaux points de peering européens |
| git clone (gros dépôt, 2 Go) | 14s | Depuis GitHub, limité par le débit sortant de GitHub |
| CocoaPods install (50 pods) | 28s | Incluant les git clones et la résolution des specs |
| Docker pull (image de 1 Go) | 8s | Depuis Docker Hub |
# Network benchmark commands
brew install iperf3
iperf3 -c speedtest-server.example.com -t 30
# Measure git clone speed
time git clone --depth 1 https://github.com/nicklockwood/SwiftFormat.git
# Test download speed
curl -o /dev/null -w "Speed: %{speed_download} bytes/sec\n" \
https://speed.hetzner.de/1GB.bin
Tableau comparatif complet
Toutes les métriques côte à côte pour une comparaison facile.
| Métrique | M4 Pro | M4 | M2 Pro | Intel i9 |
|---|---|---|---|---|
| Geekbench SC | 3,850 | 3,800 | 2,750 | 1,680 |
| Geekbench MC | 22,000 | 15,000 | 14,500 | 8,200 |
| Xcode Clean Build (500k LOC) | 4m 12s | 5m 45s | 7m 15s | 12m 30s |
| SPM Clean Build | 1m 50s | 2m 29s | 3m 07s | 6m 13s |
| Docker Build (no cache) | 42s | 58s | 1m 15s | 2m 38s |
| Llama 3 8B Inference | 48.2 tok/s | 35.6 tok/s | 28.4 tok/s | 8.1 tok/s |
| SSD Read | 7,400 MB/s | 6,800 MB/s | 5,100 MB/s | 2,800 MB/s |
| SSD Write | 6,200 MB/s | 5,100 MB/s | 4,200 MB/s | 2,300 MB/s |
| Power Consumption | ~45W peak | ~30W peak | ~40W peak | ~120W peak |
Ce que cela signifie pour le CI/CD
Un matériel plus rapide se traduit directement par des pipelines CI/CD plus rapides, des boucles de retour développeur plus courtes et des coûts par build réduits.
Gain de temps sur les pipelines de build
Un pipeline CI iOS typique (checkout, build, test, archive) qui prenait 25 minutes sur Intel se termine désormais en moins de 10 minutes sur M4 Pro.
# Typical CI pipeline timing (M4 Pro): # git checkout: 5s (vs 15s Intel) # pod install: 28s (vs 1m20s) # xcodebuild: 4m12s (vs 12m30s) # xcodebuild test: 3m15s (vs 8m40s) # archive: 2m30s (vs 6m15s) # Total: ~10m (vs ~29m Intel)
Comparaison du coût par build
En supposant 100 builds par mois à 85 $/mois pour le M4, comparé aux runners macOS hébergés par GitHub à 0,08 $/min.
# MyRemoteMac M4 Pro ($149/mo): # 100 builds x 10min = 1,000 min # Cost per build: $1.49 # GitHub-hosted macOS runner: # 100 builds x 25min = 2,500 min # Cost: 2,500 x $0.08 = $200/mo # Cost per build: $2.00 # Savings: 25% cheaper + 2.5x faster
Impact sur la productivité des développeurs
Des études montrent que les temps de compilation impactent directement l'état de flow des développeurs. Un build de 10 minutes signifie que les développeurs changent de contexte vers d'autres tâches et perdent 15 à 20 minutes au total. Un build de 4 minutes permet aux développeurs de rester dans leur flow. Pour une équipe de 5 développeurs effectuant 10 builds par jour chacun, le M4 Pro permet d'économiser environ 5 heures de temps d'attente cumulé par jour par rapport à l'Intel i9.
Essayez par vous-même
Exécutez ces benchmarks sur votre propre serveur MyRemoteMac pour constater les résultats par vous-même.
# Quick benchmark script for your MyRemoteMac server
#!/bin/bash
echo "=== System Info ==="
sysctl -n machdep.cpu.brand_string
sw_vers
echo ""
echo "=== Geekbench 6 ==="
echo "Download from: https://www.geekbench.com/download/"
echo ""
echo "=== SSD Benchmark ==="
echo "Write speed:"
dd if=/dev/zero of=./benchfile bs=1G count=2 2>&1 | tail -1
echo "Read speed:"
sudo purge 2>/dev/null
dd if=./benchfile of=/dev/null bs=1G count=2 2>&1 | tail -1
rm -f ./benchfile
echo ""
echo "=== Network Speed ==="
curl -o /dev/null -w "Download speed: %{speed_download} bytes/sec\n" \
https://speed.hetzner.de/100MB.bin 2>/dev/null
echo ""
echo "=== Xcode Version ==="
xcodebuild -version
echo ""
echo "Done! Compare your results with the benchmarks at"
echo "https://myremotemac.com/guides/mac-mini-m4-pro-benchmarks"