Go amplía su soporte SIMD con una interfaz portable y planes para Arm SVE
El lenguaje Go ya soporta AVX, AVX2, AVX-512, NEON y WASM SIMD en fase experimental, y prepara una interfaz común que no dependa de la arquitectura ni del tamaño del vector.
Una entrada publicada este jueves en el blog de Go.dev repasa el soporte experimental de SIMD en el lenguaje Go y la interfaz portable que el proyecto está construyendo para que el mismo código aproveche instrucciones vectoriales en distintas CPU. El paquete SIMD de Go cubre ya AVX, AVX2, AVX-512, Arm NEON y WASM SIMD, y para Go 1.28 se planea añadir Arm SVE.
De x86 a una API común
Desde Go 1.26 existen API experimentales para usar SIMD en CPUs modernas, con x86_64 como primer objetivo y capacidades como AVX. Go 1.27 amplió ese soporte a ARM64 mediante NEON. El problema es que cada arquitectura tiene implementaciones distintas, vectores de tamaño fijo diferente y diferencias de comportamiento. Para aislar al desarrollador de ese laberinto, Go 1.27 incorporó una interfaz SIMD completamente portable, independiente de plataforma y de tamaño, inspirada en la librería Highway de Google. La idea: escribir operaciones vectoriales una vez y que la implementación las adapte al hardware disponible.
Los planes para Go 1.28 pasan por sumar Arm SVE al código SIMD y por ampliar el número de operaciones que admite esa interfaz. Hoy el paquete ya cubre AVX, AVX2, AVX-512, NEON y WASM SIMD; SVE es el siguiente hueco en Arm, donde los vectores escalables rompen la suposición de anchura fija que arrastraban las versiones anteriores.
Qué implica para quien programa en Go
SIMD permite procesar varios datos en una sola instrucción, algo que en cargas numéricas, análisis de texto, compresión o cifrado se traduce en rendimiento sin tener que bajar a ensamblador. Hasta ahora, hacerlo en Go solía implicar ensamblador específico o depender de bibliotecas externas. Una interfaz portable dentro del lenguaje cambia el coste de mantenimiento: el código deja de estar atado a una familia de CPU concreta y puede recompilarse para otra sin reescribir rutas críticas.
No es una función terminada ni estable. El soporte sigue siendo experimental, la API puede cambiar y no hay garantías de rendimiento homogéneo entre arquitecturas. Quien dependa de estos paquetes debería seguir las notas de cada versión antes de fijar una dependencia. Para el resto, la señal es que Go quiere que el código vectorial sea ciudadano de primera, no un parche en ensamblador. Los detalles están en la entrada del blog de Go.dev.
