OpenMP란 무엇인가?

OpenMP는 공유 메모리 환경에서 프로그램을 병렬화 하는 표준 입니다. OpenMP 는 컴파일러 지시자, 런타임 루틴 그리고 포트란, C, C++ 프로그램에서 공유 메모리 병렬화를 지정할때 프로그래머가 사용할 수 있는 환경 변수등을 제공합니다.

OpenMP 컴파일러 지시자는 프로그램내에서 사용되며 OpenMP를 인식하는 컴파일러가 멀티 쓰레드를 이용해서 병렬로 실행되는 실행파일을 생성하도록 지시 합니다. 소스 코드의 많은 수정이 필요 없습니다(최고의 퍼포먼스를 얻기 위해 튜닝을 할때를 빼고). OpenMP 컴파일러 지시자는 여러분이 다양한 아키텍쳐와 시스템 상에서 프로그램을 병렬화 하기 위한 우아하고, 일관적이고 포터블한 인터페이스를 사용 가능하도록 합니다. OpenMP는 광범위하게 채용되는 표준으로써 Sun, IBM, Intel, SGI 등이 지원하고 있습니다. (하단의 참고자료 링크를 이용해서 최신의 OpenMP 표준 문서를 확인하시기 바랍니다.)

OpenMP 는 쓰레드를 생성하고 관리해 줌으로써 병렬 프로그래밍을 좀더 발전된 레벨로 끌어 올려 줍니다. 여러분이 해야할일은 단순히 적절한 컴파일러 지시자를 소스 프로그램에 삽입시키고 OpenMP 를 지원하는 컴파일러를 이용해서 프로그램을 컴파일 하고 적절한 컴파일러 옵션을 사용 하는 것입니다 (썬 스튜디오는 -xopenmp 컴파일러 옵션을 사용). 컴파일러는 컴파일러 지시자를 해석하고 코드를 병렬화 시킵니다. OpenMP 를 지원하지 않는 컴파일러는 OpenMP 구문을 조용히 무시해 버립니다.

이 글은 OpenMP를 C 와 C++ 프로그램에서 사용하는 예제를 제공하지만 동일한 프로그램이 포트란95 에도 존재 합니다. OpenMP 유저 가이드에서 좀 더 상세한 정보를 알아보시기 바랍니다.

OpenMP 컴파일러 지시자

OpenMP 표준은 컴파일러 지시자의 셋을 정의 합니다. 지시자는 컴파일러에게 코드의 블럭을 어떻게 처리할 것인지를 알려 줍니다. 가장 많이 쓰이는 기본 지시자는 #pragma omp parallel 로 병렬화 구역 임을 나타 냅니다.

OpenMP 는 병렬 실행시에 fork-join 모델을 사용 합니다. OpenMP 프로그램은 초기 쓰레드라고 하는 싱글 쓰레드로 시작 합니다. 쓰레드가 병렬 구조를 만나면 그 자신과 0개 혹은 그 이상의 추가 쓰레드로 구성된 쓰레드 팀을 만든 다음 그 자신이 새로운 팀의 마스터가 됩니다. 새로운 팀의 모든 멤버(마스터를 포함)는 병렬 구조상에서 코드를 실행 합니다. 병렬 구조의 끝에는 암묵적인 장벽이 존재 합니다. 오직 마스터 쓰레드만이 병렬 구문 이후의 유저 코드를 계속해서 실행할 수 있습니다.

병렬 지역을 실행하는 팀의 쓰레드 갯수는 몇가지 방법으로 조정할 수 있습니다. 한가지 방법은 환경 변수 OMP_NUM_THREADS 를 이용하는 것입니다. 또다른 방법은 런타임 루틴 omp_set_num_threads() 를 호출 하는 것입니다. 또 다른 방법은 num_threads 절을 parallel 컴파일러 지시자와 같이 사용하는 것입니다.

