이 섹션에서 다루어지는 내용은 모든 리눅스의 네가지 병렬 처리 모델들에 적용되는 것이다.
나는 주로 컴파일러 연구자로 알려져 있다. 그래서 나는 리눅스 시스템들에 대한 효율적인 병렬 코드를 자동으로 생성하는 위대한 컴파일러들이 많이 있다고 말할 수 있었으면 한다. 불행하게도 다양한 명시적 통신과 다른 병렬 연산들을 사용한 여러분의 병렬 프로그램을 GCC로 컴파일될 C 코드로 표현함으로써 성능을 높일 수 있다는 것은 어렵다는 것이 진실이다.
다음 언어/컴파일러 프로젝트들이 고-수준 언어들로부터 효율적인 코드를 만드는 노력을 하고 있다. 일반적으로 이들 각각은 그것이 지향하는 프로그래밍 작업들의 종류에 대해서는 효율적이지만 어떤 것도 강력한 범용 언어이지 않고, GCC로 컴파일할 C 프로그램을 작성하는 것을 영원히 멈추게 할 만한 것이 없다. (그래도) 이것은 좋다. 이런 언어들과 컴파일러들을 그들이 의도된 바대로 사용하고 여러분은 더 짧은 개발 시간, 쉬운 디버깅과 유지 보수 등의 보상을 받을 것이다.
여기에 리스트된(알파벳 순서로) 것들 외에 많은 언어들과 컴파일러들이 있다. 자유롭게 사용가능한 컴파일러들(이들중 대부분은 리눅스 병렬 처리에 대해서 아무것도 하지 못한다)은 http://www.idiom.com/free-compilers/에 있다.
적어도 과학 컴퓨팅 사회에서는 언제나 포트란(Fortran)이 있다. 물론 이제
포트란은 1966년 ANSI 표준에서 그랬던 것과 똑같은 것을 의미하지 않는다.
기본적으로 포트란 66은 아주 단순한 것이다. 포트란 77은 많은 것들을
추가했고 이들 중 가장 주목할 만한 것은 문자 데이터에 대한 개선된 지원과
DO 루프 문법의 변경이다. PCF (Parallel Computing Forum)
포트란은 77에다 다양한 병렬 처리 지원을 더하려고 시도하였다. 포트란 90은
완전한-기능의 현대 언어이다. 이것은 기본적으로 C++-비슷한 객체-지향
프로그래밍 기능들과 병렬 배열 문법을 77 언어에 추가한 것이다. 두
버전들(HPF-1과 HPF-2)를 가지는 HPF (High-Performance Fortran,
http://www.crpc.rice.edu/HPFF/home.html)는 기본적으로
진보된, 표준화된, 우리들이 보통 CM 포트란, MasPar 포트란, 또는 포트란
D로 알고 있는 것의 버전이다; 이것은 다양한 병렬 처리 개선점들을 넣어서
포트란 90을 확장한 것이다. 주로 데이터 레이아웃을 지정하는 데 촛점을 둔
것이다. 마지막으로 포트란 95는 90을 상대적으로 적게 증진시키고 개선한
것이다.
C로 작업한 것은 일반적으로 f2c, g77 (리눅스-종속적인
훌륭한 개관은
http://linux.uni-regensburg.de/psi_linux/gcc/html_g77/g77_91.html에
있다), 또는
http://extweb.nag.co.uk/nagware/NCNJNKNM.html
상업용 버전 포트란 90/95과도 잘 작동한다. 이것은 이들 모든 컴파일러들이
결과적으로 GCC의 백-엔드에서 사용된 것과 코드-생성에서 동일하기
때문이다.
SMP에 대한 코드를 생성할 수 있는 상업용 포트란 병렬기(parallelizer)들은 http://www.kai.com/과 http://www.psrv.com/vast/vast_parallel.html에서 찾을 수 있다. 이런 컴파일러들이 SMP 리눅스에서 작동할런지 안할런지는 모르지만 표준 POSIX 스레드들(즉, LinuxThreads)가 SMP 리눅스하에서 작동한다면 그것은 가능할 것이다.
포트랜드 그룹(Portland Group)은, http://www.pgroup.com/, SMP 리눅스에 대한 코드를 생성하는 상업용 병렬화 HPF 포트란(그리고 C, C++)를 가지고 있다; 그들은 또한 MPI나 PVM을 사용한 클러스터들을 타겟으로 한 버전도 갖고 있다. http://www.apri.com/의 FORGE/spf/xHPF 제폼들도 SMP들이나 클러스터들에 대해서 유용할 것이다.
병렬 리눅스 시스템들과 작업이 가능하도록 만들어질 수 있는, 자유롭게 사용가능한 병렬화 포트란들은 다음과 같은 것들을 포함한다:
포트란의 다양한 방언들에 대한 잠재적으로 유용한 많은 컴파일러들을 빼먹었다고 확신하지만 추적하기에 어려운 점이 많다. 나중에 나는 리눅스에서 작동한다고 알려진 그런 컴파일러들만 모아 보고자 한다. pplinux@ecn.purdue.edu로 비평이나 교정을 이메일로 보내주기 바란다.
GLU (Granular Lucid) 는 집약적이고(intensional) (Lucid) 긴급한 모델들을 조합한 하이브리드 프로그래밍 모델에 기반한 고-수준 프로그래밍 시스템이다. 이것은 PVM과 TCP 소켓들을 지원한다. 이것은 리눅스에서 실행되는가? 좀 더 많은 정보가 http://www.csl.sri.com/GLU.html에 있다.
Jade 는 C를 확장해서 순차적이고 긴급한(imperative) 프로그램들 안에서 성긴 협력을 개발하도록 한 병렬 프로그래밍 언어이다. 이것은 분산 공유 메모리 모델을 가정한다. 이것은 PVM을 사용하는 워크스테이션 클러스터들에 대해서 SAM에 의해 구현된다. 좀 더 많은 정보는 http://suif.stanford.edu/~scales/sam.html에서 찾을 수 있다.
Mentat는 워크스테이션 클러스터들에서 작동하고 리눅스로 포팅된바 있는 객체-지향 병렬 처리 시스템이다. Mentat 프로그래밍 언어(MPL)은 C++에 기반하고 있는 객체-지향 프로그래밍 언어이다. Mentat 실시간 시스템은 비-블록킹 RPC들과 약간 닮은 어떤 것들을 사용한다. 좀 더 많은 정보는 http://www.cs.virginia.edu/~mentat/에서 찾을 수 있다.
Legion http://www.cs.virginia.edu/~legion/ 는 Mentat 의 상위에 만들어진 것이고 WAN으로 묶인 기계들에 대해서 단일 가상 기계를 제공한다.
Mentat 의 MPL과 혼동되지 말자. 이 언어는 원래 MasPar SIMD 슈퍼컴퓨터를 위한 원시 병렬 C 방언으로써 개발되었다. 글쎄, MasPar는 실제 더이상 장사를 하지 않지만(그들은 이제 NeoVista Solutions, http://www.neovista.com, 데이터 마이닝 회사이다), 그들의 MPL 컴파일러는 GCC를 사용해서 개발되었었다. 그래서 이것은 아직도 자유롭게 사용가능하다. Huntsville의 알라바마 대학교와 퍼듀 대학교 이들과 조인트해서 MasPar 의 MPL은 AFAP 호출들을 가진 C 코드를 생성하는 것으로 목표가 바뀌었다(섹션 3.6을 참조), 그래서 리눅스 SMP 및 클러스터들 위해서 작동한다. 그러나 그 컴파일러는 다소 버그가 많다. http://www.math.luc.edu/~laufer/mspls/papers/cohen.ps 참조.
Myrias 는 PAMS (병렬 어플리케이션 관리 시스템) 이라고 불리는 소프트웨어 제품을 파는 회사이다. PAMS는 가상 공유 메모리 병렬 처리를 위한 아주 단순한 지시어들을 제공한다. 리눅스 기계들의 네트웍은 아직 지원되지 않는다. 좀 더 자세한 정보를 위해서는 http://www.myrias.com/를 참조하자.
Parallaxis-III 는 데이터 병렬화 (SIMD 모델)에 대한 "가상 프로세서와 커넥션(virtual processors and connections)"으로 Modula-2를 확장한 구조적 프로그래밍 언어이다. Parallaxis 소프트웨어는 순차 및 병렬 컴퓨터 시스템들을 위한 컴파일러들과, 디버거(gdb와 xgdb 디버거에 대한 확장판), 그리고 서로 다른 영역의, 특별히 이미지 처리 영역의, 많은 양의 샘플 알고리즘들로 이루어져 있다. 이것은 순차 리눅스 시스템들 위헤서 실행된다... 구 버전은 다양한 병렬 타겟들을 지원했었다. 그리고 새로운 버전도 (예, PVM 클러스터를 타겟으로 삼음) 또한 그럴것이다. 좀 더 자세한 정보는 http://www.informatik.uni-stuttgart.de/ipvr/bv/p3/p3.html에서 찾을 수 있다.
pC++/Sage++ 는 어떤 기본 "요소(element)" 클래스로부터 "객체들의 집합체(collections of objects)"를 사용하여 데이터-병렬 스타일 작업들을 허용하는 C++에 대한 언어 확장이다. 이것은 PVM에서 실행될 수 잇는 C++ 코드를 생성하는 선행 프로세서이다. 이것은 리눅스에서 작동하는가? 좀 더 많은 정보는 http://www.extreme.indiana.edu/sage/에서 찾을 수 있다.
SR (리소스 동기(Synchronizing Resources))는 리소스들이 그들이 공유하는 프로세스들과 변수들을 캡슐화하는 협력(concurrent) 프로그래밍 언어이다; 연산(operation)들이 프로세스 상호작용에 대한 주요 메카니즘을 제공한다. SR 은 호출과 서비스 작업들에 대한 메카니즘들의 새로운 정합을 제공한다. 결과적으로 모든 로컬 그리고 리모트 프로시저 호출, 랑데뷰, 메시지 전달, 동적 프로세스 생성, 멀티캐스트, 그리고 세마포어들이 지원된다. SR 은 또한 공유된(shared) 전역 변수들과 연산(operation)들을 지원한다.
이것은 리눅스로 포팅되었지만 그것으로 실행될 수 있는 병렬화가 무엇인지는 분명하지 않다. 좀 더 많은 정보는 http://www.cs.arizona.edu/sr/www/index.html에서 가능하다.
ZPL 은 공학과 과학 어플리케이션들을 지원하도록 고안된 배열-기반 프로그래밍 언어이다. 이것은 IronMan 이라고 불리는 단순한 메시지-전달 인터페이스에 대한 호출을 생성하며 이런 인터페이스를 구성하는 몇가지 함수들이 거의 모든 메시지-전달 시스템을 사용해서 쉽게 구현될 수 있다. 그러나 워크스테이션 클러스터들 상의 PVM 과 MPI, 그리고 리눅스가 지원되는 것이 주요 타겟이다. 좀 더 자세한 정보는 http://www.cs.washington.edu/research/projects/orca3/zpl/www/에서 찾을 수 있다.
특정한 마더보드, 네트웍 카드들 등을 어떤 것이 최고인가를 알아보려고 벤치마킹하는 데, 많은 시간을 소비하는 사람들이 많이 있다. 이런 것의 문제는 여러분이 어떤 것을 벤치마킹할 수 있을 때에는 이미 그것이 사용할 수 있는 것 중에 최고가 더이상 아니라는 것이다; 이것은 심지어 시장에서 사라지고 완전 다른 속성들을 가진 개선된 모델로 교체되었을수 있다.
PC 하드웨어를 사는 것은 오랜지 쥬스를 사는 것과 같다. 보통 이것은 라벨에 붙은 회사 이름이 무엇인지는 상관이 없고 아주 좋은 재로로 만들어진다. 구성 성분들(또는 오렌지 쥬스 농축액)이 무엇으로 만들어졌는지 신경쓰거나 아는 사람은 거의 없다. 즉, 여러분이 신경쓸 하드웨어 차이들은 별로 안된다. 여러분이 리눅스로 쓸 하드웨어에 대해서 기해할 수 있는 것이 무엇인가를 확실히 알고 빠른 배달, 좋은 가격, 그리고 반품에 대한 적절한 정책에 대해서만 신경을 집중하라는 것이 내 조언이다.
서로 다른 PC 프로세서들에 대한 훌륭한 개관은 http://www.pcguide.com/ref/cpu/fam/에 있다; 사실 완전한 WWW 사이트 http://www.pcguide.com/에는 PC 하드웨어의 좋은 기술적인 개관들이 모여 있다. 특정 하드웨어 설정들의 성능에 대해서 조금 아는 것도 유용하다. 그리고 리눅스 벤치마킹 HOWTO(Linux Benchmarking HOWTO) http://sunsite.unc.edu/LDP/HOWTO/Benchmarking-HOWTO.html가 시작하기에 좋은 곳이다.
인텔 IA32 프로세서들은 실행중인 시스템의 성능을 정교한 세부사항까지 측정하는 데 사용되는 많은 특수한 레지스터들을 가진다. 인텔 VTune, http://developer.intel.com/design/perftool/vtune/, 는 아주 완전한 코드-튜팅 시스템에서 성능 레지스터들을 넓게 사용한다... 이것은 불행하게도 리눅스에서 실행되지 않는다. 펜티엄 성능 레지스터들을 억세스하기 위한 로딩 가능한 모듈 장치 드라이버, 그리고 라이브러리 루틴들은 http://www.cs.umd.edu/users/akinlar/driver.html에서 찾을 수 있다. 이런 성능 레지스터들은 다른 IA32 프로세서들과 다르다는 것을 기억하자; 이런 코드는 486, Pentium Pro, Pentium II, K6 등과는 작동하지 않고 Pentium에 대해서만 작동한다.
성능에 대한 다른 언급은, 커다란 클러스터들을 만들고 그것을 조그만 공간에 넣고자 하는 사람들에 특별히, 적절하다. 적어도 요즘의 어떤 프로세서들은 온도 센서를 내장하고 있고 운영 온도가 너무 높을 때 내부 클럭을 늦추는 데 사용되는 회로들(열 생성을 줄이고 신뢰도를 높이는 시도)을 가지고 있다. 나는 모든 사람들이 펠티에
역자주: 펠티에 효과 - 이종(異種)의 금속 접촉면에 약한 전류가 흘렀을 때 열이 발생 또는 흡수되는 현상장치(열 펌프)를 사서 각 CPU를 식힐 필요는 없다고 제안하지만 높은 운영 열이 성분들의 사용시간을 줄일뿐만 아니라 - 시스템 성능을 직접 줄일 수도 있다는 것을 알아야 한다. 여러분의 컴퓨터들을 공기흐름을 차단하는 물리적 배치속에 놓지 말고 제한된 영역안에서 열을 잡아라. 기타 등등.
마지막으로 성능이란 단순히 속도뿐만이 아니고 신뢰도와 가용성도 포함된다. 높은 신뢰도란 여러분의 시스템이, 비록 구성 요소들이 실패하더라도, 거의 절대로 죽지(crash) 않는다는 것을 의미한다... 이것은 일반적으로 여분의 파워 공급기와 핫-스왑 마더보드와 같은 특수 기능들을 요구한다. 이것은 보통 싸지 않다. 높은 가용성이란 거의 모든 시간에 사용 가능하다는 개념을 말한다... 시스템은 그 구성요소가 실패할 때 죽을 수도 있지만 시스템은 재빨리 고쳐지고 리부팅된다. 많은 기본 이슈들을 논의한 High-Availability HOWTO가 있다. 그러나 클러스터에 대해서 특별히, 높은 가용성은 몇개의 여분을 가지는 것으로 쉽게 획득될 수 있다. 나는 적어도 한개의 여분을 권장하는 바이고 커다란 클러스터에서 16개 기계마다 하나씩의 여분을 적어도 가지는 것을 선호한다. 잘못된 하드웨어를 버리고 그것을 여분의 것으로 교체하는 것은 유지보수 계약보다도 더 높은 가용성과 더 낮은 비용을 얻을수 있도록 한다.
그래 리눅스를 사용해서 병렬 처리를 하는 사람이 있는가? 그렇다!
많은 사람들이 많은 병렬-처리 슈퍼컴퓨터 회사들이 죽는다는 것이 병렬 처리가 시들시들해지기 시작한다는 것을 의미하는 것이 아닌가하고 생각했던 것은 아주 오래 전의 일이 아니다. 나는 그당시 그럴 것이라고 생각하지 않았고(내가 실제로 일어날 것이라고 생각한 것에 대한 것을 재미거리로 보려면 http://dynamo.ecn.purdue.edu/~hankd/Opinions/pardead.html를 참조하기 바란다), 병렬 처리가 지금 또다시 일어서고 있는 것은 명백한 사실이다. 심지어 얼마전에 병렬 슈퍼컴퓨터를 만드는 것을 중지한 Intel이 MMX와 앞으로 나올 IA64 EPIC (Explicitly Parallel Instruction Computer)과 같은 것들에서 병렬 처리 지원을 한다고 자랑하고 있다.
여러분이 선호하는 검색 엔진에서 "Linux"와 "paralle'을 검색한다면 여러분은 몇개의 사이트들이 리눅스를 사용한 병렬 처리에 포함된다는 것을 알게 될 것이다. 특별히 Linux PC 클러스터들은 모든 곳에서 떠오르는 것처럼 보일 것이다. PC 하드웨어의 저비용 고성능과 합쳐서 리눅스의 적절함(appropriateness)는 리눅스를 사용한 병렬 처리를 작고, 예산이 적은 그룹들과 크고 예산이 많고 국가적인 연구소들 모두의 인기있는 슈퍼컴퓨팅 접근으로 만들었다.
이 문서 도처에 있는 다양한 프로젝트들이 비슷한 병렬 리눅스 설정을 가지는 "유사한" 연구 사이트들 리스트를 관리한다. 그러나 http://yara.ecn.purdue.edu/~pplinux/Sites/에, 병렬 처리에 리눅스 시스템들을 사용하는 다양한 사이트들의 사진, 설명, 그리고 연락 정보들을 제공하기 위해서 고안된 문서들이 있다.
현재 리스트에는 14개의 클러스터들이 있지만 우리는 적어도 수십개의 클러스트들이 전세계에 있다는 것을 안다. 물론 리스트가 암시나 보증, 기타 등등을 의미하지 않는다; 우리는 단지 리눅스를 사용한 병렬 처리를 포함한 인식, 연구, 그리고 협력을 증진하기를 바랄뿐이다.