O Windows Server 2025 roda melhor em ARM

• Em uma comparação virtualizada do Windows Server 2025, a configuração com host ARM64 e guest ARM64 funcionou de forma estável e também mostrou uma sensação de resposta mais rápida no início de serviços, na abertura de consoles de administração e na execução de tarefas práticas
• As duas VMs foram configuradas de forma idêntica em memória, processadores virtuais e funções instaladas, e nas medições o sistema com Snapdragon apresentou menor variação no uso de CPU, manteve Processor Queue Length em 0 e registrou valores consistentes em CPU Wait Time Per Dispatch
• Em medições repetidas de IIS, DNS, consultas ao Active Directory, autenticação de domínio e I/O de arquivos, o Snapdragon X Elite quase sempre mostrou tempos reproduzíveis, enquanto o Intel foi mais rápido em algumas execuções, mas no geral teve maior variação
• A diferença não foi atribuída apenas à arquitetura de CPU; com latência consistente e escalonamento previsível tendo mais peso em cargas de servidor virtualizadas, junto com características de armazenamento, memória, gerenciamento de energia e aquecimento
• Em workloads focados em throughput máximo, o x64 ainda mantém vantagens, mas em implantações típicas de Windows Server com muitas tarefas pequenas sensíveis à latência, o ARM64 se torna mais atraente; ainda assim, a plataforma padrão para ensino continua sendo x64 devido à falta de suporte a virtualização aninhada no ARM64

---

Ambiente de teste e critérios de comparação

• Foi feita uma comparação montando um ambiente virtual de Windows Server 2025 em dois sistemas
  • Um sistema com Intel Core i9 de 14ª geração baseado em Windows 11, executando várias máquinas virtuais Hyper-V
  • Um sistema com Snapdragon X Elite baseado em Windows 11 on ARM, com o mesmo ambiente de Windows Server 2025
• Como o site da Microsoft não oferece uma ISO oficial de instalação do Windows Server 2025 ARM, a instalação foi feita a partir de uma imagem gerada com UUP dump, baseada nos servidores de atualização da Microsoft
• As duas VMs Hyper-V foram configuradas de forma idêntica em memória, processadores virtuais e funções instaladas
  • O Snapdragon X Elite usou ARM64 guest on ARM64 host
  • O Intel Core i9 usou x64 guest on x64 host

Observações iniciais e escopo da interpretação

• O ambiente Windows Server 2025 no sistema ARM foi estável, funcionou corretamente e, na prática, pareceu mais rápido no uso geral, em um nível plenamente utilizável
  • Inicialização de serviços mais rápida
  • Abertura de consoles de administração mais rápida
  • Menor tempo para executar tarefas práticas usadas na escrita de material didático
• Ainda assim, a diferença de desempenho não foi tratada como resultado apenas da arquitetura de CPU
  • Armazenamento, memória, gerenciamento de energia e características térmicas também podem influenciar os resultados
  • Em vez de concluir que “ARM é mais rápido”, a interpretação deve considerar as características do sistema como um todo
• As cargas típicas de serviço do Windows Server têm grande peso de threads e são centradas em tarefas pequenas, mas frequentes, de CPU e I/O
  • Isso inclui Active Directory, DNS, DHCP, IIS, serviços de arquivos SMB/NFS/DFS, Print Services, Certificate Services, Remote Desktop Services, Routing and Remote Access, NPS e outros
  • Esse tipo de carga é sensível a latência e troca de contexto, e se beneficia de desempenho consistentemente estável

Observações sobre a diferença de desempenho

• Sistemas ARM da linha Snapdragon tendem a oferecer desempenho contínuo e estável, em vez de buscar clocks de boost mais altos
• CPUs Intel modernas podem entregar desempenho máximo mais alto graças a aumento de frequência e throttling dinâmico
  • Em contrapartida, sob carga contínua ou mista, isso pode aumentar a variabilidade de escalonamento e latência
• Em ambientes virtualizados, essa variabilidade se torna mais importante
  • Um hipervisor como o Hyper-V atua, na prática, como um escalonador de hardware
  • Quanto mais previsível for o timing de execução do hardware, mais consistente tende a ser o escalonamento do hipervisor
  • Esse efeito aparece na responsividade da VM e dos serviços dentro dela
