Talk on “Parallel Programming Patterns” by Ralph Johnson
via Sutter’s Mill: Ralph Johnson on Parallel Programming Patterns
UIUC의 교수이자, 허브 서터가 언급한 것 처럼 GoF[1] 의 한 사람인 Ralph Johnson의 세미나. UIUC의 온라인 세미나로 제공되고 있다.
약 한 시간 짜리 톡인데, 초반에 약간 지루한 부분이 있지만 참고 넘어가니 꽤 들을만 했음. 물론 아쉬움도 한가득.
이 이하는 적당히 요약한 것 + 개인적인 논평 약간.
About Patterns
패턴은 은탄환[2] 이 아니며, 경험 그 자체를 대체하지도 못한다. 다만 경험을 얻는 속도를 늘려주고, 어느정도 빨리 배우게 해주는 수단이다.
Patterns for Parallel Programming
Talk의 제목이기도 한데 -_-a 알고보니 책 제목이었다. 이 책에 대한 R. Johnson의 평가는,
- 기술 독립적이고,
- 도메인 독립적이고 — 즉, 다양한 도메인에 적용 가능한 아이디어 위주
- Pattern language를 제공한다. (프로그래밍 언어얘기가 아님)
제공하는 패턴들은,
- Finding concurrency
- Algorithm Structure
- Supporting Architecture
- Implemenation mechanism — OS 만드는 사람한테나 패턴이지, 그렇지 않은 사람에겐 하부 구조일 뿐이다라고 설명
인데, 여기서 알고리즘 구조 부분을 다시,
- Organize by task — intel TBB 에서 말하는 linear task / recursive task 등의 개념
- Organize by data-decomposition — linear 한 데이터 교환 / recursive 한 작업 분할
- Organize by flow-of-data — 데이터 흐름의 파이프라이닝 등.
정도로 쪼개서 책의 내용을 설명한다. 개략 저기 위의 개념들을 설명하고 짧은 예를 드는 수준임.
그리고 이에 대해 이런 비판을 가한다.
- 더 많은 기술 의존적인 패턴이 필요하다
- 도메인 의존적인 패턴이 필요하다 — 슈퍼컴퓨팅에서의 일곱 난장이[3] , 버클리에서 말하는 13개의 모티프 등 자주 쓰이는 특정 도메인에 적응된 계산 패턴이 있다. + 파티클 시스템의 orthogonal하게 병렬화할 수 있는 최적화들을 설명
- 더 작은 수준에 적용 가능한 패턴이 소개 되어야 한다.
책에서 다루는 고 수준 패턴들은 많은 예가 필요하며 배우기 힘들다고 얘기하고 있다. (물론 저수준 패턴들은 배우기 쉽고도 역시 중요하다는 얘기도 한다)
특히 도메인 의존적인 것에서 나타나는 패턴들을 강조하는 몇 가지 예 — Particle System, MPI의 exchange 예 — 를 든다.[4]
결론적으론,
- 패턴을 발견하고[5]
- 사용하고
- 다른 사람들이 쓸 때 무슨 일이 일어나는지 보고
- 고쳐라
의 시도를 해보라고 말하면서 마무리.
디자인 패턴의 근원 자체가 저런 식으로 발견된 것이긴 한데, 지금 병렬 프로그래밍에 필요한게 과연 “패턴” 뿐인지는 솔직히 의문이다.
패턴 의전에 근본적인 구성요소(building blocks; primitives) 자체가 부족한게 아니냐는 생각도 들고 -_-a
컴퓨터 공학 수업에서 배우는 것도 뭘 하면 안되느냐에 가깝지, 병렬 프로그래밍의 빌딩 블럭을 구성하거나 하진 않는다는 느낌이라 -_-;;
뭐 여튼 재밌긴 하지만 아쉬운 톡.
Updated( 2008/9/26 17:36) shurain 의 제보로 잘못 들은 부분 수정: (저수준 패턴 관련)
- Design Patterns의 저자 4명을 Gang of Four 라고 부른다 [↩]
- 모든걸 해결해주는 만능장치 같은 것을 비유하는 용어. 컴퓨터 공학 쪽에서 좀 자주 인용되는 느낌 [↩]
- dense & spare matrices, structured & unstructured meshes, FFT, Particl System, Monte Carlo methods 의 7개. [↩]
- 근데 뭔가 난 이건 설득력이 부족한 것 같은데. 완성되지 않은 패턴 내지는 프레임웍을 쓸 때 나타나는 문제랄까. 물론 프레임웍 자체를 만들어야하거나, 새 것이 필요할 때는 몸에 지니고 있어야하는 능력이긴 하겠지만 -_-;; [↩]
- 만드는게 아니다! 라고 말함 [↩]
Berkeley의 7난장이는 13난장이로 확장된 지 꽤 되었습니다. (EECS-2006-183 참조)
산오리
26 Sep 08 at 4:04 pm
(Phil Colella의)슈퍼컴퓨팅의 일곱 난장이 / 버클리의 13모티프(13 motifs or dwarfs) 로 쓴 것입니다. + PPT를 원문을 가능한 그대로 옮긴 것이기도 합니다.
rein
26 Sep 08 at 4:15 pm
빌딩 블럭에 대한 고민이 더 늘어나야 하는 것은 분명한 것 같아요.
슈레인
26 Sep 08 at 5:50 pm
슈레인 / I need
ammoSTM!rein
26 Sep 08 at 6:12 pm