슈퍼스칼라·비순차·big.LITTLE

순서 속에 숨은 병렬성

프로그램은 명령을 한 줄로 늘어놓지만, 명령들이 정말로 그 순서를 지켜야 하는 것은 아니다. a = b + c와 d = e × f는 서로 아무 관계가 없으니 동시에 해도 된다. 반면 g = a + d는 앞의 두 결과를 기다려야 한다. 명령 사이의 이런 "앞 결과를 써야 함" 관계를 화살표로 그리면 데이터 흐름 그래프(Dataflow graph)가 된다. 그래프에서 가장 긴 사슬, 즉 임계 경로가 계산 자원이 무한해도 넘을 수 없는 시간의 하한이다. 명령 수를 임계 경로 길이로 나눈 값이 그 프로그램이 원리적으로 가진 명령어 수준 병렬성(ILP, Instruction-Level Parallelism)이다.

실제 프로그램을 이렇게 분석하면, 분기 예측이 완벽하고 계산기가 무한하다는 이상적 조건에서 IPC가 수십~수백에 이르는 경우도 많다. 문제는 그 병렬성이 멀리 흩어져 있다는 것이다. 지금 실행할 수 있는 명령이 수십 줄 뒤에 있을 수 있다. 그것을 찾아내려면 많은 명령을 한꺼번에 들여다볼 수 있어야 한다.

슈퍼스칼라: 한 사이클에 여러 명령

3장의 파이프라인은 매 사이클 명령 하나를 들여보내므로 CPI가 1보다 작아질 수 없었다. 파이프라인을 여러 줄 깔아 한 사이클에 명령을 2개, 4개, 8개씩 인출·해독·실행하면 이 벽을 넘을 수 있다. 이것이 슈퍼스칼라(Superscalar)다. 한 사이클에 들여보내는 명령 수를 발행 폭(Issue width)이라 한다. 그런데 명령을 프로그램 순서대로만 들여보내면(순차 슈퍼스칼라) 앞 명령 하나가 막히는 순간 뒤의 모든 명령이 같이 멈춘다. 폭을 늘리며 두 방식을 비교해 보자.

순차 슈퍼스칼라도 쓸모가 있다. 스마트폰의 효율 코어가 바로 2~3폭 순차 코어다. 단순해서 작고, 전력이 적다. 하지만 폭을 그 이상 늘리는 것은 순차 방식에선 의미가 없다. 그래서 고성능 코어는 명령을 일단 넓은 대기실에 받아 두고, 준비된 것부터 먼저 실행하는 비순차 실행(Out-of-order execution)을 쓴다. 그 대기실을 크게 만들려면 먼저 풀어야 할 문제가 하나 있다.

레지스터 이름 바꾸기: 거짓 의존 지우기

명령 사이 의존에는 세 종류가 있다. 앞 명령이 쓴 값을 뒤가 읽는 RAW(Read After Write, 참 의존), 앞 명령이 읽을 레지스터를 뒤가 덮어쓰는 WAR(Write After Read), 둘이 같은 레지스터에 쓰는 WAW(Write After Write). RAW만 진짜 데이터의 흐름이다. WAR과 WAW는 레지스터 이름이 32개뿐이라 같은 이름을 돌려쓰다 생긴 이름 충돌이다. 순서를 바꾸면 이 충돌 때문에 값이 엉킨다.

해법은 이름을 넉넉하게 바꿔 주는 것이다. 코어 안에는 프로그램이 보는 32개의 구조 레지스터보다 훨씬 많은(수백 개) 물리 레지스터가 있다. 명령이 레지스터에 쓸 때마다 빈 물리 레지스터를 새로 하나 내주고, "구조 레지스터 r1은 지금 물리 레지스터 p9에 있다"는 대응표, RAT(Register Alias Table)를 고친다. 뒤의 명령은 이 표를 보고 올바른 물리 레지스터를 읽는다. 이것이 레지스터 이름 바꾸기(Register renaming)다. 한 명령씩 넘기며 표가 어떻게 바뀌는지 보자.

이름 바꾸기 뒤에 남은 것은 RAW뿐이므로, 명령은 피연산자가 준비되는 순서대로 아무 때나 실행해도 된다. 물리 레지스터가 언제 다시 자유 목록으로 돌아가는지도 중요하다. r1에 새 값을 쓴 명령이 확정(다음 절)되면 그 전의 r1 값을 담던 물리 레지스터는 더 이상 아무도 읽지 않으므로 반납한다. 물리 레지스터가 바닥나면 이름 바꾸기가 멈추고, 그 뒤로 명령이 들어오지 못한다. 큰 코어가 물리 레지스터를 수백 개씩 두는 이유다.

비순차 실행 코어: ROB와 순서대로 확정하기

비순차 코어의 일은 세 박자로 흐른다. ① 순서대로 들여보내기: 인출·해독·이름 바꾸기를 거친 명령을 프로그램 순서대로 재정렬 버퍼(ROB, Reorder Buffer)의 꼬리에 넣는다. ② 순서 없이 실행하기: 대기 중인 명령 가운데 피연산자가 준비되고 계산 장치가 비어 있는 것을 골라 실행한다. 이 대기실을 스케줄러(예약 스테이션)라 하며, 1960년대 IBM 360/91의 Tomasulo 알고리즘이 원형이다. ③ 순서대로 확정하기: ROB의 머리, 즉 가장 오래된 명령이 끝났으면 그 결과를 정식으로 확정(Commit, Retire)하고 ROB에서 뺀다.