• Também foi mencionada a possibilidade de diferenças no próprio build ARM64 do Windows Server
  • Com base em várias notas de versão encontradas online, a versão ARM64 pode evitar algumas camadas legadas de compatibilidade e usar binários mais modernos e otimizados
  • Há a observação de que ela pode ser um build mais enxuto do que a versão x64
  • Não foram apresentados mais detalhes concretos sobre a implementação interna

Medições com o Performance Monitor

• As medições foram feitas adicionando contadores do Performance Monitor nos dois hosts Windows 11
  • \\Processor(_Total)\\% Processor Time
    • Uso de CPU considerando todos os núcleos
  • \\System\\Processor Queue Length
    • Número de threads esperando tempo de CPU
    • O ideal é manter 0
  • \\Hyper-V Hypervisor Virtual Processor(*)\\CPU Wait Time Per Dispatch
    • Tempo médio que um processador virtual espera até ser escalonado para a CPU
• Depois, foi gerada carga dentro de cada VM com PowerShell e os resultados foram observados
  • Foram executados 8 loops infinitos consultando repetidamente os 5 processos com maior uso de CPU, ordenados a partir do resultado de Get-Process
• Nas medições, o Snapdragon mostrou um padrão de desempenho contínuo e estável
  • Variação muito menor em % Processor Time
  • Processor Queue Length permaneceu em 0
  • CPU Wait Time Per Dispatch também ficou estável e consistente
• No sistema Intel, a variabilidade de boost/throttling apareceu nos indicadores
  • Maior variação em % Processor Time
  • Processor Queue Length subia bruscamente de forma periódica
  • CPU Wait Time Per Dispatch também apresentou flutuações significativas

Medição de responsividade dos serviços

• Em cada VM, foi usado Measure-Command no PowerShell para medir o tempo de tarefas típicas de serviço
• Foi feito um teste com servidor web IIS
  • Invoke-WebRequest http://localhost -UseBasicParsing | Out-Null repetido 1000 vezes
• Outros serviços também foram medidos repetidamente da mesma forma
  • DNS
    • Resolve-DnsName "domainX.com" -Server 127.0.0.1 | Out-Null
  • Consulta ao Active Directory
    • Get-ADUser -Filter * -ResultSetSize 1 | Out-Null
  • Latência de autenticação de domínio
    • Test-ComputerSecureChannel -Verbose:$false
  • I/O de arquivos
    • Criação do diretório C:\TestFiles
    • Repetição de 2000 ciclos de criação de arquivo, gravação de conteúdo, leitura e exclusão
• Após várias execuções, o sistema com Snapdragon quase sempre registrou tempos consistentes e reproduzíveis
• O sistema Intel mostrou maior variação nos resultados
  • Em algumas execuções, foi mais rápido que o Snapdragon
  • Mas, na maioria dos casos, ficou atrás
• No conjunto, a conclusão foi de vantagem do Snapdragon em todos os testes

Conclusão principal

• O elemento comum que atravessa todos os resultados é a consistência da latência
• Cargas virtualizadas de Windows Server dependem fortemente de resposta rápida a tarefas pequenas e frequentes e de escalonamento previsível
• Em workloads onde o mais importante é o throughput máximo, sistemas x64 ainda têm vantagem clara
• Já em ambientes como implantações típicas de Windows Server, onde muitas pequenas tarefas sensíveis à latência rodam juntas sob virtualização, consistência importa mais do que pico absoluto de velocidade
• Nesse contexto, o ARM64 se torna mais atraente
• O ARM64 já é amplamente usado em nuvem, e também foi mencionada uma relação custo/desempenho melhor do que a do x64
• Foi levantada a necessidade de a Microsoft considerar ampliar o peso do ARM64 no futuro do Windows Server
  • Atualmente, a Microsoft não oferece suporte completo ao Windows Server on ARM64
  • Ainda assim, foi citado que no último ano 33% das novas instâncias de VM do Microsoft Azure eram ARM64, e na Amazon AWS, 50% eram ARM64

Escolha da plataforma padrão para ensino

