Sun Developer Network 공식 블로그

2.1 OpenMP 소개

OpenMP 는 썬 마이크로시스템즈, HP, IBM, 그리고 인텔 같은 수 많은 컴퓨터 제조사들과 최고의 소프트웨어 개발자들에 의해 개발된 표준 API 디자인 스펙 입니다. 좀 더 자세한 정보는 웹사이트 www.openmp.org 에서 찾으실 수 있습니다. 이 스펙의 목표는 소프트웨어 개발자가 좀 더 쉽게 병렬 어플리케이션을 디자인하거나 수정하고 현재의 순차적으로 실행되는 어플리케이션을 병렬화 시켜서 공유 메모리가 설정된 멀티프로세서 컴퓨팅 시스템에서의 장점을 얻을 수 있도록 하기 위한 공통의 스펙을 제공하는 것입니다. 이식성 또한 OpenMP 의 중요한 목표 중에 하나 입니다. OpenMP 를 이용해 개발된 병렬 어플리케이션 소스 코드는 OpenMP 를 지원하는 어떠한 컴파일러에 의해서도 컴파일 될 수 있고 컴파일된 바이너리는 병렬 퍼포먼스의 이득을 얻을 수 있는 어떠한 타겟 하드웨어 플랫폼에서도 실행 됩니다.

OpenMP 는 다양한 네이티브 프로그래밍언어를 지원합니다: 포트란, C/C++. 그림1에는 C/C++ 그리고 포트란으로 쓰여진 OpenMP의 간단한 예제를 보여줍니다.




이 예제에서 y 배열을 x 배열에 더하는 루프 반복작업은 병렬로 실행될 것입니다. OpenMP 생성자는 소스 내에서 pragma, 지시자 그리고 프로그래밍 API 에 의해 표현 됩니다. OpenMP  생성자는 프로그래머가 병렬 구역, 동기화, 데이타 영역 속성등을 지정할 수 있도록 합니다.  예를 들어 환경 변수 OMP_NUM_THREADS 는 런타임시에 쓰레드 갯수를 지정할 수 있습니다.

2.2 OpenMP 예제

썬 스튜디오 컴파일러는 OpenMP 와 관련된 SPEC OMPM 세계 기록들을 2P, 4P, 그리고 듀얼 코어 벤치마크 분야에서 가지고 있습니다. 썬 스튜디오 OpenMP 를 살펴 보기 위해서 필자는 특정 범위 안에 소수 숫자들을 찾는 작은 C++ OpenMP 프로그램을 구현했습니다. 24개의 1.2GHz 울트라SPARC III+ 프로세서와 9.9GB 의 메인 메모리에 솔라리스 5.9 가 운용되고 있는 썬 파이어 6800 머신에서 300만 이하의 모든 소수 숫자를 찾는 프로그램을 실행 하였습니다.  결과는 매우 흥미로웠습니다. 표 1을 살펴 보시기 바랍니다.

필자는 몇시간 만에 순차적으로 실행되는 프로그램을 OpenMP 버전으로 변환하였습니다. 병렬화의 효과는 이렇게 작고 간단한 프로그램을 최소한의 노력으로 바꾸었다는 점에서 매우 놀라웠습니다. 이 OpenMP 프로그램을 싱글 쓰레드로 실행했을때 OpenMP 작업의 오버헤드로 인해 퍼포먼스는 8.65% 정도 하락했습니다. 그러나 2 쓰레드로 시작해서 20개 까지 올렸을때 퍼포먼스는 훌륭하게 향상되었습니다. 흥미로운점은 프로그램을 20 쓰레드 이상으로 실행했을 때 인데, 20 쓰레드 이상으로 실행했을때 확장성의 한계에 다다랐고 포화도에 따른 하락을 보였습니다. OpenMP 프로그램은 20 쓰레드 보다 훨씬 더 확장되어야 합니다. 이러한 조기 포화도에 대한 잠재적인 이유로는 이 프로그램의 프로그래밍 로직이 좀 더 병렬화 될 만큼 복잡하지 않다는 것입니다. 사실 프로그램의 OpenmP 병렬 루프 내에는 오직 몇 줄의 코드가 존재합니다.

