Windows Server 2025 läuft auf ARM besser

• In einem Vergleich virtualisierter Windows Server 2025-Umgebungen lief die Konfiguration mit ARM64-Gast auf ARM64-Host stabil, und es zeigte sich eine subjektiv schnellere Reaktion beim Starten von Diensten, beim Ausführen von Verwaltungskonsolen und bei Praxisaufgaben
• Beide VMs wurden mit identischer Speicher-, virtueller Prozessor- und Rollen-Konfiguration eingerichtet; in den Messungen zeigte das Snapdragon-System geringere Schwankungen bei der CPU-Auslastung, hielt Processor Queue Length bei 0 und lieferte konsistente Werte bei CPU Wait Time Per Dispatch
• Auch bei wiederholten Messungen von IIS, DNS, Active-Directory-Abfragen, Domänenauthentifizierung und Datei-I/O zeigte der Snapdragon X Elite fast immer reproduzierbare Zeitwerte; Intel war in einzelnen Durchläufen schneller, insgesamt aber deutlich schwankender
• Der Unterschied wurde nicht allein auf die CPU-Architektur zurückgeführt; zusammen mit Speicher, Arbeitsspeicher, Energieverwaltung und thermischen Eigenschaften spielten vor allem Latenzkonsistenz und vorhersehbares Scheduling bei virtualisierten Serverlasten eine wichtigere Rolle
• Bei Workloads mit Fokus auf maximalen Durchsatz bleibt x64 im Vorteil, doch für typische Windows-Server-Bereitstellungen mit vielen kleinen, latenzempfindlichen Aufgaben wird ARM64 attraktiver; als Standardplattform für die Ausbildung bleibt jedoch x64, da ARM64 keine verschachtelte Virtualisierung unterstützt

---

Testumgebung und Vergleichsmaßstab

• Eine virtuelle Windows Server 2025-Umgebung wurde auf zwei Systemen aufgebaut und verglichen
  • Auf einem Intel Core i9-System der 14. Generation mit Windows 11 wurden mehrere Hyper-V-VMs betrieben
  • Auf einem Snapdragon X Elite-System mit Windows 11 on ARM wurde dieselbe Windows-Server-2025-Umgebung eingerichtet
• Da Microsoft auf seiner Website kein offizielles Installations-ISO für Windows Server 2025 ARM bereitstellt, wurde mit UUP dump ein auf Microsoft-Update-Servern basierendes Image erzeugt und installiert
• Beide Hyper-V-VMs wurden mit identischem Arbeitsspeicher, identischen virtuellen Prozessoren und identischen installierten Rollen konfiguriert
  • Snapdragon X Elite: ARM64 guest on ARM64 host
  • Intel Core i9: x64 guest on x64 host

Erste Beobachtungen und Interpretationsrahmen

• Die Windows-Server-2025-Umgebung auf dem ARM-System lief stabil und ordnungsgemäß und wirkte insgesamt auch im praktischen Einsatz schneller
  • Schnellere Startzeiten von Diensten
  • Schnelleres Öffnen von Verwaltungskonsolen
  • Kürzere Ausführungszeiten für Übungsaufgaben zur Bucherstellung
• Der Leistungsunterschied wurde jedoch nicht ausschließlich auf die CPU-Architektur zurückgeführt
  • Speicherlaufwerk, Arbeitsspeicher, Energieverwaltung und thermische Eigenschaften könnten die Ergebnisse ebenfalls beeinflusst haben
  • Statt „ARM ist schneller“ wurde eine Einordnung anhand der Gesamtsystemeigenschaften betont
• Die typische Dienstlast von Windows Server ist stark threadlastig und geprägt von kleinen, aber häufigen CPU- und I/O-Aufgaben
  • Dazu zählen Active Directory, DNS, DHCP, IIS, SMB/NFS/DFS-Dateidienste, Print Services, Certificate Services, Remote Desktop Services, Routing and Remote Access und NPS
  • Diese Art von Last ist empfindlich gegenüber Latenz und Kontextwechseln, sodass konsistente Leistung klare Vorteile bietet

