Windows Server 2025 fonctionne mieux sur ARM

• Dans une comparaison virtualisée de Windows Server 2025, la configuration avec hôte ARM64 et invité ARM64 a fonctionné de manière stable, avec une meilleure réactivité perçue pour le démarrage des services, le lancement des consoles d’administration et l’exécution des tâches pratiques
• Les deux VM ont été configurées à l’identique en mémoire, processeurs virtuels et rôles installés. Lors des mesures, le système Snapdragon a montré des variations plus faibles de l’utilisation CPU, un Processor Queue Length maintenu à 0, et des valeurs cohérentes pour CPU Wait Time Per Dispatch
• Sur les mesures répétées d’IIS, DNS, des requêtes Active Directory, de l’authentification de domaine et des E/S de fichiers, le Snapdragon X Elite a presque toujours produit des temps reproductibles. Intel a parfois été plus rapide sur certains essais, mais avec une variabilité globale plus importante
• La différence n’est pas attribuée au seul type d’architecture CPU. Les caractéristiques du stockage, de la mémoire, de la gestion de l’alimentation et de la dissipation thermique comptent aussi, mais la cohérence de la latence et un ordonnancement prévisible semblent plus importants pour des charges serveur virtualisées
• Pour les charges centrées sur le débit maximal, x64 conserve des atouts, mais dans les déploiements Windows Server typiques avec de nombreuses petites tâches sensibles à la latence, l’intérêt d’ARM64 augmente. En revanche, la plateforme standard pour l’enseignement reste x64, faute de prise en charge de la virtualisation imbriquée sur ARM64

---

Environnement de test et critères de comparaison

• Un environnement virtualisé Windows Server 2025 a été mis en place sur deux systèmes pour comparaison
  • Un système Intel Core i9 de 14e génération sous Windows 11 exécutant plusieurs machines virtuelles Hyper-V
  • Un système Snapdragon X Elite sous Windows 11 on ARM avec le même environnement Windows Server 2025
• Comme Microsoft ne fournit pas d’ISO officiel d’installation de Windows Server 2025 ARM sur son site, l’installation a été réalisée à partir d’une image générée via UUP dump depuis les serveurs de mise à jour de Microsoft
• Les deux VM Hyper-V ont été configurées de manière identique en mémoire, processeurs virtuels et rôles installés
  • Le Snapdragon X Elite utilisait ARM64 guest on ARM64 host
  • L’Intel Core i9 utilisait x64 guest on x64 host

Observations initiales et portée de l’interprétation

• L’environnement Windows Server 2025 sur le système ARM s’est montré stable, fonctionnel, et globalement plus rapide dans l’usage réel
  • Démarrage plus rapide des services
  • Lancement plus rapide des consoles d’administration
  • Réduction du temps nécessaire pour les travaux pratiques liés à la rédaction d’un manuel
• Cela dit, l’écart de performances n’est pas présenté comme le résultat du seul choix d’architecture CPU
  • Le stockage, la mémoire, la gestion de l’alimentation et le comportement thermique peuvent aussi influencer les résultats
  • Plutôt qu’affirmer que « ARM est plus rapide », il faut interpréter les résultats à l’échelle des caractéristiques globales du système
• Les charges de service typiques de Windows Server sont généralement fortement orientées threads et reposent sur de petites opérations CPU et I/O fréquentes
  • Cela inclut Active Directory, DNS, DHCP, IIS, les services de fichiers SMB/NFS/DFS, Print Services, Certificate Services, Remote Desktop Services, Routing and Remote Access, NPS, etc.
  • Ce type de charge est sensible à la latence et aux changements de contexte, et bénéficie d’une performance constante dans le temps

Observations sur les écarts de performances

• Les systèmes ARM de la famille Snapdragon ont tendance à privilégier une performance soutenue et stable plutôt qu’une quête de fréquences boost maximales
• Les CPU Intel récents peuvent offrir des performances de pointe élevées grâce à l’accélération de fréquence et au throttling dynamique
  • En contrepartie, sous charge soutenue ou mixte, cela peut accroître la variabilité de l’ordonnancement et de la latence
• En environnement virtualisé, cette variabilité devient plus importante
  • Un hyperviseur comme Hyper-V joue en pratique un rôle de planificateur matériel
  • Plus le timing d’exécution matériel est prévisible, plus l’ordonnancement de l’hyperviseur produit des résultats cohérents
  • Cet effet se répercute sur les VM et sur la réactivité des services qu’elles exécutent
