Go 팀, 플랫폼 독립 SIMD 패키지 공개 설명 — 어셈블리 없이 AVX·NEON·Wasm을 한 코드로

WHAT HAPPENED무슨 일이 있었나

SIMD(단일 명령 다중 데이터)는 한 명령으로 여러 값을 동시에 계산하는 CPU 기능이다. 예를 들어 float64 쌍 8개를 명령 하나로 더할 수 있다. 암호화, 데이터 처리, AI 연산에서 큰 속도 차이를 만들고, Go의 그린 티(Green Tea) 가비지 컬렉터도 살아 있는 객체를 찾는 메모리 스캔에 SIMD를 쓴다고 블로그는 설명했다.

문제는 접근 방법이었다. 이 실험 API 이전에는 Go 어셈블리를 직접 작성하는 것이 유일한 길이었고, 그래서 정말 성능이 결정적인 커널에만 쓰였다. 블로그는 그 결과 "SIMD 덕을 볼 수 있는 많은 소프트웨어가 CPU의 상당 부분을 놀려 왔다"고 진단했다. Go 1.27 릴리스 노트도 새 실험 패키지로 simd를 명시하고, 모든 아키텍처에서 사용할 수 있으며 하드웨어 명령이 있으면 활용한다고 적었다.

DESIGN두 층의 구조: archsimd와 simd

왜 두 층이 필요한지에 대한 설명이 이 글의 핵심이다. SIMD 아키텍처는 차원이 여러 개다. wasm·PowerPC·s390x는 128비트 하나, amd64는 128·256·512비트, loong64는 128·256비트를 쓴다. riscv64는 128비트에서 65536비트 사이의 2의 거듭제곱 길이를, arm64는 고정 128비트(NEON)와 128~2048비트 가변(SVE)을 지원한다. 같은 amd64라도 AVX인지 AVX2인지 AVX-512인지 실행 시점에 확인해야 한다.

마스크 처리 방식도 제각각이다. wasm·AVX·AVX2·NEON은 별도 마스크 레지스터 없이 비트마스크 벡터로 처리하고, AVX-512와 RVV는 원소당 1비트의 마스크 레지스터를, SVE는 바이트당 1비트를 쓴다. 지원 연산도 다르다. 예컨대 wasm에는 64비트 정수 벡터 비교가 없다. 아키텍처별 패키지를 아무리 균일하게 만들어도 이런 차이가 남기 때문에, 효율을 해치지 않는 선에서 차이를 숨기는 별도 층이 필요했다는 설명이다.

// innerProduct returns the inner product of x and y.
func innerProduct(x, y []float32) float32 {
    var a simd.Float32s
    var i int
    for i = 0; i < len(x)-a.Len()+1; i += a.Len() {
        u := simd.LoadFloat32s(x[i : i+a.Len()])
        v := simd.LoadFloat32s(y[i : i+a.Len()])
        a = u.MulAdd(v, a)
    }
    if i < len(x) {
        u, _ := simd.LoadFloat32sPart(x[i:])
        v, _ := simd.LoadFloat32sPart(y[i:])
        a = u.MulAdd(v, a)
    }
    return sum(a) // 1.27에는 ReduceSum이 없어 직접 구현
}

코드에 벡터 길이가 등장하지 않는다는 점이 눈에 띈다. a.Len()이 실행 중인 하드웨어에 맞는 길이를 알려 주고, 남은 꼬리는 LoadFloat32sPart로 처리한다. 블로그는 첫 실험 릴리스의 한계도 숨기지 않았다. 벡터 원소 전체를 더하는 공통 방법이 없어 1.27의 simd는 합계 연산을 지원하지 않으며, 다음 릴리스에서 simd.ReduceSum이 나온다고 했다.

UNDER THE HOOD컴파일러가 하는 일과 시험 방법

