工學碩士學位論文

VIA 기반의 병렬 라이브러리

구현 및 성능 평가

2000年 2月

서울大學校 大學院

컴퓨터工學科

金 善 載

VIA 기반의 병렬 라이브러리

구현 및 성능 평가

指導敎授 河 舜 會

이 論文을 工學碩士 學位論文으로 提出함

1999年 11月

서울大學校 大學院

컴퓨터工學科

金 善 載

金善載의 工學碩士 學位論文을 認准함

1999年 12月

委 員 長 印

副委員長 印

委 員 印

요 약

하드웨어와 소프트웨어 기술이 발전함에 따라, 컴퓨팅 환경은 급속히 변

화하고 있으며, 병렬 처리 분야에서도 성능 좋고 저렴한 PC나 워크스테이션

을 고속의 네트웍으로 연결하여 고성능의 수퍼 컴퓨터들을 대체하고자 하는

클러스터링(Clus tering)에 관한 연구가 활발히 진행되고 있다. 클러스터 시스

템은 SAN(System Area Network)이라고 하는 비교적 소규모의 지역적인

환경에서 구성되기 때문에 기존의 T CP/ IP와 같은 복잡한 프로토콜은 전체

적인 시스템의 성능 향상에 걸림돌이 된다. 이와 같은 이유로 해서 기존의

T CP/ IP가 갖는 소프트웨어적인 오버헤드를 줄이고 고속의 통신을 가능하게

하기 위한 많은 연구들이 진행되고 있으며, VIA(Virtual Interface

Architecture)는 이러한 연구의 결과로 만들어진 프로토콜의 하나이다.

본 논문에서는 VIA를 기반으로 구성된 클러스터 시스템에서 효율적인

병렬 프로그래밍을 위한 병렬 라이브러리를 구현하였다. 널리 알려진

MPI(Message Pass ing Interface)와 BSP(Bulk Synchronous Parallel) 라이브

러리를 VIA 기반 위에서 구현하고, 기존의 T CP/ IP나 UDP/ IP 기반의 MPI,

BSP 라이브러리와의 비교를 통해 VIA 기반 병렬 라이브러리의 성능을 분

석하였다.

주요어 : 클러스터, SAN, VIA, MPI, BSP

학 번 : 98419- 512

목 차

제 1 장 서론 1

1.1 연구 배경 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 연구 내용 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 논문 구성 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

제 2 장 VIA / MPI/ BS P 7

2.1 VIA(Virtual Interface Architecture) . . . . . . . . . . . . . . . . . 7

2.1.1 VIA의 구조 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.2 VIA의 동작 원리 . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.3 M- VIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 MPI(Message Pass ing Interface) . . . . . . . . . . . . . . . . . . 17

2.2.1 MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.2 MPICH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3 BSP(Bulk Synchronous Parallel) . . . . . . . . . . . . . . . . . . . 19

2.3.1 BSP 계산 모델 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.2 BSPlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

제 3 장 VIA 기반의 병렬 라이브러리 구현 22

3.1 VIA 기반의 병렬 라이브러리 구현 기법 . . . . . . . . . . . . . . . 22

3.1.1 VIA 기반의 병렬 라이브러리 구현 시 고려 사항 . . . . . . . 22

3.1.2 제어 메시지 수신을 위한 기법 . . . . . . . . . . . . . . . . . . 25

3.1.3 채널의 이중화로 인한 오버헤드를 줄이기 위한 기법 . . . . . 27

3.2 VIA 기반의 MPI 라이브러리(VMPI) 구현 . . . . . . . . . . . . . . 29

3.2.1 VIA 기반 MPI 라이브러리의 구현 함수 . . . . . . . . . . . . . 30

3.3 VIA 기반의 BSP 라이브러리(VBSPlib) 구현 . . . . . . . . . . . . 37

3.3.1 VIA 기반 BSP 라이브러리의 구현 원리 . . . . . . . . . . . . . 37

3.3.2 VIA 기반 BSP 라이브러리의 구현 함수 . . . . . . . . . . . . . 39

제 4 장 성능 평가 47

제 5 장 결론 55

참고 문헌 56

그림 목차

1.1 클러스터 컴퓨터 아키텍처 . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 VI 아키텍처 모델 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 가상 인터페이스 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 완료 큐 모델 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Send/Receive 모델에서의 디스크립터 형태 . . . . . . . . . . . . . . . 11

2.5 VI 아키텍처의 연결 설정 과정 . . . . . . . . . . . . . . . . . . . . . . 15

2.6 M- VIA 구성 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.7 BSP 모델에서의 수퍼스텝 . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 VIA 기반 병렬 라이브러리의 통신 메커니즘 . . . . . . . . . . . . . 23

3.2 제어 채널을 통한 제어 메시지 수신 유형 . . . . . . . . . . . . . . . 24

3.3 데이터 크기에 따른 통신 메커니즘 . . . . . . . . . . . . . . . . . . . 28

3.4 제어 메시지 수신을 위한 사전 포스팅 수 . . . . . . . . . . . . . . . . 29

4.1 VMPI와 MPICH의 지연 시간 비교 . . . . . . . . . . . . . . . . . . . 48

4.2 VBSPlib과 BSPlib의 지연 시간 비교 . . . . . . . . . . . . . . . . . . 49

4.3 VMPI와 MPICH의 대역폭 비교 . . . . . . . . . . . . . . . . . . . . . 50

4.4 VBSPlib과 BSPlib의 대역폭 비교 . . . . . . . . . . . . . . . . . . . . 51

4.5 VMPI와 MPICH의 100차 정방 행렬 곱셈 . . . . . . . . . . . . . . . 52

4.6 VMPI와 MPICH의 Adjoint Convolut ion . . . . . . . . . . . . . . . . 52

4.7 VBSPlib과 BSPlib의 100차 정방 행렬 곱셈 . . . . . . . . . . . . . . 53

4.8 VBSPlib과 BSPlib의 Sample Sort . . . . . . . . . . . . . . . . . . . . 53

표 목차

3.1 VIA 기반 MPI 라이브러리의 구현 함수 . . . . . . . . . . . . . . . . 30

3.2 VIA 기반 BSP 라이브러리의 구현 함수 . . . . . . . . . . . . . . . . 38

4.1 VMPI와 VBSPlib의 지연 시간 . . . . . . . . . . . . . . . . . . . . . . 49

제 1 장 서 론

1.1 연구 배경

하드웨어와 소프트웨어 기술이 발전함에 따라, 컴퓨팅 환경은 급속히 변

화하고 있다. 현재 상업용 프로세서의 성능은 눈부신 발전을 이루어 누적 성

장률이 1992년 이래로 154%에 이르고 있으며, 네트웍 분야에서도 데이터의

특성이 과거의 텍스트 위주에서 멀티미디어 등의 대용량으로 변함에 따라,

100Mb 또는 Gb 이상의 대역폭을 갖는 장비들이 등장하였다[16]. 또한, 분산

컴퓨팅을 위한 다양한 소프트웨어 도구들이 개발되었고, 운영 체제도 분산

컴퓨팅을 위한 기능을 지원해 가고 있는 추세이다. 이와 같은 기술의 발전은

병렬 처리 분야에서도 새로운 시도를 가능하게 하였는데 이 중 하나가 클러

스터링(Clustering) 기법이다.

클러스터는 독자적인 컴퓨터를 상호 연결망으로 연결하여 함께 동작하게

함으로써 하나의 통합된 계산 자원으로 활용할 수 있게 하는 병렬 또는 분

산 컴퓨터 시스템이다[16]. 클러스터는 기존의 SMP(Symmetric

Mult i- Processor)나 전통적인 분산 시스템과는 다른 개념으로, SMP가 여러

프로세서들이 메모리, I/O 등의 자원을 공유하여 사용하는 반면, 클러스터는

여러 컴퓨터들이 독자적인 메모리, I/O 등의 자원을 소유한다. 따라서 SMP

는 클러스터에 비해 확장성, 가용성, 시스템 관리, 소프트웨어 사용 등의 측

면에서 제약을 가지고 있다. 분산 시스템은 기능별로 용도가 정해진 독자적

인 컴퓨터로 구성되어 있고, 비교적 느린 네트웍으로 연결된 소결합

(loosely- coupled) 상태로 되어 있다. 반면, 클러스터는 각 노드의 익명성이

1

보장되어 시스템 전체적으로 하나의 이미지를 갖게 하며, 노드들은 고성능의

네트웍으로 밀결합(tight ly- coupled) 상태를 이룬다. U.C Berkeley의 워크스

테이션 기반의 NOW(Network Of Workstat ion) 시스템이나, NASA 산하

CESDIS(Center of Excellence in Space Data and Information Sciences )의

리눅스 기반의 PC를 활용한 Beowulf 프로젝트 등이 대표적인 클러스터 시

스템들이다[5][6][7][8].

일반적으로 클러스터는 그림 1.1과 같이, 다수의 컴퓨터, 운영 체제, 네트

웍 및 스위치, 네트웍 인터페이스 카드(Netw ork Interface Card, NIC), 통신

프로토콜, 클러스터 미들웨어, 병렬 프로그래밍 환경 및 도구, 응용 프로그램

으로 구성된다[15].

그림 1.1 클러스터 컴퓨터 아키텍처

다수의 고성능 컴퓨터 : 클러스터 시스템의 각 노드는 독자적인 컴퓨

터로서, 주로 PC나 워크스테이션이 사용된다. 각 노드는 단일 프로세서

시스템이나, SMP 시스템이 될 수 있다.

운영 체제 : 운영 체제로는 UNIX, LINUX, Window s NT 등이 다양

하게 사용되고 있는데, 최근 들어 LINUX가 널리 보급됨에 따라

2

LINUX에 대한 관심이 높아지고 있다.

고성능 네트웍 / 스위치 / NIC(Network Interface Card) : 고성능 네

트웍을 구성하기 위해 100Mb 또는 Gb 이상의 네트웍 장비를 사용하고

있으며, Fas t Ethernet, Gigabit Ethernet, Myrinet, Memory Channel,

ServerNet 등이 대표적인 예이다.

고성능 통신 프로토콜 : 기존의 T CP/ IP 이외에도, 클러스터 시스템이

SAN(System Area Network)이라고 불리어지는 소규모의 지역적인 환

경에서 구성된다는 특성을 이용하고, T CP/IP가 갖는 소프트웨어적인

오버헤드를 줄이기 위한 새로운 프로토콜들이 제안 및 개발되고 있다.

클러스터 미들웨어(Middleware) : 클러스터 시스템이 사용자에게 하

나의 통합된 시스템 이미지로 보이게 하고, 전체의 시스템 자원을 효

율적으로 관리하며, 각 노드 간의 부하를 균등하게 분배하는 등의 작업

을 수행하기 위한 하드웨어 또는 소프트웨어 제품군을 말한다.

병렬 프로그래밍을 위한 환경 및 도구 : 이에 해당하는 것으로는 가장

널리 알려진 PVM(Parallel Virtual Machine)이나 MPI(Message

Passing Interface)와 같은 것들이 있으며, 일반 사용자가 보다 쉽게 병

렬 프로그램을 작성할 수 있도록 하기 위한 많은 도구들이 연구

개발되고 있다.

응용 프로그램 : 사용자에 의해 작성된 실제 병렬 수행을 하기 위한

프로그램을 말한다.

비록, 하드웨어 기술의 발달로 물리적으로 클러스터를 구성하는 것은 가

능해졌지만, 이 클러스터를 활용하기 위한 소프트웨어의 발전은 비교적 더디

게 진행되었다. 특히 MPP(Mass ively Parallel Processor)에 비해 클러스터가

갖는 약점이면서, 진정한 클러스터 구현에 있어서 중요한 장애가 되었던 것

3

이 큰 통신 오버헤드이다. Gregory F. Pfis ter에 의하면, 이 통신 오버헤드의

주요한 원인은 기존의 프로토콜을 소프트웨어적으로 구현함에 있어 생긴 비

효율성에 근거한다고 한다[1]. T CP/ IP와 같은 기존의 통신 프로토콜은

LAN/WAN 환경에서 다양한 네트웍에 연결되어 있는 컴퓨터들을 안정적으

로 접근하고, 사용자에게 투명한 네트웍의 접근을 허용하기 위해 두터운 프

로토콜 스택이 필요했다. 과거에는 물리적 네트웍의 성능을 고려할 때, 소프

트웨어 오버헤드는 크게 문제되지 않았지만, 물리적 네트웍의 성능이 향상됨

에 따라 소프트웨어 오버헤드는 전체 통신 지연의 가장 중요한 원인이 되었

다. 따라서, 큰 대역폭과 짧은 지연 시간을 요구하는 SAN 환경에 적합한 새

로운 프로토콜의 필요성이 제기되었고, 이를 위한 다양한 연구가 진행되었

다. 대표적인 연구로는 Berkeley NOW 시스템의 Active Message(AM),

Cornell 대학의 U- Net, Princeton 대학의 SHRIMP(Scalable

High- performance Really Inexpensive Multi- Proces sor) 프로젝트에서 제안

한 VMMC(Virtual Memory- Mapped Communication), Illinois 대학의 Fast