Beobachtungen zu den Leistungsunterschieden

• ARM-Systeme der Snapdragon-Reihe liefern eher anhaltende und stabile Leistung als das Erzielen möglichst hoher Boost-Taktraten
• Moderne Intel-CPUs können durch Frequenzboost und dynamisches Throttling eine hohe Spitzenleistung liefern
  • Unter Dauerlast oder Mischlast kann das jedoch zu stärkerer Schwankung bei Scheduling und Latenz führen
• In virtualisierten Umgebungen fällt diese Schwankung stärker ins Gewicht
  • Ein Hypervisor wie Hyper-V übernimmt faktisch die Rolle eines Hardware-Schedulers
  • Je vorhersehbarer das Timing der Hardwareausführung ist, desto konsistenter fällt auch das Scheduling des Hypervisors aus
  • Dieser Effekt zeigt sich dann in den VMs und in der Reaktionsfähigkeit der darin laufenden Dienste
• Es wurde auch auf mögliche Unterschiede der Windows Server ARM64-Builds hingewiesen
  • Verschiedenen online gefundenen Release Notes zufolge könnte die ARM64-Version einige Legacy-Kompatibilitätsschichten vermeiden und modernere, stärker optimierte Binärdateien verwenden
  • Beobachtet wurde, dass sie ein aufgeräumterer Build sein könnte als die x64-Version
  • Konkrete Belege zur internen Implementierung wurden jedoch nicht weiter geliefert

Messungen mit Performance Monitor

• Auf beiden Windows-11-Hosts wurden Zähler im Performance Monitor hinzugefügt und gemessen
  • \\Processor(_Total)\\% Processor Time
    • CPU-Auslastung über alle Kerne hinweg
  • \\System\\Processor Queue Length
    • Anzahl der Threads, die auf CPU-Zeit warten
    • Im Idealfall bleibt dieser Wert bei 0
  • \\Hyper-V Hypervisor Virtual Processor(*)\\CPU Wait Time Per Dispatch
    • Durchschnittliche Wartezeit, bis ein virtueller Prozessor CPU-Zeit zugewiesen bekommt
• In jeder VM wurde anschließend per PowerShell Last erzeugt und das Ergebnis beobachtet
  • Es liefen 8 Endlosschleifen, die wiederholt die Ausgabe von Get-Process nach CPU-Auslastung sortierten und die Top 5 abfragten
• In den Messungen zeigte Snapdragon ein anhaltendes und stabiles Leistungsmuster
  • Die Schwankungsbreite von % Processor Time war deutlich geringer
  • Processor Queue Length blieb bei 0
  • Auch CPU Wait Time Per Dispatch blieb flach und konsistent
• Beim Intel-System spiegelte sich die Boost-/Throttling-Variabilität in den Metriken wider
  • % Processor Time schwankte stärker
  • Processor Queue Length stieg periodisch sprunghaft an
  • Auch bei CPU Wait Time Per Dispatch traten deutliche Schwankungen auf

Messung der Dienstreaktionsfähigkeit

• In der PowerShell jeder VM wurden mit Measure-Command typische Dienstoperationen zeitlich gemessen
• Für den IIS-Webserver wurde folgender Test durchgeführt
  • Invoke-WebRequest http://localhost -UseBasicParsing | Out-Null wurde 1000-mal wiederholt
• Auf dieselbe Weise wurden weitere Dienste gemessen
  • DNS
    • Resolve-DnsName "domainX.com" -Server 127.0.0.1 | Out-Null
  • Active-Directory-Abfrage
    • Get-ADUser -Filter * -ResultSetSize 1 | Out-Null
  • Latenz bei der Domänenauthentifizierung
    • Test-ComputerSecureChannel -Verbose:$false
  • Datei-I/O
    • Verzeichnis C:\TestFiles erstellen
    • 2000-mal Dateien erzeugen, Inhalte schreiben, lesen und wieder löschen