simd는 패키지이자 내부 구현 패키지이며, 동시에 컴파일러 프런트엔드의 AST 재작성이다. simd 타입을 언급하는 함수·변수·타입은 벡터 길이별로 특화된 복사본이 만들어지고, 이름에 128·256·512 또는 에뮬레이션을 뜻하는 0이 붙은 @simdNNN 접미사가 생긴다. 시그니처에 simd 타입이 없는 함수는 프로그램 시작 때 감지한 SIMD 수준에 따라 알맞은 특화 버전을 부르는 래퍼가 된다. 디스패치 비용을 계산 루프 밖으로 끌어올리기 위한 절충이라는 설명이다.

부족한 연산은 ToArch()로 아키텍처별 타입으로 내려갔다가 FromArch 함수로 돌아오는 방식으로 메울 수 있다. 블로그는 1.27에 없는 Int8s.OnesCount()를 amd64·NEON·Wasm과 에뮬레이션 버전으로 각각 구현하는 예제를 보여 주면서, 인터페이스 변환과 타입 스위치는 컴파일러가 특화 과정에서 최적화로 없앤다고 설명했다.

IMPACT개발자에게 미치는 영향

당장 프로덕션 코드를 갈아엎을 일은 아니다. 실험 기능이라 GOEXPERIMENT 플래그가 필요하고, API는 안정판이 아니다. 하지만 바이트 처리, 해시, 압축, 이미지 필터, 벡터 검색처럼 반복 루프가 성능을 좌우하는 코드를 Go로 짜는 사람에게는 어셈블리를 배우지 않고도 SIMD를 시험할 수 있는 길이 처음 열렸다. 블로그는 "LLM이 코드를 쓰게 되더라도 읽고 이해하기 쉬운 것"을 설계 목표 중 하나로 꼽기도 했다.

Go 팀은 1.28에서 archsimd에 SVE 지원을 추가하고 simd에도 넣기를 바란다고 밝혔다. 또 하드웨어 벡터는 있지만 연산 한두 개가 빠진 라즈베리 파이 같은 플랫폼이 통째로 에뮬레이션으로 떨어지지 않도록 소수의 "기능 변형"을 넣을 계획이다. archsimd를 자세히 다루는 별도 블로그 글도 곧 낼 예정이라고 했다.

자주 묻는 질문

Go에서 SIMD를 쓰려면 어떻게 해야 하나?

Go 1.27 이상에서 GOEXPERIMENT=simd 환경 변수를 켜고 빌드하면 이식형 simd 패키지와 아키텍처별 simd/archsimd 패키지를 쓸 수 있다. 실험 기능이라 API가 바뀔 수 있으며, 이전에는 Go 어셈블리가 유일한 방법이었다.

Go simd 패키지는 어떤 CPU를 지원하나?

Go 1.27 기준 amd64의 AVX·AVX2·AVX-512, arm64의 NEON, WebAssembly SIMD를 지원한다. 하드웨어 지원이 없는 플랫폼에서는 모든 연산이 에뮬레이션으로 동작하므로 코드는 어디서나 실행된다.

simd와 simd/archsimd는 무엇이 다른가?

archsimd는 128·256·512비트처럼 크기가 고정된 아키텍처별 타입과 플랫폼 고유 연산을 제공해 이식성이 없다. simd는 크기가 정해지지 않은 벡터 타입과 모든 플랫폼 공통 연산만 제공하고, 부족한 연산은 ToArch로 archsimd에 내려가 보완한다.

Go 1.28에서 simd는 어떻게 달라지나?

Go 팀은 1.28에서 arm64 SVE 지원과 ReduceSum·OnesCount·마스크·셔플 같은 연산 추가를 예고했다. 일부 연산만 빠진 하드웨어가 전부 에뮬레이션으로 떨어지지 않도록 기능 변형도 도입할 계획이다.

참고 자료

• The Go Blog — Platform-independent SIMD in Go
• Go 1.27 Release Notes