콘텐츠 정의 청킹(content-defined chunking)은 파일을 고정된 크기로 자르는 대신, 슬라이딩 윈도우 해시를 파일 위로 굴리며 해시가 특정 값을 가질 때마다 청크 경계를 만드는 기법이다. 청크 길이가 분포를 따라 가변적이 되는 단점이 있지만, 파일 중간에 바이트가 삽입되거나 삭제되어도 경계가 크게 흔들리지 않는다는 이점이 크다. FastCDC 논문이 제시한 GEAR 롤링 해시가 이 방식의 기본 구성 요소이며, 이를 Rust로 구현하고 SSE4.2·AVX2용 최적화를 담은 것이 gearhash 크레이트다. 이번에 0.1.4 버전에서 ARM64용 NEON 백엔드가 추가되면서 일반적인 청크 크기에서 대략 2배 빨라졌다. aarch64에서 자동으로 선택되고 하위 호환되므로, 크레이트 사용자는 버전만 올리면 된다.
이 최적화가 지금 의미를 갖게 된 배경에는 ARM64의 위상 변화가 있다. 크레이트를 처음 작성하던 시점만 해도 ARM64는 최적화할 가치가 큰 대상이 아니었다. AWS의 1세대 Graviton A1은 Cortex-A72 기반의 스케일아웃용이었고, 경쟁력 있는 코어를 갖춘 Graviton2는 2020년 5월에야 정식 출시됐으며 Apple의 M1은 그해 11월에 발표됐다. 지금은 상황이 다르다. Apple이 ARM64를 소비자 하드웨어의 주류로 끌어올렸고, AWS는 3년 연속 새로 추가한 CPU 용량의 절반 이상이 Graviton이라고 밝혔으며, GitHub Actions는 2025년 공개 저장소용 무료 ARM64 러너를 추가했다. 게다가 gearhash는 Git LFS를 대체한 Hugging Face의 대용량 파일 저장 프로토콜인 Xet 클라이언트의 핵심 요소가 되어 하루 1만~2만 건 다운로드된다. 그럼에도 이 모든 머신에서 크레이트는 스칼라 루프로 폴백하고 있었다.
벡터화가 어려운 이유
GEAR 해시 커널은 64비트 정수에 대한 직렬 함수로, 매 바이트마다 해시를 왼쪽으로 1비트 시프트하고 테이블 값을 더한다. 핵심 관찰은 해시가 64비트 폭이고 바이트당 1비트씩 밀리므로, 64바이트가 지나면 초기값이 완전히 밀려 나간다는 점이다. 따라서 버퍼의 임의 지점에서 hash=0으로 시작해 64바이트 동안 '워밍업'하면, 그 이후의 해시는 처음부터 계산한 것과 비트 단위로 동일해진다. 이 성질 덕분에 청크를 여러 스트립(strip)으로 나눠, 0번 레인에는 실제 유입 해시를, 나머지 레인에는 각 스트립 앞 64바이트를 해싱한 값을 시드로 넣고 모든 스트립을 동시에 돌릴 수 있다. 어떤 레인이 매치를 보고했을 때 가장 이른 매치를 가려내는 부분이 구현 복잡도의 대부분을 차지했다.
스칼라보다 느렸던 직접 포팅
처음에는 SSE4.2 구현을 거의 기계적으로 옮겼다. aarch64의 uint64x2_t는 x86의 __m128i와 마찬가지로 64비트 레인 두 개라 구조가 그대로 대응됐다. 다만 NEON에는 pmovmskb 같은 마스크 추출 명령이 없어, 레인 비교 결과를 스칼라 레지스터로 꺼내려면 좁히는 시프트와 이동이 필요했다. 결과는 0.92배로 오히려 스칼라보다 느렸다. 원인은 루프 이월 지연(loop-carried latency)에 있었다. Apple 코어에서 벡터 버전의 반복당 연산은 각각 약 2사이클이라 반복당 약 4사이클이 들고, 한 반복이 2바이트(레인당 1바이트)를 처리하니 바이트당 약 2사이클이다. 반면 스칼라 버전은 시프트-레지스터 덧셈 단일 명령으로 컴파일되어 역시 바이트당 약 2사이클이다. 임계 경로 기준 작업량은 같은데, 벡터 쪽은 로드와 마스크 추출 비용까지 더 내야 하니 앞설 수가 없었다.
의존성 체인을 줄이는 싸움
돌파구는 의존성 체인 자체를 짧게 만드는 것이었다. 바이트당 업데이트를 두 단계 펼쳐 곱해 정리하면, 2연산/2바이트를 2연산/4바이트로 바꿀 수 있다. G=(g₀