명령어 사이클 — 인출, 해독, 실행

한 줄 요약

CPU 는 메모리에서 명령어를 하나 가져와(인출) 무슨 뜻인지 풀고(해독) 실제로 수행하는(실행) 일을 끝없이 반복하는 기계다.

왜 이게 필요했나

프로그램은 결국 메모리에 늘어놓은 숫자 덩어리다. 이 숫자를 누가 어떤 순서로 읽어서 무엇을 할지 정해야 한다. 초기 설계자들이 내린 결정이 지금까지 이어지는데, 핵심은 두 가지다. 첫째, 명령어와 데이터를 같은 메모리에 둔다(폰 노이만 구조). 둘째, 다음에 실행할 명령어의 주소를 레지스터 하나에 담아 둔다(프로그램 카운터).

이 두 결정 덕분에 CPU 는 아주 단순한 규칙 하나만 지키면 된다. "프로그램 카운터가 가리키는 곳에서 명령어를 가져와 실행하고, 카운터를 다음으로 옮겨라." 반복문도 함수 호출도 조건 분기도 전부 이 카운터 값을 바꾸는 일에 불과하다.

어떻게 동작하나

한 사이클은 대략 이렇게 흐른다.

1. 인출(Fetch) — 프로그램 카운터가 가리키는 주소에서 명령어를 읽어 명령어 레지스터에 넣는다.
2. 해독(Decode) — 비트 패턴을 보고 어떤 연산인지, 피연산자가 어디 있는지 판단한다.
3. 실행(Execute) — 산술 논리 장치가 계산하거나, 메모리에 접근하거나, 카운터를 다른 곳으로 옮긴다.

문제는 이걸 순서대로만 하면 대부분의 회로가 놀고 있다는 것이다. 해독기가 일하는 동안 인출기는 쉰다. 그래서 나온 것이 파이프라인이다. 세탁기와 건조기를 나눠 쓰듯, 1번 명령어가 해독될 때 2번 명령어를 미리 인출한다. 단계가 5개면 이론상 처리량이 5배가 된다.

공짜는 아니다. 파이프라인은 세 가지 위험(hazard)을 만든다.

| 위험 | 상황 | 대응 |
| --- | --- | --- |
| 구조적 위험 | 두 단계가 같은 회로를 동시에 원함 | 자원을 분리하거나 한쪽을 지연 |
| 데이터 위험 | 앞 명령어 결과를 뒤 명령어가 필요로 함 | 포워딩, 안 되면 파이프라인 정지 |
| 제어 위험 | 분기 결과를 아직 모름 | 분기 예측, 틀리면 파이프라인 비우기 |

세 번째가 특히 비싸다. 분기 예측이 빗나가면 이미 진행 중이던 명령어들을 전부 버려야 한다. 현대 CPU 의 파이프라인은 15단계를 넘기도 하므로, 한 번 빗나갈 때마다 수십 사이클이 날아간다. 정렬된 배열을 도는 반복문이 정렬되지 않은 배열보다 몇 배 빠른 유명한 현상이 여기서 나온다. 조건이 규칙적이면 예측기가 맞히기 때문이다.

현장에서 만나는 모습

성능 측정을 할 때 자주 보게 되는 지표가 IPC(사이클당 명령어 수)다. 클록이 같아도 IPC 가 2배면 2배 빠르다. 반대로 IPC 가 0.3 처럼 낮게 나온다면 CPU 가 계산을 못 해서가 아니라 무언가를 기다리고 있다는 신호다. 대개는 메모리다.

그래서 "CPU 사용률 100퍼센트"를 곧바로 "연산 유닛이 100퍼센트 계산 중"으로
읽으면 안 된다. 코어는 비유휴 상태여도 캐시 미스처럼 메모리 계층을 기다리며
실행이 정지할 수 있다. 다만 블로킹 I/O로 잠든 태스크의 시간은 보통 그
프로세스의 CPU 사용 시간으로 세지 않으므로, 메모리 지연과 I/O 대기를 구분해야 한다.

이어지는 퀴즈에서 확인할 것

파이프라인이 왜 처리량은 늘리면서 명령어 하나의 지연은 줄이지 못하는지, 분기 예측 실패가 왜 비싼지를 스스로 설명할 수 있는지 점검한다.