• Une différence propre à la build Windows Server ARM64 est également évoquée
  • D’après plusieurs notes de version consultées en ligne, la version ARM64 pourrait éviter certaines couches de compatibilité legacy et utiliser des binaires plus modernes et mieux optimisés
  • Elle pourrait donc être une build plus épurée que la version x64
  • Aucun élément technique interne précis supplémentaire n’est toutefois apporté

Mesures avec Performance Monitor

• Des compteurs Performance Monitor ont été ajoutés sur les deux hôtes Windows 11 pour effectuer les mesures
  • \\Processor(_Total)\\% Processor Time
    • Utilisation CPU sur l’ensemble des cœurs
  • \\System\\Processor Queue Length
    • Nombre de threads en attente de temps CPU
    • Idéalement, la valeur doit rester à 0
  • \\Hyper-V Hypervisor Virtual Processor(*)\\CPU Wait Time Per Dispatch
    • Temps moyen d’attente avant qu’un processeur virtuel soit planifié sur le CPU
• Une charge a ensuite été générée depuis PowerShell à l’intérieur de chaque VM
  • Huit boucles infinies ont été lancées pour interroger à répétition les 5 premiers processus triés par consommation CPU à partir du résultat de Get-Process
• Les résultats montrent que le Snapdragon présente un profil de performance soutenu et stable
  • Les variations de % Processor Time sont nettement plus faibles
  • Processor Queue Length reste à 0
  • CPU Wait Time Per Dispatch demeure lui aussi plat et cohérent
• Sur le système Intel, la variabilité due au boost/throttling apparaît dans les métriques
  • Les variations de % Processor Time sont plus importantes
  • Processor Queue Length augmente périodiquement de façon marquée
  • CPU Wait Time Per Dispatch présente aussi des fluctuations significatives

Mesure de la réactivité des services

• Le temps d’exécution d’opérations de service courantes a été mesuré depuis PowerShell dans chaque VM avec Measure-Command
• Un test a été réalisé sur le serveur web IIS
  • Invoke-WebRequest http://localhost -UseBasicParsing | Out-Null répété 1000 fois
• D’autres services ont été mesurés de la même manière
  • DNS
    • Resolve-DnsName "domainX.com" -Server 127.0.0.1 | Out-Null
  • Requête Active Directory
    • Get-ADUser -Filter * -ResultSetSize 1 | Out-Null
  • Latence d’authentification au domaine
    • Test-ComputerSecureChannel -Verbose:$false
  • E/S de fichiers
    • Création du répertoire C:\TestFiles
    • Répétition 2000 fois des opérations de création de fichier, écriture, lecture et suppression
• Sur plusieurs séries d’exécution, le système Snapdragon a presque toujours produit des temps cohérents et reproductibles
• Le système Intel a montré une plus grande dispersion des résultats
  • Il a parfois été plus rapide que le Snapdragon sur certains essais
  • Mais dans la plupart des cas, il était derrière
• Globalement, la conclusion est que Snapdragon l’emporte sur l’ensemble des tests

Conclusion principale

• Le facteur commun qui ressort de l’ensemble des résultats est la cohérence de la latence
• Les charges Windows Server virtualisées accordent une grande importance à la réponse rapide aux petites opérations fréquentes et à un ordonnancement prévisible
• Pour les charges où le débit maximal prime, les systèmes x64 conservent encore des avantages nets
• À l’inverse, dans des environnements typiques de Windows Server où de nombreuses petites tâches sensibles à la latence s’exécutent ensemble sous virtualisation, la cohérence compte plus que la vitesse de pointe absolue
• Dans ce contexte, l’attrait d’ARM64 augmente
• ARM64 est déjà largement utilisé dans le cloud, et il est mentionné qu’il offre un meilleur rapport performance/coût que x64
• Il est suggéré que Microsoft devrait envisager d’accroître la place d’ARM64 dans l’avenir de Windows Server
  • Microsoft ne prend actuellement pas entièrement en charge Windows Server on ARM64
  • Mais il est indiqué que l’an dernier, 33 % des nouvelles instances de VM Microsoft Azure étaient en ARM64, contre 50 % sur Amazon AWS

Choix de la plateforme standard pour l’enseignement