OpenMP 는 두가지 기본 두가지의 작업-공유 구조를 지원해서 병렬 지역 내의 작업이 팀 내의 쓰레드 간에 나뉘어 질 수 있도록 지정할 수 있습니다. 이러한 작업-공유 구조는 루프와 섹션 입니다. 루프를 위해 #pragma omp 이 사용 되고 #pragma omp sections 가 섹션 을 위해 사용 됩니다 — 병렬로 수행될 수 있는 코드의 블럭들.

#pragma omp barrier 는 팀의 모든 쓰레드가 장벽 이후의 코드를 계속 수행 하기 전에 다른 다른 쓰레드를 기다리도록 합니다. 이것은 병렬 지역의 끝에 암묵적인 장벽이라고 합니다. #pragma omp master 은 컴파일러에게 이후의 블럭은 오직 마스터 쓰레드에 의해서만 실행되도록 합니다. #pragma omp single 은 팀의 오직 하나의 쓰레드만이 해당 코드의 블럭을 실행시키도록 지시 합니다; 이 쓰레드는 꼭 마스터 쓰레드가 되어야 할 필요는 없습니다.여러분은 #pragma omp critical 지시자를 이용해서 오직 한번에 하나의 쓰레드만에 의해서 코드 블럭이 실행되도록 보호할 수 있습니다. 물론 이러한 지시자는 오직 parallel 지시자 안에서만 의미가 있습니다 (병렬 지역).

OpenMP 런타임 루틴

OpenMP 는 프로그램 상의 쓰레드에 대한 정보를 얻을 수 있는 몇가지 런타임 루틴을 제공 합니다. 것은 omp_get_num_threads(), omp_set_num_threads(), omp_get_max_threads(), omp_in_parallel(), 와 다른 루틴들을 포함합니다. 추가적 적으로 OpenMP 는 몇가지 lock 루틴을 제공해서 쓰레드 동기화에 사용할 수 있도록 해 줍니다.

OpenMP 환경 변수들

OpenMP 는 OpenMP 프로그램의 동작을 조정할 수 있는 몇가지 환경 변수들을 제공합니다.

가장 중요한 환경 변수는 OMP_NUM_THREADS 로 병렬 지역을 실행할때 사용되는 팀내의 쓰레드 갯수를 조정합니다 (팀의 마스터 쓰레드도 포함). 널리 사용되는 또 다른 환경 변수는 OMP_DYNAMIC 입니다. 이 환경 변수를 FALSE 로 설정함으로써 구현적으로 실행시에 동적인 쓰레드 갯수 조정을 비활성화 시킬 수 있습니다. 일반적인 규칙은 시스템상의 코어 보다 적은 숫자의 쓰레드 숫자를 지정하는 것입니다.

표준 OpenMP 환경 변수에 덧붙여서 썬 스튜디오 컴파일러는 썬-특수한 환경 변수의 셋을 추가 시켜서 런타임 환경을 좀 더 조정할 수 있도록 해 줍니다. 이러한 것들은 OpenMP 유저 가이드에 설명되어 있습니다.

예제

간단한 행렬 곱하기 프로그램을 이용해서 OpenMP가 어떻게 프로그램을 병렬화 시키는지 알아 봅시다. 다음의 코드 부분은 2개의 행렬을 곱하는 것입니다. 이것은 매우 간단한 예제로써 진짜로 훌륭한 행렬 곱셈 루틴을 원한다면 캐시 효과를 고려하거나 좀 더 낳은 알고리즘을 사용해야 합니다. (Strassen 혹은 Coppersmith 와 Winograd 의 알고리즘 등).

for (ii = 0; ii < nrows; ii++) {
 for (jj = 0; jj < ncols; jj++) {
 for (kk = 0; kk < nrows; kk++) {
 array[ii][jj] = array[ii][kk] * array[kk][jj];
 }
 }
}

위의 루프로 감싸진 각 레벨에서 각 루프 반복은 독립적으로 수행될 수 있습니다. 그러므로 위의 코드 세그먼트의 병렬화는 매우 직관적입니다: #pragma omp parallel for 지시자를 제일 외곽쪽의 루프 전에 (ii 루프) 추가시킵니다. 지시자를 제일 외곽쪽 루프에 삽입하는 것이 이득입니다. 왜냐하면 이것이 최고의 퍼포먼스 이득을 가져다 주기 때문입니다. 병렬화된 루프에서 변수 array, ncols 와 nrows 는 쓰레드간에 공유 되고 ii, jj, 와 kk 는 각 쓰레드에 독립적입니다. 이제 이전의 코드는 다음과 같이 변경됩니다:

#pragma omp parallel for shared(array, ncols, nrows) private(ii, jj, kk)
for (ii = 0; ii < nrows; ii++) {
 for (jj = 0; jj < ncols; jj++) {
 for (kk = 0; kk < nrows; kk++) {
 array[ii][jj] = array[ii][kk] * array[kk][jj];
 }
 }
}

또다른 예제로 0 <= x < n. 구간에서 f(x) 의 합을 구하는 다음의 코드 부분을 보시기 바랍니다.

for (ii = 0; ii < n; ii++) {
 sum = sum + some_complex_long_fuction(a[ii]);
}

위의 코드를 병렬화 하기 위해서 첫번째 단계는 다음과 같습니다.

#pragma omp parallel for shared(sum, a, n) private(ii, value)
for (ii = 0; ii < n; ii++) {
 value = some_complex_long_fuction(a[ii]); 

 #pragma omp critical
 sum = sum + value;
}

혹은 좀더 낳은 방법으로 reduction 절을 이용할 수 있습니다

#pragma omp parallel for shared(a, n) private(ii) reduction(+: sum)
for (ii = 0; ii < n; ii++) {
 sum = sum + some_complex_long_fuction(a[ii]);
}

시작하기

프로그램을 병렬화 시키는 방법은 여러가지가 있습니다. 첫째로 여러분이 병렬화가 필요한지 결정합니다. 몇몇 알고리즘은 병렬화에 적당하지 못합니다. 만약 새로운 프로젝트를 시작한다면 여러분은 병렬화가 가능한 알고리즘을 선택할 수 있습니다. 코드가 올바른지 (직렬환경에서) 확인하는 것이 병렬화를 시도 하기 전에 가장 중요 합니다. 직렬화된 실행시간을 반드시 측정해서 병렬화가 유용한지에 대해서도 판단하시기 바랍니다.

직렬로 실행되는 버전을 최적화 옵션을 이용해서 컴파일합니다. 컴파일러는 보통 여러분이 할 수 있는 것 보다 더 많은 최적화작업을 수행할 수 있습니다.

프로그램을 병렬화할 준비가 되었다면 썬 스튜디오의 수 많은 기능과 툴들이 여러분의 목적을 이루도록 도와줄 것입니다. 간단하게 이러한 기능들에 대해 설명합니다.

자동 병렬화

컴파일러의 자동 병렬화 옵션을 사용해 봅니다 (-xautopar). 병렬화를 컴파일러에게 넘김으로써 여러분이 노력할 필요 없이 컴파일러가 알아서 프로그램을 병렬화 해줍니다. 자동병렬화는 또한 OpenMP 지시자를 이용해서 병렬화 할수 있는 코드의 부분들을 인식할 수 있도록 도와주고 반대로 병렬화를 하지말아야 할 코드의 부분(예를 들어 내부 루프 의존 같은)도 알려 줍니다. 여러분은 컴파일러가 알려주는 정보를 -g 플래그를 이용해서 프로그램을 컴파일 해서 썬 스튜디오의 er_src(1) 를 이용함으로써 확인할 수 있습니다.

 % cc -g -xautopar -c source.c
 % er_src source.o

자동범위지정

OpenMP 프로그램시에 일반적인 타입의 오류는 범위 지정의 오류 입니다. 즉 변수의 범위가 잘못 지정되어서, 예를 들어 private(shared) 로 지정되어야 할 변수가 shared (private) 로 지정되는 것 입니다. 자동범위 지정 기능은 썬 스튜디오 컴파일러가 변수의 범위를 자동으로 결정해 줍니다. 두가지 OpenMP 의 확장 기능이 지원됩니다: __auto 절과 default(__auto) 절. OpenMP 의 유저 가이드에서 자세한 내용을 확인하시기 바랍니다.

