Profile Guided Optimization (PGO)

Profile Guided Optimization, 이하 PGO는 가장 공격적인 컴파일 최적화 방식 중 하나다.

컴파일 언어를 쓰고 최적화 옵션을 이것저것 넣더라도, 최적화에 한계는 온다.

최적화 힌트를 통한 마이크로매니징과 흑마법을 떡칠한다면 당장은 어떻게 되더라도, 그건 별로 지속 가능하지가 않다는 단점이 있다.
이럴 때 선택할 수 있는 가장 효과적인 접근법이 이 PGO라는 것이다.

일반적인 컴파일

우리가 컴파일이라고 표현하는 것들은 대부분 정적 분석(Static program analysis)을 통해서 엄격한 규칙 기반으로, 코드를 실행하지 않고 코드를 어셈블리로 변환하는 과정이다.

이런 고전적인 컴파일은 일반적인 경우에 잘 작동하고, 성능도 그럭저럭 나오긴 한다.
하지만 해당 프로그램이 낼 수 있는 최적의 성능을 낼 수는 없다는 근본적인 한계가 있다.
컴파일타임 시점의 규칙적인 분석으로는 실제로 어떤 함수가 많이 호출되는지, 어떤 분기를 많이 타는지, 어떤 입력이 많이 들어오는지 등을 절대로 미리 알 수가 없기 때문이다.

PGO는 이런 한계점을 보완하고자 생긴 개념이라고 할 수 있겠다.

PGO의 적용 과정

PGO는 다음과 같은 과정을 거쳐서 수행된다.

1. 일단 프로파일링 수집을 활성화한 채로 컴파일해서 실행파일을 뽑는다.

2. 실행파일을 실행하고, 실제 사용사례에 맞게 실행을 유도하면서 프로파일 데이터를 뽑는다.

3. 프로파일 데이터를 가져다가 옵션을 주고 다시 컴파일을 한다.

4. 그러면 컴팩트하게 최적화된 실행파일이 나오는 것이다.

Go와 Rust(LLVM)의 사용 예시를 링크로 달아놓겠다.
https://blog.naver.com/sssang97/222888877448
https://blog.naver.com/sssang97/223176448202

PGO가 최적화를 하는 방법

PGO의 최적화 수준과 접근법은 툴체인마다 다를 수 있는데, 여기서는 LLVM을 기준으로 설명해보겠다.
아래 항목을 제외하고도 접근법은 매우 다양하다. 자질구레한 것까지 다루면 끝도 없어서 대표적인 것 몇가지만 정리해본다.

함수 인라이닝

함수 호출은 생각보다 무거운 면이 있는 동작이다.
인자 넘길때마다 레지스터를 쌓거나 메모리 스택을 쌓아야 하고, 함수 진입 시점과 탈출 시점마다 jump 인스트럭션이 필요하기 때문이다.
그나마 함수로 진입할 때는 함수의 주소가 고정주소니까 괜찮은데, 함수를 이탈할 때는 return address가 여러곳일 수 있기 때문에 분기 예측으로 인한 최적화가 잘 안되는 편이다.

그래서 함수 단위를 제거하고 매크로처럼 코드 본문에 삽입하는 것을 인라이닝이라고 한다. 함수 호출로 인한 오버헤드를 줄일 수 있으나, 그게 항상 의미가 있는건 아니라서 컴파일러들도 그때그때 상황 봐가면서 한다.
마구잡이로 넣어대면 코드 크기가 비대해져서 성능이 떨어질 수 있기 때문이다. 그냥 커져서 명령어 캐시 로드를 제대로 못할 수도 있고, branch prediction이 더 복잡해질 수도 있다.

인라인에는 2가지 방법이 존재할 수 있는데, 특정 함수가 그냥 많이 호출되는 함수라면 그 함수를 모든 호출 지점에 인라인할 수도 있고, 특정 함수가 특정 경로에서만 자주 호출된다면 거기에만 인라인을 할 수도 있다.

PGO를 적용할 경우에는 후자, 자주 호출되는 함수 호출 경로에 대해 더 공격적인 인라이닝을 수행한다.

분기 예측 (branch prediction)

branch, 그러니까 조건 분기에 대한 내용이다.
CPU는 branch 명령어를 만나면 다음에 실행될 명령어의 주소를 예측한다. 예측이 맞다면 굉장히 빠른 성능을 보일 수 있지만, 실패한다면 그 시점에 다시 코드를 캐시로 불러와야 하기 때문에 끔찍한 성능 저하가 발생할 수 있다.