• Über mehrere Wiederholungen hinweg lieferte das Snapdragon-System konsistente und reproduzierbare Zeitwerte fast bei jedem Durchlauf
• Das Intel-System zeigte größere Streuung
  • In einzelnen Läufen war es schneller als Snapdragon
  • In den meisten Fällen lag es jedoch zurück
• Insgesamt lautete das Fazit: Snapdragon lag in allen Tests vorn

Zentrale Schlussfolgerung

• Das verbindende Element über alle Ergebnisse hinweg war die Konsistenz der Latenz
• Virtualisierte Windows-Server-Lasten profitieren stark von schneller Reaktion auf kleine, häufige Aufgaben und von vorhersehbarem Scheduling
• Bei Workloads, in denen maximaler Durchsatz entscheidend ist, behalten x64-Systeme weiterhin klare Vorteile
• In Umgebungen wie typischen Windows-Server-Bereitstellungen, in denen viele kleine, latenzempfindliche Aufgaben gleichzeitig unter Virtualisierung laufen, ist Konsistenz wichtiger als reine Spitzengeschwindigkeit
• In diesem Kontext gewinnt ARM64 an Attraktivität
• ARM64 ist in Cloud-Umgebungen bereits weit verbreitet; zudem wurde erwähnt, dass das Preis-Leistungs-Verhältnis besser sein könne als bei x64
• Es wurde angeregt, dass Microsoft einen größeren ARM64-Anteil in der Zukunft von Windows Server in Betracht ziehen sollte
  • Derzeit unterstützt Microsoft Windows Server on ARM64 nicht vollständig
  • Als Zahlen wurden genannt, dass im vergangenen Jahr 33 % der neuen Microsoft-Azure-VM-Instanzen ARM64 waren und bei Amazon AWS 50 % ARM64

Wahl der Standardplattform für Schulungen

• Für die Übungsumgebung des Lehrmaterials bleibt x64 weiterhin der Standard
• Grund dafür ist, dass die Übungen verschachtelte Virtualisierung enthalten
• Da Hyper-V auf ARM64 keine verschachtelte Virtualisierung unterstützt, wird ARM64 derzeit nicht als Standardumgebung für Schulungen verwendet
• Studierende können sich zwar Umgehungslösungen für die Übungen aufbauen, doch eines der Ziele des Lehrmaterials ist Reproduzierbarkeit, daher wird eine Umgebung bevorzugt, die Schritt für Schritt identisch funktioniert
• Zum aktuellen Zeitpunkt bleibt x64 für Ausbildungszwecke die praktischere Wahl

[GN⁺]

Hacker-News-Kommentare

• Die für die Reproduktion des Tests nötigen Einstellungen, Vermutungen und sogar der Code wurden zwar alle offengelegt, aber die tatsächlich wahrgenommenen Ergebniswerte selbst fehlten, weshalb es mir etwas verdächtig vorkam. Ich war neugierig, wie schnell ARM in der Praxis numerisch wirklich war
  • Es gab einen Grund, warum die Ausgabe-Screenshots absichtlich weggelassen wurden. Ich wollte vermeiden, dass der Beitrag als Benchmark-Artikel verwässert wird, und je nach ARM-Hardware oder genauerem Snapdragon-X-Elite-Modell könnten die Ergebnisse variieren und Missverständnisse erzeugen. Stattdessen habe ich ein PowerShell-Snippet eingefügt, damit es jeder reproduzieren kann. Grob gesagt war die Snapdragon-VM je nach Test etwa 20–80 % schneller als die Intel-VM: DNS ungefähr 20 %, IIS etwa 50 %, der Rest meist nahe 80 %
