Windows Server 2025 funciona mejor en ARM

• En una comparación virtualizada de Windows Server 2025, la configuración con huésped ARM64 sobre host ARM64 funcionó de forma estable, y también mostró una respuesta perceptiblemente más rápida al iniciar servicios, abrir consolas de administración y ejecutar tareas prácticas.
• Ambas VM se configuraron con la misma memoria, procesadores virtuales y roles instalados; en las mediciones, el sistema con Snapdragon mostró una variación mucho menor en el uso de CPU, mantuvo Processor Queue Length en 0 y registró valores consistentes en CPU Wait Time Per Dispatch.
• En mediciones repetidas de IIS, DNS, consultas de Active Directory, autenticación de dominio y E/S de archivos, Snapdragon X Elite mostró tiempos reproducibles casi en cada ejecución; Intel fue más rápido en algunas corridas, pero en general tuvo más variación.
• No se atribuyó la diferencia únicamente a la arquitectura de CPU; junto con almacenamiento, memoria, administración de energía y características térmicas, la consistencia de la latencia y una programación predecible resultaron más importantes para cargas de servidor virtualizadas.
• En cargas centradas en el rendimiento máximo, x64 aún conserva ventajas, pero en despliegues típicos de Windows Server con muchas tareas pequeñas sensibles a la latencia, ARM64 gana atractivo; aun así, la plataforma estándar para enseñanza sigue siendo x64 por la falta de virtualización anidada en ARM64.

---

Entorno de pruebas y criterios de comparación

• Se comparó Windows Server 2025 en entornos virtuales montados por separado en dos sistemas.
  • Un sistema con Intel Core i9 de 14.ª generación basado en Windows 11 ejecutando varias máquinas virtuales Hyper-V.
  • Un sistema con Snapdragon X Elite basado en Windows 11 on ARM con el mismo entorno de Windows Server 2025.
• Como el sitio web de Microsoft no ofrece una ISO oficial de instalación de Windows Server 2025 ARM, se generó una imagen basada en los servidores de actualizaciones de Microsoft usando UUP dump y se instaló desde ahí.
• Las dos VM de Hyper-V se configuraron con la misma memoria, procesadores virtuales y roles instalados.
  • Snapdragon X Elite: ARM64 guest on ARM64 host
  • Intel Core i9: x64 guest on x64 host

Observaciones iniciales y alcance de la interpretación

• El entorno de Windows Server 2025 en el sistema ARM fue estable, funcionó correctamente y, en términos percibidos, también fue más rápido en general a un nivel apto para uso real.
  • Inicio de servicios más rápido
  • Apertura de consolas de administración más rápida
  • Menor tiempo para completar tareas prácticas usadas en la redacción de material didáctico
• Aun así, no se concluyó que la diferencia de rendimiento fuera resultado exclusivo de la arquitectura de CPU.
  • El almacenamiento, la memoria, la administración de energía y las características térmicas también pueden influir en los resultados.
  • En lugar de afirmar que “ARM es más rápido”, se plantea que debe interpretarse según las características del sistema completo.
• La carga típica de servicios de Windows Server suele tener muchos hilos y se basa en tareas pequeñas pero frecuentes de CPU y E/S.
  • Incluye Active Directory, DNS, DHCP, IIS, servicios de archivos SMB/NFS/DFS, Print Services, Certificate Services, Remote Desktop Services, Routing and Remote Access, NPS, entre otros.
  • Este tipo de carga es sensible a la latencia y al cambio de contexto, por lo que se beneficia de un rendimiento sostenidamente consistente.

Observaciones sobre la diferencia de rendimiento

• Los sistemas ARM de la familia Snapdragon tienden a ofrecer rendimiento sostenido y estable más que buscar clocks boost muy altos.
• Los CPU Intel modernos pueden ofrecer un rendimiento máximo elevado gracias a la aceleración de frecuencia y el throttling dinámico.
  • A cambio, bajo cargas sostenidas o mixtas, puede aumentar la variabilidad en la programación y la latencia.
• En entornos virtualizados, esa variabilidad se vuelve más importante.
  • Un hipervisor como Hyper-V actúa en la práctica como un programador de hardware.
  • Cuanto más predecible sea el timing de ejecución del hardware, más consistentes serán también los resultados de programación del hipervisor.
  • Ese efecto se refleja en la VM y en la capacidad de respuesta de los servicios dentro de ella.