Message(FM)과 Intel, Compaq, Microsoft가 주축이 되어 제안한 Virtual

Interface Architecture(VIA) 등이 있다[2][3][4][5][9][10].

1.2 연구 내용

본 연구에서는 전통적인 통신 프로토콜 기반의 병렬 라이브러리를 고성

능 프로토콜로 대체하여 통신 오버헤드로 인한 병목을 해소하고자 한다.

우선 고성능의 통신 프로토콜은 VIA를 채택하였다. VIA는 응용 프로그

램에서 네트웍 디바이스에 직접 데이터를 전달할 수 있게 하고 프로토콜 스

4

택을 단순화하여, 기존의 T CP/ IP가 가지고 있던 커널 복사 오버헤드를 줄이

고, 불필요한 기능을 제거함으로써 최대 성능을 발휘하기 위해 제안된 프로

토콜이다. VIA는 세계적인 컴퓨터 관련업체인 Intel, Compaq, Microsoft 이

외에 많은 회사들이 후원하고 있으며, 하드웨어와 소프트웨어로 모두 구현

가능하다는 점에서 주목을 끌고 있다. 현재 하드웨어로는 Giganet에서 생산

된 제품이 있고, 소프트웨어로는 Berkely의 NERSC(National Energy

Research Scientific Computing Center)에서 발표한 LINUX 기반의

M- VIA(Modular- VIA)와 Intel에서 발표한 Windows NT를 기반으로 한 것

이 있다. 본 연구는 LINUX 위에서 소프트웨어로 구현된 M- VIA를 기반으

로 하고 있다.

VIA는 통신에 필요한 최소한의 인터페이스를 저수준에서 제공하기 때문

에, 일반 사용자가 이를 이용하여 병렬 프로그래밍을 한다는 것은 너무나 번

거로운 일이다. 따라서 일반 사용자가 VIA 기반 위에서 쉽게 병렬 프로그램

을 작성하기 위한 병렬 프로그래밍 환경의 필요성이 제기된다. 이러한 이유

로 본 연구에서는 VIA 기반 위에서 효율적인 병렬 프로그래밍을 위한 환경

으로 MPI와 BSP 라이브러리를 구현하였다.

MPI는 메시지 전달 방식의 병렬 프로그래밍을 위해 가장 널리 알려진

표준안으로, 연구용으로 공개된 MPICH가 널리 사용되고 있다. BSP는 원래

알고리즘의 성능 평가를 위한 계산 모델로써 제안된 것인데, 병렬 프로그래

밍을 기술하는데 용이하다는 장점 때문에 Oxford 대학 등에서 이를 라이브

러리로 구현하려는 연구가 진행되어 왔으며, 대표적인 라이브러리로는

BSPlib이 있다.

본 연구에서 사용된 클러스터 시스템은 네 대의 Pentium 컴퓨터와 Fas t

Ethernet으로 구성되었다. 각 노드의 컴퓨터로는 512KB 캐쉬에 64MB와

128MB의 메모리를 갖는 Pentium Pro 200Mhz 시스템 두 대와 256KB 캐

5

쉬와 64MB 메모리를 갖는 Pentium Celeron 433Mhz 시스템 두 대가 사용되

었다. 이들 컴퓨터들은 스위칭 허브를 이용하여 Fas t Ethernet으로 연결되어

있다.

본 논문에서는 VIA를 기반으로 MPI와 BSP 라이브러리를 구현하고, 기

존의 T CP/ IP나 UDP/ IP 위에서 구현된 MPICH나 BSPlib과 성능을 비교 분

석해 봄으로써 현 연구의 발전 가능성과 앞으로의 방향에 관해 제시하고자

한다. 우리는 VIA 기반의 MPI를 VMPI, VIA 기반의 BSPlib을 VBSPlib이

라고 부르기로 한다.

1.3 논문 구성

본 논문의 구성은 다음과 같다. 먼저 제 2장에서는 VIA의 구조, 구성 요

소 및 동작 원리에 대해 살펴보고, 이어 MPI와 BSP 계산 모델 및 BSPlib에

대해 설명한다. 제 3장에서는 우리가 구현한 VIA 기반의 MPI와 BSP 라이

브러리의 구현 원리를 설명한다. 제 4장에서는 본 연구에서 구현한 VIA 기

반의 MPI, BSP 라이브러리와 기존의 T CP/ IP 기반의 MPICH 및 UDP/ IP

기반의 BSPlib을 몇 가지 실험을 통해 성능을 분석한다. 끝으로 제 5장에서

는 본 연구에 대한 결론 및 앞으로의 연구 방향에 대해 기술한다.

6

제 2 장 VIA / MPI/ BS P

2.1 VIA(Virtual Interface Architecture)

하드웨어 기술의 발달로 링크의 대역폭은 날로 증가하고 있으며, 네트웍

디바이스 사이의 전파 지연 시간은 점차 감소하고 있다. 그러나 응용 프로그

램들은 사용자 레벨과 커널 레벨 사이의 많은 소프트웨어 계층 때문에 향상

된 네트웍의 성능을 충분히 활용하지 못하고 있다. VIA(Virtual Interface

Architecture)는 Intel, Compaq, Microsoft가 주축이 되어, 사용자 레벨의

zero- copy 정책으로 SAN(Sys tem Area Netw ork) 환경에 적합하도록 기존

의 소프트웨어 오버헤드를 줄인 새로운 프로토콜이다.

T CP/IP와 같은 전통적인 네트웍에서 데이터를 전송하기 위해서는 투명

한 통신, 시스템 보호, 자원의 공유 등의 목적으로 사용자 영역에 있는 데이

터를 커널 영역으로 복사를 해야 했다. 이러한 데이터 복사는 사용자 레벨에

서 커널 레벨로의 문맥 교환과 사용자 영역에서 시스템 버퍼로의 데이터 복

사로 인한 오버헤드를 동반한다. VIA는 네트웍 디바이스가 사용자 영역을

직접 접근할 수 있게 하여, 불필요한 메시지 복사와 문맥 교환을 줄임으로써

고성능의 통신을 가능하게 한다. 이 장에서는 VIA의 구조와 동작 원리에 대

해 살펴본다.

2.1.1 VIA의 구조

(1) VIA의 구성 요소

7

VIA는 네 개의 기본 요소 즉, 가상 인터페이스(Virtual Interface, VI), 완

료 큐(Completion Queue, CQ), VI- 제공자(VI Provider), VI- 수요자(VI

Consumer)로 구성된다. VI- 제공자는 물리적인 네트웍 어댑터와 소프트웨어

인 커널 에이전트(라이브러리)를 포함하며, VI- 수요자는 VIA를 이용하는 응

용 프로그램을 말한다.

그림 2.1 VI 아키텍처 모델

가상 인터페이스(VI)는 여러 프로세스에 의해 공유되어 사용되는 네트웍

어댑터에 대하여 VI- 수요자에게 가상으로 하나의 전용 어댑터가 할당되어

있는 것처럼 보이게 하여 원격 프로세스와 통신을 할 수 있게 해 주는 메커

니즘이다. 두 프로세스가 통신을 하기 위해서는, 우선 각 프로세스가 가상

인터페이스를 하나씩 생성하고, 이들 가상 인터페이스 사이에 가상 회선을

설정하여야 한다. 가상 인터페이스는 작업 큐(Work Queue)라 불리는 송신

큐(Send Queue)와 수신 큐(Receive Queue)의 쌍으로 이루어진다. VI- 수요

자는 전달할 또는 전달받을 메시지에 대한 정보를 담고 있는 디스크립터를

작업 큐에 추가함으로써 메시지를 교환할 수 있다. VI- 제공자는 가상 인터

페이스를 통하여 사용자 영역에 있는 데이터를 직접 접근할 수 있는 정보를

8

얻게 된다.

가상 인터페이스는 VI- 수요자의 요구에 따라 VI- 제공자에 의해 생성되

며, 이 때 생성된 송신 큐와 수신 큐는 각각 도어벨(Doorbell)이라는 VI- NIC

에 위치한 하드웨어 자원에 연결된다. 커널 에이전트는 작업 큐에 처리할 메

시지가 들어왔을 때 이 도어벨을 울려 VI- NIC에게 알린다. VIA가 소프트웨

어적으로 구현될 때에는 별도의 인터럽트 루틴 등을 이용하여 도어벨을 대

신하게 된다. 작업 큐에 처리할 메시지가 남아 있는 경우 가상 인터페이스는

소멸될 수 없다.

그림 2.2 가상 인터페이스

VI 작업 큐는 하나의 완료 큐와 연결될 수 있다. VI 작업 큐가 완료 큐

와 연결되면, 이 완료 큐와 연결된 VI 작업 큐에 삽입되어진 디스크립터의

송수신 완료 상태는 완료 큐 위에 놓이게 된다. VI- 수요자는 완료 큐의 상

태를 검사함으로써 각 VI가 송수신을 완료한 순서대로 결과를 취합할 수 있

다.

완료 큐의 생성은 이와 연결될 VI가 생성되기 전에 미리 생성되어야 한

다. 완료 큐의 크기는 생성 시 고정되어 있어서 필요한 경우 VI- 제공자에

9

의해 동적으로 크기를 확장시킬 수 있다. 완료 큐는 이와 연결된 모든 VI가

소멸될 때까지 소멸될 수 없다.

그림 2.3 완료 큐 모델

VI- 제공자는 디바이스 및 VI를 관리하고, VI- 수요자에게 필요한 서비스

를 제공하는 역할을 한다. VI- 제공자는 VI- NIC(Netw ork Interface

Controller)과 커널 에이전트로 구성된다. VI- NIC은 가상 인터페이스와 완료

큐의 집합으로 이루어진다. VI- NIC은 네트웍 카드에 하드웨어적으로 구현할

수도 있고, 소프트웨어적으로 애뮬레이션할 수도 있다. 커널 에이전트는 운

영 체제의 한 부분으로 VI- NIC을 위한 네트웍 디바이스 드라이버와, VI- 수

요자와 VI- NIC 사이에서 VI를 유지하기 위해 필요한 각종 설정 및 자원 관

리를 수행하는 커널 모듈로 구성된다.

VI- 수요자는 VIA를 이용하여 통신하는 응용 프로그램으로 사용자가 커

널 에이전트에게 특정 연산을 수행하도록 하기 위한 라이브러리가 제공된다.

10

(2) 디스크립터의 구성 및 관리

디스크립터는 송수신할 데이터에 대한 정보가 기록된 자료 구조로써, 컨

트롤 세그먼트, 어드레스 세그먼트, 데이터 세그먼트의 세 가지 형태가 있다.

컨트롤 세그먼트는 디스크립터에 대한 제어 및 상태 정보를 저장하며, 어드

레스 세그먼트는 RDMA(Remote Direct Memory Access ) 연산의 경우에만

사용되는 것으로 데이터를 주고받을 원격 버퍼에 대한 정보를 저장한다. 데

이터 세그먼트는 데이터를 주고받을 지역 버퍼에 대한 정보를 저장하며 다

수의 메모리 블록을 지역 버퍼로 지정할 수 있다.

디스크립터에 주고받을 데이터에 대한 정보 설정이 끝나면, 실제로 데이

터를 주고받기 위해 디스크립터를 해당 작업 큐에 삽입하게 되는데, 이 과정

을 포스팅(pos ting)이라고 부른다. VI- 수요자에 의해 디스크립터 포스팅이

끝나면 VI 커널 에이전트는 도어벨을 울려 VI- NIC에게 처리할 데이터가 있

음을 알린다. 포스팅된 디스크립터의 처리해야할 데이터가 송신 또는 수신을

완료되면 해당 디스크립터의 컨트롤 세그먼트에 완료 상태를 기록하고, VI-

수요자는 이 상태를 검사하여 완료된 디스크립터를 해당 작업 큐로부터 제

거한다.

그림 2.4 Send/Receive 모델에서의 디스크립터 형태

11

그림 2.4은 Send/Receive 데이터 전달 모델에서 디스크립터의 형태이다.

2.1.2 VIA의 동작 원리

(1) 데이터 전달 모델

VI 아키텍처는 데이터 전달을 위해 다음과 같은 두 가지 모델을 제공한

다.

전통적인 Send/Receive 메시징 모델

Remote Direct Memory Access(RDMA) 모델

Send/Receive 메시지 모델에서 송신 프로세스는 보낼 데이터를 포함하는

메모리 영역을 명시하고, 수신 프로세스는 데이터를 받을 메모리 영역을 명

시한다. VI 아키텍처에서 이러한 작업은 데이터 송수신에 필요한 메모리 영

역을 디스크립터에 지정하고, 이 디스크립터를 VI의 작업 큐에 포스팅함으

로써 이루어진다. VI 아키텍처에서는 송신 프로세스가 송신 디스크립터를

포스팅하기 전에 반드시 수신 프로세스가 먼저 수신 디스크립터를 포스팅하

여야 한다. 만약 수신 디스크립터가 먼저 포스팅되어 있지 않다면 송신 프로

세스가 보낸 데이터를 저장할 공간이 마련되어 있지 않기 때문에 그 데이터

를 잃게 된다. 포스팅이 이루어진 후에는 해당 디스크립터의 상태를 검사하

