병렬 혹은 멸망

병렬 혹은 멸망(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 관련된 내용은 어딨나요(…). 코어 간 속도차가 달라질 수도 있다 하나로 땡?