표 1: OpenMP 프로그램 퍼포먼스의 예

1	Serial Version	6.636 sec	base
2	OpenMP 1 쓰레드	7.210 sec	8.65% drop
3	OpenMP 2 쓰레드	3.771 sec	1.76x faster
4	OpenMP 4 쓰레드	1.988 sec	3.34x faster
5	OpenMP 8 쓰레드	1.090 sec	6.09x faster
6	OpenMP 16 쓰레드	0.638 sec	10.40x faster
7	OpenMP 20 쓰레드	0.550 sec	12.06x faster
8	OpenMP 24 쓰레드	0.931 sec	saturation

2.3 OpenMP 제약사항

OpenMP 프로그래밍 모델은 싱글 프로세스에 제한되기 때문에 확장성은 싱글 머신에서의 프로세서 갯수(쓰레드) 에 절대적으로 제한됩니다. 확장성은 또한 위에서 언급한 것 처럼 프로그래밍 로직의 복잡성과 프로그래밍 스타일에 의해 제한 됩니다. 현재 OpenMP 구문은 몇몇 어플리케이션에서는 사용할 수 없을 만큼 유연하지 않습니다. 예를 들어,  현재 OpenMP 스펙은 병렬 구역에서 오직 제한된 수의 동적 쓰레드 생성을 허용합니다. 썬 마이크로시스템즈, 인텔 그리고 다른 많은 회사들이 속해 있는 OpenMP 언어 위원회의 멤버들은 동적인 태스크 큐 생성자를 지정해서 이러한 제약을 없을 수 있는 작업을 하고 있습니다. OpenMP 어플리케이션 프로그래밍시에 좀 더 일반적으로 발생하는 다른 문제로는 복수개의 쓰레드 간의 레이스 컨디션을 피하고 동시 작업중인 쓰레드 간에 적절한 로드 밸런싱을 수행하는 것입니다.

3: MPI

3.1 MPI 소개

MPI 는 멀티 프로세서 머신과 머신 클러스터 상에서 고성능의 컴퓨팅을 위한 업계 표준 API 스펙입니다. 표준은 광범위한 컴퓨터 벤더 와 소프트웨어 개발자 그룹에 의해 디자인 되었습니다. 현재 다양한 연구 기관 및 회사에서 나온 다양한 MPI 구현이 존재 합니다. 가장 유명한 것으로는 MPICH 가 있으며 특정 플랫폼 혹은 연결(interconnect) 를 위해 최적화된 MPI 구현을 위한 코드 베이스로써 자주 사용 됩니다. 관심있는 독자들은 MPI 표준과 MPICH 에 대한 좀 더 자세한 정보를 웹사이트: http://www-unix.mcs.anl.gov/mpi 에서 찾으실 수 있습니다. MPI 는 병렬 어플리케이션을 위한 분산 메모리 프로그래밍 모델을 제공합니다. 비록 전체 MPI API 셋이 상대적으로 큰 300개 이상의 루틴을 포함하고 있지만 많은 MPI 어플리케이션들은 12개 이하의 기본적인 루틴 만으로도 작성될 수 있습니다. 그림 2번은 메세지를 전송하고 수신하기 위한 루틴의 짝을 보여주고 있습니다.

각 루틴의 첫 3개 매개변수는 장소, 데이타 타입, 그리고 메시지의 용량을 지정하고 있습니다. 4번째 매개변수는 통신을 할 타겟 프로세스를 지정하고 있습니다. 5번째 매개변수 태그 ID 는 서로 다른 메세지를 구분할 수 있는 추가적인 메카니즘을 제공합니다. 6번째 매개변수는 통신 문맥을 지정합니다. 수신 루틴에는 수신 상태를 알리기 위한 추가적인 매개변수가 존재 합니다.

MPICH 디자인에서 전체 API 셋은 저수준의 디바이스 연결 루틴 들의 코어 셋을 이용해서 구현되고 빌드 되었습니다. 이 디자인 아키텍쳐는 서로 다른 플랫폼간에 훌륭한 이식성을 제공 합니다. 오직 한가지 필요한 작업은 디바이스 연결 루틴의 작은 코어 셋이 새로운 플랫폼 혹은 연결을 위해 최적화 되도록 포팅하고 최적화 하는 작업입니다.

