잡상: 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 에서 일부가 잡힐 뿐이다. 물론 메모리 접근에 제약이 있는 점 때문인게 제일 클 것 같지만 ((SPE는 메인 메모리에 접근할 수 없으며 instruction + data를 담는 core-local한 메모리가 존재 한다)) , 프로그래머가 이를 쉽게 사용할 수 있는 추상화 계층이 없으면 없느니만 못한 게 될 것이다. ((하다못해 보조 프로세서들을 전부 포기하고 복잡한 코어 2개인게 나을 수 있다. 실제로 Xbox360 같은 경우엔 복잡한 프로세서 3개가 한 팩키지에 들어가 있는 형태이며, 각각이 하이퍼스레딩을 수행해서 6개의 하드웨어 스레드가 동작하게 설계되었다. 그래서 상대적으로 단순한 프로그래밍 모델을 가지며, 이 때문인지 일반적인 응용에서는 성능 차이가 거의 없다 설계상으론 PS3의 Cell CPU가 나은면이 매우 많지만, 프로그래밍 모델의 복잡함이 이를 전부 상쇄해서인지 실제 업계 내의 얘기를 보면 그거나 그거나 성능은 비슷하단 소리가 많다)) .

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

Jinuk Kim
Jinuk Kim

SW Engineer / gamer / bookworm / atheist / feminist

Articles: 935

8 Comments

  1. 예전에 과제로 CELL 프로그래밍을 좀 해봤는데 어렵더라구요. ; 로컬 메모리와 메인 메모리 사이의 통신에도 따로 동기화를 해줘야 하던데 상당히 불편하고… 로컬 메모리가 너무 작은 점도 있고요. 게다가 벡터 연산에서 당연히 있을 것 같은 명령이 의외로 없는 경우도 있어서 활용도가 더 낮아지는 것 같습니다.

    그래도 STFT 알고리즘 기준으로 상당한 스피드업이 나와준걸 보면 프레임워크만 제대로 마련되었도 전망이 있었을텐데… 소프트웨어적으로건 하드웨어적으로건 메모리 부분만 투명해지면 충분히 쓸 수 있지 않을까 싶네요.

    • 엄청나게 속도가 중요한 프로그램의 경우엔 특정 형식으로만 쓰고 / 최적화가 중요하니까 CELL 아키텍쳐 같은걸 쓰는 것도 이해가 가긴하는데, lolized님 말씀처럼 “상당히 유연한 프레임웍”이 나와주지 않고는 널리 쓰기긴 너무 힘들 것 같긴 해요;

  2. CELL은 캐시 코히런시가 없어서 코딩하기 어려운데 그래서 예를 들어 이재진 교수님 랩에서 나온 COMIC 같은 것이 있지요. 근데 안 써봐서 얼마나 더 편해지는지는 모르겠네요. 암튼 CELL 프로그래밍은 하드웨어 설계자들이 너무 배를 째서 참 힘들죠.

    • 이재진 교수님 랩에서 나온 COMIC은 찾아봐야겠군요. CELL 설계자들이 배를 좀 쨌다는 얘기는 정말 공감합니다(?!).

  3. 내가 알기론 OpenCL은 다양한 컴퓨팅 유닛(CPU, GPU, GPGPU, PPE, SPE 등등)을 아우르는 다양한 heterogeneous 환경하에서의 계산을 portable 하게 지원하기 위한 framework인데, 다른 platform specific한 확장 API들 보단 좀 더 넒은 개념이 아닐까?

    • * 현재로써 OpenCL을 지원하는 OS(?)는 MacOSX Snow Leopard뿐이고
      * Graphic Card vendor들이 지금까지 한 방향을 보면 분명히 양쪽을 다 지원하는 쪽으로 갈 가능성이 크고(nvidia와 인텔은 일단은 OpenCL에 베팅하는 듯 하지만)
      …OS 점유율이라는 현실을 더하면 사실 비슷한 수준의 대결이 아닌가 싶어서.

        • 윈도우즈 용도 있는 거군요. 정보 감사합니다.

          밑에 있는 팀 스위니 프리젠테이션은 본거네요. 결국 현재 추세로는 CPU는 GPU로(many-core), GPU는 CPU로(generic computation) 가고있으니 래러비 같은 쪽으로 가긴하겠죠. (물론 실제로 의미있고 업계에서 쓸만해야하겠지만)

Leave a Reply