12 속도의 기계장치 — 표준의 탄생

12.1 파이프라인 — 조립 라인 위의 명령들

세탁소를 떠올리면 된다. 세탁 30분, 건조 30분, 다림질 30분이라 할 때, 한 벌을 끝내고 다음 벌을 시작하면 세 벌에 270분이 걸린다. 그러나 첫 벌이 건조기로 넘어가는 순간 둘째 벌을 세탁기에 넣으면 — 장비 세 대가 서로 다른 벌을 동시에 처리하며, 흐름이 차오른 뒤에는 30분마다 한 벌씩 완성되어 나온다.

CPU가 명령을 처리하는 것도 똑같이 단계로 나뉜다 — 가져오고(fetch), 해독하고(decode), 계산하고(execute), 결과를 쓴다(write). 이 단계들을 조립 라인으로 만든 것이 파이프라인(pipeline)이다. 명령 하나하나가 빨라지는 것이 아니다 — 단위 시간에 완성되는 명령의 수가 는다. 현대 CPU의 파이프라인은 열 단계가 넘고, 여기에 라인을 여러 개 두어 박자당 여러 명령을 완성하는 데까지 나아갔다. 4장의 “한 박자에 한 걸음”은 이렇게 무너진다 — 겉보기 순서는 지키되, 속은 겹쳐 돌아간다.

같은 시대의 요령 하나를 여기 적어 둔다. 루프 한 바퀴마다 드는 관리 비용(횟수 세기, 갈림길 판단)을 아끼려고 한 바퀴에 여러 개씩 일을 처리하는 기법이 있다 — 루프 언롤링(loop unrolling)이라 한다. 1983년, Tom Duff라는 프로그래머는 이 기법을 C의 두 문법을 기괴하게 겹쳐 쓰는 방법으로 극한까지 밀어붙였고, 그 코드는 Duff’s device라는 이름의 전설이 됐다. 코드 자체는 아직 보여 줄 수 없다 — 이 책이 그 문법들을 아직 소개하지 않았기 때문이다. 재회를 예약해 둔다(32장). 지금은 한 문장이면 된다: 그 시절에는 사람이 이런 곡예로 기계의 박자를 짜냈다는 것, 그리고 오늘날 그 곡예는 컴파일러의 일이 됐다는 것(13장).

12.2 분기 예측 — 갈림길을 미리 짐작하다

파이프라인에는 아픈 곳이 있다. 갈림길이다. “결과가 0이면 저쪽으로 건너뛰어라” 같은 명령(분기)을 만나면, 어느 쪽 길의 명령을 라인에 실어야 할지 결과가 나오기 전에는 모른다. 라인을 세우고 기다리면 겹침의 이득이 사라진다.

그래서 CPU는 짐작한다. 단골 손님의 주문을 미리 만들어 두는 카페처럼, 지금까지의 이력으로 “이 갈림길은 대개 이쪽”을 학습해 그쪽 명령을 미리 라인에 싣는다 — 분기 예측(branch prediction)이다. 맞으면 공짜고, 틀리면 미리 만든 주문을 전부 버리고 라인을 비운 뒤 다시 시작한다. 이 벌금이 파이프라인 깊이만큼 크기 때문에, 현대 CPU는 예측기에 진지한 회로를 투자하고 적중률은 일상 코드에서 90%를 훌쩍 넘는다.

12.3 클록의 한계, 그리고 멀티코어

이 모든 겹침에도 불구하고, 2000년대 중반에 벽이 왔다. 클록을 더 올리면 전력과 발열이 감당할 수 없이 치솟는 물리적 한계였다. 수십 년 이어지던 “내년에는 더 빠른 클록”이 멈춘 것이다.

산업의 응답은 방향 전환이었다 — 한 일꾼을 더 빠르게 만드는 대신, 일꾼의 수를 늘린다. CPU 하나에 독립적으로 명령을 실행하는 엔진 — 코어(core) — 를 두 개, 네 개, 수십 개씩 넣기 시작했다. 오늘의 스마트폰조차 코어 여덟 개쯤은 예사다. 공짜 점심은 끝났다 — 프로그램이 저절로 빨라지던 시대가 끝나고, 여러 일꾼에게 일을 나누어 주는 문제가 프로그래머의 몫이 된 것이다(이 책의 범위 밖이지만, 지형은 알아 둔다).

그리고 일꾼이 여럿이 되자, 11장의 캐시가 뜻밖의 사고 현장이 된다.

False sharing(거짓 공유)이라 불리는 사고다. 두 코어가 서로 다른 변수를 만지는데 — 공유한 것이 하나도 없는데 — 하필 두 변수가 같은 캐시 라인 상자에 나란히 놓여 있으면, 하드웨어의 눈에는 같은 상자를 두 코어가 다투는 것으로 보인다. 한쪽이 쓸 때마다 다른 쪽 책상의 상자가 무효가 되고, 상자가 두 책상 사이를 핑퐁처럼 오가며, 두 코어 모두 수십 배 느려진다. 코드만 보면 아무것도 공유하지 않으므로 원인이 보이지 않는다 — 기억이 상자 단위로 움직인다는 11장의 사실을 알아야만 진단이 되는, 현대적인 사고의 대표 사례다.