PGO를 사용한다면 컴파일러는 실행 기록을 기반으로 자주 걸리는 hot branch와 덜 걸리는 cold branch를 통계적으로 판단할 수 있다.
그래서 이를 기반으로 실행 빈도가 높은 hot branch를 가까이 배치해서 캐시에 타도록 하고, 실행 빈도가 낮은 cold branch를 멀리 배치해서 분기 예측률이 높아지도록 유도하는 것이다.

코드 레이아웃 최적화

요새 고급 언어들에서는 함수나 코드의 위치가 성능과 연관이 없는 것처럼 동작하지만, 실제 어셈블리 수준에서는 그렇지 않다.
CPU라는 녀석도 모든 코드를 항상 들고 있지는 않고, 그 다음 코드가 가까이 위치해야지 캐시에서 빠르게 로드해서 실행을 할 수가 있기 때문이다.

그래서 PGO를 사용하면 실제 실행 순서에 기반해서 명령어 블록 배치 순서를 조정하고, 자주 실행되는 Hot 코드를 가까이에, 덜 실행되는 Cold 코드를 멀리에 배치한다.

간접 호출 최적화 (indirect call)

간접 호출이란 간접 분기(indirect branch)에 의해서 함수를 호출하는 것을 말한다.
간접 분기란, 메모리(RAM)의 저장값 기준으로 분기를 태우는 것이다.

C++의 가상함수를 포함해서, 객체지향에서의 메서드 다형성 동작은 전부 간접 분기로 구현된다. 실제 객체의 타입 값을 기반으로 해당 타입의 메서드를 실행시켜야 하기 때문이다.
간접 분기는 분기 예측(branch prediction)을 망가뜨리는 주범 중 하나인지라, 이런 간접 호출이 쌓이다보면 성능에 꽤 큰 악영향을 줄 수도 있다.

PGO를 적용한다면 실제 실행 기록을 기반으로 간접분기를 최소화할 수 있다. 경우에 따라서는 branch prediction을 추가해주거나, 가상함수 자체를 인라이닝하기도 한다.

루프 최적화: 루프 언롤링

루프 언롤링은 루프 내 연산 동작을 압축하고 branch 횟수를 줄이는 최적화 방법이다.
PGO를 적용하면 실행 빈도가 높은 루프를 우선적으로 언롤링을 시도한다.

https://blog.naver.com/sssang97/221800631864

Dead Code 제거

Dead Code 제거, 그러니까 사용되지 않는 코드에 대한 제거는 사실 일반 컴파일에서도 충분히 걸러질 수 있는 부분이긴 하다.

하지만 컴파일 시점에서는 알 수 없고 실제로 실행을 해봐야 dead code인지 판단할 수 있는 경우가 더러 있다.
동적 라이브러리 링킹이나, OS나 드라이버 상태에 따라서 진입 가능/불가능한 코드 지점이 정해질 수 있기 때문이다. 이런건 PGO나 JIT을 태운 경우에만 확실하게 판단해서 제거할 수 있다.

이를 통해서 바이너리 크기와 성능을 최적화할 수 있다.

PGO의 적용 사례

GCC, LLVM, MSVC, ICC 등 메이저한 컴파일러 툴체인들은 모두 PGO 기능을 기본으로 제공한다.
이런 짬이 쌓여있는 환경들은 PGO가 아주 효과적으로 동작한다. 바이너리 크기도 대부분 확연히 줄어들고, 성능도 눈에 띄게 향상된다. 2배 3배까지는 아니더라도 10~40% 정도의 속도 향상은 보통 느끼는 것 같다.

Golang은 비교적 최근에 PGO를 자체적으로 구현해서 내놓았는데, 다른건 거의 없고 인라이닝만 하는거라서 성능 향상도 미미하고 바이너리가 오히려 커지더라.

JIT 컴파일

PGO가 가장 잘 사용되는 분야는 사실 일반 컴파일러가 아니라, 일부 하이브리드 런타임 언어들이다.

PGO 컴파일이 꽤 강력하긴 하나 매번 세팅하고 프로파일 뽑고, 다시 컴파일하는 과정을 거치는 것은 번거로울 수 밖에 없다.

하이브리드 컴파일 언어인 Java와 C#는 JIT 컴파일, 그러니까 실시간 컴파일 최적화에서 일종의 PGO를 수행한다.
실시간으로 실행하면서 실행 기록을 수집하고, 그걸 기반으로 PGO 최적화를 그때그때 하는 것이다.
Java가 자랑하는 뛰어난 성능은 대부분 여기에서 나온다.

Java의 최적화 구조에 대한 참조
https://blog.naver.com/sssang97/223573816314

참조
https://llvm.org/devmtg/2020-09/slides/PGO_Instrumentation.pdf
https://chrisfeilbach.com/2025/07/05/understand-cpu-branch-instructions-better/
https://d2.naver.com/helloworld/8404108?ref=pangyoalto.com