• Aus Sicht eines Windows-Entwicklers sieht es sehr danach aus, dass hier der segment heap eine Rolle spielt. Bei der Heap-Implementierung von Windows gibt es zwei voneinander unabhängige Linien: den alten NT heap und den in den 2010er Jahren eingeführten segment heap. Letzterer war bei Speicherfragmentierung und der Wiederverwendung kleiner Allokationen effizienter. Windows legt aber extrem viel Wert auf Legacy-Kompatibilität, und alte Apps könnten sich auf riskantes Verhalten wie use-after-free oder auf interne NT-heap-Strukturen stützen, weshalb man den Standard nicht pauschal umgestellt hat. Deshalb wurde ein Kompromiss gewählt: Für packaged ausführbare Dateien gilt segment heap standardmäßig, für unpackaged bleibt es beim Alten. Da die UWP-Umstellung aber scheiterte, wurde das Windows-Ökosystem noch stärker zersplittert, und die meiste wichtige Software blieb weiterhin unpackaged x64. arm64-Binärdateien sind dagegen weniger wahrscheinlich alter Legacy-Code, daher ist auf ARM der segment heap standardmäßig aktiviert. Ich denke, ein nicht unerheblicher Teil davon, dass Nutzer ARM-Windows als reaktionsschneller empfinden, liegt genau daran. Es wäre interessant, x64 mit erzwungen aktiviertem segment heap zu testen. Pro ausführbarer Datei kann man unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\.exe den DWORD-Wert FrontEndHeapDebugOptions auf 8 setzen, global unter HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap den DWORD-Wert Enabled auf 3. Auf meinem Entwicklungsrechner habe ich nach globaler Aktivierung keine Probleme gesehen, und der Speicherverbrauch sank im Test um etwa 15 %
  • Bei meinen RAM-/CPU-intensiven Workloads war die Gesamtleistung mit Segment Heap gegenüber NT Heap konstant um etwa 7 % besser. Die zusammengeführte Arbeit war 7 % schneller abgeschlossen. Wenn es frühere Zertifizierungen wie „Compatible with Windows XXX“ auch für Windows 10/11 gegeben hätte, hätte man dort einen segment-heap-Check aufnehmen können, um mehr Apps und Nutzern Vorteile bei Leistung, Energieeffizienz und Nachhaltigkeit zu bringen. Und das Problem von UWP lag meiner Ansicht nach weniger in der Technik selbst als in der Fixierung auf Packaging und Store-Kopplung, was mit der Existenzweise von Windows als OS kollidierte
  • Wer daran interessiert ist, kann in der application manifest der eigenen ausführbaren Datei heapType auf SegmentHeap setzen und dieses Verhalten so per Opt-in aktivieren. Die Dokumentation erklärt das
  • Solche praktischen Tipps sind genau das, was HN wertvoll macht. Mich würde interessieren, ob der globale Registry-Schlüssel einen Neustart erfordert oder ob er ab dem Start einer ausführbaren Datei sofort greift
  • Das war so interessant, dass es eher als Blogbeitrag festgehalten werden sollte als in einem Forenkommentar
  • Früher habe ich diese globale Einstellung als 0 gegenüber non-zero beschrieben gesehen; deshalb frage ich mich, warum der Wert ausgerechnet 3 ist. Ich würde auch gern wissen, was 2 bedeutet und wo man die Bedeutung solcher Werte selbst nachschlagen kann
• Die Formulierung im Artikel, ARM liefere „ohne Jagd nach hohem Boost-Takt eine konstante Leistung“, wirkte auf mich etwas übertrieben. Alle ARM-Systeme, die ich benutzt habe, nutzten ebenfalls Frequenzskalierung und verhielten sich darin ähnlich wie x86. Der Unterschied schien am Ende eher zu sein, wie hoch sie tatsächlich takten
  • Das hängt sicher vom Workload ab, aber in den Cloud-Umgebungen mehrerer Organisationen, in denen ich gearbeitet habe, brachte allein der Wechsel auf ARM unter x86 bereits spürbare Kostensenkungen. Die Instanzpreise waren niedriger und die Effizienz besser. Besonders in einer Organisation mit Hunderten Kubernetes-Knoten und dynamischem Autoscaling wurde ohne weitere Änderungen allein durch x86 -> ARM konservativ ein Einsparpotenzial von rund 15 % erwartet, und das wurde auch erreicht. Bei CPU-gebundenen Workloads, die weniger an x86-spezifische Funktionen gebunden sind, könnte es deutlich mehr als 15 % sein