여 데이터의 송수신이 이루어졌는지를 확인하고, 이루어졌을 경우 디스크립

터를 작업 큐에서 제거함으로써 모든 데이터 전송이 완료된다.

RDMA 모델은 직접 원격 메모리의 해당 영역에 접근하여 데이터를 읽고

쓰는 메커니즘으로 데이터를 전송하는 프로세스는 전달할 데이터가 있는 메

12

모리 영역뿐만 아니라 데이터가 전달될 메모리 영역까지 명시한다. RDMA

연산의 유형에는 RDMA Write와 RDMA Read의 두 가지 종류가 있다.

RDMA Write는 지역 메모리의 데이터를 지정된 원격 메모리 영역에 쓰는

연산이며, RDMA Read는 지정된 원격 메모리 영역의 데이터를 자신의 지역

메모리로 읽어오는 연산이다. 이러한 연산을 수행하기 위해서는 먼저 데이터

를 읽고 쓰기 위한 원격 메모리 영역의 주소를 알아야만 하는데, 이것은 해

당 영역의 주소를 Send/Receive 연산에 의해 명시적으로 주고받음으로써 이

루어진다. RDMA 연산이 이루어질 때 원격 노드에서는 어떠한 디스크립터

의 포스팅도 필요하지 않으며, 원격 노드에서 해당 연산이 완료되었는지에

대해 검사할 수 있는 별도의 방법은 제공되지 않는다.

(2) 메모리 등록 및 보호

대부분의 컴퓨터 시스템은 네트웍 인터페이스 카드를 통해 데이터를 전

달하기 전에 데이터 메모리 영역에 대한 가상 메모리 주소를 물리적인 메모

리 주소로 변환하고 그 영역을 잠그고, 데이터 전송이 완료되면 해당 영역을

푼다. 전통적인 네트웍 전송 방식은 모든 데이터 전송 요구 시마다 이러한

과정을 반복하며, 이는 중요한 오버헤드로 작용하였다.

VI 아키텍처는 데이터를 전송하기 전에 VI- 수요자가 해당 메모리 영역을

VI 커널 에이전트에 등록하여, 등록된 메모리 영역의 데이터에 대해서만 전

송할 수 있도록 한다. 이는 등록된 영역에 대한 재사용을 가능하게 하고 반

복적인 주소 변환 및 잠금(locking)으로 인한 오버헤드를 줄인다. 또한 메모

리 등록은 VI- 제공자가 중간에 운영 체제의 커널 버퍼를 통하지 않고 VI-

수요자의 버퍼와 네트웍 사이에 직접 데이터를 전송하도록 하는 메커니즘을

제공하여 전통적인 네트웍 아키텍처의 데이터 복사로 인한 오버헤드를 줄일

13

수 있다.

VI- 수요자가 메모리를 VI 커널 에이전트에 등록하면 VI 커널 에이전트

는 VI- NIC의 페이지 테이블에 해당 메모리 영역에 대한 물리적 주소 및 메

모리 보호 정보 등을 기록하고, 그 영역을 유일하게 식별할 수 있는 메모리

핸들을 반환한다. 또한 메모리를 등록하면 등록된 영역에 있는 모든 페이지

는 물리적 메모리 내에서 고정되어, VI- NIC이 해당 영역을 접근하는 동안

페이지 교환이 일어나는 일을 방지한다.

등록된 메모리는 메모리 보호 태그(Memory Protection T ag)를 통해 보

호된다. 메모리 보호 태그는 VI 및 등록된 메모리 영역에 대한 접근 권한을

제한하고 보호하기 위한 유일한 식별자로 VI- 제공자에 의해 생성 또는 소멸

된다. 유효하지 않은 메모리 보호 태그를 가진 VI 및 등록된 메모리 영역에

대한 접근은 거부된다. 또한 VI 및 등록된 메모리 영역에 대한 메모리 보호

속성(Memory Protection Attribute)은 해당 VI 및 메모리 영역이 RDMA

Read나 RDMA Write가 가능한지 여부를 표시한다. 만약 VI에 설정된 속성

과 등록된 메모리 영역에 설정된 속성이 틀릴 경우 해당 영역에 대한 연산

수행은 거부된다.

(3) VI의 연결 설정 및 해제

VI 아키텍처는 연결- 지향(connect ion- oriented) 데이터 전달 서비스를 제

공한다. VI- 수요자는 자신의 VI와 원격지의 VI를 연결하기 위해 VI- 제공자

에게 요청한다. VI의 연결 설정은 기본적으로 클라이언트- 서버 모델에 의해

이루어진다. 서버 측은 클라이언트로부터의 연결 요구가 오기를 기다리고,

이 요구가 들어오면 원격 VI의 연관된 속성에 따라 연결을 설정하던지 거부

한다. 자세한 연결 과정은 그림 2.5와 같다

14

.

그림 2.5 VI 아키텍처의 연결 설정 과정

2.1.3 M- VIA

M- VIA(Modular- VIA)는 Berkely의 NERSC(National Energy Research

Scientific Computing Center)에서 VIA를 LINUX 상에서 소프트웨어적으로

구현한 프로젝트이다. M- VIA는 Intel의 Virtual Interface Architecture

Developer ' s Guide에 정의된 VIA의 기본 명세를 LINUX 상에서 구현하려는

목적으로 개발되어 1999년 10월 현재 1.0 버전을 발표했으며, 그 소스 코드

또한 일반인들에게 공개하여 자유롭게 배포 및 연구 가능하게 하고 있다.

M- VIA는 소프트웨어적으로 구현되어 있기 때문에 별도의 도어벨을 가

지고 있지 않으며, 인터럽트 루틴에 의해 도어벨 기능을 대신한다. 또한 현

15

재 RDMA 연산을 완벽하게 지원하지 못하고 있으며, VIA의 명세에 포함되

어 있는 몇 가지 기능은 아직 구현되지 않았다.

M- VIA는 크게 세 가지 요소로 이루어져 있다. 사용자가 M- VIA를 이용

한 프로그래밍을 원활히 할 수 있도록 기본 API를 제공해 주는 VI- 제공자

라이브러리(VIPL), 네트웍 인터페이스 카드(NIC)가 VIA의 기능을 지원하도

록 하기 위한 네트웍 디바이스 드라이버와 VIA의 제어를 위한 M- VIA 커

널 에이전트로 이루어진 VI 커널 에이전트, 그리고 물리적인 네트웍 인터페

이스 카드로 구성된다.

그림 2.6 M- VIA의 구성

M- VIA의 가장 핵심적인 역할을 수행하는 M- VIA 커널 에이전트를 기

능별로 구분하면 크게 다음과 같이 구성된다.

연결 관리자(Connection Manager) : VI 사이의 논리적인 연결을 설정

한다.

보호 태그 관리자(Protect ion T ag Manager) : 메모리 영역의 보호를

16

위한 태그의 할당 및 회수를 한다.

등록 메모리 관리자(Regis tered Memory Manager) : 데이터를 주고받

기 위한 버퍼와 디스크립터를 위한 버퍼의 메모리 영역을 등록한다.

에러 큐 관리자(Error Queue Manager) : VIA 디바이스 사이에 발생

하는 에러를 감시한다.

본 논문의 주 연구 내용인 VIA 기반의 병렬 라이브러리를 구현하는데는

M- VIA의 1.0 버전을 이용하였다. M- VIA 1.0 버전은 LINUX 커널 버전

2.2 이상을 요구하며, 다음과 같은 종류의 네트웍 디바이스를 지원한다.

Loopback

DEC T ulip fas t ethernet card

PacketEngines GNIC- I gigabit ethernet card

PacketEngines GNIC- II gigabit ethernet card

3Com 3C905 fast ethernet card

Intel EtherLink fast ethernet card

2.2 MPI(Mes s ag e Pas s ing Interface)

2.2.1 MPI

MPI(Message Pass ing Interface)는 공유 메모리를 갖지 않는 메시지 전

달 프로그래밍 모델에서 각 프로세서 사이의 메시지 전달을 위한 라이브러

리에 대한 표준 명세이다. MPI는 일반 사용자가 사용하기 쉬운 프로그래밍

17

인터페이스를 제공하며, 가급적 불필요한 메모리 복사를 줄이고, 통신과 지

역적인 계산의 중복을 통한 효율적인 통신 방법을 제공한다. 또한 이기종의

환경에서도 서로 연결 가능하며, 가장 보편화된 프로그래밍 언어인 C, C++,

Fortran 77을 지원한다. PVM(Parallel Virtual Machine)과 같은 기존의 병렬

라이브러리와 크게 다르지 않은 인터페이스를 제공하며, 다양한 플랫폼에서

동작한다는 장점도 가지고 있다[11].

MPI는 또한 Send와 Receive로 이루어지는 일대일 통신을 위한 기본적인

루틴 이외에도 집합적인 통신을 위한 루틴과 프로세스의 그룹 지정 및 이들

간의 그룹 통신을 위한 루틴 등 다양한 기능의 루틴을 제공한다.

MPI에서는 각 노드 간의 일대일 통신을 위한 루틴에서 데이터의 크기

및 송수신의 상태에 따라 효율적인 데이터 전달을 위해 다음과 같은 네 가

지의 통신 모드를 지원한다.

표준 모드 (S tandard Mode)

버퍼 모드 (Buffered Mode)

동기 모드 (Synchronous Mode)

준비 모드 (Ready Mode)

버퍼 모드는 송신자와 수신자 사이에 비동기적인 동작을 지원하기 위해

메시지를 임시로 버퍼에 저장하는 방식이며, 동기 모드는 이와 달리 수신자

가 이미 수신을 할 준비가 되어 있는 경우에만 송신자가 메시지를 전달하는

방식이다. 준비 모드는 수신자가 항상 수신을 할 준비가 되어있다는 보장 하

에 송신자가 무조건 메시지를 전달할 수 있는 방식이며, 마지막으로 표준 모

드는 메시지의 크기와 송수신 상태에 따라 앞에서 언급한 모드들을 선택적

으로 취하는 방식이다.

18

또한 해당 연산의 완료 시점에 따라 Blocking Send/Receive와

Nonblocking Send/ Receive를 지원한다. Blocking Send는 송신자의 버퍼의

내용이 의미적으로 수신자에게 전달되었다는 것을 보장하는 것으로, 이 연산

이후 버퍼의 내용에 대한 조작이 이전의 송신 결과에 영향을 주지 않는 연

산이고, Blocking Receive는 수신 버퍼에 송신자의 메시지가 도착할 때까지

연산을 완료하지 않는 것이다. 이와 반대로 Nonblocking Send/ Receive의

경우 해당 버퍼의 메시지 송수신에 관계없이 연산을 완료하는 것이다.

2.2.2 MPICH

MPICH는 Mississ ipi 대학에서 MPI의 기본 명세에 따라 구현한 대표적

인 메시지 전달 방식의 라이브러리로 SUN OS, Solaris , HP UX, AIX,

IRIX, Intel Paragon, Meiko CS2, Cray T 3D, LINUX 등 다양한 플랫폼에

구현되었다[17]. 또한 MPI로 작성된 병렬 프로그램의 분석 및 디버깅을 위

한 MPE(Multi- Processing Environment)라는 별도의 라이브러리를 제공하여

다양한 프로그래밍 환경을 제공하고 있다. 본 연구에서는 LINUX 기반의

MPICH를 이용하여 VIA 기반의 MPI와 성능을 비교 평가한다.

2.3 BS P(Bulk S ynchronous Parallel)

2.3.1 BS P 계산 모델

BSP(Bulk Synchronous Parallel)는 알고리즘의 성능 평가를 위해 제안된

19

계산 모델의 하나이다. BSP 모델에 있어서 하나의 프로그램은 일련의 수퍼

스텝(Superstep)의 집합으로 이루어지며, 각 수퍼스텝의 마지막에는 배리어

(Barrier) 동기화를 수행한다. 하나의 수퍼스텝은 지역적인 데이터에 대한 연

산과 다른 프로세서와의 메시지 교환으로 구성되는데, 한 수퍼스텝에서 전송

된 메시지는 그 다음 수퍼스텝에서 결과가 반영되어 사용된다[14].

그림 2.7 BSP 모델에서의 수퍼스텝

BSP 모델은 성능 평가를 위한 세 개의 인자를 포함하는데, 이 인자의 값

을 통해서 BSP 모델로 기술된 프로그램의 성능을 사전에 검증해 볼 수 있

다.

P : 프로세서의 수

L : 동기화 비용

g : 통신 비용

P는 BSP 모델로 기술된 프로그램을 수행하기 위해 사용되는 프로세서

의 수이며, L 은 각 수퍼스텝 사이에서 동기화를 수행할 때 소요되는 시간을

의미한다. g는 통신에 따른 소요 시간을 나타내는 인자로 단위 메시지에 대

20

해 정의된다. 각 프로세서가 최대 h개의 메시지를 서로 송수신할 때 이러한

통신 패턴을 h - 관계( h - relations)라 하는데, 이 때 통신에 따른 총 소요 시

간은 hg로 표시된다. 만약 w i가 수퍼스텝 i에서 각 프로세서에 의해 수행

