Testaufbau
Alle Benchmarks wurden auf dedizierten MyRemoteMac-Servern unter identischen Bedingungen durchgeführt:
- M4 Pro: Mac Mini M4 Pro, 14-Core-CPU / 20-Core-GPU, 24GB RAM, 512GB SSD
- M4: Mac Mini M4, 10-Core-CPU / 10-Core-GPU, 16GB RAM, 256GB SSD
- M2 Pro: Mac Mini M2 Pro, 12-Core-CPU / 19-Core-GPU, 16GB RAM, 512GB SSD
- Intel i9: Mac Mini Intel Core i9 (2018), 6-Core, 32GB RAM, 512GB SSD
- macOS: Sequoia 15.2, Xcode 16.2, alle aktuellen Updates
Geekbench 6 Werte
Geekbench 6 misst die reine CPU-Leistung. Der Single-Core-Wert gibt die Reaktionsfähigkeit bei alltäglichen Aufgaben und IDE-Operationen an. Der Multi-Core-Wert spiegelt die Build- und Kompilierungsleistung wider.
| Chip | 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 |
Zentrale Erkenntnis: Der Multi-Core-Wert des M4 Pro ist 2,68-mal schneller als der des Intel i9, was bedeutet, dass Builds, die auf Intel 10 Minuten dauerten, jetzt in unter 4 Minuten abgeschlossen sind. Die Single-Core-Verbesserung sorgt dafür, dass sich die Xcode-Oberfläche, die Codevervollständigung und die Indexierung deutlich reaktionsschneller anfühlen.
Xcode-Build-Zeiten
Wir haben Clean Builds an einem großen produktiven iOS-Projekt mit etwa 500.000 Zeilen Swift-Code, über 200 Targets und gemischten Swift/Objective-C-Modulen getestet.
| Chip | Clean-Build-Zeit | Inkrementeller Build | Zeitersparnis 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 |
Wie wir gemessen haben
# 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
Swift Package Manager Clean Build
Wir haben ein Swift-Package-Manager-Projekt mit 50 Abhängigkeiten getestet, darunter große Pakete wie Alamofire, Kingfisher, SnapKit und Firebase SDK.
| Chip | Abhängigkeitsauflösung | Clean Build | Gesamtzeit |
|---|---|---|---|
| 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)
Docker-Build-Performance
Wir haben das Erstellen eines Docker-Images einer produktiven Node.js-Anwendung getestet (Multi-Stage-Build mit npm install, TypeScript-Kompilierung und nginx-Einrichtung) mit Docker Desktop für Mac.
| Chip | Docker-Build (ohne Cache) | Docker-Build (gecachte Layer) | Image-Größe |
|---|---|---|---|
| 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 .
LLM-Inferenz-Performance
Die Unified-Memory-Architektur von Apple Silicon macht es ideal für das lokale Ausführen von großen Sprachmodellen. Wir haben die Inferenzgeschwindigkeit mit llama.cpp und Metal-Beschleunigung getestet.
| Modell | 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."
Hinweis: Der M4 Pro mit 24GB Unified Memory kann Modelle mit bis zu etwa 40 Milliarden Parametern in 4-Bit-Quantisierung ausführen. Für das 70B-Modell benötigen Sie die 48GB- oder 64GB-Konfiguration. Der Intel i9 mit 32GB kann technisch 7-13B-Modelle ausführen, jedoch mit unbrauchbaren Geschwindigkeiten aufgrund der fehlenden Metal-GPU-Beschleunigung.
SSD-Performance
Die SSD-Geschwindigkeit wirkt sich direkt auf die Xcode-Indexierung, die Projektöffnungszeiten, den Simulator-Start und die Abhängigkeitsauflösung aus. Wir haben die sequentiellen Lese-/Schreibgeschwindigkeiten mit dd und Disk Speed Test gemessen.
| Chip | Sequentielles Lesen | Sequentielles Schreiben | Zufälliges 4K-Lesen (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
Netzwerkdurchsatz
Alle MyRemoteMac-Server sind über ein 1Gbps-Netzwerk angebunden. Hier sind die praxisnahen Übertragungsgeschwindigkeiten, die wir gemessen haben.
| Test | Geschwindigkeit | Anmerkungen |
|---|---|---|
| iperf3 (lokales Rechenzentrum) | 9.42 Gbps | Nahezu Leitungsgeschwindigkeit innerhalb des Rechenzentrums |
| Speedtest (Internet) | 8.7 Gbps Download / 8.2 Gbps Upload | Zu den wichtigsten europäischen Peering-Punkten |
| git clone (großes Repo, 2GB) | 14s | Von GitHub, begrenzt durch GitHubs Egress |
| CocoaPods install (50 Pods) | 28s | Inklusive git clones und Spec-Auflösung |
| Docker pull (1GB Image) | 8s | Von 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
Vollständige Vergleichstabelle
Alle Metriken nebeneinander für einen einfachen Vergleich.
| Metrik | 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 |
Was das für CI/CD bedeutet
Schnellere Hardware führt direkt zu schnelleren CI/CD-Pipelines, kürzeren Feedbackschleifen für Entwickler und geringeren Kosten pro Build.
Zeitersparnis bei der Build-Pipeline
Eine typische iOS-CI-Pipeline (Checkout, Build, Test, Archivierung), die auf Intel 25 Minuten dauerte, ist auf dem M4 Pro jetzt in unter 10 Minuten abgeschlossen.
# 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)
Vergleich der Kosten pro Build
Angenommen 100 Builds pro Monat bei 85 $/Monat für den M4, verglichen mit GitHub-gehosteten macOS-Runnern zu 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
Auswirkung auf die Entwicklerproduktivität
Studien zeigen, dass Build-Zeiten sich direkt auf den Flow-Zustand von Entwicklern auswirken. Ein Build von 10 Minuten bedeutet, dass Entwickler zu anderen Aufgaben wechseln und insgesamt 15-20 Minuten verlieren. Ein Build von 4 Minuten hält Entwickler in ihrem Flow. Für ein Team von 5 Entwicklern, die jeweils 10 Builds pro Tag durchführen, spart der M4 Pro im Vergleich zum Intel i9 täglich etwa 5 Stunden kumulierte Wartezeit.
Selbst ausprobieren
Führen Sie diese Benchmarks auf Ihrem eigenen MyRemoteMac-Server aus, um die Ergebnisse aus erster Hand zu sehen.
# 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"