소개

어플리케이션이 컴파일될때 컴파일러는 최적화된 명령어 사용과 코드의 최적화된 배열을 위해 최선을 다 하게 됩니다. 이러한 작업은 소스코드에 바탕을 두고 이루어 집니다. 그러나 소스 코드에는 코드의 동적인 동작에 대한 정보를 포함하고 있지 않습니다;그래서 컴파일러는 'best-guess'라는 방법을 제공합니다.

이 방법을 통해 코드를 배열하고 루틴들이 포함되어 지고 어떠한 코드들이 자주 실행되고 하는 것들을 결정하게 됩니다.

컴파일러가 코드를 다룰때 겪는 대표적인 예를 예제 1번을 통해 알아보겠습니다:

예제 1번의 코드는 컴파일러가 매우 흥미로운 결정을 하는 것을 보여 줍니다; 코드를 배열하는 다양한 방법이 있습니다. 컴파일러는 A와 B를 기본적으로 make해야 할까요 아니면 코드를 재배열해서 서로 같은 퍼포먼스를 갖도록 해야 할까요?

문제는 컴파일러가 어떻게 수많은 방법이 존재하는 코드 배열방식을 결정하여 최상의 방법으로 배열할것이냐 하는 것 입니다. 다른 결정들의 예를 보겠습니다.:

• 자주 실행되는 루틴이 인라인되어 진다면 성능 향상이 가능할 것인가?
• 코드가 어떻게 메모리에 배열되어 져서 캐시를 좀더 효과적으로 사용할 것인가?
• 자주 실행되는 루프들을 분리하는 것이 더 좋을것인가?

이러한 결정들은 오직 정형화된 방법에 의해서만 관리되어 지고 컴파일러는 런타임시에 프로그램에 어떠한 일이 발생하는지에 대해 전혀 알지 못합니다. 어쨌든 profile feedback이란 메카니즘을 통해 컴파일러는 대표적인 'training' 데이타셋을 실행하여 프로그램이 런타임시에 발생하는 정보를 얻을 수 있게 해 줍니다.

profile feedback을 이용하여 벤치마크 스윗인 SPEC CPU2000으로 성능을 체크해본 결과 부동소숫점 연산에서 7%, 정수 연산에서 16% 정도의 평균적인 성능향상이 있었습니다. 스윗에 포함된 코드는 아예 성능 향상이 없는 경우도 있었고 엄청난 성능향상을 보여준 경우도 있었습니다.

profile feedback을 이용한 빌딩

profile feedback는 아주 짧은 시간동안 프로그램을 실행시키고 그동안에 프로그램에 발생한 데이타를 수집하는 것입니다. 컴파일러는 이 데이타를 이용하여 최적화 방법을 결정하게 됩니다.

profile feedback의 처리 순서는:

1. 바이너리는 -xprofile=collect 플래그를 이용하여 빌드합니다. 이 플래그는 스페셜한 버전의 어플리케이션을 생성하고 실행중에 발생한 데이타를 수집합니다.
   
2. 그때 어플리케이션은 'training' workload와 함께 실행됩니다. 'training' workload는 어플리케이션이 실제로 수행해야할 대표적인 작업이지만 시간이 진짜 workload만큼 오래 걸리지 않는 작업입니다.
   
3. 바이너리를 -xprofile=use 플래그를 사용하여 리빌드합니다. 이 플래그는 수집된 데이타를 이용해 프로그램을 최적화하는데 사용됩니다.

즉 profile feedback을 사용하면 사용하지 않았을때 보다 두배의 작업이 필요합니다. 왜냐하면 빌드는 컴파일러의 두가지 과정을 거치고 거기다 더해서 약간의 실행시간이 더해지기 때문입니다. 런타임시에 얻을 수 있는 퍼포먼스 향상은 복잡한 빌드 과정을 필요로 할 가치가 있습니다.

대표적인 workload 정하기

profile feedback을 이용해 빌드하는 데에는 런타임시에 어플리케이션의 행동에 대한 정보를 얻기 위한 대표적인 'training' workload가 필요합니다. workload의 키포인트들은 다음과 같습니다:

• 작업시간이 짧아야 합니다. 긴시간의 작업은 필요하지 않습니다.
  
• workload는 어플리케이션의 모든 중요한 작업을 구현할 수 있어야 합니다. Sun Studio Performance Analyzer 또는 tcov(1) 같은 툴은 training workload가 코드의 가장 중요한 부분을 커버하는지 검사해 볼 수 있고, 실제 workload와 비슷한지에 대해서도 조사가 가능합니다.
  
• 몇가지 training workload는 실제로 전체 코드의 성능향상에 도움이 될 수 있습니다.

몇가지 위험한 점은 잘못된 'training' workload를 사용할 경우 오히려 성능을 떨어뜨린다는 점입니다. 왜냐하면 다음과 같은 두가지 이유 때문입니다:

• 'training' workload는 전체 어플리케이션을 커버해주지 못할 수도 있습니다.
  
• 문제가 있는 워크로드의 동작은 실제 'training' workload의 동작과는 심각하게 다릅니다.

두가지 경우 모두 다른 'training' workload를 추가하여 문제 있는 workload의 성능향상을 가져올 수 있습니다. 코드를 보거나 다양한 루틴의 실행시간을 검사하여 퍼포먼스의 차이가 어디서 오는지 알아 볼 수도 있습니다. 'training' workload가 다른 workload의 실행을 느리게 할경우는 드뭅니다. 오히려 'training' workload가 특정부분의 최적화가 필요 없음을 알려 줄 수 있고 추가적인 'training' workload를 통해서 다른 workload가 퍼포먼스에 영향을 주지 않지 않음을 알 수도 있습니다.

profile feedback의 이익

더 많은 정보를 컴파일러가 가질 수록 좀 더 좋은 최적화를 할 수 있습니다. 모든 최적화 과정을 통해서 어떤 코드는 엄청나게 향상될 수 있고 또 그렇지 않은 경우도 있습니다. 그것은 전적으로 코드의 종류에 달려 있습니다.

profile feedback을 통해 이익을 얻을 수 있는 코드는 엄청난 수의 조건문(if 같은) 을 포함하고 있거나, 예측 가능한 행동을 내포하는 코드들입니다. 그러나 그런 행동들은 컴파일러가 명확하게 알지 못합니다.

이러한 코드의 간단한 예로 값을 체크하는 것을 들 수 있습니다. 컴파일러는 프로그래머가 값의 옳고 그름을 수행시 그들이 어떤 값을 기대하는지 알지 못하기 때문에 보통 옳고 그름을 똑같이 취급합니다. 만약 테스트가 정확했다면 코드 안에 있는 값은 거의 옳을 것입니다. 그러면 profile feedback은 컴파일러가 이것을 인식할 수 있게 해주고 코드를 올바르게 최적화 하게 해줍니다.

profile feedback을 이용하여 성능을 개선할 수 있는 또다른 예는 어떤 루틴들을 인라인시켜서 빌드 할 것인지 결정하는 것입니다. 인라인에는 두가지 장점이 있습니다. 첫번째는 루틴을 호출하는데 드는 비용을 줄일 수 있고 두번째는 좀더 최적화 할 수 있는 여지를 가질 수 있게 됩니다. 인라인에 단점은 코드 사이즈를 크게 한다는 것입니다;따라서 인라인된 코드가 별로 유용하지 않은것으로 판명된다면 코드 사이즈를 크게 할 뿐만 아니라 성능저하도 발생할 것입니다. profile feedback은 올바르게 루틴들을 판단하여 이러한 인라인 작업을 가능하게 해줍니다.

profile feedback 컴파일러 플래그

플래그는 어플리케이션을 빌드 하고 profile을 모으고 또는 현재 존재하고 있는 profile을 사용하는 것 같은 일련의 작업들을 컴파일러에게 알려 줄 수 있습니다. 플래그의 사용은 좀 더 설명이 필요합니다.