된 지역적인 연산의 양을 나타내고, h i가 해당 수퍼스텝에서 송수신한 최대

메시지의 수를 나타낸다면 이 때 수퍼스텝 i의 수행 시간 T i는 다음과 같

이 주어진다[13].

T i = w i + gh i + L

2.3.2 BS Plib

BSPlib은 라이브러리 형태로 구현된, BSP 계산 모델을 위한 BSP 프로그

래밍 모델이다. BSPlib에서 노드 사이에 통신을 하기 위한 방법에는 사용자

입장에서 단방향의 통신을 위한 DRMA(Direct Remote Memory Access) 방

식과 Send와 Receive에 의해 명시적으로 양방향 통신을 하는 기존의 메시지

전달 방식과 유사한 BSMP(Bulk Synchronous Message Pass ing) 방식이 있

다.

21

제 3 장 VIA 기반의 병렬 라이브러리 구현

이제까지 본 연구에서 기반을 둔 고속 통신 프로토콜인 VIA와 기존의

대표적인 병렬 라이브러리의 특징을 살펴보았다. 이번 장에서는 VIA 기반

위에서 MPI와 BSP 라이브러리의 구현 과정을 자세히 살펴본다.

3.1 VIA 기반의 병렬 라이브러리 구현 기법

먼저 VIA를 이용하여 병렬 라이브러리를 구현하기 위해 고려해야 할 사

항 및 효율적인 구현을 위해 적용한 기법들을 살펴본다.

3.1.1 VIA 기반의 병렬 라이브러리 구현 시 고려 사항

VIA 기반의 병렬 라이브러리를 구현하는데 있어서 먼저 몇 가지 고려해

야 할 사항들이 있다. VIA에서 VI를 통해 임의의 프로세스에게 메시지를

전달하기 위해서는 수신자 측의 프로세스가 먼저 메시지를 수신하기 위한

기억 공간을 지정하는 수신 디스크립터를 포스팅하고 있어야 한다. 이 경우

문제가 되는 것 중의 하나는 수신 프로세스는 언제 송신 프로세스가 메시지

를 보낸다는 사실을 알고 미리 수신 디스크립터를 포스팅할 수 있느냐는 것

이다. 비슷한 문제로써 수신 프로세스는 송신 프로세스가 어떤 크기의 메시

지를 보내는지 어떻게 알고 미리 그 크기에 해당하는 기억 공간을 할당하느

냐는 것이다.

이러한 문제를 해결하기 위한 방법으로 두 노드 간의 통신을 위해서 서

로 다른 두 개의 채널을 유지하였다. 하나는 제어 정보를 전달하기 위한 제

22

어 채널이고, 다른 하나는 실제로 원하는 데이터를 전달하기 위한 데이터 채

널로써 각 채널은 별도의 VI를 이용한다. 두 개의 채널을 이용하기 때문에

두 노드 사이에 메시지를 전달하는 과정은 두 단계로 나누어진다. 첫 번째

단계는 제어 채널을 통해서 보내려는 데이터에 대한 제어 정보를 교환하는

단계이고, 두 번째 단계는 데이터 채널을 통해서 실제로 보내려는 데이터를

전송하는 단계이다. 또한 제어 채널을 통한 제어 메시지의 수신을 위해서 항

상 미리 충분한 제어 메시지 수신을 위한 디스크립터가 포스팅되도록 보장

해 주어야 한다.

그림 3.1 VIA 기반 병렬 라이브러리의 통신 메커니즘

하나의 데이터가 전달되는 과정을 구체적으로 살펴보면, 송신 프로세스는

실제 보내려는 데이터의 크기 및 데이터의 종류를 표시하는 태그 등에 대한

정보를 송신 디스크립터에 실어 포스팅함으로써 REQUEST 메시지를 보내

고, 수신 프로세스로부터 제어 메시지를 받았다는 ACK 메시지가 올 때까지

대기한다. 수신 프로세스는 미리 제어 정보를 받기 위해 포스팅한 수신 디스

크립터를 통해 송신 프로세스가 보낸 제어 메시지를 수신하고, 이 제어 정보

를 바탕으로 실제 데이터를 받아들이기 위한 기억 공간을 할당한 후 수신

23

디스크립터를 포스팅한다. 또한 제어 메시지 수신을 위해 미리 포스팅해 둔

하나의 수신 디스크립터를 소비하였으므로 이를 보충하기 위해 새로운 제어

메시지를 위한 수신 디스크립터를 포스팅하고 송신 프로세스에게 메시지를

수신할 준비가 되었음을 알리는 ACK 메시지를 보낸다. ACK 메시지를 받은

송신 프로세스는 실제 데이터를 보내기 위해 송신 디스크립터를 포스팅하고,

수신 프로세스는 앞서 포스팅한 수신 디스크립터를 통해 실제 데이터를 수

신한다.

앞서 언급했듯이 이 경우 제어 채널을 통해 들어오는 제어 메시지를 수

신하기 위해서 항상 수신 디스크립터가 미리 포스팅되어 있어야 한다. 기본

적으로는 미리 포스팅된 디스크립터를 소비할 때마다 즉시 새로운 디스크립

터를 포스팅하게 함으로써 미리 포스팅되는 디스크립터의 수를 항상 일정하

게 유지할 수 있다. 그러나 여기서 고려할 것은 소비된 디스크립터를 보충하

기 전에 연속적인 제어 메시지가 들어올 경우에 대비하여 가능한 연속적인

메시지의 최대 수만큼의 수신 디스크립터가 미리 포스팅되도록 보장되어야

한다는 것이다. 연속적인 제어 메시지의 가능한 최대 수신 수를 알기 위해

다음과 같은 세 가지 경우에 대해 생각해 볼 수 있다.

(가) 연속적인 REQUEST 또는 (나) 연속적인 REQUEST 와

연속적인 ACK가 들어오는 경우 ACK가 들어오는 경우

그림 3.2 제어 채널을 통한 제어 메시지 수신 유형

24

연속적인 REQUEST 메시지가 들어오는 경우

연속적인 ACK 메시지가 들어오는 경우

연속적으로 REQUEST 메시지와 ACK 메시지가 들어오는 경우

먼저 연속적인 REQUEST 메시지가 들어오는 경우를 살펴보면, 우리가

제안하는 모델 상에서 하나의 REQUEST 메시지를 보낸 후, 다음

REQUEST 메시지를 보내기 위해서는 반드시 중간에 상대 노드로부터 ACK

메시지를 받아야만 한다. 따라서 REQUEST 메시지를 받는 노드는 ACK 메

시지를 보내기 전 REQUEST 메시지로 소비된 디스크립터를 다시 보충해

놓는다면 아무리 많은 REQUEST 메시지가 연속적으로 들어온다고 해도 항

상 일정한 수의 디스크립터가 미리 포스팅되는 것을 보장할 수 있다. 연속적

인 ACK 메시지가 들어오는 경우도 마찬가지로 하나의 ACK 메시지가 들어

오고, 다음 ACK 메시지가 들어오기 위해서는 먼저 상대 노드에 REQUEST

메시지를 보내어야 하므로 ACK 메시지를 수신한 후 바로 새로운 디스크립

터를 보충해 놓는다면 언제나 일정한 수의 디스크립터가 미리 포스팅되는

것을 보장할 수 있다. 마지막으로 연속적으로 REQUEST 메시지와 ACK 메

시지가 들어오는 경우를 살펴보면 하나의 노드가 보낸 REQUEST 메시지

에 대해 상대 노드가 ACK 메시지를 보냄과 동시에 REQUEST 메시지를 보

낼 수 있다. 이 경우엔 ACK 메시지에 의해 소비된 디스크립터를 보충한 이

후에 REQUEST 메시지가 들어오리라는 것을 보장할 수 있는 방법이 없다.

따라서 연속적인 REQUEST 메시지와 ACK 메시지가 동시에 들어오는 경우

를 대비해서 항상 이를 처리할 수 있는 최소 두 개의 디스크립터가 미리 포

스팅되어야 한다.

3.1.2 제어 메시지 수신을 위한 기법

25

제어 채널을 통해 들어오는 제어 메시지에 대해 적절한 동작을 하기 위

해서는 제어 채널을 주기적으로 검사할 수 있는 루틴이 필요하다. 이러한 동

작을 수행하기 위해 VIA에서 제공하는 기본 함수 중에 VipCQNotify를 사용

하였다. 앞서 2장에서 VIA에 대해 설명할 때 언급했던 것처럼 VIA에서는

여러 개의 VI의 작업 큐에 포스팅된 디스크립터의 결과를 취합하기 위해 완

료 큐를 제공한다. VipCQNotify는 이 완료 큐의 상태를 검사하여 특정 VI에

완료된 디스크립터가 있을 때 지정된 핸들러 함수를 호출하는 함수로 프로

토타입은 다음과 같다.

VipCQNotify(VIP_CQ_HADLE CQHandle,

VIP_PVOID Context,

void(*Handler)(VIP_PVOID Context,

VIP_NIC_HANDLE NicHandle,

VIP_VI_HANDLE ViHandle,

VIP_BOOLEAN RecvQueue))

VipCQNotify 함수의 좀더 구체적인 동작을 살펴보면 최초로

VipCQNotify가 호출되었을 경우에 이 함수는 새로운 쓰레드를 생성하고 별

도의 큐에 VipCQNotify의 인자로 넘어온 Handler 함수에 대한 포인터를 삽

입한다. 생성된 쓰레드에서는 이 핸들러 큐를 검사하여 처리할 핸들러 함수

가 있을 경우에는 VipCQWait 함수를 호출하여 완료 큐와 연결된 VI 작업

큐의 디스크립터가 송신 또는 수신을 완료하기를 기다리게 된다. 송신 또는

수신이 완료되면 핸들러 큐로부터 핸들러 함수를 꺼내어 해당 함수를 수행

한다. VipCQNotify의 프로토타입에서 Handler 함수의 인자 중 RecvQueue는

완료된 디스크립터가 송신 큐에 있는 것인지 수신 큐에 있는 것인지를 나타

26

내는 것으로 송신 큐에 있는 것이면 VIP_FALSE가 전달되고, 수신 큐에 있

는 것이면 VIP_T RUE가 전달된다. 현재 VIA 기반의 병렬 라이브러리를 구

현하는데 있어서는 제어 채널로 이용하기 위해서 각 노드 당 설정된 VI들의

수신 큐를 완료 큐에 연결하여 각 VI의 수신 큐의 상태를 검사한다. 이 때

Handler 함수에서는 해당 수신 큐로부터 완료된 디스크립터를 꺼내어 수신

된 메시지가 REQUEST 메시지인지 ACK 메시지인지 등을 검사하고 그에

해당하는 동작을 수행한다. 한번 생성된 쓰레드는 해당 완료 큐가 소멸될 때

까지 지속되며, 최초의 VipCQNotify 함수 호출 후 다시 이 함수가 호출되었

을 경우에는 단지 핸들러 큐에 Handler 함수에 대한 포인터만 삽입한다.

3.1.3 채널의 이중화로 인한 오버헤드를 줄이기 위한 기법

앞서 설명한 것처럼 VIA 기반의 병렬 라이브러리 구현에서 메시지를 전

달하기 위해서는 먼저 제어 채널을 통한 제어 정보 교환이 이루어져야 한다.

이는 메시지 전달 시 사전 정보 전달 단계를 반드시 거치도록 강요함으로

해서 적지 않은 오버헤드로 작용한다. 특히 크기가 작은 메시지를 전달할 경

우에 실제 메시지 전달에 소요되는 시간에 비해 제어 정보 전달을 위해 소

요되는 시간이 상대적으로 크기 때문에 전체적인 지연 시간을 증가시킬 수

있다. 이러한 문제점을 해결하기 위한 방법의 하나로 현재 VIA 기반의 병렬

라이브러리 구현에서는 작은 크기의 메시지에 대해서 제어 채널을 통해 메

시지를 제어 정보와 함께 보내도록 하였다. 현재 4KB 이하의 메시지에 대해

서는 송신 디스크립터에 제어 정보와 메시지를 함께 실어 포스팅하고, 수신

자 측에서는 항상 제어 정보와 4KB의 메시지를 받아들일 수 있는 버퍼를

포스팅하여 4KB 이하의 메시지에 대해서는 별도의 데이터 채널을 통한 메

시지 교환 없이 직접 제어 채널을 통해 수신한다. 이와 같은 방식은 앞서 2

27

장의 MPI에서 설명한 네 가지 통신 모드 중 준비 모드와 같은 방식이라 할

수 있다.

(가) 4KB 이하인 경우 (나) 4KB 이상인 경우

그림 3.3 데이터 크기에 따른 통신 메커니즘

제어 채널과 데이터 채널을 통해 두 단계에 걸쳐 메시지를 전달할 경우

수신자 측의 데이터 수신을 위한 디스크립터의 사전 포스팅을 보장하기 위

해 송신자 측이 ACK 메시지를 기다리는 것은 필수적인 일이다. 그러나 제

어 채널을 통해 데이터를 함께 보내는 경우 송신자가 ACK 메시지를 받기

위해 기다리는 것은 송신자 측의 다음 연산의 수행을 지연시켜는 결과를 가

