---
title: "분기 오예측 비용: 정확도가 두 배 좋아져도 실행 시간은 같을 수 있다"
author: "브레이브브라우저쓰자"
published_at: "2026-10-14T13:58:01.811Z"
updated_at: "2026-10-06T00:34:29.216Z"
tags: ["분기 오예측 비용"]
canonical_url: "https://ariser.io/@writer_a9817d5a8de0/%EB%B6%84%EA%B8%B0-%EC%98%A4%EC%98%88%EC%B8%A1-%EB%B9%84%EC%9A%A9-%EC%A0%95%ED%99%95%EB%8F%84%EA%B0%80-%EB%91%90-%EB%B0%B0-%EC%A2%8B%EC%95%84%EC%A0%B8%EB%8F%84-%EC%8B%A4%ED%96%89-%EC%8B%9C%EA%B0%84%EC%9D%80-%EA%B0%99%EC%9D%84-%EC%88%98-%EC%9E%88%EB%8B%A4"
ai_assisted: true
---

# 분기 오예측 비용: 정확도가 두 배 좋아져도 실행 시간은 같을 수 있다

이 글은 AI가 활용됐습니다.

[원문](https://ariser.io/@writer_a9817d5a8de0/%EB%B6%84%EA%B8%B0-%EC%98%A4%EC%98%88%EC%B8%A1-%EB%B9%84%EC%9A%A9-%EC%A0%95%ED%99%95%EB%8F%84%EA%B0%80-%EB%91%90-%EB%B0%B0-%EC%A2%8B%EC%95%84%EC%A0%B8%EB%8F%84-%EC%8B%A4%ED%96%89-%EC%8B%9C%EA%B0%84%EC%9D%80-%EA%B0%99%EC%9D%84-%EC%88%98-%EC%9E%88%EB%8B%A4)

분기 예측 정확도를 95%에서 97.5%로 높였는데 프로그램은 빨라지지 않았다. 예측기가 맞히는 비율만으로는 이상한 결과지만, 틀린 한 번을 복구하는 시간이 길어졌다면 충분히 가능하다. 분기 오예측 비용은 얼마나 자주 틀렸는지와, 그때 얼마나 많은 실행 기회를 잃었는지를 함께 계산해야 보인다.

정확도는 분기 실행 횟수를 분모로 삼는다. 프로그램의 시간은 모든 명령을 끝내는 데 든 사이클로 정해진다. 두 지표 사이에는 분기가 얼마나 자주 나타나는지와 복구의 실제 길이가 있다.

## 같은 오예측률도 코드에 따라 다른 부담이다

가상의 프로그램에서 완료한 명령 1,000개 중 분기가 200개이고, 그중 5%인 10개를 잘못 예측했다고 하자. 오예측 10회/1,000명령이므로 MPKI는 10이다. MPKI는 여기서 완료 명령 1,000개당 오예측 횟수라는 정의로 사용한다.

같은 분기 오예측률 5%라도 분기가 50개뿐인 다른 프로그램에서는 평균적으로 2.5회/1,000명령, MPKI 2.5다. 충분히 긴 실행의 평균을 말하므로 2.5가 한 구간에서 실제 사건 두 개 반이 발생했다는 뜻은 아니다. 분기 자체의 정확도가 같아도 전체 명령 흐름의 오예측 빈도는 다르다.

측정에서는 분모를 확인해야 한다. 실행 중 잘못된 경로에서 가져온 명령 수를 완료한 명령 수처럼 사용하면 MPKI나 CPI의 의미가 바뀐다. 실제 성능 카운터가 어느 분기와 어떤 경로의 사건을 세는지도 해당 구현의 정의를 읽어야 한다. 이름이 같다는 이유로 서로 다른 계측을 같은 수치로 취급할 수 없다.

## 절반만 틀려도 두 배 오래 잃으면 같다

겹침을 무시하는 단순 모델에서 기본 CPI를 C₀, MPKI를 M, 오예측 한 번의 추가 비용을 P사이클이라고 하자. 추가 CPI는 M×P/1,000이고 전체 CPI는 C₀+M×P/1,000이다. 다른 stall 비용은 기본값에 고정되어 있으며 각 오예측의 추가 비용이 서로 독립적으로 더해진다고 가정한다.

C₀=0.50, M=10, P=12라면 추가 CPI는 0.12, 전체는 0.62다. IPC는 그 역수로 약 1.61이다. 예측기를 바꾸어 M이 5가 되었지만 P가 24로 늘었다면 추가 CPI는 여전히 0.12다. 앞의 분기 비율을 유지하면 오예측률은 5%에서 2.5%로 절반이지만 이 모델의 처리 속도는 같다.

이 숫자는 특정 CPU의 성능을 예측한 것이 아니다. 정확도 이득이 복구 비용과 함께 평가되어야 함을 보이는 가상 계산이다. 새로운 예측기의 조회 지연, 경로 수정 방식이나 다른 파이프라인 변화가 있으면 기본 CPI와 클록 주파수도 달라질 수 있다. 고정하지 않은 항목까지 같은 것으로 계산해서는 안 된다.

BOOM의 실행 단계 문서는 오예측 때 올바른 PC로 redirect하고 프런트엔드와 fetch buffer를 비우며, 그 분기에 의존한 실행 중 명령들을 취소하는 과정을 설명한다. PC redirect를 빨리 보내되 kill 신호는 타이밍 경로 때문에 한 사이클 늦추는 선택도 명시한다. 복구는 한 개의 방향 비트를 뒤집는 것보다 많은 상태를 처리한다. [BOOM Execute Pipeline, Branch Unit & Branch Speculation](https://docs.boom-core.org/en/latest/sections/execution-stages.html#branch-unit-branch-speculation)

## 한 번의 비용은 늘 같은 숫자가 아니다

분기 결과를 알려면 입력 피연산자가 준비되어야 한다. 의존하는 연산이나 load가 늦으면 분기가 확정되는 시점도 늦어질 수 있다. 이미 틀린 경로에 얼마나 많은 명령이 진행했는지, 올바른 경로의 명령 캐시가 준비되어 있는지에 따라서도 복구 후 공급은 달라진다.

BOOM의 fetch 문서는 해당 명령 캐시가 miss를 처리하는 동안 추가 요청을 받지 않는 제약을 설명한다. 오예측을 발견하여 새 주소로 가고 싶어도 캐시 상태가 실제 요청을 지연시킬 수 있는 예다. 이 특정 구현 조건을 모든 CPU에 일반화할 수는 없지만, 파이프라인 깊이만으로 복구 비용을 확정할 수 없다는 점은 드러난다. [BOOM Instruction Fetch, Rocket Core I-Cache](https://docs.boom-core.org/en/latest/sections/instruction-fetch-stage.html#the-rocket-core-i-cache)

분포를 보면 평균의 의미도 달라진다. 오예측의 90%가 8사이클, 10%가 48사이클을 잃는 가상 경우의 평균은 12사이클이다. 대부분은 8사이클이지만 드문 긴 사건이 평균을 끌어올린다. 모든 오예측이 12사이클짜리라고 생각하면 어떤 입력과 대기 상황이 비싼 사건을 만들었는지 찾기 어렵다.

실제 out-of-order 실행에서는 오예측 복구와 다른 대기가 겹칠 수 있어 단순히 사건별 사이클을 모두 더하면 중복이 생길 수 있다. MPKI와 평균 비용의 식은 비교를 시작하는 모델이며, 전체 실행 시간은 실제 경로와 겹침을 포함한 측정이나 검증된 모델에서 확인해야 한다.

분기 오예측 비용을 줄이는 방법은 적게 틀리는 것과 일찍 알아채는 것, 새 경로의 명령을 빨리 공급하는 것을 함께 포함한다. 정확도가 좋아졌는데 속도가 그대로라면 오예측의 분모, 발견 시점과 복구 비용의 분포부터 살펴보면 된다. 맞힌 비율을 실행 시간으로 연결하는 사이의 조건들이 그 차이를 설명한다.