• También se menciona la posibilidad de diferencias en la propia compilación ARM64 de Windows Server.
  • Según varias notas de lanzamiento revisadas en línea, la versión ARM64 podría evitar algunas capas de compatibilidad heredadas y usar binarios más modernos y optimizados.
  • Se observa que podría ser una compilación más limpia que la versión x64.
  • No se aportan pruebas adicionales sobre la implementación interna concreta.

Mediciones con Performance Monitor

• Se agregaron contadores de Performance Monitor en ambos hosts con Windows 11 para realizar las mediciones.
  • \\Processor(_Total)\\% Processor Time
    • Uso de CPU sobre el total de núcleos
  • \\System\\Processor Queue Length
    • Cantidad de hilos esperando tiempo de CPU
    • Idealmente, conviene que se mantenga en 0
  • \\Hyper-V Hypervisor Virtual Processor(*)\\CPU Wait Time Per Dispatch
    • Tiempo promedio que un procesador virtual espera antes de ser programado en la CPU
• Luego se generó carga desde PowerShell dentro de cada VM y se observaron los resultados.
  • Se ejecutaron 8 bucles infinitos que consultaban repetidamente los 5 procesos con mayor uso de CPU ordenando la salida de Get-Process.
• En los resultados, Snapdragon mostró un patrón de rendimiento sostenido y estable.
  • La variación en % Processor Time fue mucho menor.
  • Processor Queue Length se mantuvo en 0.
  • CPU Wait Time Per Dispatch también conservó valores planos y consistentes.
• En el sistema Intel, la variabilidad por boost/throttling se reflejó en los indicadores.
  • Hubo mayor variación en % Processor Time.
  • Processor Queue Length aumentó bruscamente de forma periódica.
  • CPU Wait Time Per Dispatch también mostró fluctuaciones significativas.

Medición de capacidad de respuesta de servicios

• En PowerShell dentro de cada VM se usó Measure-Command para medir el tiempo de tareas de servicio comunes.
• Se realizó una prueba sobre un servidor web IIS.
  • Invoke-WebRequest http://localhost -UseBasicParsing | Out-Null repetido 1000 veces
• De la misma manera, también se midieron otros servicios en repetición.
  • DNS
    • Resolve-DnsName "domainX.com" -Server 127.0.0.1 | Out-Null
  • Consulta de Active Directory
    • Get-ADUser -Filter * -ResultSetSize 1 | Out-Null
  • Latencia de autenticación de dominio
    • Test-ComputerSecureChannel -Verbose:$false
  • E/S de archivos
    • Creación del directorio C:\TestFiles
    • Repetir 2000 veces: crear archivo, escribir contenido, leerlo y eliminarlo
• Tras varias ejecuciones, el sistema Snapdragon registró tiempos consistentes y reproducibles casi siempre.
• El sistema Intel mostró mayor variación en los resultados.
  • En algunas corridas fue más rápido que Snapdragon.
  • Pero en la mayoría de los casos quedó por detrás.
• En conjunto, la conclusión fue que Snapdragon se impuso en todas las pruebas.

Conclusiones clave

• El elemento común que atraviesa los resultados es la consistencia de la latencia.
• Las cargas virtualizadas de Windows Server dependen mucho de la respuesta rápida a tareas pequeñas y frecuentes y de una programación predecible.
• En cargas donde importa el rendimiento máximo, los sistemas x64 todavía mantienen ventajas claras.
• En cambio, en entornos como los despliegues típicos de Windows Server, donde se ejecutan juntas muchas tareas pequeñas sensibles a la latencia bajo virtualización, la consistencia importa más que la velocidad pico.
• En ese contexto, ARM64 gana atractivo.
• ARM64 ya se usa ampliamente en la nube, y también se menciona que ofrece una mejor relación rendimiento/costo que x64.
• Se plantea que Microsoft debería considerar ampliar el peso de ARM64 en el futuro de Windows Server.
  • Actualmente Microsoft no brinda soporte completo a Windows Server on ARM64.
  • Sin embargo, se citan cifras según las cuales el año pasado 33% de las nuevas instancias de VM de Microsoft Azure fueron ARM64, y en Amazon AWS el 50% fueron ARM64.

Elección de la plataforma estándar para enseñanza