dbx 디버거

썬 스튜디오 디버거 dbx 는 쓰레드 디버깅이 가능한 디버거로 여러분의 OpenMP 프로그램을 디버깅하는데 도움을 줍니다. OpenMP 프로그램을 디버깅 하려면 첫째로 -xopenmp=noopt -g 컴파일러 옵션을 이용해서 어떠한 최적화도 적용하지 않은채 컴파일하고 dbx 를 결과 실행파일을 이용해서 실행합니다. dbx 를 이용해서 여러분은 병렬 지역에 브레이크 포인트를 설정할 수 있고 병렬 지역을 순차적으로 실행시킬 수 있고 쓰레드에 private 한 변수를 검사 할 수 있고 기타 여러가지 작업을 할 수 있습니다.

퍼포먼스 분석기

썬 스튜디오 퍼포먼스 분석기를 통해 프로그램의 병목현상을 잡아낼 수 있습니다. 이 툴은 사용자가 대부분의 시간이 소요되는 핫 루틴을 프로그램상에서 잡아낼 수 있습니다. 또한 작업 및 대기 시간, 함수의 속성, 소스 라인, 그리고 명령어등 OpenMP 프로그램의 병목현상을 잡아 낼 수 있도록 도와 줍니다.

OpenMP 와 MPI 혼용하기

MPI (Message Passing Interface) 는 병렬 프로그램의 또 다른 모델입니다. OpenMP 와는 다르게 MPI 는 여러개의 프로세스를 실행시키고 TCP/IP 를 통해 통신 합니다. 이러한 프로세스들은 동일한 주소 공간을 공유하지 않기 때문에 원격 머신에서 실행 될 수 있습니다(혹은 클러스 환경). OpenMP 와 MPI 중 어느것이 더 낳다고 말하기는 어렵습니다. 두가지 모두 장단점이 존재 합니다. 더 흥미로운 점은 OpenMP 가 MPI 와 함께 사용될 수 있다는 것입니다. 일반적으로 MPI 를 사용해서 작업을 여러 머신으로 정련되지 않은 채로 분산시킨 다음 OpenMP 를 이용해서 각 싱글 머신의 병렬화 레벨을 좀더 향상 시키는 방법을 사용 합니다.

요약하자면 썬 스튜디오 컴파일러와 툴은 OpenMP 를 네이티브하게 지원하고프로그램을 병렬화 할 수 있는 수 많은 유용한 기능을 제공 합니다. 자세한 정보는 아래의 참고자료 섹션을 참고 바랍니다.

Resources

• OpenMP specifications for C/C++ and Fortran 95. Includes examples and commentary.
• compunity.org  The OpenMP User Community.
• Techniques for Optimizing Applications by Rajit Garg and Ilya Sharapov. A practical guide to performance optimization of computationally intensive programs on Sun UltraSPARC platforms. A Sun Blueprint publication.
• Sun Studio 11: OpenMP API User’s Guide. This manual contains information specific to the Sun Studio implementation.
• Parallel Programming in OpenMP by Rohit Chandra and others is a good introduction, and is published by Morgan Kaufmann. ISBN 1-55860-671-8.
• OpenMP Support in Sun Studio Compilers and Tools

위의 명령을 내리면 X11의 설정파일 내용을 볼 수 있다. 그 중

위의 섹션 내용 중 아래와 같은 옵션이 있는지 확인하고 없다면 아래 내용을 섹션 내에 삽입한다.

X를 다시 시작하고(뭔소린지 모른다면 재부팅) 로그인 한 뒤 터미널에서 아래와 같은 명령을 내리면 터치패드가 꺼진다.

$ synclient TouchpadOff=1

다시 아래와 같은 명령을 내리면 켜진다.

$ synclient TouchpadOff=0

로그인과 동시에 터치패드를 끄고 싶다면 세션의 시작 프로그램 에 넣는다.
[System] -> [기본설정] -> Startup Program ->Add -> 위의 명령 삽입

