하드웨어를 구입하기 전에 시스템의 디자인을 고려해보는 것이 좋다. 베오울프 시스템의 디자인을 하기 위한 기본적인 2가지 하드웨어 문제점로는: 당신이 사용할 노드나 컴퓨터의 종류; 컴퓨터 노드들을 연결하기위한 방법. 하드웨어를 결정하는데 있어서 영향을 미치는 소프트웨어 문제점이 통신 라이브러리나 API 이다. 소프트웨어에 대한 자세한 사항은 이 문서 후반부에서 다루기로 하겠다. 선택의 폭이 그렇게 넓지는 않은 반면에, 베오울프 시스템을 구성할때 몇 개의 중요한 디자인 결정이 있다. 병렬 계산의 과학(또는 예술)은 많은 다른 해석이 있을 수 있기때문에, 개요는 다음에 제공하겠다.(?) 배경이 되는 요소를 읽고 싶지 않으면, 이 절을 뛰어 넘어도 좋지만, 마지막 하드웨어 결정을 하기 전에 "적합성"이라는 절을 읽는 것을 권하는 바이다.
이 절은 병렬 계산 개념에 대한 배경지식을 제공할 것이다. 병렬 계산 과학과 기술을 완벽히 다루지는 않을 것이다. 베오울프 디자이너와 사용자에게 중요한 문제점에 대한 간락한 기술을 할 것이다. 당신의 베오울프를 디자인하고 구성함에 있어서, 당신의 결정과정에 있어서 다음에 기술될 많은 문제점이 중요 하게 되게 될 것이다. 베오울프 구성요소의 특성으로 인해서 베오울프 슈퍼컴퓨터는 많은 인자들이 사용자의 제어하에 있기 때문에 조심스럽게 고려하는 것을 요구한다. 일반적으로, 병렬 계산과 관련된 문제점들을 이해하기 어려운 것만은 아니다. 사실, 문제점을 이해하기만 하면, 당신의 기대는 더욱 현실적이게 되고 성공은 더욱 현실과 가까워지게 될 것이다. 가장 중요한 인자인 프로세서 속도는 "순차 세계"와는 달라서, "병렬 세계"에서 프로세서 속도는 전체 시스템 성능과 효율를 결정하는 몇가지 인자중에 하나이다.
병렬 계산은 많은 형태를 가지고 있다. 사용자 관점에서 각각의 방법론의 장점과 단점를 고려해보는 것이 중요하다. 다음 절은 병렬 계산의 방법상의 몇가지 관점을 제공하고, 머신이 일련의 과정중에 어느 곳의 베오울프 머신이 실패하였는지를 가르치려고 한다.
이 질문의 대답은 중요하다. 8개의 CPU를 가지고 워드프로세서를 실행한다고 하면 "over-kill"처럼 들리고, 또한 그렇다. 웹 서버, 데이터베이스, 랜더링 프로그램, 또는 프로젝트 일정표에 대해서는 어떠한가? 여분의 CPU가 있다면 도움이 될 것이다. 복잡한 시뮬레이션, 유체역학 코드, 또는 데이타 마이닝 풀그림은 어떠한가? 이런 상황에서는 여분의 CPU는 찐짜루 도움이 된다. 사실, 다중 CPU은 더욱더 많은 문제들을 풀기위해 사용되지곤 한다: 보통 다음 질문 으로: "왜 두 개 또는 네 개의 CPU가 필요한가, 나는 986 터보-하이퍼 칩이 나오기를 기다리려고 한다." 이러한 이유로는:
아주 큰 가계 앞에 8개의 현금 계산대로 함께 있다고 하자. 각각의 계산대는 하나의 CPU이고 각 고객은 컴퓨터 프로그램이라 가정하자. 컴퓨터 프로그램의 크기(일의 양)은 각 고객의 요구의 크기이다. 다음 analogy들은 병렬 계산 계념을 설명할때 사용되곤 한다.
하나의 현금 계산대는 열려이고(사용중) 한번에 하나의 고객을 처리한다.
예: MS DOS
하나의 현금 계산대는 열려 있지만, 현재 한번에 각 요구의 부분만을 처리 한고 다음 사람의 요구의 일부를 처리한다. 모두가 줄을 같이 지나가는 것 처럼 보일테지만, 아무도 줄에 없다면, 더 빨리 지나가게 될 것이다.
예: UNIX, NT using a single CPU
현재 가게에 몇개의 현급 계산대가 열려있다. 각 요구는 따로따로 현금 계산대가 처리하고 줄은 더 빨리 이동하게 된다. 이를 SMP (Symetric Multi- processing)라 한다. 여분의 현금 계산대다 열려 있을 지라도, 한개의 현금 계산대를 사용하는 것 보다 더 빨리 지나가지는 못한다.
예: UNIX and NT with multiple CPUs
요구 중에 "break-up"이라는 아이템이 있다면, 한번에 여러 현금 계산대를 사용하여 줄을 더 빠르게 이동할 수 있다. 먼저, 여러개의 현금 계산대를 사용할려면 "당신의 요구를 조각냄"시간을 들여야 하기 때문에 많은 양의 물건을 가지고 있다고 하자. 이론적으로는 전보다 "n"배 정도 더 빠르게 줄을 통과할 수 있다(여기서 "n"은 현금 계산대 개수). 출납원이 총 합계를 구 할때, 다른 "지역" 현급 계산대를 보거나 말을 하여 재빠르게 정보를 교환 한다. 그들이 정보를 찾기 위해 다른 현금 계산대를 기웃거릴 지라도, 그들은 더 빨리 일을 처리하기를 원한다.(?) 그러나 얼마나 많은 현급 계산대가 가계에 있어야 하고 어느 장소에 위치해야 효과적인가하는 제한에 부딪치게 된다. Amdals 법칙에서 풀그림의 속도향상은 프로그램의 가장 늦은 일련의 부분으로 제한해야 된다는 것이다. 예: 같은 마더보드에서 여분의 CPU를 가진 UNIX 나 NT에서 다중 쓰레드화된 프로그래들 수행.
성능 향상에 있어서, 가계 뒤에 8개의 계산대를 추가하였다. 새로운 현급 계산대는 정면 현급 계산대와는 떨어져 있기 때문에, 출납원은 이들의 총 합계을 상점 정면으로 보내기 위해서는 전화를 사용하여야 한다. 이런 거리는 출납원 사이의 통신에 있어서 추가적인 오버헤드(시간)를 들게 한지만, 통신을 적게한다면, 이것은 문제도 아니다. 모든 계산대를 필요로 할 만큼 진짜루 큰 요구가 있다면, 같은 시간에 모든 현금 계산대를 사용하여 속도를 향상시키기 전에 추가적인 오버헤드가 발생할 수 있음을 고려해야 한다. 몇몇의 경우에 모든 상점을 통틀어 한개의 현금 계산대(또는 현금 계산대 섬)를 가지고 있다고 볼수 있다(각각의 현금 계산대(또는 섬)은 전화를 통해서 통신해야 한다). 현금 계산대에 작업하는 모든 출납원은 전화를 통해서 각자 얘기를 할 수 있다면, 그들이 어디에 있든지 상관이 없다.
예: One or several copies of UNIX or NT with extra CPUs on the same or different motherboard communicating through messages.위의 시나리오가 정확하지 않을 지라도 병렬 시스템의 제한점을 잘 표현 하고 있다. 한개의 CPU(또는 현급 계산대) 통신도 다른 문제점이다.
병렬 계산의 보편적 방법과 구조은 다음에 나타나 있다. 완전하게 설명하지 않을 지라도, 베오울프 디자인에 관련된 기본적인 문제점을 이해하는데 충분하다.
다음 두 방법을 사용하는 기본적인 병렬 컴퓨터:
프로그램에서 병행성을 표현하는 기본적인 표현 두 가지 방법:
역사적으로, 메시지 전송 기술은 초기 지역 메모리 병렬 컴퓨터 디지인에서 가져왔다. 쓰레드는 같은 장소에서 데이터를 사용하는 반면에 메시지는 데이터 복사를 가져다 쓴다. 복사되어 질수 있는 메시지들에서 대기시간와 속도은 메시지 전송 모델에 따라 제한 인자가 있다. 메시지는 아주 간단하다. : 몇몇 데이터와 목적 프로세서. 공통 메시지 전송 API들은 PVM또는 MPI이다. 메시지 전송은 쓰레드와 메시지가지고 효과적으로 구현된다. 둘다 SMP 머신과 머신들의 클러스터 사이에서도 잘 작동한다. SMP 머신에서 메시지를 사용함 으로서 얻어지는 이점은 쓰레드 반대로 앞으로 클러스터들을 사용할 결심을 했다면 머신들의 추가나 풀그림 확장을 쉽게 할 수 있다.
운영 체제 쓰레드는 공유 메모리 SMP (Symmetrical Multiprocessing)은 프로그램 병행 부분들 사이에서 더 빠른 공유 메모리 통신과 동기화 을 가능하게 디자인 하기 위하여 개발되졌다. 쓰레드는 공유 메모리를 통하여 통신을 하기 때문에 SMP 시스템들에서 잘 작동한다. 이러한 이유로 사용자는 글로발 데이터에서 지역 데이터를 분리해야 한다. 그렇지 않으면, 프로그램은 잘 작동하지 않는다. 메시지에 비교하면, 프로세스들(쓰레드들) 상에 데이터를 공유하기 때문에 많은 양의 복사가 생략된다. 그렇지만, cache coherence 이라는 오버헤드가 덧붙이게 되었다. 쓰레드는 SMP 경계 저편으로 연장되는 NUMA 기술을 요한다. 이 기술은 사치스럽고 전에 리눅스에 의해 지원되지 안았었다. 메시지 위에서 쓰레드를 구현해 오고 있지만 ( syntron.com/ptools/ptools_pg.htm), 쓰레드가 메시지를 이용하여 구현하였을 때 종종 비효율적이게 된다. 다음은 성능에 관한 상태를 보여주고 있다:
SMP 머신 머신들의 클러스터 확장성
성능 성능
----------- ------------------- -----------
메시지 좋음 매우 좋음 매우 좋음
쓰레드 매우 좋음 나쁨* 나쁨*
* 사치스런 NUMA 기술을 요구.
다중 CPU에서 병렬로 풀그림을 실행하기 위해서는 병행 부분으로 확실히 쪼개야 한다. 표준 단일 CPU 풀그림은 다중 프로세서에서 단일 CPU 풀그림 보다 더 빠르지는 않을 것이다. 프로그램을 쪼개져야할 몇가지 툴들과 컴파일하지만, 병렬 코드은 "plug and play" 작동을 하지 않는다. 풀그림에 의존적으로 병렬 코드는 쉽고, 극도록 어렵거나, 알고리즘 의존에 따라 불가능한 경우도 있을 수 있다. 소프트웨어 문제점의 설명이 필요한 적합성 개념을 짚고가자.
병렬 계산에 대한 대부분의 질문들은 비슷한 답변을 가진다: "모든 것은 풀그림에 달렸있다." 논쟁점으로 들어가기 전에, 만들어질 필요가 있는가에 대한 매우 중요한 구별이 하나 있다 - 병행과 병렬사이의 차이. 이런 논의를 한 목적은 다음에 오는 두 가지 개념을 정의하기 위해서 이다: 프로그램의 병행 부분은 독립적으로 계산이 되는 것이다. 프로그램의 병렬 부분들은 그들의 병행 부분으로 같은 시간에 분리된 처리 단위에서 실행된다. 이런 구별은 매우 중요하다. 왜냐하면, 병행성은 프로그램의 속성이고 효율적인 PARALLELISH은 머신의 속성이기 때문이다. 이상적으로, 병렬 실행은 더 빠른 성능으로 끝마쳐야 한다. 병렬 성능에서 재한 요인은 통신 속도와 계산 노드들 사이의 대기시간이다. (또한, 대기시간은 cache coherency로 인해 쓰레드화된 SMP 풀그림에도 있다.) 많은 일반 병렬 평가 테스트은 높은 병렬, 통신, 그리고 대기시간이지, 병목현상에 있지 않다. 이런 형태의 문제를 "obviously parallel"이라 한다. 다른 풀그림들은 병렬에서 프로그램의 병행 부분이 그렇게 간단하고 실행할 수 있는 것이 아니기에 사실 프로그램이 더 느리게 실행하는 원인이 되기도 한다. 그렇기 때문에 프로그램의 다른 병행 부분에 얻어진 임의 성능향상을 떨어뜨리게 된다. 짧은 기간에서 통신 시간 비용을 계산 시간으로 보충해야 한다. 그렇지 않으면, 병행 부분의 병렬 실행은 비효율적이다. 프로그래머의 임무는 프로그램의 병행 부분들을 병렬로 실행해야 하는 것과 하지 말아야 할 것을 결정하는 것이다. 이 대답은 풀그림의 효율로 결정할 수 있다. 다음 그래프는 프로그램의 상황을 간략히 보여주고 있다.
| *
| *
| *
% of | *
appli- | *
cations | *
| *
| *
| *
| *
| *
| ****
| ****
| ********************
+-----------------------------------
communication time/processing time
완벽한 병렬 컴퓨터에서 통신/처리 비율이 같이지게 될 것이고, 어떤 것이든지 병렬로 병행을 구현되어 진다. 공유 메모리를 가지고 있는 실제 병렬 컴퓨터에서는 이 그래프에서 보여주는 효과에 따라오게 된다. 베오울프 디자인 할 때, 병렬 효율은 특정 병렬 컴퓨터에 대한 통신 시간과 처리 시간의 비율에 의존적이기 때문에 사용자 이 그래프를 마음에 새겨두기 바란다. 풀그림은 병렬 컴퓨터들 사이에 이동할 수 있어야 하지만, 다른 플랫폼상의 효율은 보장할 수 없다. 일반적으로 이식가능하면서 효율적인 병렬 프로그램은 존재하지 않는다.
위의 그래프를 통해 또 다른 한가지를 유추할 수 있다. 병렬 수행 효율은 통신/처리 비율에 의존하는 것이기 때문에, 단지 이 비율 요소의 한 부분만을 (즉, 통신 성능 또는 처리 성능 둘 중 하나만을) 변화시키는 것으로부터 어떤 특정 응용프로그램은 더 빨라질 것이라는 기대를 항상 할 수 있는 것은 아니다라는 것이다. 통신속도는 변하지 않은 상태에서 처리 속도만의 변화는 프로그램에 예상치 않은 영향을 줄 수 있다. 예를들어, 통신속도는 그대로 유지한채 CPU 속도를 두배 또는 세배 증가시킨 경우 변경 이전 병렬 수행이 효율적이었던 프로그램의 부분을 순차적으로 수행하도록 수정하는 것이 더욱 효율적인 경우도 있다. 말하자면 이전의 병렬실행부분을 이제는 순차적으로 수행시키는 것이 속도가 더 빠를 수 있다는 것이다. 더 나아가, 병렬화하면 비효율적인 부분을 병렬수행하게 되면 결국 응용프로그램이 최고 속도를 내지 못하게 된다. 이러한 경우, 더 빠른 프로세서를 추가하여 병렬수행시키면 오히려 응용프로그램의 속도가 떨어지게 된다.(그 응용프로그램이 최고 속도를 내도록 하기 위해서는 새로운 CPU를 추가하지 말아야 한다.) 그래서, 결론으로 병렬 하드웨어 환경을 사용해야 할지 하지 말아야 할지를 알고 있어야 한다. 그렇기 때문에, 병렬 머신의 적합성이 풀그림에 맞는지 간파해야할 필요가 있다. CPU 속도, 컴파일러, 메시지 전송 API, 네트워크 등등을 포함한 많은 논쟁점을 살펴볼 필요가 있다. 풀그림의 윤곽일 뿐이지 전체적인 이야기를 주는 것이 아님을 주의하라. 프로그램의 중요한 부분을 구분할 수 있지만, 이 부분에 대한 통신 비용을 알 수 는 없다. 주어진 시스템대해서도, 통신 비용은 코드 효율을 병렬화할 수는 없다. 마지막으로 일반적인 오해를 보도록 하자. 자주 "병렬화된 프로그램"이라 하지만, 실제로는 프로그램의 CONCURRENT 부분으로만 위치하고 있다. 효과적인 PARALLELIZATION은 머신의 속성이다.
병렬 계산이 필요한다고 결정했고 베오울프를 디자인하고 구성하기를 원한다면, 잠시 전의 논의된 내용을 살펴 보는 것이 좋을 것 같다. 일반적으로 다음 두 가지를 해야 한다:
이 단계는 빈번하게 "프로그램 병렬화하기"이라 하기도 한다. Parallelization 결정은 두 번째 단계에서 할 것이다. 이 단계에서는 데이터 의존을 결정할 필요가 있다. >실질적인 입장에서, 풀그림은 두 가지 병행 형태를 보이고 있다: 계산 (number crunching)과 I/O (데이터베이스). 많은 경우에 계산과 I/O 병행성은 orthogonal이지만, 풀그림은 둘 다를 요구한다. 기존의 풀그림에 대한 병행 분석을 수행할 수 있는 도구들이 있다. 이들 대부분의 도구들은 포트란에 의해 작성되었다. 포트란을 사용하는 주된 두 가지 이유: 대부분의 crunching 풀그림들이 포트란으로 작성되었고 분석하기가 쉽다. 도구들이 없다면, 이 단계는 기존 풀그림에 대해 다소 어려울 것이다.
도구들의 도움이 없으면, 시행착오를 거치거나 옛날 지식에 의해 추측을 가지고 해야할 것이다. 특정 풀그림을 생각하고 있으면 CPU 한계(계산 범위)와 하드 디스크 한계(I/O 범위)를 결정해보아라. 베오울프의 요구 사항은 당신의 요구에 따라 매우 다양하다. 예를 들어, 계산 한계에서의 문제은 몇개의 매우 빠른 CPU와 고속의 낮은 대기 시간의 네트워크를 필요로 한다. 반면에 I/O 한계 문제는 더 느린 CPU와 빠른 이더넷이 더 효과적으로 작동을 한다. 이런 권고는 종종 대부분의 사람들을 놀라게 한다. 왜냐하면, 보편적인 생각으로는 더 빠른 프로세서가 항상 더 좋다라고 여기기 때문이다. 예산이 한계가 없다면 맞는 말일지 모르지만, 실제 시스템은 비용에 있어서 제한이 있다. I/O 한계 문제에 대해서 조금 알려진 규칙(Eadline-Dekov 법칙이라 불림)이 있는데 꽤 도움이 된다: 똑 같은 누적 CPU 성능 색인을 가진 주어진 두 개의 병렬 컴퓨터에서, 늦은 프로세서(그리고 아마 프로세스간 통신 네트워크도 느려질것이다)은 I/O가 많은 풀그림에 대해서 더 좋은 성능을 보여줄 것이다. 이런 법칙의 증명은 이 문서의 나중에 나올 것이지만, 흥미가 있다면 Performance Considerations for I/O-Dominant Applications on Parallel Computers (Postscript format 109K ) ( www.plogic.com/pub/papers/exs-pap6.ps) 논문을 받아서 보면 된다. 당신의 풀그림에서 병행의 형태를 무엇인지를 결정을 했었다면, 병렬로 했을 경우 얼마나 효율이 있는지 계산할 필요가 있다. 소프트웨어 도구에 대한 설명은 "소프트웨어"절을 보아라. 도구를 가지고 있지 않으면 이 단계를 거치는 방법을 추축해야할 것이다. 계한 한계 루프를 분단위로 측정하고 초단위로 데이터 전송을 측정했다면, parallelization를 위한 좋은 후원자가 되어야 한다.(?) 그러나 기억해야 할 것은 16분이 걸리고 32 부분으로 분리하였다면, 그리고 각 부분 마다 데이터 전송하는데 몇 초의 시간이 걸린다면, 그 것은 여유를 가질 수가 없게 될 것이다. 감소하기 위한 반환점으로 도달할 것이다.
프로그램의 병병 부분을 기술하기 위한 방법이 몇가지가 있다:
기본적인 방법으로 병렬 컴퓨터를 위해 밑그림의 특정 부분을 사용자가 변경해야만 한다. 사용자는 반드시 PVM이나 MPI을 추가하거나 POSIX 쓰레드를 사용하는 쓰레드를 추가해야한다. (그러나 마음에 기억해두어야 할 것은 쓰레드 SMP 마더보드들 사이로 이동할 수 없다.) 명시적 방법은 구현과 벌레잡기가 매우 어려운 경향이 있다. 전형적으로 사용자가 표준 포트란 77이나 C/C++ 밑그림에서 명시적 함수라 불리는 것을 포함해야 한다. MPI 라이브러리은 몇가지 표준 병렬 방법을 쉽게 구현할 수 있는 몇가지 함수를 가지고 있다.(예로, 흩어주는/모으는 함수들). 추가적으로 병렬 컴퓨터을 위해 쒸여진 표준 라이브러리를 이용하는 것도 가능하다. 그렇지만, 주목할 것은 이동성과 효율성은 모순적이다. 역사적인 이유로해서 많은 숫자의 cruching 코드들은 FORTRAN으로 작성되어 져 있다. 이러한 이유로해서 FORTRAN은 병렬 계산에 있어서 가장 많은 양의 지원(도구들, 라이브러리들, 등등)을 가지고 있다. 현재 C를 사용하고 있는 많은 프로그래머들이 C가 더빨리 실행돼다는 생각으로 기존 FORTRAN 풀그림을 C로 재작성하고 있다. 이러한 생각이 보편적인 머신 코드에서 C로 된 것은 사실일지 몰라도, 몇가지 주요한 결점을 가지고 있다. C에서 포이터의 사용은 데이터 의존성을 결정하는데 있어서 극도록 어렵게 만든다. 포인터의 자동 분석은 극도로 어렵다. 기존 포트란 프로그램을 가지고 있고 앞으로 병렬로 처리할려고 한다면, C로 바꾸지 말라.
암시적 방법은 사용자가 컴파일하기 위해 병렬화 결정의 일부(또는 모드)를 포기해야 한다. 포트란 90의 예로 고성능 포트란(High Performance FORTRAN: HPF), Bluk Bynchronous Parallel (BSP), 그리고 다른 방법의 총체적 모임들은 아직도 개발중에 있다. 암시적 방법은 사용자가 그들 풀그림의 병행 성질에 대한 몇가지 정보 제공을 요구하지만, 컴파일러는 어떻게 이 병행을 병렬로 실행하는가에 대한 많은 결정을 내려야 할 것이다. 이 방법은 이동성과 효율성의 몇가지 단계를 제공하지만, 병렬 컴퓨터에 대한 병행 문제의 기술을 하는 "가장 좋은 방법"은 아직까지는 아니다.