SIMD independiente de la plataforma en Go

Artículo original ↗ Discusión en Hacker News ↗

Las nuevas APIs SIMD independientes de la plataforma de Go buscan facilitar y hacer portables las operaciones vectorizadas de bajo nivel entre CPUs, reduciendo la necesidad de ensamblador o de C/C++ escritos a mano para código crítico en rendimiento. Los comentaristas ven mejoras claras de velocidad en proyectos reales y celebran el diseño por capas, que equilibra portabilidad y acceso a funciones específicas de la arquitectura, aunque señalan que la autovectorización del compilador también está mejorando en paralelo. El hilo también retoma las tensiones de Go en torno a la seguridad de memoria y las carreras de datos, y cómo sus funciones de rendimiento en evolución lo sitúan junto a lenguajes como Rust, C++, Java y Mojo para cargas de trabajo de alto rendimiento como bases de datos, analítica y ML.

Recepción general y primeras experiencias

  • Muchos comentaristas están entusiasmados: esto elimina una necesidad de larga data de tener que recurrir a C/C++/assembly para código Go crítico en rendimiento.
  • Algunos ya informan mejoras reales de velocidad (por ejemplo, ~30% en estimación del primer plano de imágenes; ganancias medibles en inferencia de modelos de voz; ~5x frente a escalar en una demo de intercambio de paleta en un navegador, con SIMD portátil solo ~11% más lento que el SIMD específico de arquitectura).
  • Se considera especialmente beneficioso para bases de datos, analítica y otras cargas de trabajo multicore, numéricas o amigables con vectores.

SIMD frente a autovectorización

  • Algunos señalan que, para muchas cargas de trabajo, la autovectorización del compilador es “suficientemente buena” y lamentan que esta característica no resuelva directamente esa brecha.
  • Otros señalan que hay trabajo activo en la autovectorización del compilador de Go y que el SIMD explícito y una mejor autovectorización son complementarios.
  • Aparece una sugerencia para añadir linters o herramientas que puedan transformar automáticamente bucles adecuados en patrones SIMD.

Interoperabilidad, assembly y rendimiento

  • Persisten las quejas sobre la sobrecarga de CGO: el modelo de memoria de Go y su modelo de concurrencia difieren de C, así que cruzar la frontera sigue siendo costoso.
  • Una minoría sugiere usar assembly de Go en lugar de CGO para rutas críticas de rendimiento; algunos proyectos ya realizan mucho SIMD en assembly de Go.

Diseño de API y portabilidad

  • Se elogia el diseño por capas (arch‑specific archsimd más simd portátil); gusta que la sobrecarga de despacho se traslade a los llamadores mediante multi-versionado al inicio.
  • Una preocupación: el tamaño del código puede crecer porque las funciones que usan SIMD obtienen múltiples copias especializadas; el impacto real en binarios concretos no está claro.
  • El enfoque recibe elogios por ser más amigable con ISAs de longitud de vector variable como SVE y RISC‑V RVV al evitar tamaños de vector fijos en el sistema de tipos.

Seguridad de memoria y carreras de datos

  • Un gran subhilo debate si Go es “seguro en memoria” dado que las carreras de datos en valores de varias palabras (slices, strings, interfaces) pueden provocar tearing, accesos fuera de límites, pánicos y, en principio, corrupción de memoria.
  • Algunos argumentan que “seguro en memoria” es un término de arte de seguridad; según esa definición común, Go es seguro en memoria salvo cuando se usa unsafe o hay carreras.
  • Otros insisten en que la posibilidad de corrupción de memoria inducida por carreras significa que Go no es plenamente seguro en memoria, especialmente comparado con lenguajes cuyos modelos de memoria descartan ese comportamiento.

Comparaciones entre lenguajes y filosofía

  • Se compara Go con Rust, Java, C#, D, Zig, Julia, Swift, C++ (incluido std::simd), Mojo y SIMD de WebAssembly.
  • Los comentaristas destacan la filosofía de diseño conservadora de Go, de “hacer menos cosas pero hacerlas bien”, y señalan paralelos con el largo camino hacia los generics.
  • Algunos sienten que Rust tiene más impulso, pero ven nichos estables para ambos lenguajes.

Miscelánea

  • Pequeña digresión sobre la definición de “API”.
  • Varias personas lamentan la falta de resaltado de sintaxis en la documentación oficial de Go; otros defienden un resaltado mínimo o inexistente.