왜 마지막을 순서대로 할까? 중간에 예외(잘못된 메모리 접근, 0으로 나누기)나 분기 예측 실패가 일어나면, 그 명령 앞까지는 모두 끝났고 뒤는 하나도 일어나지 않은 깔끔한 상태로 되돌려야 하기 때문이다(정밀 예외(Precise exception)). ROB에 아직 확정되지 않은 결과는 언제든 버릴 수 있다. 결국 비순차 코어는 "속으로는 마음대로, 겉으로는 순서대로"다.

시뮬레이터에서 ROB 머리에 빨간 칸(미스)이 걸리면 어떤 일이 일어나는지 지켜보자. 뒤의 명령들은 계속 들어와 실행되고 초록으로 바뀌지만 확정되지 못한다. ROB가 꽉 차는 순간 들여보내기가 멈추고 코어 전체가 서 버린다. 이것이 ROB가 커야 하는 이유이자, 커도 끝이 있는 이유다. DRAM 접근 한 번(100 ns 남짓)은 4 GHz 코어에서 400사이클이고, 8폭 코어라면 그동안 명령 3,200개를 처리할 수 있었다. 어떤 ROB도 그만큼 크지는 않다.

메모리 수준 병렬성: 기다림을 겹치기

큰 ROB가 주는 가장 큰 선물은 계산의 병렬성이 아니라 기다림의 병렬성이다. 캐시 미스 여러 개를 동시에 메모리로 보내 놓으면, 하나씩 기다릴 때보다 전체 대기 시간이 미스 수만큼 나누어진다. 이를 메모리 수준 병렬성(MLP, Memory-Level Parallelism)이라 한다. 아래는 서로 독립인 적재가 일정 간격으로 나오고 모두 DRAM까지 가는 극단적인 경우다. ROB 크기를 바꾸며 미스들이 얼마나 겹치는지 보자.

큰 코어의 값: Pollack의 법칙

비순차 실행의 장부들, 즉 ROB, 스케줄러, 이름 바꾸기 표, 물리 레지스터, 넓은 해독기와 큰 분기 예측기는 면적과 전력을 많이 먹는다. 게다가 이 장부들은 크기를 키울수록 비용이 빠르게 는다. 스케줄러는 매 사이클 모든 대기 명령을 동시에 비교해야 하고, 레지스터 파일은 읽기·쓰기 포트 수의 제곱으로 커진다. 인텔의 Fred Pollack은 경험적으로 코어의 성능은 면적의 제곱근에 비례한다고 정리했다. 면적을 4배로 하면 성능은 2배쯤이다. 이것이 Pollack의 법칙(Pollack's rule)이다.

그렇다면 같은 면적에 큰 코어 하나를 둘까, 작은 코어 여럿을 둘까? 답은 일이 얼마나 병렬화되는가에 달려 있다. Hill과 Marty(2008)는 이 질문을 암달의 법칙과 Pollack의 법칙으로 풀었다. 칩 면적이 작은 코어 \(n\)개분이고, 큰 코어 하나가 작은 코어 \(r\)개분 면적을 쓴다고 하자.

수치는 제조사 발표(Arm Tech Day, Hot Chips 등)와 공개 분석의 대략값이다. 비공개 설계(Apple)는 마이크로벤치마크로 추정한 값이라 오차가 클 수 있다.

big.LITTLE: 큰 코어와 작은 코어의 분업

스마트폰의 일은 극단적으로 들쭉날쭉하다. 대부분의 시간은 알림 확인, 음악 재생, 백그라운드 동기화 같은 가벼운 일이고, 가끔 앱을 열거나 화면을 휙 넘길 때 짧고 무거운 일이 몰린다. 큰 코어는 무거운 일을 빨리 끝내지만 가벼운 일에는 낭비가 크다. 작은 코어는 느리지만 같은 일을 훨씬 적은 에너지로 한다. 둘을 함께 두고 일에 따라 골라 쓰는 구조를 Arm은 big.LITTLE이라 불렀고, 지금은 거의 모든 스마트폰 SoC와 노트북 칩(Apple의 P·E 코어, 인텔의 P·E 코어)이 같은 생각을 쓴다. 기준 칩 SB-1에는 큰 코어 3개와 작은 코어 4개가 있다.

코어마다 전압과 클럭을 조절하는 DVFS(12장)를 생각하면 그림이 더 분명해진다. 각 코어에는 "이만큼의 성능을 내려면 이만큼의 전력이 든다"는 곡선이 있다. 요구 성능을 그래프 위에서 끌어 보며 어느 코어가 더 효율적인지 보자.

곡선에서 세 가지가 보인다. 첫째, 같은 코어라도 클럭을 올릴수록 일 하나당 에너지가 커진다(전압이 함께 오르므로 \(CV^2\)가 는다). 둘째, 낮은 성능에서는 작은 코어가 훨씬 효율적이다. 큰 코어는 클럭을 낮춰도 넓은 장부를 굴리는 데 드는 에너지와 누설 전력이 있다. 셋째, 작은 코어가 낼 수 없는 성능은 큰 코어만 낼 수 있다. 그래서 운영체제 스케줄러의 일은 "각 일에 필요한 성능을 내는 가장 효율적인 코어와 클럭"을 고르는 것이 된다. 리눅스(안드로이드)의 에너지 인식 스케줄링(EAS, Energy-Aware Scheduling)은 칩 제조사가 제공한 이런 에너지 모델을 보고 일을 배치한다.