• -xprofile=collect 는 어디에 profile 정보를 둘것인지에 대한 추가적인 파라미터가 필요합니다. 예를 들어:

  -xprofile=collect:myapp 는 profile 데이타를 myapp.profile이라는 디렉토리를 프로그램이 실행되고 있는 디렉토리에 생성할 것입니다. 비슷하게 -xprofile=collect:/tmp/myapp 플래그는 /tmp/myapp.profile 디렉토리에 profile 데이타를 저장할 것입니다. 만약 장소를 지정하지 않는다면 profile은 <prog>.profile(<prog>는 현재 실행되고 있는 파일의 이름) 디렉토리에 저장될 것입니다.

• -xprofile=use 또한 profile 정보를 어디에서 가져올것인지 대한 파라미터가 필요합니다.

  -xprofile=use:/tmp/myapp 는 profile data를 /tmp/myapp.profile에 저장할 것입니다. 만약 장소가 지정되지 않는다면 현재 디렉토리에서 a.out.profile에서 데이타를 찾을 것입니다. 여기서 중요한 것은 -xprofile=collect와는 다른 동작을 한다는 것입니다. 다른 동작을 하는 이유는 profile 수집기는 실행파일의 이름을 결정할 수 있지만 컴파일러가 profile 데이타를 이용해 어플리케이션을 빌드할 때는 profile을 생성한 어플리케이션의 이름을 알 수 없기 때문입니다.

  주의: profile data를 이용해 실행파일을 생성할때에는 언제나 완전한 위치를 지정해주는 것이 좋습니다.




profile feedback을 이용하는 다른 컴파일러 플래그

profile 정보를 위해 -xprofile=collect을 이용하여 어플리케이션을 컴파일할때에, 바이너리는 매우 낮은 수준의 최적화를 거쳐서 생성됩니다. 이렇게 하는 이유는 최적화된 바이너리를 이용해 데이타를 얻는ㅜ것 보다 좀더 자세한 정보를 알 수 있기 때문입니다. 임시적인 바이너리는 소스코드와 플래그에 따라서 각각 다른 소스코드 레이아웃을 가지고 있습니다. 만약 플래그가 바뀐다면 코드의 레이아웃도 바뀔 것 입니다.

주의: -xprofile을 사용할때 외에도, 컬렉션과 사용 절차에서는 같은 플래그를 지정하는것이 가장 좋습니다.




profile 정보 수집을 위해 바이너리를 실행

바이너리가 실행되면 profile 데이타는 파일 시스템에 기록 됩니다. 기록은 실행이 모두 끝난 후에 수행 됩니다 따라서 어플리케이션의 수행이 정상적으로 되지 않는다면 profile 데이타는 기록되지 않습니다. 만약 어플리케이션이 여러번 수행된다면 profile 데이타는 모든 수행에서의 정보를 축적하게 됩니다.

만약 소스코드가 수정된다면 이전의 profile 데이타를 사용하는 것은 좋은 생각이 아닙니다. 컴파일러가 아무런 에러를 내지는 않겠지만 최적화 결정을 수행하는데에는 악영향을 줄 것입니다.

주의: -xprofile=collect를 이용하여 빌드할 때에는 이전의 profile 데이타를 지우는 것이 좋습니다.




profile feedback에 의해 수집된 정보를 컴파일러가 이용하는 옵션

profile feedback 정보를 이용 하는 몇가지 컴파일러 옵션이 있습니다:

• 최적화 level -xO5, profile feedback은 컴파일러가 자주 사용되어지는 코드의 특별한 명령을 생성할 수 있습니다. 물론 profile feedback 없이도 -xO5를 통해 가능하지만 별로 효과적이지 못합니다.

• 컴파일러 플래그 -xipo 와-xcrossfile 는 크로스파일 최적화를 수행합니다. 즉 여러 소스 파일을 거쳐서 최적화가 이루어 집니다. 한가지 예로 한 소스 코드에서의 인라인 최적화를 수행하고 또 다른 소스 파일에서 그것을 사용할 수 있게 해줍니다. profile feedback이 있다면 컴파일러는 인라인이 꼭 필요한 루틴들을 훨씬 더 잘 찾을 수 있습니다.