져온다. 그러나 ACK 메시지를 기다리지 않을 경우 제어 메시지를 받아들이

기 위한 디스크립터의 사전 포스팅을 보장하지 못함으로 해서 앞서 언급한

항상 두 개의 디스크립터만 미리 포스팅하면 된다는 제약 조건을 만족할 수

없다. VIA 기반의 병렬 라이브러리 구현에서는 ACK 메시지 대기로 인한

오버헤드를 줄이고, 디스크립터의 사전 포스팅에 대한 제약 조건을 만족시키

기 위해 미리 포스팅하는 디스크립터의 수를 늘렸다. 송신자는 REQUEST

송신 후 바로 이에 대한 ACK를 기다리는 것이 아니라 연속적으로 두 개의

REQUEST 를 송신할 수 있도록 하였으며, 세 번째 REQUEST를 송신하기

전에 첫 번째 REQUEST 에 대한 ACK를 기다리게 하였다. 이렇게 함으로써

28

송신자는 ACK를 기다리는 시간 없이 다음 연산을 수행할 수 있으며, 다음

연산 수행 시간 동안에 이전 REQUEST 에 대한 ACK가 도달할 수 있는 충

분한 시간을 제공하게 되어 ACK 메시지를 위해 대기하는 시간을 단축시켰

다. 이 경우 연속적인 두 개의 REQUEST 가 동시에 수신될 수 있으며, 이러

한 REQUEST에 대한 두 개의 ACK가 동시에 수신될 수 있으므로 전체적으

로 볼 때 최대 네 개의 제어 메시지가 동시에 수신될 수 있다. 따라서 항상

네 개의 제어 메시지를 위한 디스크립터가 미리 포스팅되는 것을 보장함으

로써 모든 제어 메시지를 수용할 수 있다.

(가) 두 개를 포스팅할 경우 (나) 네 개를 포스팅할 경우

그림 3.4 제어 메시지 수신을 위한 사전 포스팅 수

3.2 VIA 기반의 MPI 라이브러리(VMPI) 구현

우선 VIA 기반의 병렬 라이브러리를 구현하기 위해 메시지 전달 방식의

다중 컴퓨터 시스템에서 가장 널리 사용되는 MPI 라이브러리를 구현하였다.

VIA 기반의 MPI 구현은 실제 MPI의 표준 명세에 정의된 여러 함수들

중에서 병렬 프로그래밍을 하는데 가장 기본적인 각 노드 간의 일대일 통신

29

에 필요한 일부 함수와 대표적인 집합 통신을 위한 함수에 국한되어 있다.

현재 구현된 함수를 보면 표 3.1과 같다.

표 3.1 VIA 기반 MPI 라이브러리의 구현 함수

종 류 VIA 기반 MPI의 구현 함수

초기화

int MPI_Init(int *argc, char ***argv)

int MPI_Comm_rank(MPI_Comm comm, int *rank)

int MPI_Comm_size(MPI_Comm comm, int *s ize)

종료 int MPI_Finalize(void)

Blocking

연산

int MPI_Send(void *buf, int count, MPI_Datatype datatype,

int dest, int tag, MPI_Comm comm)

int MPI_Recv(void *buf, int count, MPI_Datatype datatype,

int src, int tag , MPI_Comm comm, MPI_Status *s tatus)

Nonblocking

연산

int MPI_Isend(void *buf, int count, MPI_Datatype datatype,

int dest, int tag, MPI_Comm comm, MPI_Request *request)

int MPI_Irecv(void *buf, int count, MPI_Datatype datatype,

int src, int tag , MPI_Comm comm, MPI_Reques t *request)

int MPI_Wait(MPI_Request *request, MPI_Status *status)

int MPI_T es t(MPI_Request *request, int *flag ,

MPI_Status *status)

int MPI_Iprobe(int src, int tag MPI_Comm comm, int *flag ,

MPI_Status *status)

집합 통신int MPI_Bcast(void *buf, int count, MPI_Datatype datatype,

int root, MPI_Comm comm)

기타

int MPI_Get_count(MPI_Status *s tatus , MPI_Datatype datatype,

int *count)

double MPI_Wtime(void)

3.2.1 VIA 기반 MPI 라이브러리의 구현 함수

실제로 VIA의 기반 위에서 MPI의 각 함수들이 어떻게 구현되었고, 어떻

30

게 동작하는지를 살펴보도록 하겠다.

(1) int MPI_Init(int *argc, char ***argv)

SPMD 방식의 병렬 처리 작업을 수행하기 위한 환경을 초기화하는 함수

로 먼저 프로그램 수행 시 넘어온 인자를 분석한다. VIA 기반의 MPI에서

병렬 프로그램을 수행하기 위해서는 프로그램을 실행시킬 노드의 호스트 이

름과 각각의 VIA 디바이스 이름 및 실행 파일의 경로명 등을 표시하는 별

도의 환경 설정 파일이 필요하다. MPI_Init() 함수는 프로그램 수행 시 지정

된 이 환경 설정 파일을 읽어 별도의 자료 구조에 저장한 뒤 이 정보를 바

탕으로 rsh 명령에 의해 자식 노드의 프로그램을 실행시킨다. 각 노드는 병

렬 작업에 참여할 노드 수만큼의 제어 채널과 데이터 채널로 이용할 VI를

생성하고, 제어 채널을 통한 제어 메시지 수신을 위해 네 개의 디스크립터를

미리 포스팅한다. 제어 메시지 수신을 위한 디스크립터가 하나 포스팅될 때

마다 VipCQNotify() 함수가 호출되며, 최초 호출 시 제어 채널로 들어오는

제어 메시지를 처리하기 위한 쓰레드가 생성되고, 이후에는 핸들러 큐에 핸

들러 함수에 대한 포인터만을 삽입한다. 사용자가 프로그램을 실행시킨 부모

노드는 환경 설정 파일의 정보에 의해 자식 노드로부터의 연결 요청이 들어

오기를 기다리고, 자식 노드는 부모 노드에 대해 연결을 요청한다. 연결이

이루어지면 부모 노드로부터 병렬 작업에 참여하는 각 노드들의 정보가 담

긴 환경 설정 파일에 대한 자료 구조를 전송 받아 자식 노드 간의 연결을

설정함으로써 초기화 작업이 끝난다.

(2) int MPI_Comm_rank(MPI_Comm comm, int *rank)

31

MPI에서는 각 노드가 서로를 식별하기 위해 랭크(Rank)라고 하는 별도

의 번호를 갖는다. 사용자의 직접적인 명령에 의해 실행된 부모 노드의 프로

세스는 0번의 랭크 번호를 가지며 그 외의 자식 노드의 프로세스들은 환경

설정 파일에 지정된 번호를 부여받는다. 이 번호는 MPI_Init() 함수 수행 시

별도의 전역 변수에 기록되며, MPI_Comm_rank() 함수는 이 전역 변수의

값을 반환한다. 이 함수에서 인자로 넘어온 comm은 MPI에서 병렬 작업에

참여하는 프로세스들의 집합을 정의하는 커뮤니케이터(Communicator)와 그

룹(Group)을 지정하는 객체로써 현재 VIA 기반의 MPI에서는

MPI_COMM_WORLD라는 전역적인 하나의 커뮤니케이터만을 지원한다.

(3) int MPI_Comm_size(MPI_Comm comm, int *size)

현재 병렬 처리 작업에 참여하는 프로세스의 개수를 반환하는 함수로 이

값 역시 MPI_Init() 함수 수행 시 별도의 전역 변수에 기록되며, 이 전역 변

수의 값을 읽어 반환한다.

(4) int MPI_Finalize(void)

병렬 작업의 끝을 명시하는 함수로 병렬 처리 작업을 위해 각 노드 간에

설정된 연결을 끊고 생성된 VI를 제거한다. 제어 메시지를 위해 미리 포스

팅된 네 개의 디스크립터는 소비되지 않고 남아있는 상태이기 때문에 이 경

우 정상적으로 VI가 제거되지 않는다. 이를 위해 먼저 각 노드는 네 개의

더미(Dummy) 메시지를 송수신하여 미리 포스팅된 네 개의 디스크립터를

소비한 후 VI를 제거한다.

32

(5) int MPI_Send(void *buf, int count, MPI_Datatype datatype,

int dest, int tag, MPI_Comm comm)

먼저 4KB 이하의 데이터를 전송하는 경우를 살펴보면, REQUEST 메시

지와 함께 전송하려는 데이터를 실어 보내기 전에 전전 단계에서 보낸

REQUEST 가 있었다면 이 REQUEST 에 대한 ACK 메시지가 도착했는지를

검사하고, 도착하지 않았다면 도착할 때까지 기다린다. 이후 제어 채널을 통

해 제어 정보와 데이터가 저장된 디스크립터를 포스팅하고, 그 데이터가 네

트웍 인터페이스 카드를 통해 전송될 때까지 기다린다. 이는 MPI_Send() 함

수가 Blocking Send를 지원하기 때문이며, VIA가 제공하는 VipSendWait()

함수를 호출함으로써 수행된다. VipSendWait() 함수는 포스팅된 디스크립터

가 네트웍 인터페이스 카드를 통해 전송되었는지를 검사하여 전송이 완료되

면 송신 큐로부터 해당 디스크립터를 제거하여 반환하는 역할을 수행한다.

4KB보다 큰 데이터를 전송하는 경우에는 먼저 전전 단계에서 보낸

REQUEST 에 대한 ACK 메시지를 기다린 후, 제어 채널을 통해 이후에 보

낼 데이터의 크기와 데이터 타입 및 태그 등을 명시하는 REQUEST 메시지

를 전송한 후 이에 대한 ACK 메시지가 올 때까지 기다린다. 송신자가 보낸

REQUEST 를 받은 수신자는 이 REQUEST에 저장된 제어 정보를 바탕으로,

송신자가 보낼 데이터를 저장할 메모리 영역을 지정하는 디스크립터를 포스

팅한 뒤 송신자에게 ACK 메시지를 보낸다. ACK 메시지를 받은 송신자는

대기하던 상태에서 깨어나 실제 데이터를 보낸 후 VipSendWait() 함수를 호

출하여 데이터가 전송되었음을 보장받은 후 MPI_Send() 연산을 마치게 된

다.

33

(6) int MPI_Recv(void *buf, int count, MPI_Datatype datatype,

int src, int tag, MPI_Comm comm, MPI_Status *status)

MPI_Recv() 함수는 이 함수가 호출될 당시 상대 노드로부터 REQUEST

메시지가 도착했는 지의 여부에 따라 두 가지 방식으로 동작한다. 먼저

MPI_Recv() 함수가 호출됐을 때 아직 REQUEST 메시지가 도착하지 않은

경우에는 상대 노드로부터 전송되어 오는 데이터를 받아들일 buf 영역에 대

한 메모리 주소를 미리 알고 있는 상태이기 때문에 이 영역을 통해 들어오

는 데이터를 별도의 버퍼링 없이 바로 받으면 된다. MPI_Recv() 함수는

Blocking Receive 연산이므로 데이터를 받아들일 buf를 별도의 큐에 삽입한

후 상대 노드로부터 데이터가 들어올 때까지 대기 상태에 있게 된다.

이 경우에도 전송되어 오는 데이터의 크기에 따라 두 가지 형태로 나뉘

는데 4KB 이하의 데이터일 경우에는 제어 채널을 통해 미리 포스팅된 디스

크립터의 지정된 영역에 데이터가 들어오는데, 이 데이터를 큐에 있는 buf

영역에 복사한 후 상대 노드에게 ACK 메시지를 보낸 다음 대기하고 있는

MPI_Recv() 함수를 깨움으로써 모든 연산이 끝난다. 4KB보다 큰 데이터일

경우에는 제어 채널을 통해 REQUEST 메시지를 받은 후 buf 영역을 디스

크립터에 지정하여 포스팅한 후 송신자에게 ACK 메시지를 보낸 다음 대기

하고 있는 MPI_Recv() 함수를 깨운다. MPI_Recv()는 포스팅된 디스크립터

의 buf 영역으로 데이터가 들어올 때까지 기다린 후 연산을 끝마치게 된다.

이 때 포스팅된 디스크립터의 해당 영역에 메시지가 도착할 때까지 기다리

기 위해서 VIA에서 제공하는 VipRecvWait() 함수를 이용한다. 이 함수는

포스팅된 디스크립터의 상태 비트를 검사하여 지정된 영역에 메시지가 도착

했다는 상태 비트가 표시되면 해당 디스크립터를 수신 큐로부터 제거하여

반환한다.

34

MPI_Recv() 함수가 호출되기 이전에 상대 노드로부터 REQUEST 메시

지가 먼저 도착했을 경우에는 아직 데이터를 저장할 목적지 주소를 알지 못

하므로 임시 영역을 지정하여 버퍼링을 해야 한다. 4KB 이하의 데이터일 경

우에는 제어 채널을 통해 들어온 데이터를 임시 영역에 복사하고 이 영역을

별도의 큐에 삽입한 후 상대 노드에게 ACK 메시지를 보낸다. 4KB보다 큰

데이터일 경우에는 데이터를 받기 위한 임시 영역을 지정하여 포스팅하고