MPI 구현은 여전히 진화 중입니다. MPI-1 은 포인트-투-포인트 및 커뮤니케이터를 이용한 집합적인 메세지 커뮤니케이션 같은 중요 기능들을 지원합니다. 메세지는 기본 데이타 타입 혹은 유저가 정의한 데이타 타입의 MPI 데이타를 포함할 수 있습니다. 메세지 데이타 컨텐츠는 압축되거나 압축되지 않은 형태의 포맷이 될 수 있습니다. 또한 연결 토폴로지를 지원합니다. MPI-2 는 원격 메모리 접근 과 원사이드 통신(one-side communication) 같은 다수의 향상된 기능을 제공합니다. 또한 동적인 프로세스 생성/관리 및 병렬 IO 를 지원 합니다.

3.2 메모리 구조
현재의 반도체 기술과 컴퓨터 아키텍쳐에서 가장 중요한 시스템 퍼포먼스 요소는 CPU 클럭 속도 보다 메모리 구조 입니다. 그림 3에는 비정형적인 메모리 퍼포먼스 그래프를 보여 줍니다.


만약 대부분의 명령어와 데이타 메모리 접근이 캐쉬 범위 안에서 이루어 진다면 어플리케이션 프로그램은 좀 더 빠르게 동작할 것입니다. MPI 는 분산 메모리 모델 이기 때문에 대용량의 어플리케이션에서 선형의 확장성을 보여 줍니다. MPI 어플리케이션이 대규모의 클러스터 상에서 실행된다면 각 MPI 의 메모리 공간은 감소될 것이고 메모리 접근도 메모리 구조의 최상위 범위 안에서 이루어 질 것입니다. 비정형 메모리 퍼포먼스 효과는 OpenMP 를 포함한 다른 프로그래밍 모델에서도 적용될 수 있을 것입니다.

3.3 MPI 제약사항

일반적으로 MPI 는 클러스터링 에서 병렬 어플리케이션을 위한 훌륭한 솔루션을 제공합니다. 그러나 그와 동시에 많은 개발자들에게는 어려운 프로그래밍 모델이기도 합니다. 왜냐하면 MPI 는 상대적으로 긴 통신상의 레이턴시를 가지고 있기 때문에 프로그램 코어 로직은 반드시 분산 오버헤드를 다룰 수 있도록 잘 분리되어야 하기 때문입니다. 어플리케이션의 문제를 분석하고 분리하는 작업과 이것을 분산 프로세스에 매핑하는 작업은 절대로 직관적인 작업이 될 수 없습니다. 수많은 MPI 프로세스들 간 상호작용의 복잡성 때문에 올바른 툴을 사용하더라도 수 많은 수의 노드 상에서 실행되는 MPI 어플리케이션을 디버깅 하고 튜닝 하는 것은 아주 어려운 작업입니다. MPI 루틴 구현의 품질은 추가적인 소프트웨어 개발 문제를 유발할 것입니다. MPI 퍼포먼스는 아랫단의 하드웨어 플랫폼과 연결에 의존합니다. 몇몇 극단적인 경우 MPI 어플리케이션은 엄청난 연결 트래픽에 영향을 받을 수도 있습니다. 또 다른 큰 이슈로는 대용량의 MPI 어플리케이션의 안정성 입니다. 다수의 MPI 구현에서 MPI 프로그램은 하나의 컴퓨팅 노드라도 올바르게 응답하지 않는다면 작업을 중단할 것입니다. 유감스럽게도 MPI 어플리케이션의 수천개의 컴퓨팅 노드에서 실행된다면 오류 발생율을 무시하지 못할 것입니다.

4: 그리드 컴퓨팅

4.1 그리드 소개