• O ambiente prático usado no material didático continua padronizado em x64
• O motivo é que a configuração prática inclui virtualização aninhada
• Como o Hyper-V não oferece suporte a virtualização aninhada em ARM64, o ARM64 ainda não é adotado como ambiente-base para ensino
• Os alunos até podem adaptar o laboratório por conta própria, mas um dos objetivos do material é a reprodutibilidade, então tem prioridade um ambiente que funcione do mesmo modo passo a passo
• No momento, para fins educacionais, o x64 continua sendo a opção mais prática

[GN⁺]

Comentários do Hacker News

• Eles divulgaram toda a configuração, as suposições e até o código necessários para reproduzir o teste, mas faltou justamente o resultado percebido em si, então isso pareceu um pouco suspeito. Fiquei curioso sobre o quão mais rápido o ARM realmente era em números
  • Houve um motivo para terem omitido de propósito as capturas de tela da saída. Queriam evitar que o texto virasse um post de benchmark, e acharam que os resultados poderiam variar conforme o hardware ARM ou o modelo específico do Snapdragon X Elite, o que poderia gerar interpretações erradas. Em vez disso, incluíram um snippet de PowerShell para que qualquer pessoa pudesse reproduzir. Em termos gerais, a VM com Snapdragon foi cerca de 20% a 80% mais rápida que a VM com Intel, dependendo do teste: DNS em torno de 20%, IIS perto de 50% e os demais geralmente mais próximos de 80%
• Do ponto de vista de um desenvolvedor Windows, isso parecia muito possivelmente efeito do segment heap. Na implementação de heap do Windows existem duas linhagens independentes: o antigo NT heap e o segment heap, dos anos 2010, sendo que o segment heap era mais eficiente em fragmentação de memória e reutilização de pequenas alocações. Mas o Windows dá prioridade extrema à compatibilidade legada, então não trocou o padrão de uma vez, porque apps antigos podem depender de comportamentos perigosos como use-after-free ou de estruturas internas do NT heap. Por isso, adotaram um meio-termo: executáveis packaged usam segment heap por padrão, enquanto os unpackaged continuam como estão. Só que a migração para UWP fracassou, o ecossistema Windows ficou ainda mais fragmentado e a maior parte do software importante continuou como x64 unpackaged. Já binários arm64 têm menor chance de serem código legado antigo, então no ARM o segment heap vem ativado por padrão. Uma parte nada pequena da sensação de que o Windows em ARM é mais responsivo provavelmente vem daí. Seria interessante repetir esse teste forçando o segment heap no x64. Por executável, dá para definir o DWORD FrontEndHeapDebugOptions como 8 em HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\.exe; globalmente, dá para definir o DWORD Enabled como 3 em HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap. Na minha máquina de desenvolvimento, não vi problemas após ativar globalmente, e o uso de memória caiu cerca de 15% nos meus testes
  • Nas minhas cargas de trabalho intensivas em RAM/CPU, o Segment Heap melhorou de forma consistente o desempenho geral em cerca de 7% em comparação com o NT Heap. O conjunto das tarefas terminou 7% mais rápido. Se ainda existisse algo como a antiga certificação "Compatible with Windows XXX" no Windows 10/11, seria interessante incluir uma verificação de segment heap para levar ganhos de desempenho, eficiência energética e impacto ambiental a mais apps e usuários. E o problema do UWP, na minha visão, não era tanto a tecnologia em si, mas a insistência em atrelar empacotamento e Store, o que entrava em conflito com a forma como o Windows existe como sistema operacional
  • Quem tiver interesse pode optar por esse comportamento no application manifest do próprio executável, definindo heapType como SegmentHeap. A documentação explica isso
  • Foi esse tipo de dica prática que me fez sentir o valor do HN. Fiquei curioso para saber se a chave de registro global exige reinicialização ou se já passa a valer imediatamente a partir da inicialização do executável
  • Isso era interessante a ponto de merecer um post de blog, e não só um comentário de fórum
  • Eu já tinha visto essa configuração global explicada antes como 0 versus non-zero, então fiquei curioso por que o valor era especificamente 3. Também queria saber o que significa 2 e onde eu mesmo poderia consultar o significado desses valores