• El entorno práctico para el material didáctico sigue estandarizado en x64.
• La razón es que la configuración de laboratorio incluye virtualización anidada.
• Como Hyper-V no admite virtualización anidada en ARM64, ARM64 no se adopta por ahora como entorno base para enseñanza.
• Aunque el estudiante podría adaptar el laboratorio por su cuenta, uno de los objetivos del material es la reproducibilidad, así que se prioriza un entorno que funcione igual paso a paso.
• Por ahora, para fines educativos, x64 sigue siendo la opción práctica.

[GN⁺]

Comentarios en Hacker News

• Publicaron toda la configuración, las suposiciones e incluso el código necesarios para reproducir la prueba, pero faltaban los resultados percibidos como tal, así que me dejó algo desconfiado. Quería ver cifras de qué tanto más rápido era ARM en la práctica
  • Había una razón para omitir a propósito las capturas de pantalla de la salida. Quería evitar que se desviara hacia una publicación de benchmarks, y me parecía que los resultados podían variar según el hardware ARM o el modelo específico de Snapdragon X Elite y causar malentendidos. En cambio, incluí un fragmento de PowerShell para que cualquiera pudiera reproducirlo. A grandes rasgos, la VM con Snapdragon fue entre un 20% y un 80% más rápida que la VM con Intel según la prueba: DNS alrededor de un 20%, IIS cerca de un 50%, y el resto en general más cerca del 80%
• Desde la perspectiva de un desarrollador de Windows, esto parecía muy probablemente un efecto de segment heap. En la implementación del heap de Windows hay dos líneas independientes: el viejo NT heap y el segment heap de la década de 2010, y el segment heap era más eficiente en fragmentación de memoria y reutilización de asignaciones pequeñas. Pero como Windows prioriza al extremo la compatibilidad con legado, no cambiaron el valor predeterminado de forma masiva porque las apps antiguas podían depender de comportamientos peligrosos como use-after-free o de estructuras internas del NT heap. Así que optaron por un punto medio: aplicar segment heap por defecto a los ejecutables empaquetados y dejar igual los no empaquetados. Pero como la transición a UWP fracasó, el ecosistema de Windows se fragmentó aún más, y la mayor parte del software importante siguió siendo x64 no empaquetado. En cambio, los binarios arm64 tenían menos probabilidades de ser código legado antiguo, así que en ARM el segment heap viene activado por defecto. Creo que una parte nada menor de por qué los usuarios sienten que Windows en ARM responde mejor viene de ahí. Sería interesante repetir esta prueba forzando segment heap en x64. Por ejecutable, se puede establecer FrontEndHeapDebugOptions DWORD en 8 bajo HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\.exe, y de forma global se puede establecer Enabled DWORD en 3 bajo HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap. En mi máquina de desarrollo no vi problemas tras activarlo globalmente, y el uso de memoria bajó alrededor de un 15% en mis pruebas
  • En mis cargas de trabajo intensivas en RAM/CPU, el rendimiento total mejoró de forma consistente cerca de un 7% con Segment Heap frente a NT Heap. El trabajo combinado terminó aproximadamente 7% más rápido. Si certificaciones antiguas como "Compatible with Windows XXX" siguieran existiendo en Windows 10/11, habría sido bueno incluir aquí una verificación de segment heap para dar a más apps y usuarios beneficios de rendimiento, eficiencia energética y menor impacto ambiental. Y el problema de UWP, en mi opinión, no era tanto la tecnología en sí sino la insistencia en acoplarla al empaquetado y a la Store, algo que chocaba con la forma misma en que existe Windows como sistema operativo
  • Si a alguien le interesa, puede hacer opt-in a este comportamiento configurando heapType como SegmentHeap en el application manifest de su ejecutable. Está explicado en la documentación
  • Este tipo de consejos prácticos son justo lo que hace valioso a HN. Me preguntaba si la clave global del registro requiere reinicio, o si se aplica de inmediato desde el momento en que inicia el ejecutable
  • Esto era lo bastante interesante como para merecer quedar como una entrada de blog y no solo como un comentario en un foro
  • Recuerdo haber visto antes esta configuración global explicada como 0 frente a non-zero, así que me preguntaba por qué el valor era específicamente 3. También quería saber qué significa 2 y dónde se puede consultar por cuenta propia el significado de esos valores