다시로그인 하면 터치패드가 꺼져있는 것을 확인 할 수 있다.

다음은 make 에 의해서 생성될 수 있는 가장 일반적인 에러들의 리스트이며 그것들이 의미하는 바와 그것들을 고치는 방법에 대한 정보이다.

때때로 make 에러들은, 특별히 명령 스크립트 라인에서 - 접두사가 있을 때나 명령 라인 옵션으로써 -k 가 있을 때, 치명적인 것이 아니다. 치명적인 에러들은 *** 문자열이 그 앞에 붙는다.

에러 메시지들은 모두 프로그램(보통 `make’)의 이름이 앞에 붙거나, 에러가 makefile 안에 있는 것이라면 문제를 담고 있는 파일과 라인넘버가 앞에 붙는다.

아래 테이블에서 이런 공통 접두사들이 빠져있다.

`[foo] Error NN‘

`[foo] signal description‘

이런 에러들은 실제로 make 에러들이 전혀 아니다. 그들은 make 가 명령 스크립트의 일부로써 호출한 프로그램이, make 가 실패로 해석하는 0이 아닌 에러 코드 (`Error NN‘) 를 리턴하거나 다른 이상한 스타일로(어떤 종류의 시그널과 함께) 종료하였다는 것을 의미한다. *** 가 메시지에 붙어 있지 않으면 서브프로세스가 실패했지만 makefile 의 그 규칙이 특수 문자 - 를 앞에 달고 있어서 make 가 그 에러를 무시한 것이다.

`missing separator. Stop.’

이것은 make 의 일반적인 “Huh?” 에러 메시지이다. 이것은 make 가 makefile 의 이 라이을 파싱하면서 완벽하게 성공하지 못했다는 것을 의미한다. 이것은 기본적으로 “문법 에러(syntax error)” 를 의미한다. 이런 메시지가 나오는 가장 일반적인 이유들 중의 하나는 여러분이 (또는 많은 MS-Windows 에디터들의 경우와 비슷하게, 여러분의 에디터가) TAB 문자 대신에 공백들로 명령 스크립트들을 들여쓰기하려고 하는 것이다. 명령 스크립트에 있는 모든 라인은 반드시 TAB 문자로 시작하는 것을 기억하자. 8개의 공백은 의미가 없다.

`commands commence before first target. Stop.’

`missing rule before commands. Stop.’

이것은 makefile 에서 처음으로 나오는 것이 명령 스크립트의 일부분인 것처럼 보인다는 것을 의미한다: 이것은 TAB 문자로 시작하고 합법적인 make 명령(변수 할당과 같은)처럼 보이지 않는다. 명령 스크립트들은 항상 어떤 타겟과 연결되어 있어야 한다. 두번째 형태는 그 라인이 첫번째 공백문자가 아닌 문자로써 세미콜론을 가진다면 생성된다; make 는 이것을, 어떤 규칙의 “target: dependency” 섹션을 그냥 떠났다는 것으로 해석한다.

`No rule to make target `xxx‘.’

`No rule to make target `xxx‘, needed by `yyy‘.’

이것은 make 가 타겟을 빌드할 필요가 있다고 판단했지만 makefile 안에서 그렇게 하는 것에 대한, 명시적 또는 묵시적(디폴트 규칙 데이터베이스를 포함해서) 규칙들(instructions)도 찾을 수 없다는 것을 의미한다. 그 파일이 빌드되기를 원한다면 그 타겟이 빌드되는 방법을 설명하는 규칙을 추가할 필요가 있다. 이 문제의 다른 가능성은 makefile 을 오자(그 파일 이름이 잘못되었다)했거나 소스 트리가 잘못된 경우이다(그 파일이 빌드될 것으로 생각된 것이 아니고 단지 종속물이다).

`No targets specified and no makefile found. Stop.’

`No targets. Stop.’

전자는 명령행에서 빌드될 타겟을 하나도 제공하지 않았고 make 가 읽어들일 makefile 들을 찾을수 없다는 것을 의미한다. 후자는 어떤 makefile 들이 찾아졌으나 디폴트 타겟이 없고 어떤 것도 명령행에서 주어지지 않았다는 것을 의미한다. 이들 경우에 GNU make 는 아무것도 하지 않는다.

