SIMD는 평범한 반복문을 어떻게 5배 빠르게 만들었을까요

SIMD는 평범한 반복문을 어떻게 5배 빠르게 만들었을까요

SIMD 반복문 성능 최적화 썸네일

배열이나 문자열을 한 값씩 검사하는 반복문은 코드 곳곳에 있어요. SIMD는 이런 연속 데이터를 4개, 8개, 16개씩 묶어 같은 연산을 수행해요. Ghostty 개발자 Mitchell Hashimoto는 코드 포인트 검색 루프에 이 방식을 적용했고, AVX2 기반 인텔 데스크톱에서 터미널 전체 처리량이 약 5배 높아졌다고 밝혔어요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
처리 방식	여러 값을 벡터 하나에 담아 동시에 계산해요	연속 데이터를 다루는 반복문의 명령 수를 줄일 수 있어요
공통 구조	준비, 적재, 연산, 축소·저장, 나머지 처리의 5단계를 따라요	CPU 전용 어셈블리를 몰라도 적용 흐름을 파악할 수 있어요
실제 결과	Ghostty는 AVX2 환경에서 전체 처리량이 약 5배 높아졌어요	작은 루프 개선이 애플리케이션 전체 성능으로 이어진 사례예요
적용 조건	큰 연속 데이터와 자주 실행되는 핫 루프에 잘 맞아요	짧은 입력이나 분기가 많은 코드에는 오히려 비용이 될 수 있어요

1. 한 번에 여러 값을 검사하는 반복문

SIMD는 Single Instruction, Multiple Data의 약자예요. CPU 명령 하나가 같은 종류의 값 여러 개에 동일한 비교나 산술 연산을 수행해요. 바이트 배열을 한 칸씩 읽던 루프를 벡터 폭만큼 묶어 읽는 방식으로 바꾸는 셈이에요. ARM NEON에서 `u32` 4개, AVX2에서 8개, AVX-512에서 16개를 한 묶음으로 다룰 수 있어요. 실제 벡터 폭은 자료형과 대상 CPU에 따라 달라져요. 2

Hashimoto가 제시한 Ghostty 사례는 디코딩을 마친 코드 포인트 배열에서 다음 제어 문자를 찾는 루프예요. 기존 코드는 값이 `0xF`보다 큰지 하나씩 확인했어요. 벡터 버전은 여러 코드 포인트를 한꺼번에 비교한 뒤, 조건을 처음 만족하지 않는 레인의 위치를 비트 마스크로 찾아요. 터미널 입력 대부분이 화면에 출력할 일반 문자라는 특성을 이용해 긴 구간을 빠르게 건너뛰어요.

728x90

이론적인 최대치는 벡터에 담는 값의 개수와 비슷해요. 원문은 ARM NEON에서 최대 4배, AVX2에서 8배, AVX-512에서 16배의 국소 처리량 향상을 제시해요. 적재와 결과 축소, 주변 로직에도 시간이 들기 때문에 애플리케이션 전체가 같은 배수로 빨라지지는 않아요. Ghostty의 AVX2 측정에서는 터미널 프로그램 입력부터 최종 상태 생성까지 포함한 처리량이 약 5배 높아졌어요. 2

SIMD 코드에서 반복되는 5단계

첫 단계에서는 비교할 상수나 누산값을 벡터의 모든 레인에 채워요. Ghostty 예제는 `0xF`를 각 레인에 복제해 코드 포인트 벡터와 바로 비교할 수 있게 만들어요. 그다음 입력이 벡터 하나를 채울 만큼 남아 있는 동안 벡터 폭 단위로 읽어요.

세 번째 단계에서 비교나 덧셈 같은 연산을 모든 레인에 동시에 적용해요. 네 번째 단계는 알고리듬에 따라 달라져요. 합계를 구한다면 벡터 누산값을 숫자 하나로 줄이고, 변환 작업이라면 벡터 결과를 출력 버퍼에 저장해요. Ghostty의 검색 루프는 비교 결과를 비트 마스크로 바꾼 뒤 첫 실패 위치를 계산해요.

