잡상: many-core 시대의 프로그래밍

이미 한참 된 글이지만, 얼마 전에 DDJ에 H. Sutter가 Design for Manycore Systems란 글을 썼다.

개괄에 해당하는 내용을 아주 간단히 요약하자면,

• 요즈음의 시스템에서 가장 큰 어려움은 CPU와 메모리의 속도 차이고
• 이를 극복하기 위해서 CPU 벤더들이 접근한 방식은 더 복잡한 코어를 만들어내거나
• 더 많은 코어를 제공해서
• CPU <-> 메모리 사이의 속도차이를 “보이지 않게" 만드는 것

그리고 나선 SUN 나이아가라 CPU의 변화등을 예로 들면서, 현재까지 (클락 속도를 올리기 위해) 취해왔던 “더 복잡한 코어"를 만들어서 메모리 접근 시간을 “프로그래머에게 보이지 않게" 하는 일은 이미 한계에 다달았고 — 이미 프로그래머에게 transparent하지 않은 방법: OOE 같은 것이 나타났고, 이는 병렬 프로그래밍에서 꽤나 골치 아픈 일이다 — 이에 따라 병렬 프로그램을 쉽게 짜고 + 메모리 접근 속도를 할 적당한 방법은

• 더 간단한 코어를 만들고 (OOE 같은 복잡한 기능이 들어가기 이전 수준으로)
• 이런 간단한 코어는 더 적은 수의 칩 면적(=더 적은 수의 트랜지스터들)을 차지해서 여러 개를 집어넣으면 되고
• 이를 써서 메모리 병목에도 이 코어의 파이프라인을 충분히 활용할 수준의 하드웨어 스레드를 가능케하고 (=하이퍼 스레딩)
• 이런 프로그래밍 모델을 써서 편하게 멀티스레드 프로그래밍을 해보자

이라는 것. 그리고 이건 부수적으로 “빠른 FP 연산"과 “적은 파워 소모"라는 장점도 갖는다고 덧붙인다.

물론 이 경우는 당연히 “현재 응용 프로그램들 중 일부는 전혀 혜택을 보지 못하고, 일부는 심지어 느려진다"라는 문제가 있기에 중간 단계로는 현재의 복잡한 코어와 단순한 코어 여러 개가 들어가있는 CPU 팩키지가 될 거라고 말한다.

근데 저 아이디어에는 문제가 좀 있다. 실제로 저런 CPU가 현존하고 있다. PS3에 들어가있는 Cell 프로세서의 경우, 서터가 말한 것과 상당히 유사한 형태로 만들어져 있다. 연산처리량이 많고 복잡한 1 개의 Power 프로세서와, 이를 보조하는 8개의 보조 프로세서(SPE)가 있는데, 이 작은 보조 프로세서는 메모리 접근에 제약이 있고, 복잡한 명령어가 없다. 이런 복잡한 구조 때문인지 실제로 이 SPE를 사용하는 알고리즘은 구글링 해봐야 Power.org 에서 일부가 잡힐 뿐이다. 물론 메모리 접근에 제약이 있는 점 때문인게 제일 클 것 같지만¹, 프로그래머가 이를 쉽게 사용할 수 있는 추상화 계층이 없으면 없느니만 못한 게 될 것이다.²

그래서인지 이번에 나오는 MacOSX의 새 버젼(MacOSX 10.6; Snow Leopard)에는 이런 단순한 프로세서 여러 개가 들어있는 형태인 GPU를 활용할 방안으로 OpenCL이란 언어 확장 기능을 내놓았다. MS 쪽에서도 DX 11에 GPGPU를 위한 확장을 내놓으려 하고 있다. 이런 추상화가 서터가 말하는 중간 형태의 heterogenous processor를 잘 감싸준다면 성공적으로 자리잡을 것이고, 그렇지 않다면 아마도 상당 시간이 흐른 후에야 (=간단한 코어로도 현재 프로그램들이 성능이 나올 수준까지 접근한 후에야 혹은 현재 프로그램들이 concurrent 하게 바뀐 후에야) 이런 CPU 들이 충분히 팔리지 않을까 싶다³.