이 영역을 별도의 큐에 삽입한 후 상대 노드에게 ACK 메시지를 보낸다. 이

후 MPI_Recv() 함수가 호출되면 4KB 이하의 데이터일 경우에는 큐에 있는

임시 영역에 저장된 데이터를 바로 자신의 buf 영역에 복사하고, 4KB보다

큰 데이터일 경우에는 VipRecvWait() 함수를 호출하여 지정된 임시 영역으

로 데이터가 전송되기를 기다린 후 전송이 완료되면 자신의 buf 영역에 복

사한다.

(7) int MPI_Isend(void *buf, int count, MPI_Datatype datatype,

int dest, int tag, MPI_Comm comm, MPI_Request *request)

MPI_Isend()는 Nonblocking Send 연산으로서 기본적인 동작은

MPI_Send() 함수와 동일하며, 단지 데이터를 전송한 후 마지막에

VipSendWait() 함수를 호출하지 않는다는 점만 다르다. 즉 MPI_Isend()는

보내려는 데이터가 네트웍 인터페이스 카드를 통해 전송되었는 지의 여부를

보장하지 않은 채 현재 MPI_Isend() 함수에 의해 포스팅된 디스크립터에 대

한 정보를 별도의 큐에 삽입하고 연산을 마친다.

35

(8) int MPI_Irecv(void *buf, int count, MPI_Datatype datatype,

int src, int tag, MPI_Comm comm, MPI_Reques t *request)

MPI_Irecv()는 Nonblocking Receive 연산으로 MPI_Irecv() 함수의 호출

당시 이미 상대 노드로부터 전송된 데이터가 있으면 해당 데이터를 자신의

buf 영역에 복사하고, 없으면 데이터를 받아들일 자신의 buf 영역에 대한 정

보를 별도의 큐에 삽입한 뒤 연산을 끝마친다.

(9) int MPI_Wait(MPI_Reques t *reques t, MPI_Status *status)

MPI_Isend() 또는 MPI_Irecv()에 의해 별도의 큐에 삽입된 정보를 이용

하여 각각의 함수가 데이터의 송신 또는 수신을 위해 포스팅한 디스크립터

의 상태가 완료되기를 기다린다. 이 동작 역시 VipSendWait() 또는

VipRecvWait() 함수에 의해 수행된다.

(10) int MPI_T es t(MPI_Reques t *reques t, int *flag,

MPI_Status *status)

MPI_Wait() 함수와 유사하며, 디스크립터의 상태가 완료되기를 기다리는

것이 아니라 MPI_T est() 함수의 호출 당시 디스크립터의 상태를 검사하여

완료 여부만을 flag에 설정하여 반환한다.

(11) int MPI_Iprobe(int s rc, int tag MPI_Comm comm,

int *flag, MPI_Status *status)

36

MPI_Iprobe() 함수의 호출 당시 이미 상대 노드로부터 전송된 데이터가

있는지의 여부만을 검사하여 flag를 설정한 뒤 반환한다.

(12) int MPI_Get_count(MPI_Status *status, MPI_Datatype datatype,

int *count)

MPI_Get_count() 함수는 자신이 어떤 타입의 데이터를 몇 개 받았는지에

대한 정보를 반환해 주는 함수로 MPI_Recv(), MPI_Wait(), MPI_T est() 등

의 함수를 통해 반환된 status 내의 정보를 읽어 그 값을 알아낸다.

(13) double MPI_Wtime(void)

이 함수는 MPI_Wtime() 함수가 호출될 시점의 시간을 us 단위의 정밀도

로 계산하여 반환한다.

3.3 VIA 기반의 BS P 라이브러리(VBS Plib) 구현

3.3.1 VIA 기반 BS P의 구현 원리

VIA 기반 BSP의 기본적인 구현 원리는 VIA 기반 MPI의 구현 원리와

같다. 제어 채널과 데이터 채널을 분리하여 데이터 전달 시 이에 대한 제어

정보를 먼저 전달함으로써 수신 디스크립터의 사전 포스팅을 보장하였다. 또

한 이로 인한 작은 메시지 전달의 오버헤드를 줄이기 위해 bsp_put()과

37

bsp_send() 함수의 경우 4KB 이하의 메시지에 대해서는 제어 채널을 통해

제어 정보와 데이터를 함께 전송하도록 하였다.

표 2.2 VIA 기반 BSP 라이브러리의 구현 함수

종 류 VIA 기반 BSP의 구현 함수

수행 제어

void bsp_begin(int maxprocs)

void bsp_end(void)

void bsp_init(void (*spmdproc)(void), int argc, char **argv)

수행 인자

질의

int bsp_nprocs(void)

int bsp_pid(void)

double bsp_time(void)

동기화 void bsp_sync(void)

DRMA

void bsp_push_reg(cons t void *ident, int s ize)

void bsp_pop_reg(const void *ident)

void bsp_put(int pid, const void *src, void *dst, int offset,

int nbytes)

void bsp_get(int pid, cons t void *src, int offset, void *dst,

int nbytes)

void bsp_hpput(int pid, cons t void *src, void *dst, int offset,

int nbytes)

BSMP

void bsp_set_tagsize(int *tag_nbytes )

void bsp_send(int pid, const void *tag, cons t void *payload,

int payload_nbytes)

void bsp_qsize(int *nmessages , int *accum_nbytes)

void bsp_get_tag(int *status , void *tag)

void bsp_move(void *payload, int reception_nbytes)

void bsp_hpmove(void **tag_ptr, void **payload_ptr)

또한 VIA 기반 BSP에서는 BSPlib에서 사용하고 있는 컴바이닝

(Combining)이라는 기법을 도입하여, 하나의 수퍼스텝 내에서 동일한 노드

에 4KB 미만의 메시지를 연속적으로 전송할 경우 이 메시지를 합쳐서 하나

38

의 패킷으로 보내도록 하였다. 컴바이닝 기법은 bsp_put()과 bsp_send() 함

수에만 적용되며, 이 함수의 인자로 4KB 미만의 메시지가 넘어올 경우 우선

임시 공간에 저장한다. 동일한 노드에 대한 다음 bsp_put()이나 bsp_send()

함수가 호출될 경우 임시 공간에 저장된 메시지의 크기와 인자로 넘어온 메

시지의 크기의 합이 4KB보다 큰지를 검사하여 클 경우 현재 임시 공간에

저장된 메시지를 전송하고, 그렇지 않을 경우에는 임시 공간에 새로운 메시

지를 합친다. 현 수퍼스텝의 마지막에 도달했을 때 아직 임시 공간에 메시지

가 남아 있으면 이를 전송함으로써 모든 컴바이닝된 메시지에 대한 전송을

끝낸다.

표 3.2는 VIA 기반 BSP 라이브러리의 구현 함수들로써 BSPlib에서 제공

되는 기본 함수 중에 bsp_hpget() 함수만이 VIA의 특성으로 인한 구현 상의

어려움으로 포함되지 않았다.

3.3.2 VIA 기반 BS P 라이브러리의 구현 함수

(1) void bsp_init(void (*spmdproc)(void), int argc, char **argv)

프로그램이 수행되는 각 노드의 프로세스 ID 및 전체 노드의 수 등을 초

기화하는 함수로 사용자가 프로그램을 수행하는 노드의 프로세스는 0번의

ID가 주어진다. 프로세스 ID가 0번인 프로세스는 병렬 처리 작업을 수행할

호스트들의 정보를 명시하는 bsphosts 파일을 읽어 해당 자료 구조에 저장

하게 되며, 프로세스 ID가 0번이 아닌 프로세스는 rsh에 의해 프로그램 수행

시 넘어온 인자에 의해 자신의 프로세스 ID 및 전체 노드의 수, 프로세스

39

ID가 0번인 부모 노드의 호스트 이름 등을 알아낸다.

(2) void bsp_begin(int maxprocs)

병렬적으로 수행되는 코드의 시작 부분을 명시하는 함수로 프로세스 ID

가 0번인 부모 노드일 경우 bsp_init() 함수를 통해 저장된 병렬 처리 작업을

수행할 호스트들에 대한 정보를 바탕으로 rsh에 의해 자식 노드의 프로그램

을 실행시킨다. 또한 제어 채널과 데이터 채널을 위해 각 노드 별로 VI를

생성하고, 제어 채널을 통한 제어 메시지 수신을 위해 네 개의 디스크립터를

미리 포스팅한 후 자식 노드들의 해당 VI를 통한 연결 요청을 기다린다. 자

식 노드 역시 제어 채널과 데이터 채널을 위한 VI의 생성 및 네 개의 제어

메시지 수신을 위한 디스크립터를 포스팅한 후 부모 노드에게 연결을 요청

한다. 이렇게 하여 부모 노드와 자식 노드 간에 연결이 설정되면 부모 노드

는 병렬 처리 작업을 수행할 호스트들에 대한 정보를 자식 노드들에게 송신

하고, 이를 수신한 자식 노드는 이 정보를 바탕으로 자식 노드들 간의 연결

을 설정한다. bsp_begin() 함수의 마지막에는 bsp_time() 함수의 요청에 의

한 병렬 처리 작업의 수행 시간을 알려주기 위해 현재의 시간을 전역 변수

에 기록한다.

(3) void bsp_end(void)

병렬 작업의 끝을 명시하는 함수로 MPI_Finalize() 함수와 동일한 동작을

수행한다. 먼저 병렬 처리 작업을 위해 각 노드 간에 설정된 연결을 끊고 생

성된 VI를 제거한다. 제어 메시지를 위해 미리 포스팅된 네 개의 디스크립

터는 소비되지 않고 남아있는 상태이기 때문에 이 경우 정상적으로 VI가 제

거되지 않는다. 이를 위해 먼저 각 노드는 네 개의 더미(Dummy) 메시지를

40

송수신하여 미리 포스팅된 네 개의 디스크립터를 소비한 후 VI를 제거한다.

(4) int bsp_nprocs(void)

bsp_begin() 함수가 수행되기 전에 호출되었을 경우 bsp_init() 함수에서

지정된 정보를 통해 사용자가 명시한 병렬 처리 작업에 참여할 전체 노드의

수를 반환하며, bsp_begin() 함수 호출 후에는 bsp_begin() 함수의 인자로

넘어온 값에 의해 현재 병렬 처리 작업에 참여하는 노드의 수를 반환한다.

(5) int bsp_pid(void)

bsp_init() 함수에서 지정된 정보를 통해 병렬 처리 작업이 수행되는 현재

프로세스 자신의 프로세스 ID를 반환한다.

(6) double bsp_time(void)

이 함수는 bsp_begin() 함수의 수행 이후 이 함수가 호출 때까지의 경과

시간을 초단위로 반환하는 함수로 현재 시간에서 bsp_begin() 함수의 마지막

에 기록된 시간을 뺌으로써 계산한다.

(7) void bsp_push_reg(cons t void *ident, int s ize)

bsp_put()이나 bsp_get() 함수에 의해 사용되어질 원격 메모리에 대한 접

근을 위해 전역적으로 호출되어 해당 메모리 영역에 대한 주소 및 일련 번

호를 테이블에 저장하는 함수로 잦은 메모리 등록 시 테이블을 위한 메모리

41

공간을 효율적으로 관리하기 위해 동적인 할당 기법을 사용한다. 처음 고정

된 크기의 메모리 등록을 위한 테이블을 할당하고, 해당 크기의 테이블을 초

과하는 메모리 등록 요청 시 동일한 크기의 새로운 테이블을 할당받는다. 또

한 특정의 등록된 메모리에 대한 일련 번호의 질의 시 전체 테이블을 찾아

야 하는 오버헤드를 줄이기 위해 가장 최근에 등록된 메모리 영역에 대해서

는 별도의 캐쉬 테이블에 저장한다.

(8) void bsp_pop_reg(cons t void *ident)

등록된 메모리 영역을 해제하는 함수로 해당하는 메모리 주소가 저장된

테이블의 엔트리의 유효 비트를 INVALID로 설정함으로써 끝난다.

(9) void bsp_put(int pid, const void *src, void *dst, int offset,

int nbytes)

먼저 전전 단계에서 데이터의 송신을 위해 요청한 REQUEST 메시지에

대한 ACK 메시지가 수신되었는지를 검사한다. 데이터의 크기가 4KB 미만

일 경우에는 먼저 컴바이닝을 위한 임시 공간에 저장된 데이터의 크기와 현

재 인자로 넘어온 데이터의 크기의 합이 4KB보다 큰지를 검사한다. 클 경우

에는 임시 공간의 데이터를 전송하고, 현재의 데이터를 임시 공간에 새로 저

장한다. 만약 크지 않을 경우에는 단지 임시 공간에 현재의 데이터를 합쳐서

저장한 후 연산을 끝마친다. bsp_put()에 대한 요청을 받은 수신자 측은 제

어 채널을 통해 받은 메시지를 임시 영역에 저장하고, 함께 전송된 제어 정

보를 별도의 제어 큐에 저장한다. 또한 제어 메시지를 위한 디스크립터를 보

42

충하기 위해 하나를 새로 포스팅한 후 송신자 측에 ACK 메시지를 보낸다.

데이터의 크기가 4KB 이상일 경우에는 먼저 전송할 데이터의 크기 등을 명

