[Cpp] fast_float 성능 힌트: 분기 예측 실패를 데이터 지식으로 줄이기

“-731.51” 같은 문자열을 double로 바꾸는 일은 CSV, JSON, 로그 처리에서 가장 흔한 핫패스 중 하나다. 이 변환을 빠르게 하는 C++ 라이브러리 fast_float에 Daniel Lemire가 성능 힌트(performance hints) 라는 기능을 제안했다. 파서가 추측해야 하는 부분을 호출자가 템플릿 인자로 미리 알려 주는 방식이다. 이 글은 2026년 11월 10일 Lemire의 블로그에 실린 내용을 바탕으로 원리, 세 가지 힌트, 측정 결과, 그리고 “언제 켜면 오히려 느려지는가"를 정리한다. 글 시점에 이 기능은 병합되지 않은 풀 리퀘스트였고, 아래 수치는 모두 저자가 보고한 자체 벤치마크이며 필자가 재측정한 것이 아니다.

왜 숫자 파싱은 분기가 많은가

숫자 파서는 문자열을 읽는 동안 계속 결정을 내린다. 부호가 있는가, 자릿수가 몇 개인가, 소수점이 어디인가, 반올림 모드가 기본값인가. 각각이 분기(branch)다. 최신 CPU는 분기 결과를 예측해 파이프라인을 미리 채우는데, 예측이 틀리면 그 분기 이후에 해 둔 일을 버려야 하고 대략 15–20 사이클을 잃는다. 데이터가 규칙적이면 예측기는 거의 항상 맞히므로 분기는 사실상 공짜다. 문제는 입력이 불규칙할 때다. 가격 변동처럼 부호가 무작위로 섞인 데이터에서는 부호 분기를 예측기가 맞힐 수 없다. Lemire의 측정에서 힌트 없는 Intel 프로세서는 가격 변동 숫자의 약 60%에서 분기를 잘못 예측했다.

여기서 설계상 비대칭이 생긴다. 라이브러리는 입력이 어떤 분포인지 모르지만, 호출자는 안다. “이 파일의 숫자는 거의 다 8자 이하다”, “프로그램은 반올림 모드를 바꾸지 않는다” 같은 지식이다. 힌트는 이 지식을 API로 전달하는 통로다.

flowchart LR
    caller["호출자: 데이터 모양을 안다"] -->|"템플릿 인자로 힌트 전달"| parser["fast_float::from_chars"]
    parser --> noHint{"힌트 있음?"}
    noHint -->|"없음"| branches["분기로 추측 (예측 실패 시 15–20 사이클 손실)"]
    noHint -->|"있음"| branchless["해당 분기를 건너뛰고 명령어를 더 실행"]

세 가지 힌트

힌트는 fast_float::performance_hints 열거형 값이며 from_chars<...>의 템플릿 인자로 넘기고 |로 조합한다. 힌트가 없으면 기존 동작 그대로다. 원문에 따르면 from_chars, from_chars_advanced, integer_times_pow10에서 쓸 수 있다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
#include <fast_float/fast_float.h>
#include <string_view>

// 부호가 무작위로 섞인 가격 변동 데이터를 파싱한다.
// 힌트는 분기 대신 명령어를 더 쓰는 거래이므로, 아래 조합이 실제로 빠른지는 벤치마크로 확인해야 한다.
using fast_float::performance_hints;

bool parse_change(std::string_view input, double& value) {
  auto answer = fast_float::from_chars<
      performance_hints::unpredictable_sign |
      performance_hints::assume_round_to_nearest>(
      input.data(), input.data() + input.size(), value);
  return answer.ec == std::errc();
}

이 코드는 풀 리퀘스트가 병합되기 전에는 컴파일되지 않을 수 있는 제안 API 기준이다. 힌트별 의미는 다음과 같다.

