Go 1.27 adds platform-independent SIMD API
Go introduces experimental portable SIMD interface supporting multiple architectures with near-assembly performance and fallback emulation.
What to know
- Go 1.27 introduces an experimental portable SIMD package that abstracts CPU architecture differences (amd64 AVX/AVX2/AVX512, arm64 NEON/SVE, wasm), allowing write-once code that runs across platforms with near-assembly performance.
- The portable API accepts ~11% performance penalty versus architecture-specific intrinsics but still delivers ~5x speedup over scalar computation and includes efficient emulation for platforms without native SIMD.
- Developers report practical gains: speech-to-text/text-to-speech models show measurable improvements, and the API handles both fixed-size vectors (128–512 bits) and variable-size architectures like RISC-V and Arm SVE.
- The feature addresses a longstanding gap in Go—previously only assembly offered SIMD access—and positions Go competitively alongside recent C++ std::simd and Mojo implementations for performance-critical workloads.
This is a major win for Go's ecosystem that opens doors for database and performance-critical workloads.
-
“This will welcome more database/warehouses to be written in Go.”
vira28 · Hacker News ↗
Portable SIMD (with ~11% penalty) is practical for real work and fills a long-standing gap in language support.
-
“I can anecdotally say the SIMD work made a measurable improvement in the performance of the calculations vs. just plain Go.”
sixdimensional · Hacker News ↗
Go's SIMD complements existing low-level work and existing high-performance solutions.
-
“I am using Go assembly for SIMD very heavily in [project], this is just icing on the cake.”
rcarmo · Hacker News ↗
Go team Language maintainers
How it unfolded 2 developments, newest first · click a bar or a number to jump articlespostscomments
-
background
Go blog publishes platform-independent SIMD design — The Go team publishes a blog post detailing experimental SIMD APIs introduced in Go 1.26 and 1.27. Go 1.26 added amd64 SIMD support; Go 1.27 extends this with arm64 (NEON) and wasm APIs, plus a new portable simd package that abstracts platform differences and works across fixed-size and variable-size vector architectures.
-
2
Developer reports measurable SIMD performance gains in speech model project
A developer shares experience testing experimental SIMD on speech-to-text and text-to-speech models running natively in Go, reporting measurable performance improvements from SIMD versus plain Go.
“I don't have formal benchmarks for that, but I can anecdotally say the SIMD work made a measurable improvement in the performance of the calculations vs. just plain Go.”
— sixdimensional -
Very neat, and comes pretty close to how Mojo handles portable SIMD.It's great to see two of my favorite languages finally making SIMD easy to use. It's such low-hanging fruit for performance, yet somehow languages have ignored it for years. Portable SIMD, even with some performance penalty, still beats scalar computation whenever vector…
2 more of the top 3 · 7 posts in this stretch
-
I did some testing with the experimental SIMD on a project I was doing to make speech-to-text and text-to-speech models run natively in Go (with CGO_ENABLED=0, so no C depenencies), and testing non-SIMD w/ SIMD.I don't have formal benchmarks for that, but I can anecdotally say the SIMD work made a measurable improvement in the performance of the…
-
> The new simd package hides these differences by removing fixed-size vectors from the type system, and by only supporting those operations that are in the intersection of all the different platforms, and fills gaps in the intersection with efficient emulation in terms of other SIMD instructions.The intersection would be the operations supported…
-
-
1
ImJasonH benchmarks portable SIMD performance
A developer releases a wasm-based image palette-swap tool demonstrating portable SIMD versus architecture-specific and non-SIMD implementations, showing portable SIMD is ~11% slower than non-portable but ~5x faster than scalar operations.
“Portable SIMD is ~11% slower than non-portable SIMD in this case, but both are ~5x faster than non-SIMD.”
— ImJasonH -
https://imjasonh.github.io/playground/palette-swap/ swaps colors in a provided image in wasm, entirely locally in your browser, to benchmark portable SIMD vs non-portable archsimd vs non-SIMD.Portable SIMD is ~11% slower than non-portable SIMD in this case, but both are ~5x faster than non-SIMD.
2 more of the top 3 · 5 posts in this stretch
-
This feature opens many doors for optimizing low-level performance in Go projects, that are already running multicore. IIRC there aren’t a lot of languages with built-in std lib support for SIMD and variants. Love the way Go is trying new stuff lately.
-
This will welcome more database/warehouses to be written in Go.Personally I will implement it in
-
Also covered reported alongside — the timeline has no entry for these yet
-
first by Phoronix, 2d ago · also HN Best, HN Frontpage
1 more headline
- Platform-Independent SIMD in Go HN Best · 2d ago
What people are saying 6 voices from 1 site · best of 12 · verbatim
- Sep 25
-
Now with Mojo and WebAssembly I notice 3 different approaches for platform-independent SIMD. For examples operating on an array of floats:- WebAssembly: 4 float32s- Mojo: N float32s where N is a compile-time parameter- Go simd: vector of float32s
-
Curious how much of the emulation ends up in hot paths before SVE and the feature variants land.
-
I am using Go assembly for SIMD very heavily in https://github.com/rcarmo/go-pherence, this is just icing on the cake.
-
Just want to say among many portable SIMD solutions I’ve seen recently (e.g. Fearless SIMD), this is the first that makes non-fixed vectors like SVE and RISC-V vector (RVV) easier to support. Glad to see they made this decision
-
C++ is getting std::simd in the latest version and I am all aboard writing the vectorization with the least amount of intrinsic builtins I am able to. Even if not optimal, it's far better than the scalar ops.
-
This is why I love Go. Nobody was asking for this, but they took the time to do it right and continue to Push go as a memory safe, high-level systems language.