서론

• 컴퓨터 설계자들은 오랫동안 컴퓨터 설계의 엘도라도를 찾으려고 애써왔는데, 그 꿈은 기존의 작은 컴퓨터 여러 개를 연결만 하면 강력한 성능의 컴퓨터가 되는 것이었다. 이러한 금빛 환상이 멀티프로세서(multiprocessor)의 근원이다.
  • (확실히 단일 기술은 소형화를 하고, 규모가 필요할 때는 그것들을 묶어서 사용하는 게 맞다)
• 만약 소프트웨어가 프로세서들을 효율ㅈ거으로 활용할 수 있다면 크고 비효율적인 프로세서를 작으면서 효율적인 프로세서 여러 개로 대치함으로써 단위 에너지당 성능을 개선할 수 있다. 이처럼 멀티프로세서는 확장 가능한(scalable) 성능을 제공할 뿐만 아니라 전력 효율도 개선할 수 있다.
• 멀티프로세서 소프트웨어에 확장성이 있으면 하드웨어가 일부 고장 나더라도 동작이 중지되지 않도록 설계할 수 있다. 즉 프로세서 n개 중에서 한 개가 고장 나면 남은 n-1개가 작업을 계쏙할 수 있게 하는 것이다. 이와 같이 멀티프로세서는 가용성을 개선할 수도 있다.
• 고성능이 여러 독립적인 작업들에 대한 높은 처리량을 의미하는 경우도 있다. 이를 태스크 수준 병렬성(task-level parallelism) 혹은 프로세스 수준 병렬성(process-level parallelism)이라고 한다.
  • 이때 병렬로 수행되는 작업 하나 하나는 독립적인 응용 프로그램으로 이런 방식은 흔하면서도 중요한 병렬 컴퓨터 사용 방법 중 하나이다. 이는 여러 개의 프로세서가 한 작업을 나누어서 수행하는 것과는 대조된다.
  • 이를 구별하기 위해 한 개의 프로그램이 여러 프로세서에서 동시에 수행될 때 병렬처리 프로그램(parallel processing program)이라는 용어를 사용한다.
• 항상 더 빠른 컴퓨터를 필요로 하는 과학 계산 문제들이 있었다. 이런 문제들 때문에 지난 수십 년 동안 여러 독창적인 병렬 컴퓨터들이 등장했다. 어떤 문제들은 독립적으로 동작하는 다수의 서버들로 구성된 클러스터를 사용하여 간단히 해결될 수 도 있다.
  • 클러스터(cluster)는 과학 분야 뿐 아니라 검색엔진, 웹 서버, 전자우편 서버, 데이터베이스 같이 부하가 많은 응용에도 사용될 수 있다.
• 1장에서 설명한 바와 같이 멀티프로세서가 다시 큰 주목을 받게 된 것은 명시적으로 하드웨어 병렬성을 이용하여 성능을 올리는 것이 클럭 주파수를 올리거나 CPI를 올리는 것보다 에너지 측면에서 더 유리하기 때문이다.
  • 같은 이름에서 중복을 피하기 위해 이런 프로세서를 '멀티프로세서 마이크로프로세서' 대신 '멀티코어 마이크로프로세서(multicore microprocessor'라고 부른다.
  • 멀티코어 칩에서는 프로세서를 코어(core)라고 부른다. 코어의 수는 Moore의 법칙에 따라 배가될 것으로 예측되고 있다. 멀티코어는 대부분 실제 주소공간을 공유하는 공유 메모리 프로세서(SMP; shared memory processor)이다.
• 오늘날 성능을 중시하는 프로그래머는 병렬 프로그래머가 될 수 밖에 없다. 왜냐하면 이제 순차 프로그램은 느린 프로그램을 의미하기 때문이다.
• 산업체가 직면한 큰 문제는 칩 안에 집적되는 코어의 수가 늘어남에 따라 성능과 에너지를 효율적으로 활용하는 벼렬 프로그램을 정확하고 쉽게 작성하도록 하는 하드웨어와 소프트웨어를 발명하는 것이다.
• 마이크로프로세서 설계에서 변화가 급격하게 이루어지다보니 신중하게 대처할 여유가 없었고, 이 때문에 용어의 사용과 그 의미에서 심각한 혼란이 일어나고 있다.
  • 그림 6.1에서 직렬적(serial), 병렬적(parallel), 순차적(squential), 병행적(concurrent)이라는 용어들을 구별하려고 시도해 보았다.
  • 이 그림에서 열은 소프트웨어를 나타내는데, 소프트웨어는 근본적으로 순차적이든지, 병행적이다. 행은 하드웨어를 나타내는데 하드웨어는 직렬적이거나 병렬적이다.
  • 예컨대 컴파일러를 만드는 프로그래머는 컴파일러를 파싱, 코드 생성, 최적화 등이 단계적으로 진행되는 순차적인 프로그램으로 생각한다.
  • 반면 운영체제를 만드는 프로그래머는 운영체제를 컴퓨터에서 실행 중인 독립적 작업들의 입출력 이벤트를 처리하는 프로세스들로 구성된 병행적인 프로그램으로 생각한다.

