« SIMD를 알아야 하는 이유」: Mitchell Hashimoto의 여전히 중요하고 유일한 최적화에 대한 조언

Mitchell Hashimoto (HashiCorp 설립자)는 SIMD를 알지 못하는 것은 CPU의 성능을 4배에서 16배까지 활용하지 못하는 것이라고 주장하는 에세이를 발표했습니다.

구체적인 사례

Mitchell Hashimoto - HashiCorp의 공동 창업자이자 현재는 Ghostty(Zig로 작성된 터미널 에뮬레이터)라는 프로젝트의 활발한 개인 기여자가 된 인물 -는 Everyone Should Know SIMD라는 제목의 긴 글을 발표했다. 핵심은 한 문장으로 요약된다: CPU가 주파수 면에서는 정체되어 있지만 벡터 레지스터 면에서는 넓어지는 세상에서 SIMD를 무시한다는 것은 성능의 여러 차수를 잠재우는 것이다.

SIMD(Single Instruction, Multiple Data)는 CPU 명령어로, 동일한 연산을 여러 값에 동시에 적용하는 방식이다 - 한 사이클에 여덟 개의 float를 더하거나, 열여섯 바이트를 한 번에 비교하는 식이다. 현대 x86-64 CPU에서는 SSE / AVX / AVX2 / AVX-512 명령어 집합이, ARM(Apple Silicon, Neoverse 서버)에서는 NEON과 SVE가 SIMD를 담당한다.

내부 메커니즘: 왜 이 주제가 다시 떠오르는가

SIMD는 MMX(1996년)부터 존재해온 기술이지만, 최근 변화가 있었다:

1. 레지스터 너비 증가: 128비트(SSE, NEON) → 256비트(AVX2) → 512비트(AVX-512). AVX-512 레지스터 하나는 16개의 float32 또는 64개의 int8를 담을 수 있다.
2. 보급 확대: AVX2는 인텔 Haswell(2013년) 이후 모든 x86 일반용 CPU에 탑재되었다. NEON은 ARMv8(아이폰 5S 이후 모든 모델, 모든 ARM 서버)에서 표준이다.
3. CPU 주파수 한계: 세대별 성능 향상이 줄어들고 있다. 반면 벡터화는 여전히 효과적이다.
4. 자동 벡터화의 한계: LLVM, GCC 등 컴파일러는 단순한 루프는 잘 벡터화하지만, 분기, 포인터 추적, 특수한 누산 등이 포함되면 실패하는 경우가 많다. 이 경우 프로그래머가 직접 처리해야 한다.

Hashimoto의 말

핵심 메시지: SIMD는 그래픽 엔진이나 비디오 코덱 개발자만의 전유물이 아니다. 대량 데이터 처리(파싱, 검색, 문자열 비교, 통계 계산, 이미지 필터, 해싱 등)는 벡터화로 큰 성능 향상을 얻을 수 있다.

실제 사례:

• simdjson은 최신 CPU에서 JSON을 초당 3~5GB 파싱하며, 대부분 SIMD 덕분이다.
• 정렬 엔진 VqSort(구글)와 ips4o는 SIMD를 활용해 std::sort보다 3~5배 빠른 성능을 보인다.
• 칼럼형 DB(ClickHouse, DuckDB)는 SIMD 커널을 기반으로 한다.
• Protobuf와 UTF-8 파싱도 벡터화로 유사한 성능 향상을 얻을 수 있다.

요약하자면, SIMD는 더 이상 niche 기술이 아니라 대용량 데이터 처리 성능의 기본 역량이다.

진입 방법: 어려움에 빠지지 않고

SIMD를 직접 다루는 것은 어렵기로 유명하다: x86과 ARM 간 이식성이 떨어지고, 인트린식(intrinsics)이 난해하다. 현재 유용한 세 가지 접근법:

1. Highway(구글): C++ 라이브러리로, SSE/AVX/NEON/SVE를 공통 API로 추상화하며 런타임에 CPU에 맞게 dispatch한다.
2. std::simd(C++26 제안): STL에 포함될 예정인 포터블 SIMD로, 아직 실험 단계다.
3. Rust / Zig의 포터블 SIMD: 두 언어 모두 포터블 벡터 API 제공(core::simd in Rust nightly, @Vector builtin in Zig).

일반 애플리케이션 개발자라면 Highway, std::simd, @Vector 같은 포터블 라이브러리를 통해 저수준 인트린식까지 파고들지 않으면서도 핵심 성능 향상을 얻을 수 있다.

우리의 해석

Hashimoto의 지적은 옳다: JavaScript, Python, Go 등 관리형 런타임에서 훈련받은 개발자들은 CPU가 지난 10년간 제공해온 계산 능력이 코드에서 전혀 활용되지 않는다는 사실을 종종 간과한다. 이는 비난이 아니라 사실에 가깝다. 그리고 이 계산 능력을 크리티컬 패스(critical path)에 연결했을 때의 ROI는 놀라울 정도로 크다.

기억할 점

• SIMD는 더 이상 exotic 최적화가 아니다: CPU에서 남은 성능 향상의 주요 원천이다.
• Highway, std::simd, Zig @Vector 같은 포터블 라이브러리가 진입 장벽을 낮췄다.
• 대용량 데이터 처리(파서, DB, 이미지, 해싱 등)는 SIMD 관점에서 재검토해야 한다.