• L’environnement pratique utilisé pour le manuel reste standardisé sur x64
• La raison est que la configuration des travaux pratiques inclut de la virtualisation imbriquée
• Comme Hyper-V ne prend pas en charge la virtualisation imbriquée sur ARM64, ARM64 n’est pas adopté pour l’instant comme environnement d’enseignement par défaut
• Les étudiants peuvent contourner cette limite dans leur propre configuration, mais l’un des objectifs du manuel est la reproductibilité, d’où la priorité donnée à un environnement identique étape par étape
• À ce stade, pour un usage pédagogique, x64 reste le choix le plus pratique

[GN⁺]

Avis Hacker News

• Les réglages, hypothèses et même le code nécessaires pour reproduire le test ont tous été publiés, mais il manquait la sensation de résultat elle-même, ce qui m’a rendu un peu méfiant. Je voulais savoir en chiffres à quel point ARM était réellement plus rapide.
  • Il y avait une raison au fait d’avoir volontairement omis les captures d’écran de sortie. Je voulais éviter que cela dérive en article de benchmark, et selon le matériel ARM ou le modèle précis de Snapdragon X Elite, les résultats pouvaient varier et prêter à confusion. À la place, j’ai inclus un snippet PowerShell pour que tout le monde puisse reproduire le test. En gros, la VM Snapdragon était environ 20 à 80 % plus rapide que la VM Intel selon les tests : DNS autour de 20 %, IIS autour de 50 %, et le reste plutôt proche de 80 %.
• Du point de vue d’un développeur Windows, cela semblait très probablement lié au segment heap. L’implémentation du tas Windows comporte deux familles indépendantes : l’ancien NT heap et le segment heap apparu dans les années 2010, ce dernier étant plus efficace en matière de fragmentation mémoire et de réutilisation des petites allocations. Mais Windows accorde une importance extrême à la compatibilité legacy, donc le basculement du comportement par défaut n’a pas été généralisé, car d’anciennes applications pouvaient dépendre de comportements risqués comme le use-after-free ou de structures internes du NT heap. Ils ont donc choisi un compromis : activer le segment heap par défaut pour les exécutables packaged, et laisser les unpackaged inchangés. Or, comme la transition vers UWP a échoué, l’écosystème Windows s’est davantage fragmenté, et l’essentiel des logiciels importants est resté en x64 unpackaged. En revanche, les binaires arm64 ont moins de chances d’être du vieux code legacy, donc le segment heap est activé par défaut sur ARM. À mon avis, une part non négligeable du ressenti de meilleure réactivité de Windows sur ARM vient de là. Ce serait intéressant de refaire ce test en forçant le segment heap sur x64. Par exécutable, il suffit de définir le DWORD FrontEndHeapDebugOptions à 8 sous HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\.exe, et globalement, de définir le DWORD Enabled à 3 sous HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap. Sur ma machine de dev, je n’ai vu aucun problème après activation globale, et l’usage mémoire a diminué d’environ 15 % sur mes tests.
  • Sur mes workloads intensifs en RAM/CPU, les performances globales étaient de façon stable environ 7 % meilleures avec Segment Heap qu’avec NT Heap. Le travail combiné se terminait 7 % plus vite. S’il existait encore sous Windows 10/11 une sorte de certification comme les anciens « Compatible with Windows XXX », on pourrait y ajouter une vérification segment heap pour faire profiter davantage d’apps et d’utilisateurs des gains en performances, efficacité énergétique et impact environnemental. Et pour moi, le vrai problème d’UWP n’était pas tant la technologie elle-même que l’obstination à la lier au packaging et au Store, ce qui entrait en conflit avec la manière même dont Windows existe comme OS.
  • Pour ceux que cela intéresse, il est possible d’opter pour ce comportement en définissant heapType sur SegmentHeap dans l’application manifest de son exécutable. C’est expliqué dans la documentation.
  • C’est exactement ce genre de conseils pratiques qui fait la valeur de HN. Je me demandais si la clé de registre globale nécessite un redémarrage, ou si elle s’applique immédiatement à partir du lancement des exécutables.
  • C’était suffisamment intéressant pour mériter un article de blog plutôt qu’un simple commentaire de forum.
  • J’avais déjà vu par le passé ce réglage global décrit comme 0 contre non-zéro, donc je me demandais pourquoi la valeur était précisément 3. J’aimerais aussi savoir ce que signifie 2 et où l’on peut vérifier soi-même le sens de ces valeurs.