`Makefile `xxx‘ was not found.’

`Included makefile `xxx‘ was not found.’

명령행에서 주어진 makefile (첫번째 형태) 또는 포함된 makefile (두번째 형태) 가 없다.

`warning: overriding commands for target `xxx”

`warning: ignoring old commands for target `xxx”

GNU make 는 타겟 하나에 대해서 단 한번만 명령들이 지정되는 것을 허락한다(더블-콜론 규칙들을 제외하고). 이미 명령들을 가지도록 정의된 타겟에 대해서 명령들을 다시 주면 이 경고가 발행되고 두번째 명령들은 첫번째 것을 오버라이드할 것이다.

 

`Circular xxx <- yyy dependency dropped.’

make 가 종속성 그래프에서 루프를 발견했다는 것을 의미한다: 타겟 xxx 의 종속물 yyy, 그리고 이것의 종속물들 등등 을 추적한 후 그들중 하나가 xxx 에 다시 종속한다는 의미이다.

 

`Recursive variable `xxx‘ references itself (eventually). Stop.’

이것은 확장될 때 자기자신(xxx)을 참조할 일반 (재귀적인) make 변수 xxx 를 정의했다는 것을 의미한다. 이것은 허용되지 않는다; 단순-확장 변수 (:=) 를 사용하든지 아니면 추가 연산자 (+=) 를 사용하자.

 

`Unterminated variable reference. Stop.’

이것은, 변수나 함수 참조에서 적절하게 닫는 괄호나 중괄호를 제공하는 것을 잊었다는 것을 의미한다.

 

`insufficient arguments to function `xxx‘. Stop.’

이것은 이 함수에 대해서 필요한 개수의 매개변수들을 제공하지 않았다는 것을 의미한다. 매개변수들의 설명에 대해서는 그 함수의 문서를 보자.

`missing target pattern. Stop.’

`multiple target patterns. Stop.’

`target pattern contains no `%’. Stop.’

이들은 잘못된 정적 패턴 규칙들에 대해서 생성된다. 첫번째는 규칙의 타겟 섹션에 어떤 패턴도 없다는 것을 의미하고, 두번째는 타겟 섹션에 다수의 패턴들이 있다는 것을 의미하며, 세번째는 타겟이 패턴 문자 (%) 를 담고 있지 않다는 것을 의미한다.

Makefile:17: *** missing separator. Stop.

Makefile을 작성할 때 명령어(command)부분은 모두 TAB 문자로 시작해야 한다고 첫 번째 장부터 강조하였다. 위의 에러는 TAB 문자를 쓰지 않았기 때문에 make가 명령어인지 아닌지를 구별 못하는 경우이다.

대처: 17번째 줄(근처)에서 명령어가 TAB 문자로 시작하게 바꾼다.

make: *** No rule to make target `io.h', needed by `read.o'. Stop.

위의 에러는 의존 관계에서 문제가 발생했기 때문이다. 즉 read.c가 io.h에 의존한다고 정의되어 있는데, io.h를 찾을 수 없다는 에러이다.

대처: 의존 관계에서 정의된 io.h가 실제로 존재하는지 조사해 본다. 없다면 그 이유를 한번 생각해 본다. make dep를 다시 실행시켜서 의존 관계를 다시 생성시켜 주는 것도 하나의 방법이다.

Makefile:10: *** commands commence before first target. Stop.

위 의 에러는 ‘첫 번째 타겟이 나오기 전에 명령어가 시작되었다’는 애매한 에러 메시지이다. 필자가 경험한 이 에러의 원인은 주로 긴 문장을 여러 라인에 표시를 하기 위해서 ”를 사용할 때, 이를 잘못 사용했기 때문인 것 같다. 즉 ”부분은 라인의 가장 끝문자가 되어야 하는데 실수로 ”뒤에 스페이스를 몇 개 집어넣으면 여지없이 위의 에러가 발생한다.