시하는 제어 정보를 제어 채널을 통해 송신한 후 ACK 메시지를 기다린다.

수신자 측은 제어 채널을 통해 받은 제어 정보를 제어 큐에 저장하고, 제어

메시지를 위한 디스크립터와 데이터를 받기 위한 임시 영역을 지정하는 디

스크립터를 포스팅한 후 송신자 측에 ACK 메시지를 보낸다. 이 ACK 메시

지를 받은 송신자는 실제 데이터를 수신자에게 전송함으로써 모든 연산을

끝마친다. 수신된 데이터의 목적지 주소로의 복사는 제어 큐에 저장된 제어

정보를 바탕으로 bsp_sync() 함수에 의해 이루어진다.

(10) void bsp_get(int pid, cons t void *src, int offset, void *dst,

int nbytes)

bsp_get() 함수는 원격 메모리 영역의 데이터를 읽어오는 함수로

bsp_sync() 함수의 수행에 의해 현 수퍼스텝의 모든 지역적인 계산이 끝났

다는 것이 보장된 이후의 데이터를 읽어와야 한다. 따라서 bsp_get() 함수는

단지 별도의 큐에 bsp_get()에 대한 요청이 있었음을 표시하는 정보를 저장

하는 것으로 모든 연산이 끝난다. bsp_sync() 함수는 이 큐에 저장된 정보를

바탕으로 원격 메모리 영역의 데이터를 읽어온다.

(11) void bsp_hpput(int pid, cons t void *src, void *ds t, int offset,

int nbytes)

bsp_hpput() 함수는 데이터를 쓸 원격 메모리의 영역이 해당 수퍼스텝

43

내에서 변경되지 않는다는 것이 보장될 때, bsp_hpput() 함수 수행 시 바로

데이터를 원격 메모리 영역에 씀으로써 데이터의 임시 버퍼링을 줄여 성능

을 높인다. 기본적인 동작은 bsp_put()과 같으며, 단지 수신된 데이터가 임시

영역에 저장된 후 bsp_sync() 함수를 통해 목적지 주소로 복사되는 것이 아

니라 바로 목적지 주소에 저장된다.

(12) void bsp_set_tagsize(int *tag_nbytes)

bsp_send() 함수에 의해 전송될 태그의 길이를 설정하는 함수로 해당하

는 전역 변수에 인자로 넘어온 태그의 길이를 저장한다.

(13) void bsp_send(int pid, cons t void *tag, const void *payload,

int payload_nbytes)

bsp_send() 함수의 기본 동작은 bsp_put() 함수와 유사하며, bsp_send()

함수의 경우 별도의 태그 정보를 데이터와 함께 전송할 수 있다. 수신된 태

그와 데이터는 bsp_sync() 함수를 통해 별도의 메시지 큐에 저장되어 이후

bsp_move()나 bsp_hpmove() 함수에 의해 사용되어진다.

(14) void bsp_qsize(int *nmessages, int *accum_nbytes )

bsp_send() 함수에 의해 전송된 메시지로서 현재 메시지 큐에 저장된 전

체 메시지의 수와 크기를 반환한다.

44

(15) void bsp_get_tag(int *status, void *tag)

메시지 큐에 저장된 태그를 반환하는 함수로 메시지 큐에 메시지가 없을

경우에는 status에 - 1을 반환하고, 그렇지 않을 경우에는 메시지 큐의 가장

앞에 저장된 메시지의 길이를 반환한다.

(16) void bsp_move(void *payload, int reception_nbytes)

메시지 큐의 가장 앞에 저장된 메시지를 payload 영역으로 복사한다.

(17) void bsp_hpmove(void **tag_ptr, void **payload_ptr)

bsp_move() 함수가 메시지 큐로부터 메시지를 복사하는 오버헤드를 줄이

기 위해 메시지 큐의 가장 앞에 저장된 태그 및 메시지의 메모리 영역에 대

한 포인터를 반환한다.

(18) void bsp_sync(void)

bsp_sync() 함수는 먼저 컴바이닝을 위한 임시 공간에 아직 전송되지 않

은 데이터가 있는지를 검사하여 있을 경우 이를 전송한다. 이후 전역적인 동

기화를 이루기 위해 각 노드에 제어 채널을 통해 SYNC 메시지를 보낸 후

다른 노드들로부터 SYNC 메시지가 들어오기를 기다린다. SYNC 메시지를

보낼 때 현 수퍼스텝에서 자신이 해당 노드에 대해 bsp_get() 함수를 호출한

적이 있다면 bsp_get() 함수의 호출 회수를 SYNC 메시지에 함께 실어 보낸

다. 이는 bsp_get()에 대한 요청이 끝나기 이전에 bsp_put()에 대한 요청을

45

처리하거나 현 수퍼스텝을 끝내는 일이 없도록 보장하기 위한 것으로,

bsp_get()에 대한 요청을 처리할 때마다 전송된 상대 노드의 bsp_get() 호출

회수를 감소시켜 상대 노드의 bsp_get()에 의한 요청이 모두 끝났는지를 확

인한다. bsp_get()에 대한 요청을 먼저 처리하도록 하는 이유는 동일한 원격

메모리 영역에 대해 bsp_put()과 bsp_get()이 이루어졌을 때, bsp_get()에 의

한 원격 메모리 영역의 데이터에 대한 읽기를 먼저 수행한 후 자신의 데이

터를 동일한 원격 메모리 영역에 쓰도록 하는 의미 있는 동작을 보장하기

위해서이다. 동기화가 이루어지면 현 수퍼스텝에서 수행된 bsp_get()에 대한

요청을 먼저 처리하게 되는데 앞서 설명한 대로 bsp_get() 함수 수행 시 별

도의 큐에 저장된 정보를 이용한다. bsp_get()은 수신자가 이 함수를 호출한

자신이므로 먼저 데이터를 수신할 목적지 주소를 지정하는 디스크립터를 포

스팅한 후 해당 노드에 REQUEST 메시지를 보낸다. REQUEST 메시지를

받은 수신자는 이전에 수신한 bsp_get() 호출 회수를 하나 감소시킨 뒤 요청

된 메모리 영역에 대한 데이터를 송신하고 REQUEST 에 대한 ACK 메시지

를 보낸다. 자신의 bsp_get() 호출에 대한 처리가 모두 끝나면 상대 노드의

bsp_get() 호출에 의한 요청이 모두 끝날 때까지 기다린 후 bsp_put()과

bsp_send()에 대한 요청을 처리한다. 이 단계에서는 bsp_put()과 bsp_send()

에 대한 REQUEST 메시지 수신 시 구성된 제어 큐로부터 저장된 정보를

꺼내어 bsp_put()에 의한 요청이었으면 임시 영역에 저장된 데이터를 해당

목적지 주소로 복사하고, bsp_send()에 의한 요청이었으면 메시지 큐에 삽입

한다. 마지막으로 수퍼스텝 번호를 하나 증가시킴으로써 bsp_sync() 함수를

끝마치고 다음 수퍼스텝을 진행한다.

46

제 4 장 성능 평가

우리는 각각 64MB와 128MB의 메모리를 가진 Pentium Pro 200MHz 컴

퓨터 두 대와 64MB의 메모리를 가진 Pentium Celeron 433MHz 컴퓨터 두

대를 100Mbps의 스위칭 허브를 이용하여 연결하였다. 네트웍 인터페이스 카

드는 M- VIA에서 지원하는 DEC의 T ulip 칩셋을 가진 카드를 사용하였다.

각각의 컴퓨터에는 LINUX 배포판 중에 하나인 커널 버전 2.2.5 기반의

RedHat 6.0을 설치하였으며, 그 위에 M- VIA 1.0을 설치하여 기본적인 클러

스터 환경을 구성하였다.

이상과 같은 클러스터 환경에서 구현된 VIA 기반의 MPI와 BSP 라이브

러리인 VMPI와 VBSPlib의 성능을 분석하기 위한 대상으로, 가장 널리 알려

진 MPI 라이브러리인 MPICH 1.1.2 버전과 BSPlib 1.41 버전을 설치하였다.

MPICH는 T CP/ IP 기반 위에서 동작하며, BSPlib은 LINUX 시스템에서

T CP/ IP 버전이 동작하지 않는 관계로 UDP/ IP 버전을 설치하였다. BSPlib과

관련된 논문에 보면 BSPlib의 UDP/ IP 버전이 T CP/ IP 버전에 비해 성능이

좋은 것으로 나타나 있다[18].

먼저 VMPI와 VBSPlib의 기본적인 성능 분석을 위해 각각의 메시지 크

기에 따른 지연 시간과 대역폭을 측정하여 기존의 MPICH와 BSPlib의 그것

과 비교해 보았다.

그림 4.1은 VMPI와 T CP/ IP 기반의 MPICH의 지연 시간을 비교한 것이

다. 이는 Pentium Celeron 컴퓨터 두 대에서 MPI_Send()와 MPI_Recv() 함

수로 이루어지는 핑퐁 프로그램을 수행하여 전체 걸린 시간을 2로 나눈 값

으로, 메시지 크기에 따라 각각을 100번 반복 수행하여 평균을 낸 것이다.

47

그림에서 보는 바와 같이 VMPI가 MPICH에 비해 큰 성능 향상은 보이지

않았으나 대체로 작게는 6us에서 크게는 266us까지 VMPI가 더 작은 지연

시간을 보였다. 특히 VMPI 경우 메시지 크기가 8KB 이후부터 크기가 커질

수록 MPICH 비해 상대적으로 더 낮은 지연 시간을 보였다.

그림 4.2는 VBSPlib과 UDP/IP 기반의 BSPlib의 지연 시간을 측정한 것

으로 역시 두 대의 Pentium Celeron 컴퓨터에서 수행하였다. 먼저 한 쪽 노

드에서 각각 bsp_put(), bsp_get(), bsp_send()를 이용하여 지정된 크기의 메

시지를 전송한 후 bsp_sync()를 수행하여 상대 노드에게 이 연산에 대한 결

과를 반영시킨 뒤 다시 bsp_sync()를 수행하여 두 노드 간의 모든 메시지

교환이 완료되었음을 보장하게 함으로써 이 때 걸린 총 시간을 측정하였다.

그림에서 보는 바와 같이 VBSPlib이 BSPlib에 비해 좋은 결과를 나타냈다.

MPI 라이브러리에 비해 VBSPlib과 BSPlib의 지연 시간이 현저하게 차이가

나는 이유는 VIA가 BSP의 구조에 더 적합하다는 점을 들 수 있다. 실례로

VBSPlib과 BSPlib의 bsp_sync() 수행에 걸리는 시간은 대략 110us와 290us

로 큰 차이를 보였다.

48

그림 4.1 VMPI와 MPICH의 지연 시간 비교

그림 4.2 VBSPlib과 BSPlib의 지연 시간 비교

49

표 3.1 VMPI와 VBSPlib의 지연 시간

메시지

크기

(bytes)

지연 시간(us)

MPI 라이브러리 BSP 라이브러리

VMPI MPICHVBSPlib BSPlib

bsp_put bsp_get bsp_send bsp_put bsp_get bsp_send

32 93 132 214 228 214 593 501 590

64 99 133 216 231 217 595 504 591

128 111 136 221 239 220 601 512 605

256 134 140 236 256 235 632 544 623

512 176 182 272 298 280 670 602 653

1K 263 271 357 387 359 746 685 762

2K 386 403 480 506 476 883 825 903

4K 570 590 673 683 667 1054 1033 1082

8K 972 981 1127 1055 1108 1442 1421 1377

16K 1665 1707 1845 1776 1815 2148 2224 2129

32K 3062 3328 3346 3245 3231 3694 3885 3716

그림 4.3은 VMPI와 MPICH의 대역폭을 측정하여 비교한 것으로 각각의

지정된 크기의 메시지를 한쪽 노드에서 연속적으로 100번을 보내고, 다른 한

쪽 노드에서는 이를 모두 받은 뒤 이에 대한 ACK 메시지를 보냄으로써 이

때 걸린 총 시간 동안 보낸 전체 메시지의 크기를 비트 단위로 환산하였다.

그림에서 보면 512KB 이하의 메시지일 경우 VMPI가 더 높은 대역폭을 나

타냈으며, 16KB까지는 낮아졌다가 그 이후 다시 MPICH보다 높은 대역폭을

나타냈다.

50

그림 4.3 VMPI와 MPICH의 대역폭 비교

그림 4.4는 VBSPlib과 BSPlib의 대역폭을 측정하여 비교한 것으로, 한

쪽 노드에서 각 연산을 연속적으로 100번 수행한 후 bsp_sync()를 수행하여

상대 노드에 결과를 반영시킨 뒤 다시 bsp_sync()를 수행하여 모든 연산이

완료되었음을 보장하게 하였다. 역시 이 때 걸린 시간 동안 전달된 총 메시

지의 크기를 비트 단위로 환산하여 대역폭을 구했다. 그림에서 보면 BSPlib

의 bsp_put()은 컴바이닝의 효과가 매우 커서 VBSPlib의 경우와 비슷하게

나타났다. 그러나 전체적인 성능을 보면 VBSPlib이 더 우수하게 나타난 것