• Wenn der entscheidende Punkt die geringere Schwankung und bessere Vorhersagbarkeit der ARM-CPU-Leistung war, dann müsste man ähnliche Vorteile auch mit einer Server-CPU wie Epyc statt einer Desktop-CPU sehen können. Server-CPUs haben geringere Taktsschwankungen und weniger aggressive Boost-Richtlinien. Sogar auf vorhandener Desktop-Hardware könnte man zum Vergleich im BIOS Turbo deaktivieren und so eine Intel-CPU auf den Basistakt festlegen, um zwar niedrigere, aber stabile und vorhersagbare Leistung zu erhalten
  • Auch im Energiesparplan ließ sich das Turbo-Verhalten deaktivieren. Allerdings war diese Option in der GUI möglicherweise nicht standardmäßig sichtbar
• Ich fragte mich, ob Windows on ARM VBS beziehungsweise Virtualization Based Security verwendet und ob das in einer VM per Nested Virtualization unterstützt wird. Wichtig wäre auch, ob CPU-Schwachstellen-Mitigations in der VM doppelt greifen und so die Leistung beeinflussen. Ein erheblicher Teil der Performance-Probleme, die man heute häufig bei Windows in VMs sieht, kommt daher. Schade, dass der Beitrag diesen Punkt nicht erwähnt hat
• Ich war neugierig auf die RAM- und Speicher-Konfiguration beider Systeme. Auf der Snapdragon-Seite könnte gepackter RAM schnellere Interconnects haben, während es auf der x86-Seite DIMMs mit längeren Signalwegen sein könnten. Auch Storage oder CPU-Modell können die Leistung stark beeinflussen. Benchmarks reizen oft nur einen einzelnen Teil eines Systems übermäßig aus, daher könnte der eigentliche Unterschied eher von RAM, Syscalls, SSDs oder anderen Faktoren kommen als von der ARM-Architektur selbst
  • Beide Systeme nutzten auf dem Mainboard verlötetes DDR5 und NVMe-SSDs. Die Intel-Seite hatte sogar ein schnelleres Samsung-Modell als das Foresee-Laufwerk auf der Snapdragon-Seite
• Unter Linux läuft sowieso alles besser, und es fühlt sich so an, als würde man keine Taktzyklen an Überwachungs-Overhead verschwenden
• Es wirkte auf mich so, als würde der Artikel absichtlich nicht sagen, welcher Intel-Prozessor es war, und ich fragte mich, ob ich etwas übersehen hatte
  • Die verwendete CPU war ein Intel Core i9 der 14. Generation
• Auf HV-Servern verhindert man bei x86 oft ein Heruntertakten, etwa durch Deaktivieren von C States oder ein Power-Management auf High. Wenn die CPU nicht ständig hoch- und runtergeht, kann die Leistung deutlich besser werden. Solche Einstellungen nimmt man bei Privat- oder Laborsystemen allerdings meist nicht vor
  • Oder man deaktiviert einfach nur Turbo Boost
• Nach der Lektüre schien mir der Kern aus zwei Punkten zu bestehen. Erstens ist ARM64 womöglich weniger „smart“ als x64 und liefert statt des aggressiven Boost- und Throttling-Verhaltens wie bei einem Core i9 eher konstante Leistung, was das OS-Scheduling erleichtert. Zweitens könnte Windows auf ARM auch deshalb effizienter sein, weil es dort weniger historischen Ballast gibt als bei x64. Am Ende fragte ich mich, ob CPU-Throttling inzwischen so intelligent geworden ist, dass es gerade dadurch schadet
  • Man muss aber mitbedenken, dass hier ein Server-OS auf einer Desktop-x86-CPU getestet wurde. x86-Server-CPUs wie AMD Epyc oder Intel Xeon haben geringere Taktspielräume und weniger aggressive Richtlinien und liefern daher konstantere und besser vorhersagbare Leistung als Desktop-CPUs. Das ist bei Multithread-Workloads vorteilhaft, während Desktop-CPUs auf maximale Single-Thread-Leistung getrimmt sind und deshalb bei Multithreading sogar im Nachteil sein können