• A frase do texto de que "ARM não persegue boost clocks altos e entrega desempenho constante" pareceu um pouco exagerada. Todos os sistemas ARM que já usei também faziam escalonamento de frequência, e nesse ponto se comportavam de forma parecida com x86. No fim, a diferença me parece mais uma questão de até quão alto conseguem subir
  • Vai depender da carga de trabalho, mas nos ambientes de nuvem de várias organizações onde trabalhei, a simples migração para ARM a partir de x86 já trouxe uma boa redução de custos. As instâncias eram mais baratas e também mais eficientes. Em uma organização em particular, com centenas de nós Kubernetes em autoscaling dinâmico, sem nenhuma mudança adicional além de x86 -> ARM, estimamos de forma conservadora uma economia de cerca de 15% e de fato a alcançamos. Se a carga for limitada por CPU e menos dependente de recursos específicos de x86, isso pode ser muito maior que 15%
• Se o ponto principal fosse o desempenho menos oscilante e mais previsível das CPUs ARM, então usar uma CPU de servidor como Epyc em vez de uma CPU desktop talvez trouxesse vantagens parecidas. CPUs de servidor têm menor variação de clock e políticas de boost menos agressivas. Mesmo no hardware desktop atual, daria para desligar o Turbo no BIOS e fixar a CPU Intel no clock base, produzindo um desempenho mais baixo, mas estável e previsível, para comparação
  • Também dava para desativar o comportamento de turbo no plano de energia. Só que essa opção talvez não apareça por padrão na GUI
• Fiquei curioso se o Windows on ARM usa VBS ou Virtualization Based Security, e se isso é suportado também dentro da VM por nested virtualization. Também parece importante saber se as mitigações de vulnerabilidades da CPU estão sendo aplicadas em dobro na VM, afetando o desempenho. Hoje em dia, uma boa parte dos problemas de performance que se vê ao colocar Windows em VM vem disso. Foi uma pena o texto não mencionar esse ponto
• Fiquei curioso sobre a configuração de RAM e armazenamento dos dois sistemas. O lado Snapdragon poderia ter RAM empacotada e, portanto, um interconnect mais rápido, enquanto o lado x86 poderia usar DIMM com trilhas mais longas. Armazenamento e modelo de CPU também podem influenciar muito a diferença de desempenho. Benchmarks muitas vezes estressam demais só uma parte do sistema, então a diferença real talvez venha menos da arquitetura ARM em si e mais de RAM, syscalls, SSD ou outros fatores
  • Ambos os sistemas usavam DDR5 soldada na placa-mãe e SSD NVMe. Na verdade, o SSD do lado Intel era um modelo Samsung mais rápido do que o Foresee do lado Snapdragon
• No Linux, tudo roda melhor, e não se desperdiçam ciclos com overhead de vigilância
• O texto parecia evitar dizer de propósito qual era o processador Intel, então fiquei pensando se eu tinha deixado passar alguma coisa
  • A CPU usada era um Intel Core i9 de 14ª geração
• Em servidores HV, normalmente se evita que x86 reduza o clock com práticas como desativar C States e deixar o gerenciamento de energia em modo high. Impedir a CPU de ficar oscilando para cima e para baixo pode melhorar bastante o desempenho. Só que isso normalmente não é algo feito em máquinas pessoais ou de laboratório
  • Ou então basta simplesmente desativar o turbo boost
• Depois de ler o texto, pareceu que o ponto central era duplo. Primeiro, o ARM64 é menos "esperto" que x64, no sentido de que, em vez de ficar alternando agressivamente entre boost e throttling como um Core i9, entrega um desempenho mais constante, o que facilita o agendamento do sistema operacional. Segundo, como o Windows no ARM carrega menos bagagem histórica do que no x64, é possível que o próprio build para ARM seja mais eficiente. No fim, fiquei me perguntando se o throttling de CPU ficou inteligente demais a ponto de começar a atrapalhar
  • Ainda assim, isso precisa ser visto no contexto de que o teste foi feito com um sistema operacional de servidor rodando em uma CPU x86 desktop. CPUs x86 de servidor, como AMD Epyc ou Intel Xeon, têm faixa de variação de clock menor e políticas menos agressivas, então entregam desempenho mais constante e previsível do que CPUs desktop. Essas características favorecem cargas multithread, enquanto CPUs desktop são ajustadas para pico de desempenho em thread única e podem acabar perdendo justamente em cargas multithread