• La formulation de l’article selon laquelle « ARM ne cherche pas des boost clocks élevés et délivre des performances régulières » m’a paru un peu exagérée. Tous les systèmes ARM que j’ai utilisés faisaient aussi du frequency scaling, et à ce niveau ils se comportaient comme du x86. Au final, la différence semblait surtout porter sur jusqu’où ça montait.
  • Cela dépend sans doute des workloads, mais dans les environnements cloud de plusieurs organisations où j’ai travaillé, le simple passage à ARM depuis x86 avait déjà produit des économies notables. Les instances coûtaient moins cher et étaient aussi plus efficaces. Dans une organisation en particulier, avec des centaines de nœuds Kubernetes en autoscaling dynamique, passer de x86 à ARM sans autre changement permettait d’anticiper prudemment environ 15 % d’économies, et c’est ce qui a effectivement été obtenu. Pour des workloads CPU-bound moins liés à des fonctions spécifiques à x86, cela peut probablement être bien supérieur à 15 %.
• Si le point clé venait des performances moins fluctuantes et plus prévisibles des CPU ARM, je pensais qu’on pourrait voir un avantage similaire en utilisant un CPU serveur comme un Epyc au lieu d’un CPU desktop. Les CPU serveur ont moins de variation d’horloge et des politiques de boost moins agressives. Même sur le matériel desktop existant, on pourrait désactiver le Turbo dans le BIOS pour fixer un CPU Intel à sa fréquence de base, et comparer ainsi avec des performances plus basses mais stables et prévisibles.
  • On pouvait aussi désactiver le turbo via le plan de gestion d’alimentation. Ce réglage n’est cependant pas forcément visible par défaut dans l’interface graphique.
• Je me demandais si Windows on ARM utilisait VBS ou Virtualization Based Security, et si cela était pris en charge dans une VM via de la virtualisation imbriquée. Il semblait aussi important de savoir si les mitigations de vulnérabilités CPU s’appliquaient deux fois dans la VM, au point d’affecter les performances. Une bonne partie des problèmes de performances qu’on voit aujourd’hui avec Windows dans une VM vient souvent de là. J’ai trouvé dommage que l’article n’en parle pas.
• Je me demandais quelle était la configuration RAM et stockage des deux systèmes. Du côté Snapdragon, la RAM packagée pouvait offrir une interconnexion plus rapide, alors que du côté x86, avec des DIMM, les traces pouvaient être plus longues. Le stockage ou le modèle de CPU peuvent aussi fortement influencer les performances. Les benchmarks sollicitent souvent de manière excessive une seule partie du système, donc la vraie différence pouvait venir moins de l’architecture ARM elle-même que d’autres éléments comme la RAM, les syscalls ou le SSD.
  • Les deux systèmes utilisaient de la DDR5 soudée sur la carte mère et un SSD NVMe. En fait, le SSD côté Intel était même un modèle Samsung plus rapide que le Foresee côté Snapdragon.
• Sous Linux, tout fonctionne mieux de toute façon, sans gaspiller des cycles en surcoût de surveillance.
• L’article donnait l’impression d’éviter volontairement de dire quel était le processeur Intel, donc je me demandais si j’avais raté quelque chose.
  • Le CPU utilisé était un Intel Core i9 de 14e génération.
• Sur les serveurs HV, on empêche souvent le x86 de sous-cadencer en désactivant les C States et en configurant l’alimentation sur élevé. Empêcher le CPU d’osciller vers le haut et vers le bas peut beaucoup améliorer les performances. Mais ce genre de réglage n’est généralement pas fait sur des machines personnelles ou de labo.
  • Ou alors, il suffit simplement de désactiver le turbo boost.
• Après lecture, j’avais l’impression que l’idée centrale était double. D’abord, ARM64 serait moins « intelligent » que x64 : au lieu d’enchaîner boosts et throttling de façon agressive comme un Core i9, il fournirait des performances plus constantes, ce qui faciliterait l’ordonnancement par l’OS. Ensuite, Windows semble avoir moins de bagage historique sur ARM que sur x64, si bien que le build ARM lui-même pourrait être plus efficace. Je me demandais donc si l’on n’était pas arrivé à un point où le throttling CPU est devenu trop intelligent au point d’en être contre-productif.
  • Cela dit, il faut aussi garder en tête qu’il s’agit ici d’un OS serveur testé sur un CPU desktop x86. Les CPU serveur x86 comme les AMD Epyc ou Intel Xeon ont des plages de variation de fréquence plus faibles et des politiques moins agressives, donc ils offrent des performances plus constantes et prévisibles que les CPU desktop. Ce type de caractéristiques favorise les workloads multithread, alors que les CPU desktop, optimisés pour le pic de performance en mono-thread, peuvent au contraire y perdre en multithread.