• La frase del artículo de que "ARM no persigue boost clocks altos y entrega un rendimiento constante" me pareció algo exagerada. Todos los sistemas ARM que he usado hacían escalado de frecuencia, y en eso se comportaban parecido a x86. Al final, la diferencia me parecía más bien cuánto suben de frecuencia
  • Seguramente depende de la carga de trabajo, pero en los entornos de nube de varias organizaciones donde trabajé, cambiar de x86 a ARM por sí solo ya producía ahorros importantes. Las instancias costaban menos y además eran más eficientes. En una organización en particular, con cientos de nodos de Kubernetes en autoescalado dinámico, sin cambios adicionales pasar de x86 -> ARM nos permitió estimar de forma conservadora un ahorro de alrededor del 15%, y efectivamente lo logramos. Si la carga está limitada por CPU y depende menos de funciones específicas de x86, creo que puede ser bastante más que 15%
• Si la clave era el rendimiento menos variable y más predecible de la CPU ARM, pensaba que también se podrían ver beneficios similares usando CPU de servidor como Epyc en lugar de una CPU de escritorio. Las CPU de servidor tienen menos variación de reloj y políticas de boost menos agresivas. Incluso con hardware de escritorio actual, uno podría apagar Turbo en el BIOS y fijar una CPU Intel a su reloj base para comparar con un rendimiento más bajo pero estable y predecible
  • También se podía desactivar el comportamiento de turbo desde el plan de energía. Aunque esa opción quizá no aparezca por defecto en la GUI
• Me preguntaba si Windows on ARM usa VBS o Virtualization Based Security, y si eso está soportado también dentro de una VM mediante nested virtualization. También parecía importante saber si las mitigaciones de vulnerabilidades de CPU se aplican dos veces dentro de la VM y afectan el rendimiento. Buena parte de los problemas de rendimiento que hoy se ven comúnmente al poner Windows en una VM vienen de ahí. Me pareció una lástima que el artículo no mencionara esa parte
• Tenía curiosidad por la configuración de RAM y almacenamiento de ambos sistemas. Del lado de Snapdragon podría haber RAM empaquetada con interconexión más rápida, mientras que del lado x86 podrían ser DIMM con trazas más largas. El almacenamiento o el modelo de CPU también pueden influir mucho en el rendimiento. Los benchmarks a menudo fuerzan en exceso solo una parte del sistema, así que pensaba que la diferencia real podría venir no tanto de la arquitectura ARM en sí sino de otros factores como RAM, syscalls o SSD
  • Ambos sistemas usaban DDR5 soldada a la placa base y SSD NVMe. De hecho, el SSD del lado Intel era un modelo Samsung más rápido que el Foresee del lado Snapdragon
• En Linux todo corre mejor, y uno no desperdicia ciclos en sobrecarga de vigilancia
• El artículo parecía evitar a propósito decir qué procesador Intel era, así que me preguntaba si yo me había perdido algo
  • La CPU usada era una 14th Gen Intel Core i9
• En servidores HV normalmente se evita que x86 baje de frecuencia con cosas como desactivar C States y poner la administración de energía en high. Si evitas que la CPU esté subiendo y bajando, el rendimiento puede mejorar bastante. Pero normalmente eso no se hace en equipos personales o de laboratorio
  • O simplemente basta con desactivar turbo boost
• Después de leer el artículo, me pareció que había dos ideas principales. Primero, que ARM64 es menos "inteligente" que x64 y, en vez de estar haciendo boost y throttling agresivos como un Core i9, entrega un rendimiento constante, lo que facilita la planificación del SO. Segundo, que Windows tiene menos carga histórica en ARM que en x64, así que la compilación para ARM podría ser en sí más eficiente. Al final me preguntaba si la regulación de frecuencia de la CPU se ha vuelto tan sofisticada que ya empieza a jugar en contra
  • Aun así, esto también había que verlo como una prueba de un SO de servidor sobre una CPU x86 de escritorio. Las CPU x86 de servidor como AMD Epyc o Intel Xeon tienen menos variación de reloj y políticas menos agresivas, así que entregan un rendimiento más estable y predecible que una CPU de escritorio. Ese tipo de características favorece las cargas multihilo, mientras que las CPU de escritorio suelen ajustarse para maximizar el rendimiento de un solo hilo y eso puede terminar perjudicando el rendimiento multihilo