병렬 혹은 멸망(Parallel or Bust)라는 제목의 SD West 키노트. ((from Dr.Dobb’s Journal – SD West: Parallel or Bust ))
intel의 Reinders의 키노트를 간략히 요약하자면 (DDJ의 요약(?)도 간단하지만), 현재 우리는 기가 헤르츠(GHz)의 시대를 지나 멀티코어 시대로 진입했으며, 시장에 출시된 상태로는 현재 4-core CPU를 쓰고 있으며 곧 8-core CPU가 출시된다. ((요즘은 잘 알려진 물리적인 한계 — clock상승하면 면적당 발열이 증가하는 문제 등 — 로 CPU의 동작속도를 늘리는 것은 사실상 어려워져서.))
이런 병렬화된 CPU를 써먹기 위해선 뭐가 준비되어야하는가?
- Scaling
- Debugging
- Future Proofing
이 세 가지가 준비되어야한다. 이 중 가장 미묘한 부분이 첫번째 항목. 4코어에서 잘 최적화 되었다는게 8코어, 16코어 가도 그렇다는 보장은 없으며, 암달의 법칙에 따라 감소하는 이득을 생각할 때 — 특히나 병렬화 되는 부분이 작다면 — 특정 코어 수 이상에선 속도 향상이 없을 수 있다.
그래서 추상화된 무언가 — 물론 솔루션이 1개만으로 될리가 없지만 — 가 필요하며, (적어도 C/C++ 프로그래머는) OpenMP나 intel TBB 같은 라이브러리로 이런 추상화를 얻을 수 있을 것이다 — Concurrent Programming이 스레드 관리 프로그램이 되지 말게하라!. 그리고 이런 추상화를 써야되는 이유 중에 하나는 미래의 멀티 코어 CPU의 모든 코어가 같은 속도일리는 없다 라는 것. 그래서 추상화를 써야 이런 아키텍쳐하위 부분에 영향을 받지 않게하라는 것. ((이 부분은 특히나 중요한 대목인듯. HW를 결정할 수 있는 서버에서도 이런 생각하기 괴로운 부분이 있으면 라이브러리에 좀 의존해야할 것 같다?))
그리고 디버깅에 대한 “gem of a tip” : 동시성(concurrency)를 제거할 수 있게 하라. 즉, 멀티스레딩을 끄고 디버깅할 수 있어야 할 것. “켄트 벡의 구현 패턴”에서 동시성 관련된 토픽이 없다며 한 말과 일맥상통하는 말.
ps. 근데 future proofing 관련된 내용은 어딨나요(…). 코어 간 속도차가 달라질 수도 있다 하나로 땡?
“이런 추상화를 써야되는 이유 중에 하나는 미래의 멀티 코어 CPU의 모든 코어가 같은 속도일리는 없다 라는 것.”
-> 덜덜덜 생각해본 적도 없었다. 그러고보니 지금 그런 식으로 쓰이고 있는 것들; DSP라던가 쉐이더라던가 PS2라던가 NDS라던가; 은 프로그래밍 인터페이스가 아예 다른데 앞으로 어떻게 일반화될지 모르겠다.
지금처럼 인간이 그걸 따라잡고 쓸지(난 이걸 약간은 밀고있음), 그냥 라이브러리를 믿고 갈지 정확히 어디로 갈지도 모르겠다;
인터페이스가 아예 다르게는 아마 못갈거라고 생각하고, 적어도 비슷한거에서 시작해서 상당히 다른걸로(C->C++변화처럼) 가지 않을까 ㅋ