그리드 컴퓨팅은 매우 중요한 기술 트렌드이며 병렬 컴퓨팅 스펙트럼의 일부 입니다 .몇몇 유럽 국가들은 그리드 컴퓨팅을 인터넷 이후의 IT 혁명에 새로운 흐름으로 생각하고 그리드 기술에 엄청난 리소스를 투자하고 있습니다. 그러나 그리드 컴퓨팅은 아직 초기 단계로 우리는 이것이 어디로 향할지 아직 잘 알지 못합니다. 80년대 PC 가 처음으로 사운드 카드를 가졌을때 멀티미디어는 아주 유명한 유행어가 되었고 많은 사람들이 미래의 멀티미디어 기술을 쫓아다녔습니다. 그 시대에서 현재의 Ipod 같은 것을 생각할 수 있는 사람이 있었는지 의문입니다.
이 글에서 우리는 현재까지 우리가 알고 있는 그리드 컴퓨팅의 기본적인 개념에 대해서만 이야기할 것입니다. 간단하게 정의하자면 그리드 컴퓨팅은 유틸리티 딜리버리 메카니즘을 통한 컴퓨팅 리소스의 가상화입니다. 그리드 컴퓨팅은 인터넷의 패러다임을 수동적인 정보 공유에서 능동적인 컴퓨터 자원 공유로 바꿀 것입니다. 컴퓨팅 파워는 컴퓨팅 리소스의 종류중 하나에 불과하고 통화 처럼 순환될 수 있습니다. 그리드 컴퓨팅 환경은 리소스 디렉토리, 디스커버리, 보안, 컴퓨팅, 그리고 모니터링등의 통합 서비스 환경을 제공합니다.

4.2 DRM

그리드 컴퓨팅의 한가지 중요한 컴포넌트는 분산 리소스 매니저(Distributed Resource Manager) 입니다. DRM 은 작업 큐에 제출된 작업들을 스케줄하고 디스패치 하는 마스터 데몬 입니다. 마스터 데몬은 가장 적절한 실행 노드에 작업을 디스패치 하기 위해 실행 노드의 상태를 계속적으로 모니터링 합니다. DRM 은 또한 시스템 설정, 계정 및 리소스 사용 규칙등을 관리하는 관리 모듈 또한 가지고 있습니다. 현재 DRM 의 마켓리더는 플랫폼 컴퓨팅의 LSF (Load Sharing Facility) 입니다. 그러나 LSF 는 아주 비싼 라이센스 요금을 지불해야 합니다. 썬 마이크로시스템즈는 썬 N1 그리드 엔진 이라고 불리는 완벽히 통합된 DRM 을 제공하고 어떠한 라이센스 요금도 요구하지 않습니다. 썬 N1 그리드 엔진은 솔라리스, 윈도우, 리눅스, HP-UX, IBM AIX, 애플 매킨토시 OS/X 같은 대두분의 유명한 운영체제 상에서 실행 됩니다. 또한 자바와 네이티브 언어 바인딩을 위한 표준 DRM 어플리케이션 API DRMAA 를 지원합니다. 관심있는 독자들은 http://www.sun.com/software/gridware 에서 자세한 정보를 확인 하시기 바랍니다.

4.3 Grid 제약사항