• 그림 6.1에서 하드웨어와 소프트웨어를 다른 축으로 표시한 이유는 병행 소프트웨어가 직렬 하드웨어에서 수행될 수도 있고, 병렬 하드웨어에서 수행될 수도 있음을 보여주기 위해서이다. 순차 소프트웨어에 대해서도 마찬가지다.
• 자연스럽게 순차적으로 작성된 프로그램을 어떻게 병렬 하드웨어에서 빠르게 실행할 수 있으냐가 병렬 혁명에서 해결해야 할 유일한 문제라고 생각할 수도 있겠다. 그러나 프로세서 수가 증가함에 따라 병행 소프트웨어의 성능이 계속해서 좋아지게 하는 것도 쉽지 않으며, 이 또한 해결해야 할 문제 중 하나이다.
  • 앞으로는 순차적이거나 병행적이거나 병렬 하드웨어에서 수행되는 소프트웨어는 병렬처리 프로그램 혹은 병렬 소프트웨어라고 부르도록 한다.

병렬처리 프로그램 개발의 어려움

• 병렬처리의 어려움은 하드웨어에 있지 않다. 문제는 멀티프로세서에서 더 빨리 수행하도록 재작성된 응용 프로그램들의 수가 너무 적다는 것이다. 멀티프로세서를 사용하여 한 개의 태스크를 더 빨리 수행하는 소프트웨어를 작성하는 것은 어려운 일이다. 프로세서의 개수가 증가하면 문제는 더 심각해 진다.
• 왜 순차적인 프로그램을 개발하는 것보다 병렬처리 프로그램을 개발하는 것이 더 힘든가? 첫째 이유는 기왕 병렬 프로그램을 사용할 바에는 더 높은 성능과 에너지 효율을 얻을 수 있어야 하기 때문이다.
  • 그렇지 못하다면 단일 프로세서에서 프로그래밍 하기 쉬운 순차 프로그램을 사용하는 편이 낫다. 실제로 프로그래머의 개입이 전혀 없이도 명령어 수준의 병렬성(ILP: instruction-level parallelism)을 활용하는 수퍼스칼라나 비순차 실행 같은 단일 프로세서 설계 기술이 이미 개발되어 사용되고 있다. (4장 참조)
  • 이런 혁신적인 기법 때문에 멀티프로세서를 위해 프로그램을 다시 작성하는 것에 대한 요구가 크지 않았다. 왜냐하면 프로그래머가 아무 일도 하지 않아도 순차적인 프로그램이 새로운 컴퓨터에서 더 빠르게 돌아갈 수 있었기 때문이다.
• 빠르게 수행되는 병렬처리 프로그램을 작성하기 힘든 이유가 무엇인가? 특히 프로세서 개수가 증가할수록 어려워지는 이유는 무엇일까?
  • 1장에서 일을 8배 빠르게 할 목적으로 8명의 기자가 동시에 하나의 기사를 쓰는 비유를 사용한 바 있다. 이 방법이 성공하려면 한 작업이 동일한 크기의 8개 부분으로 나누어져야 한다. 크기가 동일 하지 않다면 큰 부분을 담당하는 사람이 일을 끝낼 때까지 나머지 사람들이 기다려야 할 것이기 때문이다.
  • 성능을 저하시킬 수 있는 또 다른 위험은 기자들이 자기가 맡은 기사 작성보다 다른 사람들과 의견을 교환하는데 더 많은 시간을 보낼 수 있다는 것이다.
  • 이 비유와 같이 병렬 프로그래밍에서 우리가 부닥치는 문제에는 작업의 스케쥴링, 작업을 병렬 조각으로 나누는 일, 부하를 균등하게 하는 일, 동기화 시간을 줄이는 일, 그리고 서로 통신하는 오버헤드를 줄이는 일 등이 있다.
  • 기사 하나를 만들기 위해서 더 많은 기자가 참여할수록 마찬가지로 병렬 프로그래밍을 위해 더 많은 프로세서를 사용할 수록 이런 문제는 더욱 어려워진다.
• 1장에서 우리는 또 하나의 장애 요인인 Amdahl의 법칙에 대해 살펴보았다. 이 법칙은 프로그램이 여러 프로세서를 효율적으로 사용하기 위해서는 프로그램의 작은 부분까지도 모두 병렬화되어야 한다는 사실을 환기시킨다.

예제) 속도 개선의 어려움