• 컴파일러 플래그-xlinkopt 는 링크타임시에 최적화를 가능하게 해줍니다. 즉 최종적으로 생성된 모든 코드들을 이용하여 코드 레이아웃의 최적화를 수행합니다. 이것은 규모가 큰 소스 코드에서 자주 수행되는 코드들을 한데 모아놓기 때문에 성능향상을 얻을 수 있습니다.




profile feedback을 이용한 예

예제 2번의 코드는 코드 레이아웃의 향상을 얻을 수 있는 좋은 예입니다. 코드를 검사해보면 함수 f를 수행하는데 시간이 걸림을 알 수 있습니다. 이 함수는 6가지 변수를 더하게 됩니다. 더하기전에 각 포인터들의 값들이 올바른지 체크를 합니다. 예를 들어 모든 값이 유효하다면 소스 코드의 나머지 부분에서의 모든 테스트도 유효할 것입니다. 그렇기 때문에 아래의 두개의 if문은 모두 유효하다고 볼 수 있습니다.

#include <stdio.h> #include <stdlib.h> static unsigned f( unsigned *a0, unsigned *a1, unsigned *a2, unsigned *a3, unsigned *a4, unsigned *a5) { unsigned result = 0; if (a0 == NULL) {printf("a0 == NULL");} else {result += (*a0);} if (a1 == NULL) {printf("a1 == NULL");} else {result += (*a1);} if (a2 == NULL) {printf("a2 == NULL");} else {result += (*a2);} if (a3 == NULL) {printf("a3 == NULL");} else {result += (*a3);} if (a4 == NULL) {printf("a4 == NULL");} else {result += (*a4);} if (a5 == NULL) {printf("a5 == NULL");} else {result += (*a5);} return result; } void main(int argc,const char *argv[]) { int i, j, niters = 1, n=6; unsigned sum, answer = 0, a[6]; niters = 1000000000; if (argc == 2) { initers = atoi(argv[1]); } for(j=0; j<n; j++) { a[j] = rand(); answer += a[j]; } for(i=0; i<niters; i++) { sum=f(a+0, a+1, a+2, a+3, a+4, a+5); } if (sum == answer) { printf("answer = %u\n", answer); } else { printf("error sum=%u, answer=%u", sum, answer); } }

예제 2 - profile feedback을 이용해 퍼포먼스 향상을 얻는 예

예제 3번은 profile feedback을 사용하지 않았을때의 결과를 보여줍니다.

$ cc -O -o example example.c $ timex example 1000000000 answer = 86902 real 43.87 user 43.28 sys 0.00

예제 3 - profile feedback을 이용하지 않고 컴파일 하여 실행했을때

예제 4는 profile feedback을 이용하여 컴파일을 하는 예를 보여 줍니다.

$ cc -O -xprofile=collect:./example -o example example.c $ example 100 answer = 86902 $ cc -O -xprofile=use:./example -o example example.c $ timex example 1000000000 answer = 86902 real 34.52 user 33.93 sys 0.01

예제 4 - profile feedback을 이용하여 컴파일 하고 실행했을때

두 코드는 약 10초의 차이를 보여서 대략 25% 정도의 성능향상을 가져 왔음을 알 수 있습니다. 물론 이 예제는 단순히 profile feedback의 최적화를 보여주기 위한 것이지만 이러한 최적화의 효과는 대부분의 코드에서 나타납니다.

---

저자 소개

Darryl Gove 는 썬마이크로 시스템즈 Compiler Performance Engineering 부서의 수석 엔지니어입니다. 주로 UltraSPARC 시스템에서의 어플리케이션 성능 향상과 분석에 대해 연구하고 있습니다. Darryl은 영국의 University of Southampton에서 박사학위를 가지고 있고 Sun 에 입사하기 전에는 영국에서 다양한 개발작업을 수행했습니다.

Chris Aoki 는 썬마이크로 시스템즈의 SPARC 컴파일러팀의 엔지니어입니다. 주로 수행하는 프로젝트는 feedback 기반의 최적화를 수행하는 것에 대한 것입니다.


(2005년 9월 7일자 업데이트)