대처: 10번째 줄(근처)에서 ”문자가 있거든 이 문자가 라인의 가장 끝문자가 되도록 한다. 즉 ”문자 다음에 나오는 글자(스페이스가 대부분) 는 모조리 없애 버린다.

make를 수행시키면 의도했던 실행 파일은 안생기고 이상한 행동만 한다. 가령 make clean 했을 때와 같은 행동을 보인다.

make는 천재가 아니라는 점을 생각해야 한다. make는 Makefile의 내용을 읽다가 첫 번째 타겟으로 보이는 것을 자신이 생성시켜야 할 결과 파일이라고 생각한다. 따라서 clean 부분을 Makefile의 첫번째 타겟으로 정해 버리면 위와 같은 결과가 나타나게 된다.

대 처: 예제 7.1에서 all 이라는 필요 없는 타겟을 하나 만들어 두었다. 이것은 make가 all 을 첫 번째 타겟으로 인식시키기 위함이었다. 따라서 자신이 생성시키고 싶은 결과 파일을 첫 번째 타겟이 되게 하던지, 아니면 예제 7.1처럼 all과 같은 더미 타겟(dummy target)을 하나 만들어 둔다. 그리고 make clean, make dep 같은 부분은 Makefile의 끝부분에 만들어 두는 것이 안전하다.

이미 컴파일했던 파일을 고치지 않았는데도 다시 컴파일한다.

이 행동은 make가 의존 관계를 모르기 때문이다. 즉 사용자가 의존 관계를 설정해 주지 않았다는 말이 된다. 따라서 make는 무조건 모든 파일을 컴파일해서 실행 파일을 만드는 일이 자신이 할 일이라고 생각하게 된다.

대처: 목적 파일, 소스 파일, 헤더 파일들의 의존 관계를 설정해 주어야 한다. gccmakedep *.c 라고 하면 Makefile의 뒷부분에 자동적으로 의존 관계를 만들어 준다. 그외의 다른 파일들에 대해서는 사용자가 적절하게 의존 관계를 설정해 주어야 한다.

main.o : main.c io.h

read.o : read.c io.h

write.o : write.c io.h

위의 예제는 첫 번째 장에서도 제시했던 건데… TARGET : DEPENDENCY의 형식으로 의존 관계를 작성한 것이다. (make에게 의존 관계를 알려주는 방법이죠)

1. 그 외의 경우에 대해서는 각자가 한번 원인과 결과를 알아보기 바란다. 그리고 팁의 형식으로 글을 올린다면 다른 사람에게도 많은 도움이 될 것이다. 일단 make에서 에러를 내기 시작하면 초보자는 원인조차 모르는 경우가 많기 때문이다.

강좌를 마치면서
이번 make 강좌는 make 유틸리티에 대한 전반적인 이해와 간단한 Makefile 작성을 목적으로 하였습니다. make에 관한 모든 것을 다 소개하지는 않았습니다. (개인적인 능력의 한계 !!) make를 아주 잘 쓰기 위해서는 make 자체에 대한 지식보다는 유닉스(리눅스)의 샐 프로그램과 고난이도(?)의 명령어까지 알고 있어야 하기 때문이죠. 해커가 되려면 이런 지식을 많이 알고 있어야 합니다. 한가지 아쉬운 게 imake에 대해서 설명을 못한 것입니다. imake에 대해서는 make 중급코스란 이름으로 언젠가 강좌를 해보도록 하죠. imake는 Makefile을 생성시켜 준다고 생각하세요)
지 금 make 다음의 강좌로 뭘해야 할지 고민 중입니다. 우선 X 강좌를 하시는 분(아직은 조용하네요)의 강좌의 이해를 높이기 위해서 X의 개념을 2회 정도의 강좌로 할 생각입니다. X 가 왜 X 이고 어떤 특징을 가지고 있는지 한번 살펴보기로 하죠.

원본 : http://wiki.kldp.org/koreandoc/html/gnu ··· e-8.html

cycle length:
sum latencies of ops in the cycle