이전에 언급했던 대로 그리드 컴퓨팅은 매우 이른 초창기 상태 입니다. 견고한 그리드 환경을 위한 훌륭한 소프트웨어 인프라스트럭쳐나 툴이 아직까지는 존재하지 않습니다. Globus 툴킷은 Globus ( http://www.globus.org ) 에서 만든 소프트웨어로 그리드 컴퓨팅을 가능하게 하는 소프트웨어를 제공합니다. Globus 툴킷은 널리 적용되는 오픈소스 소프트웨어 입니다. Globus 툴킷은 리소스 모니터링 및 디스커버리에서 보안 까지 광범위한 범위의 소프트웨어 컴포넌트를 포함하고 있습니다. 그러나 이 소프트웨어 시스템은 너무 복잡합니다. 툴킷 소프트웨어를 네트워크 환경상에서 빌드하고 디플로이 하는 것은 쉬운 작업이 아닙니다. 그와 더불어 디자인 스펙과 소프트웨어가 너무 자주 바뀜으로써 기존에 투자했던 것을 무용지물로 만들 수 있습니다.

여러분도 생각하셨을지도 모르겠지만 그리드 컴퓨팅은 SOA 와 아주 밀접한 관계가 있습니다. 그리드 컴퓨팅의 주된 목적중 하나는 컴퓨팅 리소스의 활용 서비스를 만드는 것입니다. 실제로 현재의 트렌드는 그리드 컴퓨팅을 웹서비스와 연관시키고 있습니다. 현재 그리드 컴퓨팅이 레버리지 및 빌드 할 수 있는 웹서비스 인프라스트럭쳐가 많이 존재 합니다. 한가지 중요한 이슈는 서로 다른 분야인 웹 서비스와 그리드에 대한 흥미를 어떻게 융합하느냐 입니다. 그리드 컴퓨팅의 가장 큰 도전은 대부분의 사람들과 기관들에 의해 수락될 수 있는 업계 표준 및 스펙을 만드는 것입니다.

5: 실제 케이스 스터디

이제까지 공유 메모리와 분산 메모리 프로그래밍 모델에 대해 알아 봤습니다. 이제 실제 두개의 케이스를 통해서 병렬 어플리케이션 개발의 어려움을 살펴보도록 하겠습니다.
 
5.1 병렬 검색

Search 트리 서치는 엄청나게 많은 선택이 존재하는 경우에 최적의 해답을 찾아 주거나 가능한 모든 솔루션을 찾아주는 매우 널리 사용되는 방법입니다. 수 많은 과학적인 혹은 일상 생활의 문제들이 병렬 트리 검색 문제로 변환되고 계산될 수 있습니다. 잠재적인 어플리케이션은 사소한 퍼즐 해결 부터 복잡한 전략 분석까지 다양하게 존재할 수 있습니다. 널리 이용되는 한가지 방법은 각 노드에 특정 어플리케이션의 상태를 표현하는 상태 트리를 만들고 이 상태 트리를 통해서 타겟 노드의 최적의 상태를 찾거나 최소한의 단계로 타겟 노드에 도달하는 것입니다.

이러한 병렬 검색 어플리케이션을 개발하는 방법은 두가지 단계가 있습니다. 첫번째 단계로 적당한 추상 모델을 만들어서 문제 현상을 상태 트리로 표현하는 것입니다. 추상 모델의 품질은 트리의 모양과 사이즈에 영향을 주고 이 것은 검색 작업의 효율에 영향을 줄 수 있습니다. 두번째 단계로는 병렬 컴퓨팅을 이용해서 상태 트리를 검색하는 것입니다. 트리의 품질이 중요하지 않을 경우 첫번째 단계는 매우 간단합니다. 그러나 적당히 어려운 문제만 하더라도 훌륭한 품질의 트리를 만들기 위해서는 많은 그 분야의 지식이 요구 됩니다. 두번째 단계는 상태 트리를 검색하는 것입니다. 이 단계는 보기보다 상당히 어렵습니다. 대부분의 경우 트리는 프로그램의 런타임시에 동적으로 생성됩니다. 왜냐하면 트리는 보통 불균형적인 상태로 확장되기 때문입니다. 동작하고 있는 쓰레드 혹은 프로세스에 랜덤하게 자식 노드를 추가 하는 것은 로드 밸런스를 무너 뜨릴 수 있습니다. 좀더 복잡한 접근 방법으로는 노드 작업을 태스크 큐에 넣어서 스케줄링 한 후에 작업을 작업 쓰레드 혹은 프로세스로 분산하는 것입니다. 비록 이 접근 방법은 단일 트리 노드 작업이 작업을 큐잉하는 오버헤드보다 작을 경우에는 적당하지 않을 수 있습니다.

전체적으로 병렬 검색 프로그래밍을 일반화 하는 것은 어렵습니다. 모델의 추상화 부터 시작해서 트리를 만들고 마지막으로 병렬 검색 알고리즘까지 전체적으로 어려운 작업입니다. 좋은 트리 모델은 문제를 도식화 하고 이것을 트리 노드 형태로 표현하는데에 필요한 해당 분야의 전문 지식이 필요합니다. 상태 트리가 만들어지면 일반적으로 효율적인 병렬 검색 알고리즘을 디자인하기 위한 트리 패턴의 분석 실험이 필요 합니다. 알고리즘은 보통 병렬 퍼포먼스를 얻기 위해서 트리의 노드들을 분할하고 그룹화 하는 것이 필요합니다.

5.2 병렬 시뮬레이션
 
시뮬레이션은 다양한 업계에서 중요하고 불가결한 어플리케이션입니다. 어플리케이션은 재무분석의 Monte Carol 시뮬레이션, EDA(Electronic Design Automation) 로직 시뮬레이션, 생명과학의 protein folding 에서 부터 응용 물리 시뮬레이션 까지 다양 합니다. 대용량의 시뮬에이션에서 가장 큰 도전은 엄청난 양의 객체 및 데이타를 다루는 것입니다. EDA 로직 시뮬레이션이나 생명과학의 세포 시뮬레이션 같은 어플리케이션들은 종종 수백만개 혹은 수억만개의 모델링 객체를 다룹니다. 시뮬레이션 객체를 위해 수백 만게의 쓰레드 혹은 프로세스를 생성한다는 것은 비현실적입니다. 게다가 이웃하는 엘리먼트간의 상호작용을 계산하고 서로 다른 엘리먼트간의 상호작용 결과를 전달 하는 등의 추가 계산 작업은 병렬 시뮬레이션의 효과를 완전히 없애 버릴 수도 있습니다.

실용적인 병렬 프로그래밍 방법은 적당히 복잡한 대용량의 시뮬레이션을 다루는데에 부적합합니다. 해결책은 추가적인 계산과 통신 문제를 회피 하기 위해 복잡한 레벨의 모델링 접근법을 사용합으로써 약간의 정확성을 희생하는 것입니다. 이러한 방법은 일반적으로 대규모의 현실의 문제를 시뮬레이션 하는데에 객체의 총 갯수를 줄이거나 상호작용 효과를 가정하는 large grain 모델을 광범위한 범위로 적용할때 쓰입니다. 좀 더 정확한 시뮬레이션을 위해 자주 쓰이는 곳에서는 fine grain 모델링이 사용될 수도 있습니다. 몇몇 어플리케이션에서 시뮬레이션 개발자는 그들의 문제를 해결하기 위해 특정 하드웨어를 위한 엑셀레이터를 빌드하는 추가적인 노력이 들 수 있습니다. 하드웨어 엑셀레이터는 병렬 컴퓨팅 알고리즘을 구현하는 또 다른 방법중 하나 입니다.

6: 개발자를 위한 툴

다수의 소프트웨어 개발자들이 병렬 어플리케이션 개발을 위해서 썬 스튜디오11 가 최고의 통합 환경을 제공해 준다고 생각합니다. 최근에, 2005년 11월 14일에 배포된 썬 스튜디오11 부터 썬 스튜디오 툴은 완전히 무료가 되었습니다. 그러므로 이 섹션에서는 썬 스튜디오에 촛점을 맞추어서 개발자가 어떻게 병렬 어플리케이션을 개발하는데 이 툴을 레버리지 할 수 있는지에 대해 설명할 것입니다. 관심있는 독자들은 썬 스튜디오 제품 정보를 http://www.sun.com/software/products/studio/index.xml 에서 직접 얻으실 수 있습니다. 다음의 서브 섹션에서 우리는 소프트웨어 개발 싸이클에서 가장 중요한 3가지 단계에서 툴의 사용에 대해 이야기해볼 것입니다: 컴파일, 디버깅 그리고 퍼포먼스 튜닝이 바로 그것입니다.

6.1 컴파일

병렬 어플리케이션 개발은 개발 라이프 싸이클에 두루 걸쳐서 다양한 개발 툴들을 필요로 합니다. 가장 기본적인 툴은 컴파일러 입니다. 결정한 컴파일러의 품질은 퍼포먼스와 실행코드의 품질에 엄청난 영향을 미칩니다. 컴파일러는 반드시 OpenMP 어플리케이션을 위한 최신의 OpenMP 표준을 지원해야 합니다. 컴파일러의 내부 OpenMP 작업 쓰레드 구현이 CMT 혹은 CMP 머신에서 실행되는 병렬 어플리케이션의 퍼포먼스에 심대한 영향일 미칩니다. 썬 스튜디오 컴파일러는 최근 수년 동안 썬 SMP 시스템에서 지속적으로 SPEC OMP 세계 기록을 세워 왔습니다. 관심있는 독자들은 벤치마크에 대한 정보를 다음의 사이트에서 얻으실 수 있습니다: http://www.sun.com/software/products/st ··· arks.xml.

썬스튜디오 컴파일러나 인텔 컴파일러 같은 몇몇 컴파일러들은 순차적으로 동작하는 어플리케이션들을 멀티쓰레드 어플리케이션으로 자동으로 변환해 주고 분석해 줍니다. 일반적으로 프로그램의 광범위한 부분에 자동 병렬화를 수행하긴 힘듭니다. 그러므로 컴파일러는 루프 구문에 촛점을 맞춥니다. 썬 스튜디오 컴파일러는 루프 반복문 내의 데이타 의존성을 분석하고 데이타 의존성이 존재하지 않을 경우 반복문을 멀티쓰레드 형태로 병렬화 합니다.

6.2 디버깅

디버깅은 어플리케이션 개발 싸이클에서 가장 시간을 많이 소비 하는 작업입니다. 좋은 디버깅 환경은 완벽하게 통합된 GUI 환경과 dbx 같은 강력한 백엔드의 디버깅 툴이 있어야 합니다. 썬 컴파일러는 대부분의 컴파일러 보다 더 훌륭한 품질의 심볼 매핑 데이타를 생성 합니다. 그러므로 썬 스튜디오 디버거는 프로그램 데이타의 명령어를 다루는데 좀 더 투명한 뷰를 제공합니다.

썬 스튜디오는 완벽히 통합된 GUI 환경으로 개발자가 효과적으로 브레이크 포인트 및 watch 포인트를 설정하고 관리할 수 있습니다. 콜링 스택과 로컬 변수 윈도우를 제공함으로써 현재 프로그램의 문맥을 아무때나 볼 수 있습니다. 소스 코드 에디터 윈도우에서 직접 싱글 스텝 실행이 가능함으로써 프로그램의 흐름을 쉽게 따라갈 수 있습니다. 수정 후 계속 기능은 대용량 프로그램의 빌드 타임 없이 하나씩 수정할 수 있도록 해줌으로써 디버깅 싸이클의 속도 향상을 가져다 줍니다. 썬 스튜디오 디버깅 환경은 또한 프로그램의 실행을 조정하고 와일드 포인터 혹은 초기화되지 않은 변수의 접근을 감지해 줍니다. 또 이 툴은 메모리 할당및 할당해제등을 모니터링하고 메모리 누수 현상을 보고해 줍니다.

썬 스튜디오 디버깅 환경은 위와 같은 기능을 OpenMP 프로그램과 POSIX 쓰레드(Pthread) 어플리케이션에도 동일하게 제공합니다. 또한 썬 스튜디오는 멀티세션 디버깅 기능을 제공해서 여러개의 프로그램 인스턴스를 로드하고 동시에 디버깅 할 수 있습니다. 개발자는 이러한 기능을 이용해서 동일한 버전에 순차적으로 실행되는 어플리케이션과 멀티 쓰레드 버전과의 비교를 통해 디버깅이 가능하도록 합니다.

6.3 퍼포먼스 튜닝

썬 스튜디오 퍼포먼스 분석기는 업계에서 가장 좋은 퍼포먼스를 가진 툴중에 하나 입니다. 이 툴은 C/C++, 포트란 그리고 자바를 지원 합니다. 썬 스튜디오 퍼포먼스 분석기는 사용하기 간편하고 수정을 가하지 않은 바이너리로 작업 할 수도 있습니다. 개발자는 C++ 에서 전체 소스 라인 레벨의 정보를 얻기 위해서 -g 혹은 -g0 옵션을 주고 소스를 재컴파일 하면 됩니다. OpenMP, MPI 혹은 Pthread 같은 명시적인 병렬화 혹은 자동 병렬화에 의해 생성된 병렬 프로그램에서도 사용할 수 있습니다.

퍼포먼스 분석기를 사용하는 데에는 간단한 두단계가 필요 합니다. 첫번째로 분석기는 실헝 대상을 실행시켜서 프로파일링 데이타를 수집합니다. 클럭 혹은 하드웨어 카운터에 의해 트리거링 되는 통계적인 콜스택 샘플링을 적용해서 프로파일링 데이타를 수집합니다. 그 다음에 분석기는 퍼포먼스 데이타를 불러와서 이것을 여러가지 형태의 뷰로 제공합니다. 개발자는 퍼포먼스 데이타를 루틴, 구문 혹은 명령어 수준에서 살펴볼 수 있습니다. 동적인 모드외에도 개발자는 퍼포먼스 데이타를 배치 커맨드 모드로 수집하고 출력할 수 있습니다.

분석기는 실험 데이타를 로드해서 결과를 실험대상, 쓰레드, 함수 및 시간 순서대로 필터링 할 수 있습니다. 퍼포먼스 툴은 또한 API 루틴을 제공함으로써 개발자가 코드를 직접 다룰 수 있도록 허용합니다. 썬 스튜디오 퍼포먼스 분석기는 자바 프로파일링을 3가지 모드로 지원합니다. 유저모드에서는 오직 유저 쓰레드와 자바 콜스택만을 보여 줍니다. 전문가 모드에서는 유저 쓰레드의 모든 쓰레드와 자바 콜스택을 보여주고 다른 쓰레드를 위한 머신 콜스택도 보여 줍니다. 머신 모드에서는 모든 쓰레드에 대한 머신 콜스택을 보여 줍니다.

7: 요약

위의 툴 섹션에서는 개발자에게 중요한 오직 3가지의 툴에 대해서만 다루었습니다. 병렬 어플리케이션 개발에 필요한 다른 중요한 툴들도 있는데 예를 들어 레이스 컨디션 체커 등이 있습니다. 어쨌든 개발자들은 개발 툴 하나로만은 병렬 어플리케이션 개발의 문제를 해결할 수 없다는 것을 인식해야 합니다. 실제 케이스 스터디 섹션에서 이야기했듯이 많은 병렬 어플리케이션 개발자들은 그들의 소프트웨어를 개발하기 위해 각각에 맞는 추상 모델과 프로그래밍 방법론을 수용해야 합니다. CMT 와 CMP 프로세서에 기반을 둔 최신의 플랫폼들을 접하면서 우리는 어플리케이션 개발에 대한 마음가짐과 자세를 바꿀 필요가 있습니다. 문제 정의에서 시작해서 우리는 문제를 병렬 화된 방법으로 분석하고 추상화하고 매핑해야 합니다. 이것은 물론 현재 우리가 하고 있는 방법에 비해 엄청나게 큰 변화입니다. 그러나 병렬 플랫폼에서 얻을 수 있는 보상에 비하면 아주 작은 희생에 불과 합니다.


감사의 인사

저의 동료 3명에게 감사의 인사를 전합니다. Mike Ball 은 이 글을 리뷰해주고 더욱 더 빛나게 해 주었습니다. Yuan Lin 은 소수 프로그램을 향상시키고 이것을 썬파이어6800 머신에서 실험해 주었습니다. Yuan 은 또한 이 글을 리뷰해 주었습니다. Ruud van der Pas 는 또한 이 글을 리뷰해 주었고 그의 썬 HPC 2005 워크샵 결과를 통해 이글을 쓰는데 큰 공헌을 하였습니다.

저자에 관하여

Liang Chen 은 썬 마이크로시스템즈의 Distinguished Engineer and Software Architect 입니다. 그는 아키텍쳐와 썬 스튜디오 개발 툴의 미래 기술에 촛점을 맞추고 있습니다. 현재 그가 가장 흥미를 가지고 있는 주제는 강결합된 OpenMP 를 약결합 형태의 SOA 와 그리드로 변환하는 병렬 어플리케이션 개발 입니다. 현재의 작업 이전에 Liang 은 썬랩의 소프트웨어 아키텍트및 연구 프로젝트 매니저로써 썬의 미래 컴퓨팅 시스템을 시뮬레이트 하기 위한 수천개의 프로세서를 가진 대규모 병렬 머신을 빌드하는 작업을 수행하였습니다. 그는 썬에 조인하기 전에 SGI 와 AMD 같은 회사에서 일했습니다.



이 글의 원본은 http://developers.sun.com/solaris/artic ··· lel.html 에서 보실 수 있습니다.