12.4 같은 시대, C는 계약서를 썼다 — 표준 이전의 C와 C89

기계가 이렇게 요동치던 시기, C의 세계에도 다른 종류의 요동이 있었다.

C에는 오랫동안 공식 표준이 없었다. 1978년에 나온 K&R의 책 “The C Programming Language”가 사실상의 표준 노릇을 했다 — 언어의 규격서가 아니라, 잘 쓰인 한 권의 책이 법전을 대신한 것이다. Unix와 함께 C가 대학과 업계로 번지자 회사마다 자기 컴파일러를 만들었고, 책이 못박지 않은 구석마다 방언이 자랐다. 그 시절의 C는 지금 눈에는 헐겁다 — 함수를 선언할 때 인자의 타입을 적지 않았고(원형이 없었다), 타입을 안 적은 이름은 슬그머니 int로 통했다. 어느 컴파일러에서 되던 코드가 다른 컴파일러에서 안 되는 일이 예사였고, 이식은 번번이 모험이었다.

견디다 못한 산업이 1983년 표준화 위원회(ANSI X3J11)를 꾸렸고, 6년의 격론 끝에 1989년 C89 — 최초의 공식 C 표준 — 가 나왔다. 함수 원형(인자 타입까지 적는 선언, 24장)을 들여 컴파일러가 호출의 실수를 잡을 수 있게 했고, 헐거운 구석들을 조였으며, 무엇보다 “프로그래머는 무엇을 약속받고, 구현은 어디까지 자유로운가”를 처음으로 문서로 못박았다. 8장의 IEEE 754(1985)와 같은 몇 해의 일이다 — 하드웨어의 수도, 언어의 문법도, 벤더마다 제멋대로이던 것을 계약서로 다스리기 시작한 “계약의 시대”였다.

12.5 계약서에 없는 자리 — 회색지대

계약서가 생기면 곧바로 따라오는 물음이 있다. 계약서에 적히지 않은 일은 어떻게 되는가?

표준이 하는 말은 세 갈래다 — 약속한다(어디서나 이렇게 된다), 구현이 정한다(구현마다 다르되 문서로 밝힌다), 그리고 아무 말도 하지 않는다. 셋의 정식 이름과 정확한 구별은 52장에서 다룬다.

그리고 실무에는 이름조차 없는 자리가 하나 더 있다 — 표준의 문장으로는 보장되지 않는데 모든 주요 구현에서 실제로 통하고, 널리 쓰여 사실상의 관행이 된 것이다. 이 책은 이 자리를, 그리고 앞의 세 갈래를 아울러 회색지대라 부른다.

왜 이런 자리가 생기는가. 표준은 최소공통분모를 적는다 — 아주 특이한 기계 에서도 성립할 만큼만 약속한다. 실제 구현은 대개 그보다 넉넉히 준다. 그리고 커다란 코드베이스들이 그 넉넉함 위에 집을 지으면, 컴파일러 쪽에서도 그것을 쉽게 깨뜨리지 못하게 된다 — 깨는 순간 세상의 절반이 안 도니까.

이 책에서 만나게 될 회색지대의 예를 미리 몇 개 적어 둔다. 지금은 이름만 알아 두면 된다.

12.6 C 밖의 표준이 대신 보장할 때

회색지대 중에는 성격이 조금 다른 것들이 있다. C 표준은 아무 말도 하지 않는데, 다른 표준이 그 자리를 대신 약속하는 경우다.

여기서 「C 표준이 안 정했으니 아무렇게나 되는 것」이라고 읽으면 안 된다. 그 자리에 다른 계약서가 놓여 있고, 그 계약서도 나름의 신중함으로 쓰였다.

/* 이 파일은 POSIX 를 전제한다: 함수 포인터 ↔ void * 변환(dlsym). */
static_assert(sizeof(void (*)(void)) == sizeof(void *),
              "함수 포인터와 데이터 포인터의 크기가 다른 플랫폼이다");

이 계약이라는 관념이 왜 갈수록 중요해지는가 — 기계는 이 장에서 본 것처럼 갈수록 겹치고 짐작하고 나뉘는데, 프로그래머가 그 소용돌이를 일일이 알 수는 없다. 소용돌이와 프로그래머 사이에 또 하나의 층이 서 있기 때문이다. 소스 코드를 받아 기계의 말로 옮기면서, 뜻만 지킨다면 무엇이든 뜯어고칠 권리를 가진 층 — 컴파일러다. 다음 장의 주인공이다.