Configuration de test
Tous les benchmarks ont ete realises sur des serveurs dedies MyRemoteMac dans des conditions identiques :
- M4 Pro : Mac Mini M4 Pro, CPU 14 coeurs / GPU 20 coeurs, 24 Go RAM, 512 Go SSD
- M4 : Mac Mini M4, CPU 10 coeurs / GPU 10 coeurs, 16 Go RAM, 256 Go SSD
- M2 Pro : Mac Mini M2 Pro, CPU 12 coeurs / GPU 19 coeurs, 16 Go RAM, 512 Go SSD
- Intel i9 : Mac Mini Intel Core i9 (2018), 6 coeurs, 32 Go RAM, 512 Go SSD
- macOS : Sequoia 15.2, Xcode 16.2, toutes les dernieres mises a jour
Scores Geekbench 6
Geekbench 6 mesure les performances brutes du CPU. Le score single-core indique la reactivite pour les taches courantes et les operations IDE. Le score multi-core reflete 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 cle : 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 desormais en moins de 4 minutes. L'amelioration du single-core signifie que l'interface de Xcode, l'autocompletion et l'indexation sont considerablement plus reactifs.
Temps de compilation Xcode
Nous avons teste 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 incrementiel | Temps gagne 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 mesure
# 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 teste un projet Swift Package Manager avec 50 dependances, incluant de gros packages comme Alamofire, Kingfisher, SnapKit et Firebase SDK.
| Puce | Resolution des dependances | 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 teste 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'inference LLM
L'architecture memoire unifiee d'Apple Silicon en fait une plateforme excellente pour executer des grands modeles de langage en local. Nous avons teste la vitesse d'inference avec llama.cpp et l'acceleration Metal.
| Modele | 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 memoire unifiee peut executer des modeles jusqu'a environ 40 milliards de parametres en quantification 4 bits. Pour le modele 70B, il faut la configuration 48 Go ou 64 Go. L'Intel i9 avec 32 Go peut techniquement executer des modeles 7-13B mais a des vitesses inutilisables en raison de l'absence d'acceleration GPU Metal.
Performance SSD
La vitesse du SSD impacte directement l'indexation Xcode, les temps d'ouverture de projet, le demarrage du Simulateur et la resolution des dependances. Nous avons mesure les vitesses de lecture/ecriture sequentielles avec dd et Disk Speed Test.
| Puce | Lecture sequentielle | Ecriture sequentielle | Lecture aleatoire 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
Debit reseau
Tous les serveurs MyRemoteMac sont connectes via un reseau 10 Gbps. Voici les debits reels que nous avons mesures.
| Test | Vitesse | Notes |
|---|---|---|
| iperf3 (datacenter local) | 9,42 Gbps | Proche du debit maximal au sein du datacenter |
| Speedtest (internet) | 8,7 Gbps descendant / 8,2 Gbps montant | Vers les principaux points de peering europeens |
| git clone (gros depot, 2 Go) | 14s | Depuis GitHub, limite par le debit sortant de GitHub |
| CocoaPods install (50 pods) | 28s | Incluant les git clones et la resolution 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 metriques cote a cote pour une comparaison facile.
| Metrique | 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 materiel plus rapide se traduit directement par des pipelines CI/CD plus rapides, des boucles de retour developpeur plus courtes et des couts par build reduits.
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 desormais 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 cout par build
En supposant 100 builds par mois a 75 $/mois pour le M4, compare aux runners macOS heberges par GitHub a 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 productivite des developpeurs
Des etudes montrent que les temps de compilation impactent directement l'etat de flow des developpeurs. Un build de 10 minutes signifie que les developpeurs changent de contexte vers d'autres taches et perdent 15 a 20 minutes au total. Un build de 4 minutes permet aux developpeurs de rester dans leur flow. Pour une equipe de 5 developpeurs effectuant 10 builds par jour chacun, le M4 Pro permet d'economiser environ 5 heures de temps d'attente cumule par jour par rapport a l'Intel i9.
Essayez par vous-meme
Executez ces benchmarks sur votre propre serveur MyRemoteMac pour constater les resultats par vous-meme.
# 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.html"