Platform-independent SIMD in Go

Original Article ↗ Hacker News Discussion ↗

Go’s new platform‑independent SIMD APIs aim to make low‑level vectorized operations easier and portable across CPUs, reducing the need for hand‑written assembly or C/C++ for performance‑critical code. Commenters see clear speedups in real projects and welcome the layered design that balances portability with access to architecture‑specific features, while noting that compiler autovectorization is also improving in parallel. The thread also revisits Go’s trade‑offs around memory safety and data races, and how its evolving performance features position it alongside languages like Rust, C++, Java, and Mojo for high‑performance workloads such as databases, analytics, and ML.

Overall reception and early experiences

  • Many commenters are enthusiastic: this removes a long‑standing need to drop into C/C++/assembly for performance‑critical Go code.
  • Some report real speedups already (e.g., ~30% in image foreground estimation; measurable gains in speech model inference; ~5x vs scalar in a browser palette‑swap demo, with portable SIMD only ~11% slower than arch‑specific SIMD).
  • It’s seen as especially beneficial for databases, analytics, and other multicore, numeric, or vector‑friendly workloads.

SIMD vs autovectorization

  • Some note that for many workloads, compiler autovectorization is “good enough” and lament that this feature doesn’t directly solve that gap.
  • Others point out there is active work on Go compiler autovectorization and that explicit SIMD plus better auto‑vectorization are complementary.
  • A suggestion appears to add linters or tooling that could transform suitable loops into SIMD patterns automatically.

Interop, assembly, and performance

  • Complaints about CGO overhead remain: Go’s memory model and concurrency model differ from C, so boundary crossings stay expensive.
  • A minority suggests using Go assembly instead of CGO for performance‑critical paths; some projects already do heavy SIMD in Go assembly.

API design and portability

  • The layered design (arch‑specific archsimd plus portable simd) is praised; people like that dispatch overhead is hoisted to callers via multi‑versioning at startup.
  • One concern: code size may grow because SIMD‑using functions get multiple specialized copies; the size impact on real binaries is unclear.
  • The approach is lauded for being friendlier to variable‑length vector ISAs like SVE and RISC‑V RVV by avoiding fixed vector sizes in the type system.

Memory safety and data races

  • A large subthread debates whether Go is “memory safe” given that data races on multiword values (slices, strings, interfaces) can lead to tearing, out‑of‑bounds access, panics, and in principle memory corruption.
  • Some argue memory safety is a security term of art; by that common definition Go is memory safe except when using unsafe or races.
  • Others insist that the possibility of race‑induced memory corruption means Go is not fully memory safe, especially compared to languages whose memory models rule out such behavior.

Language comparisons and philosophy

  • Go is compared with Rust, Java, C#, D, Zig, Julia, Swift, C++ (including std::simd), Mojo, and WebAssembly SIMD.
  • Commenters highlight Go’s conservative, “do fewer things but do them well” design philosophy, noting parallels with the long path to generics.
  • Some feel Rust has more momentum, but see stable niches for both languages.

Miscellaneous

  • Minor digression about the definition of “API.”
  • Several people bemoan the lack of syntax highlighting in Go’s official docs; others defend minimal or no highlighting.