Si bien las instrucciones que abarcan a AVX2 supusieron un paso adelante para AMD e Intel desde hace años, como sabemos, su implementación y función ha ido mejorando con el paso del tiempo, los SO y el software en general. El problema ahora es que con Arm en el tablero de PC y portátiles, AVX2 no solo no mejora el rendimiento bajo emulación en Windows Arm, sino que puede empeorarlo de forma clara. El cómo se ha descubierto este hecho es lo relevante, porque implica que, al menos Windows 11, no está a la altura de lo que dice Microsoft.

Un análisis técnico publicado por RemObjects demuestra que, ejecutado bajo la capa de emulación x64 de Windows 11 Arm con Prism, el código compilado con AVX2 rinde aproximadamente un 33% menos que el mismo código compilado con SSE2-4.x. La ventaja teórica de los 256 bits desaparece cuando entra en juego la traducción dinámica hacia arquitectura Arm, y claro, Microsoft está quedando, otra vez, retratado.

Windows Arm penaliza el rendimiento de AVX2 hasta hacerlo quedar por debajo de SSE2-4.x

El estudio parte de una comparación directa entre binarios x64 compilados con distintos conjuntos de instrucciones SIMD, algo normal cuando quieres comparar ISA e instrucciones tan específicas. El resultado es inesperado, pero consistente y replicable, que seguro en Redmond estarán analizando.

Los compañeros de Remobjects compilan el mismo código en varias variantes: base x64, SSE2-4.x y AVX2 con FMA. En hardware x64 nativo, AVX2 sí ofrece una mejora notable, en torno a 2,7x veces frente a SSE2 en cargas vectoriales intensivas. Es lo esperado por otra parte al conseguir más ancho de registro, más operaciones por ciclo. Sin embargo, bajo Windows 11 Arm, donde el código x64 se traduce dinámicamente mediante Prism, la situación se invierte, y llega el drama.

El rendimiento se desploma, no es capaz de ser sostenido, y el motivo de que esto pase es puramente arquitectónico. AVX2 trabaja con registros de 256 bits, mientras que la extensión SIMD NEON de Arm opera con registros de 128 bits. Por ello, cada instrucción AVX2 debe dividirse internamente en múltiples operaciones NEON equivalentes, lo cual destroza el rendimiento de Prism en Windows Arm.

Eso implica más micro-operaciones, más presión sobre el traductor dinámico y mayor sobrecarga en tiempo de ejecución, como decíamos, un drama que hasta ahora no parecía existir porque se entendió que este problema con el emulador no existía. El resultado final es que AVX2 termina rindiendo alrededor de 0,66x respecto a SSE2-4.x bajo el mismo entorno de emulación. O lo que es igual, mata el rendimiento cuando estas instrucciones entran en juego.

Compresión, descompresión, multimedia e inferencia: los escenarios cotidianos donde Windows Arm se desploma

Las mediciones muestran una pérdida sostenida cercana al 33% en cargas matemáticas vectorizadas. Es decir, si SSE2-4.x obtiene un rendimiento relativo de 100, AVX2 queda en torno a 66 bajo Windows Arm emulado con Prism.

El estudio no cuestiona la validez de AVX2 en x64 nativo, es evidente que funciona y multiplica el rendimiento, lo lleva haciendo desde que se implementó en 2013 con Haswell. Tampoco critica la emulación en general, puesto que Prism hace bien muchas tareas que se le encomiendan. El problema aparece en la intersección concreta entre instrucciones de 256 bits y una arquitectura Arm optimizada para 128 bits, ahí el rendimiento se desploma.

Si bien la traducción no es gratuita y cuando el código depende fuertemente de operaciones vectoriales anchas el coste se vuelve evidente, Microsoft podrá hacer muy poco desde su perspectiva. Esto deja entrever que Arm en sus nuevas arquitecturas debe de priorizar este tipo de instrucciones para simplificar la emulación, o facilitarla, sobre todo porque estamos a las puertas de AVX10.2 con Nova Lake.

Esto abre una cuestión incómoda para desarrolladores que buscan exprimir cada ciclo dentro de la ISA Arm, puesto que optimizar para x64 moderno con las últimas arquitecturas de AMD e Intel no garantiza el mejor resultado en entornos Arm emulados con Windows y AVX2. El problema no solo lo tiene Qualcomm, lo tiene también NVIDIA, que está por llegar al mercado con sus SoC para Windows Arm, y se va a encontrar con una encrucijada bastante interesante, al menos, mientras Microsoft no pueda paliar esta pérdida de rendimiento.