마지막에는 벡터 하나를 채우지 못한 나머지를 기존 반복문으로 처리해요. 8개씩 읽는 루프라면 끝에 0개부터 7개까지 남을 수 있어요. SIMD를 지원하지 않는 대상에서는 같은 스칼라 반복문이 전체 입력을 맡아요. 원래 코드를 남겨 두면 나머지 처리와 호환성 폴백을 함께 해결할 수 있어요.

자동 벡터화부터 확인해야 해요

현대 컴파일러도 규칙적인 반복문을 SIMD 명령으로 바꿀 수 있어요. LLVM은 루프 벡터화와 SLP 벡터화를 제공하고, 비용 모델을 바탕으로 벡터화가 이득인지 판단해요. 개발자는 최적화 옵션을 켠 빌드의 생성 코드와 벡터화 진단을 먼저 확인할 수 있어요. 이미 컴파일러가 원하는 명령을 만들었다면 수동 구현을 더할 이유가 줄어요. 3

자동 벡터화가 늘 성공하는 것은 아니에요. 데이터 의존성, 복잡한 분기, 함수 호출, 메모리 별칭 가능성 때문에 컴파일러가 안전한 스칼라 코드를 선택할 수 있어요. 성능에 큰 영향을 주는 루프라면 명시적 벡터 코드를 두고 벤치마크와 테스트로 결과를 고정하는 선택도 가능해요. 다만 컴파일러 버전이나 CPU 대상 옵션이 바뀌면 생성 코드도 달라질 수 있으므로 측정은 계속 필요해요.

모든 반복문에 넣는 가속 버튼은 아니에요

SIMD는 연속된 큰 입력에 같은 연산을 반복할 때 효과가 커요. 문자열 검색, 이미지·오디오 처리, 파싱, 수치 계산, 체크섬처럼 데이터 병렬성이 높은 작업이 대표적이에요. 반대로 입력이 몇 개뿐이거나 값마다 다른 분기를 타면 벡터를 준비하고 결과를 합치는 비용이 절감분보다 클 수 있어요.

메모리 접근도 함께 봐야 해요. 데이터가 여기저기 흩어져 있거나 캐시 미스가 병목이라면 연산만 묶어도 기대한 속도가 나오지 않아요. 먼저 프로파일러로 시간이 몰리는 핫 루프를 찾고, 데이터 배치와 접근 패턴을 확인해야 해요. 스칼라 기준 구현과 SIMD 구현을 같은 입력으로 비교하고, 경곗값과 남은 원소 처리도 테스트하는 편이 안전해요.

왜 중요한가요

SIMD를 직접 작성하지 않더라도 어떤 코드가 벡터화에 잘 맞는지 알면 자료구조와 반복문을 다르게 설계할 수 있어요. 연속된 배열, 예측 가능한 접근, 독립적인 계산은 컴파일러의 자동 벡터화에도 유리해요. 성능 문제가 생긴 뒤 CPU 전용 명령부터 찾기보다 데이터 구조 단계에서 병렬 처리 가능성을 남겨 두는 쪽이 수정 범위를 줄여요. 3

Ghostty 사례가 보여주는 실용적인 기준도 분명해요. 프로파일링으로 자주 실행되는 루프를 찾고, 생성 코드를 확인한 뒤, 큰 연속 입력에서 이득이 있을 때만 명시적 SIMD를 검토해요. 벡터 폭에 맞지 않는 나머지와 미지원 CPU를 처리할 스칼라 경로도 유지해야 해요. 이렇게 범위를 좁히면 SIMD는 일부 성능 전문가만 다루는 기법보다 반복문 최적화 도구에 가까워져요. 2

참고 자료

1. 모든 개발자가 SIMD를 알아야 하는 이유 — GeekNews
2. Everyone Should Know SIMD — Mitchell Hashimoto
3. Auto-Vectorization in LLVM — LLVM Project