Go 1.27 lleva SIMD a amd64, arm64 y wasm con un solo código

El blog oficial del lenguaje Go publicó el 25 de septiembre un recorrido técnico por el paquete simd experimental introducido en Go 1.27: una API portable y agnóstica al tamaño de vector que ofrece rendimiento cercano a ensamblador en operaciones SIMD para amd64, arm64 y wasm, con emulación automática en CPUs sin soporte.

¿Qué es SIMD y por qué debería importarle a tu startup?

SIMD (Single Instruction Multiple Data) es una característica nativa de las CPU modernas que permite ejecutar una misma operación sobre varios datos en un único ciclo. Mientras una instrucción escalar suma dos números, una instrucción SIMD puede sumar ocho pares de float64 a la vez.

El beneficio para una startup es directo: tareas con cálculo intensivo — criptografía, procesamiento de imágenes, compresión, simulaciones y, cada vez más, pipelines de inferencia de IA — corren mucho más rápido cuando están vectorizadas. El propio recolector de basura Green Tea de Go, según explica el equipo, ya usa SIMD para acelerar el escaneo de memoria en busca de objetos vivos.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

En términos prácticos, esto se traduce en tres palancas: menos cómputo por request (y por tanto menor factura en la nube), latencias más bajas en endpoints analíticos y la posibilidad de procesar más volumen sin necesidad de escalar horizontalmente.

¿Cuál era el problema histórico del SIMD en Go?

Antes de Go 1.26, la única vía para acceder a instrucciones SIMD desde Go era escribir ensamblador a mano — una práctica reservada a kernels verdaderamente críticos por su costo de mantenimiento. Buena parte del software que podía beneficiarse de SIMD simplemente dejaba gran parte de la CPU sin usar.

Go 1.26 introdujo un primer paquete, archsimd, con APIs distintas por arquitectura y vectores de tamaño fijo; el código quedaba atado a una CPU concreta. Go 1.27 cierra ese hueco con dos movimientos: extiende archsimd a arm64 (NEON) y a wasm, y suma el nuevo paquete simd, descrito por el equipo como una interfaz portable basada libremente en la biblioteca Highway de Google para C++.

¿Cómo funciona el paquete `simd` experimental?

Activarlo requiere la variable de entorno GOEXPERIMENT=simd. A partir de ahí, los tipos vectoriales son versiones en plural y mayúscula de los primitivos: simd.Uint8s, simd.Float32s, simd.Int32s, entre otros. Los vectores se cargan y se almacenan en slices mediante funciones como simd.LoadFloat32s y métodos como Store.

El ejemplo canónico del blog es el producto interno de dos slices de float32: en lugar de iterar elemento a elemento, el código carga bloques del tamaño del vector, aplica MulAdd para acumular, y delega la reducción final al escalar. En Go 1.27 todavía hace falta un sum manual; el equipo adelanta que ReduceSum llegará en el siguiente release.

Las comparaciones devuelven máscaras con tipo MaskW específico del ancho del elemento, lo que permite encadenar IfElse y Masked — un diseño uniforme pese a que AVX-512, SVE, NEON y wasm SIMD manejan el enmascarado de forma muy distinta.

¿Qué plataformas soporta y cómo se controla por `GODEBUG`?

En Go 1.27, el paquete simd soporta AVX, AVX2 y AVX512 en amd64; NEON en arm64; y las instrucciones SIMD de wasm. En plataformas sin SIMD o sin cobertura en archsimd, todas las operaciones se emulan, así que el código siempre corre.

Para probar cómo se comporta el código frente a distintos anchos de vector, el runtime expone seis niveles de GODEBUG=simd:

simd=0: fuerza emulación aunque haya hardware SIMD disponible.
simd=128, simd=256, simd=512: solicita vectores de ese tamaño y entra en panic inmediato si no están disponibles.
simd=+128, simd=+256, simd=+512: usa ese tamaño aunque falten algunas instrucciones — solo entra en panic si el código las toca. El blog cita el caso de la Raspberry Pi, que trae NEON pero carece de PMULL.

Detrás de escena, el compilador aplica una reescritura del AST que genera versiones especializadas @simd128, @simd256, @simd512 y @simd0, y eleva el despacho SIMD tan arriba como puede para evitar indirecciones dentro del cálculo. Los type switch sobre ToArch() parecen costosos, pero desaparecen tras la optimización del compilador.

¿Qué llegará con Go 1.28?

El propio blog adelanta la hoja de ruta: Go 1.28 sumará SVE a archsimd (y, si es posible, también a simd), además de operaciones que hoy faltan — OnesCount, reducciones, mezclas de vectores — y «feature variants» pensados para hardware con SIMD parcial, exactamente el nicho donde caen máquinas como la Raspberry Pi o la emulación x86 de Apple Silicon (que soporta AVX2 pero no VPCLMULQDQ).

La propuesta original del paquete, recogida en el issue #78902 del repositorio de Go, confirma el plan: empezar por la intersección entre las APIs SIMD de wasm y amd64, e ir ampliando el set a medida que cada arquitectura rellene huecos con emulaciones dentro de archsimd.

¿Qué significa esto para tu startup?

El paquete es experimental y todavía no apto para producción, pero ya es momento de mapear dónde puede rendir más en tu stack. Tres acciones concretas para empezar:

Empieza por perfilar antes de portar nada. Identifica los hotspots numéricos con pprof y herramientas de flame graph. Los hot loops en serialización, hashing, compresión o pre/post-procesamiento de modelos son candidatos naturales a vectorización.
Levanta builds experimentales en CI. Crea un job con GOEXPERIMENT=simd y corre tu suite de benchmarks; vas a poder detectar regresiones y mejoras específicas por arquitectura (AVX2 en tus servidores amd64, NEON en las Apple Silicon de tus developers) sin tocar el código de producción.
Mantente cerca de las libs que ya usas. Muchas dependencias van a tardar releases en adoptar simd. Si dependes de una pieza crítica para inferencia, compresión o crypto, abre el issue correspondiente o considera un fork interno temporal mientras la API se estabiliza.

El largo plazo pinta interesante: un Go con SIMD portable reduce la barrera entre «código Go fácil de mantener» y «código que usa todo el silicio disponible» — algo especialmente valioso para equipos chicos que no pueden mantener ramas por arquitectura.