을 볼 수 있다.

51

그림 4.4 VBSPlib과 BSPlib의 대역폭 비교

그림 4.5와 그림 4.6은 MPI 함수를 이용하여 100차 정방 행렬의 곱셈과

Adjoint Convolution을 구하는 프로그램을 노드 수를 달리하여 수행한 결과

로 전체적으로 볼 때 VMPI가 MPICH에 비해 좋은 성능을 나타냈다.

52

그림 4.5 VMPI와 MPICH의 100차 정방 행렬 곱셈

그림 4.6 VMPI와 MPICH의 Adjoint Convolution

그림 4.7과 그림 4.8은 VBSPlib과 BSPlib을 실제 응용 프로그램을 수행

하여 성능을 비교한 것으로 여기서 수행한 응용 프로그램은 BSPlib에서 제

공하는 예제 프로그램을 사용하였다. 그림 4.7은 100차 정방 행렬을 곱셈하

는데 걸린 시간을 비교한 것으로 프로그램 자체가 제곱수의 노드에서만 수

행 가능하도록 되어 있기 때문에 네 개의 노드에 대해서만 실험하였다. 그림

4.8은 전체 10만 개의 난수를 각 노드에서 Quick Sort한 후 그 결과를 다시

53

각 노드에 분배하여 다시 Quick Sort하는 방식으로 수행되는 프로그램으로

역시 VBSPlib이 좋은 성능을 보였다.

그림 4.7 VBSPlib과 BSPlib의 100차 정방 행렬 곱셈

그림 4.8 VBSPlib과 BSPlib의 Sample Sort

실험 결과를 종합적으로 살펴볼 때 어느 정도의 성능 향상은 있었지만

기대했던 큰 성능 향상은 보이지 않았다. 그 원인을 몇 가지로 분석해 보면

먼저 본 연구에서 사용한 M- VIA의 오버헤드를 들 수 있다. M- VIA의 경우

54

소프트웨어적으로 구현되었기 때문에 시스템 보호 등의 문제로 인해 완벽한

zero- copy를 지원하지 않는다. 또한 M- VIA에서 데이터를 전송하는데 사용

될 메모리를 등록하는데 소요되는 시간이 전체 통신에 소요되는 시간과 비

교해서 상대적으로 크게 나타났다. VMPI가 VBSPlib과 비교하여 큰 성능 향

상을 보이지 않은 이유로는 VIA가 MPI보다는 BSP 구조에 더 적합하다는

점을 들 수 있다. MPI의 경우 한번의 데이터 전송이 이루어지기 위해 제어

채널과 데이터 채널을 통한 이중의 메시지 교환은 큰 오버헤드로 작용한다.

그러나 BSP의 경우 구조상 데이터 전송이 이루어지기 전에 먼저 제어 정보

를 교환하는 것은 필수적인 사항이다. 또한 우리가 구성한 PC 클러스터 시

스템이 두 종류의 다른 CPU를 사용하는 이기종 컴퓨터로 구성되어 있어서

응용 프로그램 수행 시 각 노드를 어떻게 지정하느냐에 따라 결과값에 약간

의 차이를 보였다.

55

제 5 장 결 론

본 연구에서는 클러스터 시스템에서 보다 성능 좋고 효율적인 병렬 프로

그래밍의 작성을 위한 환경으로 고성능 프로토콜인 VIA 기반의 병렬 라이

브러리를 구현하였다. 기존의 T CP/ IP 또는 UDP/ IP 기반의 병렬 라이브러리

인 MPI, BSPlib과 본 연구에서 구현한 VMPI, VBSPlib을 간단한 실험을 통

해 성능 분석한 결과 VIA 기반의 병렬 라이브러리가 전반적으로 좋은 성능

을 나타냈다. 이는 클러스터 시스템에서 VIA를 이용한 통신 방법의 발전 가

능성 제시 및 아직 VIA 기반의 병렬 라이브러리 구현에 대한 연구가 활발

히 진행되고 있지 않다는 점에서 의미를 지닌다.

앞으로 VMPI와 VBSPlib의 좀더 정확한 성능 분석을 위해 보다 다양한

응용 프로그램에 적용시키는 일이 필요하다. 또한 현재 VMPI, VBSPlib은

가장 기본적인 루틴만이 구현되어 있으므로, 이에 대한 좀더 다양한 루틴을

지원하는 것이 필요하며, VIA가 지니는 장점을 최대한으로 살릴 수 있는 보

다 최적화된 코드로의 개선 작업이 필요하다.

나아가서 VMPI를 이용한 BSP 라이브러리의 구현 및 BSP의 전역적인

배리어 연산으로 인한 통신 비용을 완화시킨 연성 배리어 동기화 기법을 이

용한 VIA 기반의 BSP 라이브러리 구현을 고려할 수 있다[21]. 또한 VIA를

하드웨어로 구현하여 그 위에 우리의 병렬 라이브러리를 적용시켜 보는 일

도 하나의 흥미로운 연구 대상이다.

56

참고 문헌

[1] Jonathan Kay and Joseph Pasquale, "Profiling and Reducing

Process ing Overheads in T CP/IP," IEEE/ACM T ransactions on

Networking, Vol.4, No.6, 1996, pp.817- 828.

[2] Raoul A.F ., Bhoedjang, T im Ruhl, Henri E. Bal, "User- Level Netw ork

Interface Protocols ," IEEE Spectrum, Nov. 1998, pp.53- 60.

[3] Dave Dunning, Greg Regnier, Gary McAlpine, Don Cameron, Bill

Shubert, Frank Berry, Anne Marie Merrit t, Ed Gronke, Chris Dodd,

"T he Virtual Interface Architecture," IEEE Micro, Mar.- Apr. 1998,

pp.66- 76.

[4] T hors ten von Eicken, Werner Vogels , "Evolution of the Virtual

Interface Architecture," IEEE Spectrum, Nov. 1998, pp.61- 68.

[5] David E. Culler, Andrea Arpaci- Dusseau, Remzi Arpaci- Dusseau,

Brent Chun, Steven Lumetta, Alan Mainwaring, Richard Martin, Chad

Yoshikawa, Frederick Wong, "Parallel Computing on the Berkeley

NOW," JSPP' 97, 1997.

[6] T homas Sterling, T om Cw ik, Don Becker, John Salmon, Mike Warren,

Bill Nitzberg, "An asses sment of Beowulf- class computing for NASA

requirements: Initial findings from the firs t NASA w orkshop on

Beowulf- class clustered computing," IEEE Aerospace Conference. Mar.

1998.

[7] Michael S . Warren, Donald J. Becker, M. Patrick Goda, John K.

Salmon, T homas Sterling. "Parallel supercomputing w ith commodity

57

components ," DPT A' 97, 1997, pp.1372- 1381.

[8] Daniel Ridge, Donald Becker, Phillip Merkey, T homas Sterling Becker,

Phillip Merkey "Beow ulf: Harnessing the Pow er of Parallelism in a

Pile- of- PCs ," IEEE Aerospace, 1997.

[9] Anindya Basu, Vineet Buch, Werner Vogels , T horsten von Eicken,

"U- Net: A User- Level Network Interface for Parallel and Dis tributed

Computing," SOSP, Dec. 1995.

[10] Matthias A. Blumrich, Richard D. Alpert, Yuqun Chen,, Douglas W.

Clark, S tefanos N. Damianakis , Cezary Dubnicki, Edw ard W. Felten,

Liviu Iftode, Kai Li, Margaret Martonosi, Robert A. Shillner, "Design

Choices in the SHRIMP System: An Empirical Study," Proceedings of

25th Annual ACM/IEEE International Symposium on Computer

Architecture, Jun. 1998.

[11] Message Pass ing Interface Forum, "MPI: A Message- Pass ing

Interface Standard," May. 1994.

[12] Jonathan M. D. Hill, Bill McColl, Dan C. Stefanescu, Mark W.

Goudreau, Kevin Lang, Satish B. Rao, T orsten Suel, T hanasis

T santilas , Rob Bisseling, "BSPlib, T he BSP Programming Library,"

http:/ /w ww .bsp- worldwide.org/ , May. 1997.

[13] Jonathan M. D. Hill, Stephen R. Donaldson, David B. Skillicorn,

"Portability of performance with the BSPLib communications library,"

http:/ /w ww .bsp- worldwide.org/ , May. 1997.

[14] Kai Hw ang, Zhiwei Xu, "Scalable Parallel Computing,"McGraw - Hill,

1998, pp.20- 23.

[15] Rajkumar Buyya, "High Performance Cluster Computing," Prentice

58

Hall PT R, Vol.1 1999, pp.3- 47.

[16] Gregory F. Pfis ter, "In Search of Clusters ," Prentice Hall PT R, 1998,

pp.71- 84.

[17] Patrick Bridges, Nathan Doss, William Gropp, Edward Karrels ,

Ewing Lusk, Anthony Skjellum, "Ins tallation Guide to mpich, a

Portable Implementation of MPI," Jun. 1995.

[18] Stephen R. Donaldson, Jonathan M. D. Hill, David B. Skillicorn,

"BSP Clusters : high performance, reliable and very low cos t,"

T echnical Report PRG- T R- 5- 98, Sep. 1998.

[19] Compaq, Intel, Microsoft, "Virtual Interface Architecture Specification

Version 1.0," Dec. 1997.

[20] M- VIA Documentation, http:/ /w ww .nersc.gov/ research/FT G/via/ .

[21] 김진수, "SMP 클러스터를 위한 다중 스레드 BSP 프로그래밍 모델," 서

울대학교 공학박사학위 논문, Aug. 1999.

59

A bs tract

As hardware and software technologies have been developed, computer

environments have rapidly been changed. T here are many researches in

the field of parallel process ing about clustering; substituting cheap PCs

and workstations for super computers by interconnecting high speed

netw orks to them. How ever, cluster systems, w hich are cons tructed in

SAN (System Area Netw ork), have problems in the entire performance of

systems using complicated protocols like T CP/ IP. As the result of that, a

lot of researches for reducing the softw are overhead of T CP/ IP and for

high- speed netw orking are underway. And VIA (Virtual Interface

Architecture) protocol is the one of protocols that are made to reduce the

overhead.

In this paper, We implement parallel libraries , MPI(Message Pass ing

Interface) and BSP(Bulk Synchronous Parallel) libraries , for effective

parallel programming on the VIA based cluster sys tems and analyze

them through comparing with MPI and BSP libraries w hich are

implemented in T CP/ IP or UDP/IP based environment.

Key w ord: Clus ter, SAN, VIA, MPI, BSP

S tudent Number: 98519- 512

감사의 글

처음에는 낯설기만 했던 석사 생활이 좀 익숙해지려 하니 어느덧 2년이

라는 시간이 흘러 정리를 해야 할 때가 되었습니다. 2년이라는 석사 생활을

마치며 그 동안 제 주위에서 항상 관심과 격려를 아끼지 않아 주셨던 모든

분들께 글로나마 감사 인사 드립니다.

먼저 항상 자상하고 온화한 미소로 따뜻하게 보살펴 주시고, 이 논문이

나오기까지 올바른 연구 방향을 제시해 주신 하순회 지도 교수님께 진심으

로 감사드립니다. 더불어 저의 논문 심사에 애써 주신 전주식 교수님과 장래

혁 교수님께도 감사드립니다.

대학 생활을 함께 하며 졸업 후에서 항상 곁에서 힘이 되어준 광록이를

비롯한 많은 대학 동기들에게도 감사의 말을 전하고 싶습니다. 그리고 친동

생처럼 잘 따라주고 늘 격려를 아끼지 않았던 영애, 창오, 주영, 미자 외 많

은 후배들에게도 감사드립니다.

2년이라는 석사 생활을 함께 생활하며 정들었던 연구실 분들께도 감사드

립니다. 연구실의 듬직한 기둥으로서 늘 자상하게 여러 문제들을 해결해 주

셨던 원용이형, 연구에 충실하며 후배들의 연구 활동에 관심을 가져주셨던

찬익이형, 같은 연구팀으로서 연구 방향을 제시해 주고, 여러 가지로 많은

도움을 주었던 양석이, 잔잔한 미소를 잃지 않으며 가끔은 엉뚱한 생각으로

우리를 즐겁게 했던 현옥이, 항상 다양하고 새로운 정보와 자료 제공으로 유

익함을 주었던 도형이, 여유로운 행동으로 궂은 일도 마다 않고 솔선수범했

던 채석이, 동기로서 대학원 생활에 가장 큰 힘이 되어준 성찬, 재웅, 현욱

이, 맡은 바 일을 언제나 책임감 있게 성실히 수행하는 강녕이형, 연구실 분

위기를 항상 온화하게 만들어 준 민영이, 하루에도 몇 번씩 인사를 하던 예

의 바른 웹마스터 우철이, 그리고 내 일을 이어받아 연구 생활을 할 신입생

춘승이를 비롯한 채은, 영민, 중희 모두에게 감사드립니다.

끝으로 이 자리가 있기까지 항상 걱정을 아끼지 않고 물심양면으로 보살

펴 주신 부모님과 항상 애정 어린 눈으로 지켜봐 준 형과 누나에게 진심으

로 감사드립니다.