힌트	호출자가 하는 약속	파서가 건너뛰는 것
`unpredictable_sign`	부호가 무작위 순서로 나타난다	부호 분기 (분기 없이 처리)
`short_numbers`	각 범위에 숫자 하나, 대부분 8자 이하(`42.5`, `-3.75`)이며 모양은 제각각	자릿수·소수점 위치 분기. 8문자를 비트 연산으로 한꺼번에 읽는다
`assume_round_to_nearest`	프로그램이 반올림 모드를 바꾸지 않는다	반올림 모드 확인

세 힌트 중 결과가 달라질 수 있는 것은 assume_round_to_nearest 하나뿐이다. 약속을 어기고 반올림 모드를 바꾸면 일부 결과가 틀린다. 나머지 둘은 속도에만 영향을 준다.

측정 결과: 데이터 모양이 승패를 가른다

저자는 데이터 종류별로 100,000개 숫자를 파싱했다. 가격 변동(소수 둘째 자리, 부호 무작위), 계좌 잔액(더 긴 숫자, 부호 무작위), 센서 값(양수, 모양 다양), 정형 가격(양수, 항상 같은 모양)이다. 단위는 초당 백만 개(높을수록 빠름), 하드웨어는 Intel Xeon Gold 6338(Ice Lake, GCC 15)과 Apple M4 Max(Apple clang 17)다.

데이터	Intel 힌트 없음	Intel 최선	Apple 힌트 없음	Apple 최선
가격 변동	73	105 (`unpredictable_sign`+`assume_round_to_nearest`)	153	345 (세 힌트 모두)
계좌 잔액	61	82 (`unpredictable_sign`+`assume_round_to_nearest`)	132	199 (같은 조합)
센서 값	67	92 (`short_numbers`)	123	250 (`short_numbers`)
정형 가격	152	152 (힌트 없음이 최선)	251	355 (`short_numbers`)

표에서 읽을 수 있는 것은 세 가지다. 첫째, 부호가 무작위인 데이터는 두 플랫폼 모두 큰 이득을 본다. 둘째, 같은 힌트도 데이터에 따라 반대로 작용한다. Intel에서 unpredictable_sign 단독은 센서 값을 67에서 57로 떨어뜨렸고, short_numbers는 계좌 잔액을 82에서 70으로, 정형 가격을 152에서 104로 떨어뜨렸다. 셋째, 같은 힌트가 하드웨어에 따라 부호가 갈린다. 정형 가격에서 short_numbers는 Intel에서 느려졌지만 Apple M4 Max에서는 251에서 355로 빨라졌다. 원문은 Intel에서 Clang 21로도 같은 데이터에서 같은 힌트가 이겼다고 덧붙인다.

언제 켜고 언제 끄나

힌트는 “싸고 잘 맞는 분기"를 “더 많은 명령어"로 바꾸는 거래다. 프로세서가 이미 잘 맞히는 데이터라면 명령어만 늘어 손해다. 판단 기준은 다음과 같다.

입력 분포를 알고 있고, 실제로 분기 예측 실패가 병목임을 프로파일러로 확인했다면 해당 힌트만 후보에 올린다.
후보 조합은 반드시 대상 하드웨어에서 힌트 유무를 비교 측정한다. Intel에서 진 힌트가 Apple에서 이길 수 있다.
데이터가 규칙적(정형 가격처럼 항상 같은 모양)이면 기본값을 유지하는 편이 안전하다.
assume_round_to_nearest는 속도 이전에 정확성 약속이다. 라이브러리나 다른 스레드가 반올림 모드를 바꿀 가능성이 있으면 쓰지 않는다.

더 일반적인 교훈은 API 설계에 있다. 범용 라이브러리는 입력 구조를 모르기 때문에 보수적으로 동작한다. 호출자가 아는 구조를 컴파일 시점 인자로 받으면, 기본 경로를 건드리지 않으면서 특수 상황에서만 최적 경로를 고를 수 있다. 다만 이 제안은 글 시점에 미병합 풀 리퀘스트이므로 최종 이름과 동작은 달라질 수 있다.