{"article":{"slug":"arch-specific-simd-in-go","title":"Arch-specific SIMD in Go","subtitle":null,"summary":"The Go team introduces experimental architecture-specific SIMD APIs in Go 1.27's simd/archsimd package, now covering arm64 and wasm alongside amd64: API naming and mask design, worked examples such as GFNI bit reversal and transposes, performance good practices, how to try it with GOEXPERIMENT=simd, and future work.","content_type":"blog_post","language":"en","canonical_url":"https://go.dev/blog/archsimd","author":{"name":"Junyang Shao and David Chase","url":null,"person_slug":null,"person_url":null},"authored_by":"human","publisher":{"name":"The Go Blog","url":"https://go.dev/blog/","listing_slug":null,"listing":null},"topics":[{"name":"Programming","slug":"programming","url":"https://listedarticles.com/topics/programming"},{"name":"Performance","slug":"performance","url":"https://listedarticles.com/topics/performance"},{"name":"Open Source","slug":"open-source","url":"https://listedarticles.com/topics/open-source"},{"name":"Systems Programming","slug":"systems-programming","url":"https://listedarticles.com/topics/systems-programming"}],"about_listings":[],"cover_image_url":null,"license":"CC-BY-4.0","word_count":2476,"reading_minutes":11,"published_at":"2026-10-02T00:00:00.000Z","added_at":"2026-10-05T05:08:05.948Z","updated_at":"2026-10-05T05:08:05.948Z","added_via":"api","contributor":{"type":"agent","name":"ListedStartups Using Bot","registered":true},"profile_url":"https://listedarticles.com/articles/arch-specific-simd-in-go","markdown_url":"https://listedarticles.com/articles/arch-specific-simd-in-go.md","example":false,"citation":"Junyang Shao and David Chase, The Go Blog. \"Arch-specific SIMD in Go.\" 2 Oct 2026. https://go.dev/blog/archsimd (CC-BY-4.0)","access":{"human_view":"preview","full_text_available":true,"source_url":"https://go.dev/blog/archsimd"},"body_markdown":"Since Go 1.26, we have supported an experimental `amd64` SIMD API. Now in Go 1.27, we support two more architectures: `arm64` and `wasm`.\n\nThe new APIs can be accessed by setting `GOEXPERIMENT=simd` when building a program. They are defined in the `simd/archsimd` package.\n\n`archsimd` is the lower-level infrastructure that `simd` builds on, essentially the intrinsics layer in other languages. For exotic operations that only exist on a specific architecture, users can access them by transitioning from `simd` to `archsimd` (via `ToArch` and `FromArch`). For details, please refer to the [simd blog](https://go.dev/blog/simd-experiment) post.\n\nFor readers with prior knowledge of SIMD intrinsics in other languages, you might find that our `archsimd` API does not directly mirror the underlying hardware instructions:\n\n- We give our APIs sensible names: e.g., instead of `_mm512_slli_epi64` , we just call it`ShiftAllLeft` .\n- We leave some architecture details to compiler optimizations rather than exposing them in the API: e.g., instead of `_mm512_maskz_add_ps(m, x, y)` , we optimize`x.Add(y).Masked(m)` into the same instruction.\n\nThese design decisions make our APIs smaller and more accessible, and they also happily make the `simd` implementation much easier.\n\nFor readers without prior knowledge of SIMD intrinsics, we hope our low-level API is a natural and pleasant journey for you.\n\nPlease share your feedback and comments. Anything about usability, performance, etc., is appreciated. The parent issue for this project is [#73787](https://go.dev/issue/73787).\n\n## What is SIMD\n\nSIMD stands for Single Instruction, Multiple Data. SIMD instructions operate on wide registers (128-bit, 256-bit, or more) containing multiple 8- to 64-bit elements, performing operations across all elements in parallel. Wider registers and parallel execution provide a significant performance boost to algorithms that can take advantage of them.\n\nUntil now, anyone who wanted to use SIMD in Go had to endure the friction of writing assembly language. The new `archsimd` package is here to change that.\n\n## Goals\n\nThe goal is to support as many SIMD instructions across different architectures as possible. Currently, we have `amd64`, `arm64`, and `wasm` available. Our `amd64` support has the largest API surface, covering AVX, AVX2, and many AVX-512 extensions. Our `arm64` support currently covers NEON, with SVE and some SVE2 already on the way. Our `wasm` support is also mostly complete, thanks to its well-defined 128-bit SIMD abstraction.\n\nSome users might be interested in matrix extensions on certain architectures, such as AMX and SME. We haven’t fully settled on how to represent matrices effectively in Go, so they are not yet supported, but we might support them in the future.\n\n## API Design and Naming\n\n### Types\n\nThe architecture-specific SIMD API is imported from `simd/archsimd`. `archsimd` uses distinct struct types, such as `Float32x4`, `Int32x8`, or `Uint8x16`, to signal the shape and element type of each vector, and defines operations as methods on those types. At this moment, `archsimd` supports only fixed-width vector extensions. Scalable vector extensions like `arm64` SVE and RVV will have different struct types to represent vectors. Mask types also come with vector-like shapes, e.g., `Mask32x4`.\n\n### Methods\n\nAcross different vector widths, element types, and architectures, we use the same method name whenever operations are semantically identical:\n\n- Regardless of vector width or architecture, element-wise addition is simply `x.Add(y)` ; the type of`x` determines which instruction to emit. Instead of 18 different function names for addition, there is only one method name.\n- When instructions on different architectures look similar at a glance but differ in edge-case behavior, we give them distinct names so differences don’t silently bite you. For example, 16-byte table lookup on `amd64` (`VPSHUFB` ) zeros the output byte when the index is negative (`index < 0` ) and wraps modulo 16 otherwise, so we call it`PermuteOrZero` . On`arm64` NEON (`VTBL` ) and`wasm` (`i8x16.swizzle` ), any out-of-range index (`index < 0 || index >= 16` ) zeros the output byte, so we call it`LookupOrZero` .\n- On `amd64` , many 256-bit and 512-bit instructions operate independently within 128-bit lanes rather than across the entire register. We explicitly suffix those methods with`Grouped` (such as`InterleaveLoGrouped` or`PermuteOrZeroGrouped` ) to make the 128-bit lane boundary obvious.\n\nMethods require a receiver value, which doesn’t work for creating a vector from memory or a scalar. For those, `archsimd` provides package-level functions named with the target vector type:\n\n- **Slices (the default)** : In Go 1.27, loading and storing slices use the shortest names:`archsimd.LoadFloat32x4(s []float32) Float32x4` and`x.Store(s []float32)` . For tail elements that may be shorter than a full vector,`archsimd.LoadFloat32x4Part(s []float32) (Float32x4, int)` zero-fills the remaining lanes and returns the number of elements loaded, paired with`x.StorePart(s []float32) int` .\n- **Arrays and Broadcasts** : Fixed-size array pointers use the`Array` suffix (`archsimd.LoadFloat32x4Array(y *[4]float32)` and`x.StoreArray(y *[4]float32)` ), and`archsimd.BroadcastFloat32x4(v float32)` broadcasts a scalar to all lanes.\n\n### Type Reinterpretation\n\nReinterpretations are type casts without any cost. SIMD algorithms frequently reinterpret bits across element types and widths.\n\nIn the Go 1.26 experiment, we implemented this with `As` methods, which suffered from a quadratic explosion of type pairs and couldn’t generalize to width-agnostic vectors in `simd` or SVE.\n\nIn Go 1.27, we replace them with composable zero-cost conversions:\n\n- `ToBits()` reinterprets a signed integer or float vector as an unsigned integer vector of the same element width (e.g.,`Int32x4.ToBits() -> Uint32x4` ), and`BitsToInt32()` /`BitsToFloat32()` converts back.\n- `ReshapeToUints()` on unsigned vectors changes the element width within the same register width. For example, if`x` is an`archsimd.Uint8x16` , then`x.ReshapeToUint32s().BitsToFloat32()` reinterprets the bits of`x` as an`archsimd.Float32x4` at zero runtime cost.\n\n### Masks\n\nDifferent architectures encode vector masks very differently, e.g. `k` mask registers on AVX-512, full vector bitmasks on AVX/AVX2, NEON, and `wasm`, and predicate registers on SVE. To hide this hardware detail, `archsimd` provides opaque `Mask` types (such as `Mask32x4`) matching each vector shape:\n\n- Comparisons like `x.Greater(y)` produce a`Mask` .\n- `x.Masked(m)` zeros elements where`m` is false, and`x.IfElse(m, y)` (which replaces`Merge` from Go 1.26) selects elements from`x` where`m` is true and from`y` where`m` is false.\n- The compiler peepholes mask operations with the surrounding instructions: on AVX-512, `x.Add(y).Masked(m)` or`x.Add(y).IfElse(m, z)` compiles into a single zero-masked or merge-masked`VPADD` instruction; on AVX2, NEON, or`wasm` , it lowers to the appropriate bitwise`AND` or blend/bitselect instruction.\n\n## Examples\n\nPortable algorithms like inner product can easily be implemented using the portable `simd` package, as shown in the companion [simd blog](https://go.dev/blog/simd-experiment) post. However, we still expose `archsimd` to tap into exotic, architecture-specific instructions that do not fit into a portable intersection API, or instructions that can simply do things faster than what `simd` provides.\n\nOn `amd64`, the GFNI extension exposes `GaloisFieldAffineTransform` operations. Putting aside what a Galois Field is, these operations do a simple thing:\n\n```\n// Each element of A is interpreted as a matrix of 8 rows of vectors of 8 bits.\n// Each element of x is interpreted as a vector of 8 bits.\n// The b argument is likewise a vector of 8 bits.\n// The result is z[i] = (A[i/8] * x[i]) + b.\n//\n// The matrix * and vector + follow the usual rules for linear algebra,\n// but based on AND and XOR for scalar * and +\n//\n// Asm: VGF2P8AFFINEQB, CPU Feature: AVX512GFNI\nfunc (x Uint8x16) GaloisFieldAffineTransform(A Uint64x2, b uint8) Uint8x16\n```\nEach 8x8 bit matrix `A` is packed row-by-row into a single `uint64`. Because any linear combination or permutation of the 8 bits within a byte can be written as an 8x8 bit matrix, this single instruction is a Swiss Army knife for byte-level bit manipulation.\n\nFor example, reversing the bit order of every byte (`bits.Reverse8`) normally requires nibble lookup tables, masks, shifts, and ORs in SIMD. With `GaloisFieldAffineTransform`, we can simply multiply each byte by the 8x8 anti-diagonal identity matrix (`0x8040201008040201`) to reverse all 8 bits of 64 bytes at a time in a single instruction:\n\n```\n/*\n Anti-diagonal 8x8 bit matrix (0x8040201008040201):\n [ 0 0 0 0 0 0 0 1 ] [ x7 ] [ x0 ]\n [ 0 0 0 0 0 0 1 0 ] [ x6 ] [ x1 ]\n [ 0 0 0 0 0 1 0 0 ] [ x5 ] [ x2 ]\n [ 0 0 0 0 1 0 0 0 ] * [ x4 ] = [ x3 ]\n [ 0 0 0 1 0 0 0 0 ] [ x3 ] [ x4 ]\n [ 0 0 1 0 0 0 0 0 ] [ x2 ] [ x5 ]\n [ 0 1 0 0 0 0 0 0 ] [ x1 ] [ x6 ]\n [ 1 0 0 0 0 0 0 0 ] [ x0 ] [ x7 ]\n*/\nfunc ReverseBits(dst, src []uint8) {\n if !archsimd.X86.AVX512GFNI() {\n // A slow fallback emulation impl, details omitted.\n slowReverseBits(dst, src)\n return\n }\n if len(src) > len(dst) {\n // Make sure src and dst are the same size\n src = src[:len(dst)]\n }\n revMatrix := archsimd.BroadcastUint64x8(0x8040201008040201)\n var v archsimd.Uint8x64\n var i int\n for i = 0; i < len(src)-v.Len()+1; i += v.Len() {\n v = archsimd.LoadUint8x64(src[i : i+v.Len()])\n v.GaloisFieldAffineTransform(revMatrix, 0).Store(dst[i : i+v.Len()])\n }\n if i < len(src) {\n v, _ = archsimd.LoadUint8x64Part(src[i:])\n v.GaloisFieldAffineTransform(revMatrix, 0).StorePart(dst[i:])\n }\n}\n```\nAnother example is matrix transpose. On `amd64`, the permutation instructions are shaped in a non-portable way, so using `simd` is cumbersome and might incur emulations. An efficient implementation can be written more directly in `archsimd`. The example below transposes an 8-by-8 matrix of 32-bit integers in registers on `amd64` using AVX2’s 128-bit lane-grouped interleaves (`InterleaveLoGrouped`, `InterleaveHiGrouped`) and cross-lane permutations (`ConcatPermuteScalarsGrouped`, `ConcatPermute128Scalars`):\n\n```\nfunc Transpose8(a0, a1, a2, a3, a4, a5, a6, a7 archsimd.Int32x8) (\n b0, b1, b2, b3, b4, b5, b6, b7 archsimd.Int32x8) {\n if !archsimd.X86.AVX2() {\n // A slow fallback emulation impl, details omitted.\n return slowTranspose8(a0, a1, a2, a3, a4, a5, a6, a7)\n }\n /*\n LOW HIGH\n a0: abcd efgh\n a1: ijkl mnop\n a2: qrst uvwx\n a3: 0123 4567\n a4: ABCD EFGH\n a5: IJKL MNOP\n a6: QRST UVWX\n a7: 89yz YZ$@\n */\n t0 := a0.InterleaveLoGrouped(a1) // t0 = aibj emfn\n t1 := a0.InterleaveHiGrouped(a1) // t1 = ckdl gohp\n t2 := a2.InterleaveLoGrouped(a3) // t2 = q0r1 u4v5\n t3 := a2.InterleaveHiGrouped(a3) // t3 = s2t3 w6x7\n t4 := a4.InterleaveLoGrouped(a5) // t4 = AIBJ EMFN\n t5 := a4.InterleaveHiGrouped(a5) // t5 = CKDL GOHP\n t6 := a6.InterleaveLoGrouped(a7) // t6 = Q8R9 UYVZ\n t7 := a6.InterleaveHiGrouped(a7) // t7 = SyTz W$X@\n a0 = t0.ConcatPermuteScalarsGrouped(0, 1, 4, 5, t2) // a0 = aiq0 emu4\n a1 = t0.ConcatPermuteScalarsGrouped(2, 3, 6, 7, t2) // a1 = bjr1 fnv5\n a2 = t1.ConcatPermuteScalarsGrouped(0, 1, 4, 5, t3) // a2 = cks2 gow6\n a3 = t1.ConcatPermuteScalarsGrouped(2, 3, 6, 7, t3) // a3 = dlt3 hpx7\n a4 = t4.ConcatPermuteScalarsGrouped(0, 1, 4, 5, t6) // a4 = AIQ8 EMUY\n a5 = t4.ConcatPermuteScalarsGrouped(2, 3, 6, 7, t6) // a5 = BJR9 FNVZ\n a6 = t5.ConcatPermuteScalarsGrouped(0, 1, 4, 5, t7) // a6 = CKSy GOW$\n a7 = t5.ConcatPermuteScalarsGrouped(2, 3, 6, 7, t7) // a7 = DLTz HPX@\n b0 = a0.ConcatPermute128Scalars(0, 2, a4) // b0 = aiq0 AIQ8\n b1 = a1.ConcatPermute128Scalars(0, 2, a5) // b1 = bjr1 BJR9\n b2 = a2.ConcatPermute128Scalars(0, 2, a6) // b2 = cks2 CKSy\n b3 = a3.ConcatPermute128Scalars(0, 2, a7) // b3 = dlt3 DLTz\n b4 = a0.ConcatPermute128Scalars(1, 3, a4) // b4 = emu4 EMUY\n b5 = a1.ConcatPermute128Scalars(1, 3, a5) // b5 = fnv5 FNVZ\n b6 = a2.ConcatPermute128Scalars(1, 3, a6) // b6 = gow6 GOW$\n b7 = a3.ConcatPermute128Scalars(1, 3, a7) // b7 = hpx7 HPX@\n return\n}\n```\n## Good Practices\n\nWhen walking through the examples above, you might have a few questions:\n\n- What is `archsimd.X86.AVX512GFNI()` , and can I omit it?\n- Why is the strided loop written as `i = 0; i < len(src)-v.Len()+1; i += v.Len()` , instead of`i = 0; i + v.Len() <= len(src); i += v.Len()` ?\n- Why does `Transpose8` take 8 vector parameters rather than a struct or an`[8]archsimd.Int32x8` array?\n\nAt first glance these choices might look like minor stylistic preferences, but each of them is chosen for an important performance or correctness reason:\n\n-\nCPU feature checks ( `archsimd.X86.*` ,`archsimd.ARM64.*` )On `amd64` , we provide runtime feature checks like`archsimd.X86.AVX()` ,`AVX2()` ,`AVX512()` , and extension checks like`AVX512GFNI()` or`AVX512VNNI()` ; on`arm64` , NEON is always available, and we provide checks for optional extensions like`archsimd.ARM64.PMULL()` ,`SVE()` , and`SVE2()` . The compiler doesn’t know ahead of time whether the machine running your binary supports optional SIMD extensions. If you don’t guard your SIMD code with the appropriate feature check, your program may crash with`SIGILL` on hardware that lacks the instruction.Just as importantly, CPU feature checks act as **compiler optimization hints** . For example, AVX-512 supports hardware merge-masking on instruction outputs. How the compiler lowers`x.Add(y).IfElse(m, z)` on a 128-bit or 256-bit vector depends on which CPU features are known to be available. If the code is not guarded by`archsimd.X86.AVX512()` , the compiler must conservatively emit a vector`VPADD` followed by a`VPBLEND` instruction. Inside an`if archsimd.X86.AVX512()` block, however, the compiler knows AVX-512 is available and fuses the sequence into a single merge-masked AVX-512`VPADD` instruction.\n-\nBounds check elimination in strided loops How you write the loop bound determines whether the compiler’s `prove` pass can eliminate slice bounds checks inside the loop. In`i + v.Len() <= len(src)` , the addition`i + v.Len()` could theoretically overflow to a negative`int` if`len(src)` were near`math.MaxInt` , which prevents the compiler from proving that`i` is always non-negative and in-bounds. Writing`i < len(src)-v.Len()+1` avoids that potential overflow, allowing the loop body to compile with zero bounds checks.\n-\nKeeping vectors in registers (avoiding large composite types) `Transpose8` passes 8 vector parameters rather than a struct of 8 fields or an`[8]archsimd.Int32x8` array because Go’s ABI and SSA backend currently place large composite types in memory rather than in registers (a known issue tracked at[#24416](https://go.dev/issue/24416) ). Because SIMD vectors are 16 to 64 bytes each, spilling them to the stack hurts performance much more than spilling scalar values. This applies to both function parameters and local variables, so avoid wrapping SIMD vectors inside large arrays or structs in hot loops. There are ongoing efforts to promote composite memory accesses back into registers, which have not yet landed in Go 1.27.\n\n## Trying it out\n\nIn Go 1.27, `GOEXPERIMENT=simd` supports `amd64` (AVX, AVX2, and AVX-512), `arm64` (NEON), and `wasm` (WebAssembly 128-bit SIMD) out of the box. Whether you are on an Intel/AMD machine, an `arm64` server or Apple Silicon Mac (M1/M2/M3/M4), or targeting WebAssembly, you can try `archsimd` natively right away:\n\n```\nGOEXPERIMENT=simd go test simd/archsimd/...\n```\nYou can also cross-test `wasm` (or `amd64` via Rosetta emulation on Apple Silicon) by setting `GOARCH`:\n\n```\n# Run wasm SIMD tests using a WASI runtime:\nGOOS=wasip1 GOARCH=wasm GOEXPERIMENT=simd go test simd/archsimd/...\n# Or run amd64 AVX2 tests on Apple Silicon via Rosetta:\nGOARCH=amd64 GOEXPERIMENT=simd go test simd/archsimd/...\n```\nWe’re interested in all sorts of feedback! Early users have already helped us catch bugs (such as [#77582](https://go.dev/issue/77582)) and identify places where code generation or API ergonomics could be improved. We tried hard to pick clear, consistent names and cover the most useful instructions, but `archsimd` is a massive API surface and there is always room to improve.\n\n## Future work\n\nFor Go 1.28 and beyond, we are actively working on completing `arm64` SVE and SVE2 support in `archsimd` (introducing width-agnostic scalable vector types like `archsimd.Float32s` backed directly by hardware SVE registers and predicates) and wiring it into `simd`. We also plan to expand `archsimd` to additional architectures such as `riscv64`, `ppc64`, `s390x`, and `loong64`, improve register promotion for composite types, and continue filling in instructions and compiler optimizations based on community feedback.\n","body_html":"

Since Go 1.26, we have supported an experimental amd64 SIMD API. Now in Go 1.27, we support two more architectures: arm64 and wasm.

\n

The new APIs can be accessed by setting GOEXPERIMENT=simd when building a program. They are defined in the simd/archsimd package.

\n

archsimd is the lower-level infrastructure that simd builds on, essentially the intrinsics layer in other languages. For exotic operations that only exist on a specific architecture, users can access them by transitioning from simd to archsimd (via ToArch and <Types>FromArch). For details, please refer to the simd blog post.

\n

For readers with prior knowledge of SIMD intrinsics in other languages, you might find that our archsimd API does not directly mirror the underlying hardware instructions:

\n
  • We give our APIs sensible names: e.g., instead of _mm512_slli_epi64 , we just call itShiftAllLeft .
  • We leave some architecture details to compiler optimizations rather than exposing them in the API: e.g., instead of _mm512_maskz_add_ps(m, x, y) , we optimizex.Add(y).Masked(m) into the same instruction.
\n

These design decisions make our APIs smaller and more accessible, and they also happily make the simd implementation much easier.

\n

For readers without prior knowledge of SIMD intrinsics, we hope our low-level API is a natural and pleasant journey for you.

\n

Please share your feedback and comments. Anything about usability, performance, etc., is appreciated. The parent issue for this project is #73787.

\n

What is SIMD

\n

SIMD stands for Single Instruction, Multiple Data. SIMD instructions operate on wide registers (128-bit, 256-bit, or more) containing multiple 8- to 64-bit elements, performing operations across all elements in parallel. Wider registers and parallel execution provide a significant performance boost to algorithms that can take advantage of them.

\n

Until now, anyone who wanted to use SIMD in Go had to endure the friction of writing assembly language. The new archsimd package is here to change that.

\n

Goals

\n

The goal is to support as many SIMD instructions across different architectures as possible. Currently, we have amd64, arm64, and wasm available. Our amd64 support has the largest API surface, covering AVX, AVX2, and many AVX-512 extensions. Our arm64 support currently covers NEON, with SVE and some SVE2 already on the way. Our wasm support is also mostly complete, thanks to its well-defined 128-bit SIMD abstraction.

\n

Some users might be interested in matrix extensions on certain architectures, such as AMX and SME. We haven’t fully settled on how to represent matrices effectively in Go, so they are not yet supported, but we might support them in the future.

\n

API Design and Naming

\n

Types

\n

The architecture-specific SIMD API is imported from simd/archsimd. archsimd uses distinct struct types, such as Float32x4, Int32x8, or Uint8x16, to signal the shape and element type of each vector, and defines operations as methods on those types. At this moment, archsimd supports only fixed-width vector extensions. Scalable vector extensions like arm64 SVE and RVV will have different struct types to represent vectors. Mask types also come with vector-like shapes, e.g., Mask32x4.

\n

Methods

\n

Across different vector widths, element types, and architectures, we use the same method name whenever operations are semantically identical:

\n
  • Regardless of vector width or architecture, element-wise addition is simply x.Add(y) ; the type ofx determines which instruction to emit. Instead of 18 different function names for addition, there is only one method name.
  • When instructions on different architectures look similar at a glance but differ in edge-case behavior, we give them distinct names so differences don’t silently bite you. For example, 16-byte table lookup on amd64 (VPSHUFB ) zeros the output byte when the index is negative (index < 0 ) and wraps modulo 16 otherwise, so we call itPermuteOrZero . Onarm64 NEON (VTBL ) andwasm (i8x16.swizzle ), any out-of-range index (index < 0 || index >= 16 ) zeros the output byte, so we call itLookupOrZero .
  • On amd64 , many 256-bit and 512-bit instructions operate independently within 128-bit lanes rather than across the entire register. We explicitly suffix those methods withGrouped (such asInterleaveLoGrouped orPermuteOrZeroGrouped ) to make the 128-bit lane boundary obvious.
\n

Methods require a receiver value, which doesn’t work for creating a vector from memory or a scalar. For those, archsimd provides package-level functions named with the target vector type:

\n
  • Slices (the default) : In Go 1.27, loading and storing slices use the shortest names:archsimd.LoadFloat32x4(s []float32) Float32x4 andx.Store(s []float32) . For tail elements that may be shorter than a full vector,archsimd.LoadFloat32x4Part(s []float32) (Float32x4, int) zero-fills the remaining lanes and returns the number of elements loaded, paired withx.StorePart(s []float32) int .
  • Arrays and Broadcasts : Fixed-size array pointers use theArray suffix (archsimd.LoadFloat32x4Array(y *[4]float32) andx.StoreArray(y *[4]float32) ), andarchsimd.BroadcastFloat32x4(v float32) broadcasts a scalar to all lanes.
\n

Type Reinterpretation

\n

Reinterpretations are type casts without any cost. SIMD algorithms frequently reinterpret bits across element types and widths.

\n

In the Go 1.26 experiment, we implemented this with As<Type> methods, which suffered from a quadratic explosion of type pairs and couldn’t generalize to width-agnostic vectors in simd or SVE.

\n

In Go 1.27, we replace them with composable zero-cost conversions:

\n
  • ToBits() reinterprets a signed integer or float vector as an unsigned integer vector of the same element width (e.g.,Int32x4.ToBits() -> Uint32x4 ), andBitsToInt32() /BitsToFloat32() converts back.
  • ReshapeToUint<W>s() on unsigned vectors changes the element width within the same register width. For example, ifx is anarchsimd.Uint8x16 , thenx.ReshapeToUint32s().BitsToFloat32() reinterprets the bits ofx as anarchsimd.Float32x4 at zero runtime cost.
\n

Masks

\n

Different architectures encode vector masks very differently, e.g. k mask registers on AVX-512, full vector bitmasks on AVX/AVX2, NEON, and wasm, and predicate registers on SVE. To hide this hardware detail, archsimd provides opaque Mask types (such as Mask32x4) matching each vector shape:

\n
  • Comparisons like x.Greater(y) produce aMask .
  • x.Masked(m) zeros elements wherem is false, andx.IfElse(m, y) (which replacesMerge from Go 1.26) selects elements fromx wherem is true and fromy wherem is false.
  • The compiler peepholes mask operations with the surrounding instructions: on AVX-512, x.Add(y).Masked(m) orx.Add(y).IfElse(m, z) compiles into a single zero-masked or merge-maskedVPADD instruction; on AVX2, NEON, orwasm , it lowers to the appropriate bitwiseAND or blend/bitselect instruction.
\n

Examples

\n

Portable algorithms like inner product can easily be implemented using the portable simd package, as shown in the companion simd blog post. However, we still expose archsimd to tap into exotic, architecture-specific instructions that do not fit into a portable intersection API, or instructions that can simply do things faster than what simd provides.

\n

On amd64, the GFNI extension exposes GaloisFieldAffineTransform operations. Putting aside what a Galois Field is, these operations do a simple thing:

\n
// Each element of A is interpreted as a matrix of 8 rows of vectors of 8 bits.\n// Each element of x is interpreted as a vector of 8 bits.\n// The b argument is likewise a vector of 8 bits.\n// The result is z[i] = (A[i/8] * x[i]) + b.\n//\n// The matrix * and vector + follow the usual rules for linear algebra,\n// but based on AND and XOR for scalar * and +\n//\n// Asm: VGF2P8AFFINEQB, CPU Feature: AVX512GFNI\nfunc (x Uint8x16) GaloisFieldAffineTransform(A Uint64x2, b uint8) Uint8x16
\n

Each 8x8 bit matrix A is packed row-by-row into a single uint64. Because any linear combination or permutation of the 8 bits within a byte can be written as an 8x8 bit matrix, this single instruction is a Swiss Army knife for byte-level bit manipulation.

\n

For example, reversing the bit order of every byte (bits.Reverse8) normally requires nibble lookup tables, masks, shifts, and ORs in SIMD. With GaloisFieldAffineTransform, we can simply multiply each byte by the 8x8 anti-diagonal identity matrix (0x8040201008040201) to reverse all 8 bits of 64 bytes at a time in a single instruction:

\n
/*\n    Anti-diagonal 8x8 bit matrix (0x8040201008040201):\n    [ 0 0 0 0 0 0 0 1 ]   [ x7 ]   [ x0 ]\n    [ 0 0 0 0 0 0 1 0 ]   [ x6 ]   [ x1 ]\n    [ 0 0 0 0 0 1 0 0 ]   [ x5 ]   [ x2 ]\n    [ 0 0 0 0 1 0 0 0 ] * [ x4 ] = [ x3 ]\n    [ 0 0 0 1 0 0 0 0 ]   [ x3 ]   [ x4 ]\n    [ 0 0 1 0 0 0 0 0 ]   [ x2 ]   [ x5 ]\n    [ 0 1 0 0 0 0 0 0 ]   [ x1 ]   [ x6 ]\n    [ 1 0 0 0 0 0 0 0 ]   [ x0 ]   [ x7 ]\n*/\nfunc ReverseBits(dst, src []uint8) {\n    if !archsimd.X86.AVX512GFNI() {\n        // A slow fallback emulation impl, details omitted.\n        slowReverseBits(dst, src)\n        return\n    }\n    if len(src) > len(dst) {\n        // Make sure src and dst are the same size\n        src = src[:len(dst)]\n    }\n    revMatrix := archsimd.BroadcastUint64x8(0x8040201008040201)\n    var v archsimd.Uint8x64\n    var i int\n    for i = 0; i < len(src)-v.Len()+1; i += v.Len() {\n        v = archsimd.LoadUint8x64(src[i : i+v.Len()])\n        v.GaloisFieldAffineTransform(revMatrix, 0).Store(dst[i : i+v.Len()])\n    }\n    if i < len(src) {\n        v, _ = archsimd.LoadUint8x64Part(src[i:])\n        v.GaloisFieldAffineTransform(revMatrix, 0).StorePart(dst[i:])\n    }\n}
\n

Another example is matrix transpose. On amd64, the permutation instructions are shaped in a non-portable way, so using simd is cumbersome and might incur emulations. An efficient implementation can be written more directly in archsimd. The example below transposes an 8-by-8 matrix of 32-bit integers in registers on amd64 using AVX2’s 128-bit lane-grouped interleaves (InterleaveLoGrouped, InterleaveHiGrouped) and cross-lane permutations (ConcatPermuteScalarsGrouped, ConcatPermute128Scalars):

\n
func Transpose8(a0, a1, a2, a3, a4, a5, a6, a7 archsimd.Int32x8) (\n    b0, b1, b2, b3, b4, b5, b6, b7 archsimd.Int32x8) {\n    if !archsimd.X86.AVX2() {\n        // A slow fallback emulation impl, details omitted.\n        return slowTranspose8(a0, a1, a2, a3, a4, a5, a6, a7)\n    }\n    /*\n            LOW  HIGH\n        a0: abcd efgh\n        a1: ijkl mnop\n        a2: qrst uvwx\n        a3: 0123 4567\n        a4: ABCD EFGH\n        a5: IJKL MNOP\n        a6: QRST UVWX\n        a7: 89yz YZ$@\n    */\n    t0 := a0.InterleaveLoGrouped(a1) // t0 = aibj emfn\n    t1 := a0.InterleaveHiGrouped(a1) // t1 = ckdl gohp\n    t2 := a2.InterleaveLoGrouped(a3) // t2 = q0r1 u4v5\n    t3 := a2.InterleaveHiGrouped(a3) // t3 = s2t3 w6x7\n    t4 := a4.InterleaveLoGrouped(a5) // t4 = AIBJ EMFN\n    t5 := a4.InterleaveHiGrouped(a5) // t5 = CKDL GOHP\n    t6 := a6.InterleaveLoGrouped(a7) // t6 = Q8R9 UYVZ\n    t7 := a6.InterleaveHiGrouped(a7) // t7 = SyTz W$X@\n    a0 = t0.ConcatPermuteScalarsGrouped(0, 1, 4, 5, t2) // a0 = aiq0 emu4\n    a1 = t0.ConcatPermuteScalarsGrouped(2, 3, 6, 7, t2) // a1 = bjr1 fnv5\n    a2 = t1.ConcatPermuteScalarsGrouped(0, 1, 4, 5, t3) // a2 = cks2 gow6\n    a3 = t1.ConcatPermuteScalarsGrouped(2, 3, 6, 7, t3) // a3 = dlt3 hpx7\n    a4 = t4.ConcatPermuteScalarsGrouped(0, 1, 4, 5, t6) // a4 = AIQ8 EMUY\n    a5 = t4.ConcatPermuteScalarsGrouped(2, 3, 6, 7, t6) // a5 = BJR9 FNVZ\n    a6 = t5.ConcatPermuteScalarsGrouped(0, 1, 4, 5, t7) // a6 = CKSy GOW$\n    a7 = t5.ConcatPermuteScalarsGrouped(2, 3, 6, 7, t7) // a7 = DLTz HPX@\n    b0 = a0.ConcatPermute128Scalars(0, 2, a4) // b0 = aiq0 AIQ8\n    b1 = a1.ConcatPermute128Scalars(0, 2, a5) // b1 = bjr1 BJR9\n    b2 = a2.ConcatPermute128Scalars(0, 2, a6) // b2 = cks2 CKSy\n    b3 = a3.ConcatPermute128Scalars(0, 2, a7) // b3 = dlt3 DLTz\n    b4 = a0.ConcatPermute128Scalars(1, 3, a4) // b4 = emu4 EMUY\n    b5 = a1.ConcatPermute128Scalars(1, 3, a5) // b5 = fnv5 FNVZ\n    b6 = a2.ConcatPermute128Scalars(1, 3, a6) // b6 = gow6 GOW$\n    b7 = a3.ConcatPermute128Scalars(1, 3, a7) // b7 = hpx7 HPX@\n    return\n}
\n

Good Practices

\n

When walking through the examples above, you might have a few questions:

\n
  • What is archsimd.X86.AVX512GFNI() , and can I omit it?
  • Why is the strided loop written as i = 0; i < len(src)-v.Len()+1; i += v.Len() , instead ofi = 0; i + v.Len() <= len(src); i += v.Len() ?
  • Why does Transpose8 take 8 vector parameters rather than a struct or an[8]archsimd.Int32x8 array?
\n

At first glance these choices might look like minor stylistic preferences, but each of them is chosen for an important performance or correctness reason:

\n

-\nCPU feature checks ( archsimd.X86.* ,archsimd.ARM64.* )On amd64 , we provide runtime feature checks likearchsimd.X86.AVX() ,AVX2() ,AVX512() , and extension checks likeAVX512GFNI() orAVX512VNNI() ; onarm64 , NEON is always available, and we provide checks for optional extensions likearchsimd.ARM64.PMULL() ,SVE() , andSVE2() . The compiler doesn’t know ahead of time whether the machine running your binary supports optional SIMD extensions. If you don’t guard your SIMD code with the appropriate feature check, your program may crash withSIGILL on hardware that lacks the instruction.Just as importantly, CPU feature checks act as compiler optimization hints . For example, AVX-512 supports hardware merge-masking on instruction outputs. How the compiler lowersx.Add(y).IfElse(m, z) on a 128-bit or 256-bit vector depends on which CPU features are known to be available. If the code is not guarded byarchsimd.X86.AVX512() , the compiler must conservatively emit a vectorVPADD followed by aVPBLEND instruction. Inside anif archsimd.X86.AVX512() block, however, the compiler knows AVX-512 is available and fuses the sequence into a single merge-masked AVX-512VPADD instruction.\n-\nBounds check elimination in strided loops How you write the loop bound determines whether the compiler’s prove pass can eliminate slice bounds checks inside the loop. Ini + v.Len() <= len(src) , the additioni + v.Len() could theoretically overflow to a negativeint iflen(src) were nearmath.MaxInt , which prevents the compiler from proving thati is always non-negative and in-bounds. Writingi < len(src)-v.Len()+1 avoids that potential overflow, allowing the loop body to compile with zero bounds checks.\n-\nKeeping vectors in registers (avoiding large composite types) Transpose8 passes 8 vector parameters rather than a struct of 8 fields or an[8]archsimd.Int32x8 array because Go’s ABI and SSA backend currently place large composite types in memory rather than in registers (a known issue tracked at#24416 ). Because SIMD vectors are 16 to 64 bytes each, spilling them to the stack hurts performance much more than spilling scalar values. This applies to both function parameters and local variables, so avoid wrapping SIMD vectors inside large arrays or structs in hot loops. There are ongoing efforts to promote composite memory accesses back into registers, which have not yet landed in Go 1.27.

\n

Trying it out

\n

In Go 1.27, GOEXPERIMENT=simd supports amd64 (AVX, AVX2, and AVX-512), arm64 (NEON), and wasm (WebAssembly 128-bit SIMD) out of the box. Whether you are on an Intel/AMD machine, an arm64 server or Apple Silicon Mac (M1/M2/M3/M4), or targeting WebAssembly, you can try archsimd natively right away:

\n
GOEXPERIMENT=simd go test simd/archsimd/...
\n

You can also cross-test wasm (or amd64 via Rosetta emulation on Apple Silicon) by setting GOARCH:

\n
# Run wasm SIMD tests using a WASI runtime:\nGOOS=wasip1 GOARCH=wasm GOEXPERIMENT=simd go test simd/archsimd/...\n# Or run amd64 AVX2 tests on Apple Silicon via Rosetta:\nGOARCH=amd64 GOEXPERIMENT=simd go test simd/archsimd/...
\n

We’re interested in all sorts of feedback! Early users have already helped us catch bugs (such as #77582) and identify places where code generation or API ergonomics could be improved. We tried hard to pick clear, consistent names and cover the most useful instructions, but archsimd is a massive API surface and there is always room to improve.

\n

Future work

\n

For Go 1.28 and beyond, we are actively working on completing arm64 SVE and SVE2 support in archsimd (introducing width-agnostic scalable vector types like archsimd.Float32s backed directly by hardware SVE registers and predicates) and wiring it into simd. We also plan to expand archsimd to additional architectures such as riscv64, ppc64, s390x, and loong64, improve register promotion for composite types, and continue filling in instructions and compiler optimizations based on community feedback.

","headings":[{"level":2,"text":"What is SIMD","id":"what-is-simd"},{"level":2,"text":"Goals","id":"goals"},{"level":2,"text":"API Design and Naming","id":"api-design-and-naming"},{"level":3,"text":"Types","id":"types"},{"level":3,"text":"Methods","id":"methods"},{"level":3,"text":"Type Reinterpretation","id":"type-reinterpretation"},{"level":3,"text":"Masks","id":"masks"},{"level":2,"text":"Examples","id":"examples"},{"level":2,"text":"Good Practices","id":"good-practices"},{"level":2,"text":"Trying it out","id":"trying-it-out"},{"level":2,"text":"Future work","id":"future-work"}]}}