Nolan Mariotte
Bien que les instructions concernant AVX2 aient constitué un pas en avant pour AMD et Intel pendant des années, comme nous le savons, sa mise en œuvre et son fonctionnement se sont améliorés au fil du temps, du système d'exploitation et des logiciels en général. Le problème maintenant est qu'avec Arm sur la carte des PC et ordinateurs portables, AVX2 non seulement n'améliore pas les performances sous émulation sur Windows Arm, mais peut clairement les aggraver. La manière dont ce fait a été découvert est ce qui est pertinent, car cela implique qu'au moins Windows 11 n'est pas à la hauteur de ce que dit Microsoft.
Une analyse technique publiée par RemObjects montre que, exécuté sous la couche d'émulation x64 de Windows 11 Arm with Prism, le code compilé avec AVX2 est environ 33 % moins performant que le même code compilé avec SSE2-4.x. L'avantage théorique du 256 bits disparaît lorsque la traduction dynamique vers l'architecture Arm entre en jeu, et bien sûr, Microsoft est, une fois de plus, mis en avant.
Windows Arm pénalise les performances d'AVX2 jusqu'à ce qu'elles tombent en dessous de SSE2-4.x
L'étude est basée sur une comparaison directe entre des binaires x64 compilés avec différents ensembles d'instructions SIMD, ce qui est normal lorsque l'on souhaite comparer ISA et des instructions spécifiques. Le résultat est inattendu, mais cohérent et reproductible, et Redmond analysera sûrement.
Les collègues de Remobjects compilent le même code en plusieurs variantes : base x64, SSE2-4.x et AVX2 avec FMA. Sur le matériel x64 natif, AVX2 offre une amélioration notable, environ 2,7 fois par rapport à SSE2 sous des charges vectorielles intensives. C'est ce que l'on attend en revanche en obtenant plus de largeur de registre, plus d'opérations par cycle. Cependant, sous Windows 11 Arm, où le code x64 est traduit dynamiquement à l'aide de Prism, la situation est inversée et un drame s'ensuit.
Les performances chutent, elles ne peuvent pas être maintenues, et la raison en est purement architecturale. AVX2 fonctionne avec des registres de 256 bits, tandis que l'extension NEON SIMD d'Arm fonctionne avec des registres de 128 bits. Par conséquent, chaque instruction AVX2 doit être divisée en interne en plusieurs opérations NEON équivalentes, ce qui détruit les performances de Prism sur Windows Arm.
Cela implique plus de micro-opérations, plus de pression sur le traducteur dynamique et une plus grande surcharge d'exécution, comme nous l'avons dit, un drame qui jusqu'à présent ne semblait pas exister car il était entendu que ce problème avec l'émulateur n'existait pas. Le résultat final est qu'AVX2 finit par avoir des performances d'environ 0,66x par rapport à SSE2-4.x dans le même environnement d'émulation. Ou, ce qui revient au même, cela tue les performances lorsque ces instructions entrent en jeu.
Compression, décompression, multimédia et inférence : les scénarios quotidiens où Windows Arm s'effondre
Les mesures montrent une perte soutenue de près de 33 % des charges mathématiques vectorisées. Autrement dit, si SSE2-4.x obtient une performance relative de 100, AVX2 se situe autour de 66 sous Windows Arm émulé avec Prism.
L'étude ne remet pas en cause la validité d'AVX2 sur x64 natif, il est évident qu'il fonctionne et multiplie les performances, et ce depuis sa mise en œuvre en 2013 avec Haswell. Il ne critique pas non plus l'émulation en général, puisque Prism accomplit bien de nombreuses tâches qui lui sont assignées. Le problème apparaît à l’intersection spécifique entre les instructions 256 bits et une architecture Arm optimisée pour 128 bits, où les performances chutent.
Bien que la traduction ne soit pas gratuite et que le coût devienne évident lorsque le code repose fortement sur de vastes opérations vectorielles, Microsoft ne pourra pas faire grand-chose de son point de vue. Cela suggère qu'Arm dans ses nouvelles architectures doit prioriser ce type d'instructions pour simplifier l'émulation, ou la faciliter, d'autant plus qu'on est à la veille d'AVX10.2 avec Nova Lake.
Cela ouvre une question inconfortable pour les développeurs cherchant à exploiter chaque cycle au sein d'Arm ISA, car l'optimisation pour x64 moderne avec les dernières architectures d'AMD et d'Intel ne garantit pas le meilleur résultat dans les environnements Arm émulés avec Windows et AVX2. Le problème ne vient pas seulement de Qualcomm, mais aussi de NVIDIA, qui est sur le point d'arriver sur le marché avec son SoC pour Windows Arm, et se retrouvera à un carrefour plutôt intéressant, du moins tant que Microsoft ne pourra pas atténuer cette perte de performances.
