Darryl Gove

모든 명령어들이 동일하지는 않다

어플리케이션은 많은 명령어들로 이루어져 있고 코드들은 모든 상황들(가끔 발생하는 상황들도 포함하여)을 다룰 수 있도록 쓰여집니다. 결과적으로 많은 어플리케이션안에 전혀 사용되지 않는 명령어들도 포함되어 있습니다. 그림 1을 참조해봅시다. 녹색 사각형은 많은 루틴들이 포함된 전체 어플리케이션을 나타냅니다. 루틴들 중에서 자주 사용되는 것들은 빨간색으로 나타나 있고 잘 사용되지 않는 부분은 파란색으로 나타나 있습니다.

잘 사용되지 않는 명령어들은 메모리, 캐시등에서 공간을 차지 하고 있습니다. 예를 들어 한 캐시 라인에 자주 사용되는 명령어들과 자주 사용되지 않는 명령어들이 같이 포함되어져 있다면 자주 사용되지 않는 명령어들은 공간만 차지할 뿐이고 결과적으로 코드를 불러오기 위해 더 많은 캐시라인이 필요할 것입니다. 또한 메모리안에 코드의 레이아웃 때문에 자주 사용되는 코드가 또 다른 자주 사용되는 코드의 캐시를 차지하려고 하는 일도 발생할 수 있습니다. 이러한 상황은 캐쉬의 쓰레싱(thrashing)이라고 불립니다. 결론적으로 제한된 명령어의 셋들만 처리 될 수 있습니다.

어플리케이션에서 이러한 코드 레이아웃의 문제점은 엄청난 캐쉬 미스 이벤트, TLB 미스 이벤트, 또는 분기 예측 실패 이벤트 등을 발생시킵니다. 이러한 문제들은 UltraSPARC-III 의 퍼포먼스 카운터를 통해서 식별 할 수 있습니다. (Using UltraSPARC-IIICu Performance Counters to Improve Application Performance 문서 참조)

이제 메모리안에서 코드 레이아웃을 향상시키는 기술에 대해 알아봅시다. 일단 그전에 알아둘것은 명령어 레벨에서만 이러한 문제가 발생하는 것은 아니라는 것을 인식하는 것입니다. 모든 루틴이 매우 자주 사용될 수도 있고 그렇지 않을 수도 있습니다. 비슷하게 라이브러리도 전체가 다 자주 사용 될 수 있고 자주 사용되지 않는 하나의 라이브러리콜만 사용할 수도 있습니다.

컴파일러는 메모리안에서 코드의 레이아웃을 바꿀 수 있는 기능이 있기 때문에 컴파일러를 이용해서 메모리를 효과적으로 사용하도록 만들 수 있습니다. 이러한 일을 하기위해선 몇가지 정보가 필요합니다. 이 글의 나머지 부분에서는 메모리에 어플리케이션 레이아웃을 향상시킬 수 있는 3가지의 다른 접근법에 대해 알아봅니다.

mapfile을 이용하여 루틴을 재정렬

한가지 접근 방법은 mapfile을 이용하는 것 입니다. mapfile은 링커가 메모리에 루틴들을 어떻게 배열 할지에 대한 정보를 가지고 있습니다. 이 것을 이용하기 위해서는 루틴들을 자주 사용하는 순서대로 정렬하는 것이 필요합니다. 그림 2번은 맵파일을 이용하여 그림1번의 프로그램을 재배열 한 것입니다.

mapfile을 수동으로 만들어 줄수도 있지만 더 쉬운 방법은 퍼포먼스 분석기를 이용해 접근하는 것입니다:

• flag -xF 를 이용하여 프로그램을 빌드한다

• Run the program with a representative workload under collect

• er_print -mapfile <app> <mapfilename>를 이용하여 맵파일을 만든다

• flags -xF -M <mapfile>를 이용하여 프로그램을 재빌드한다.

어플리케이션의 맵파일을 생성하고 나면 어플리케이션의 프로파일이 바뀌거나 루틴의 이름이 변경되거나 루틴이 추가되더라도 계속 사용할 수 있습니다.

$ cc -O -xF -o app *.c
$ collect app < test_data
   Creating experiment test.1.er ...
$ er_print -mapfile app app.map test.1.er
$ cc -O -xF -M app.map -o app *.c

표 1 - 퍼포먼스 분석기 툴을 이용해 맵파일을 작성

프로파일 피드백을 이용하여 명령어들의 레이아웃을 향상

mapfile은 자주 사용되는 루틴과 사용되지 않는 루틴을 분리하는데 아주 유용합니다. 그러나 명령어 레벨에서 프로세서가 실행되지 않는 코드들의 블럭을 점프하는데 소요되는 시간도 아주 많이 걸립니다. 프로파일 피드백은 이러한 현상을 향상시키는 컴파일러 기술입니다.

프로파일 피드백은 코드가 전형적으로 어떻게 돌아가는지에 대한 정보를 컴파일러에 제공하는 것으로 다음과 같은 정보들을 통해 코드 최적화를 수행 할 수 있습니다.:

• 코드를 재정렬하여 루틴 안에 자주 사용되는 코드들을 한 군데로 모은다

• 자주 불려지는 루틴들은 아예 포함시켜서 루틴을 호출하는데 드는 비용을 줄여주고 또한 잠재적으로 포함된 코드들의 최적화를 가능하게 한다

프로파일 피드백은 크로스파일 최적화는(flag -xipo에 의해 조정됨) 모든 소스파일 간의 최적화를 잠재적으로 가능하게 하는 최고의 방법입니다.

그림 3번은 프로파일 피드백이 어떻게 자주 실행되는 코드들을 한군데 정렬하는지에 대한 방법을 보여줍니다.

프로프일 피드백은 아래와 같이 직관적으로 사용할 수 있습니다:

• -xprofile=collect -xipo를 이용하여 어플리케이션을 빌드한다

• Run the application with one or more representative workloads

• -xprofile=use -xipo를 이용하여 어플리케이션을 재빌드한다

-xipo flag는 컴파일러가 여러 소스코드들에 걸쳐서 최적화를 수행하라는 지시입니다.

$ cc -O -xprofile=collect:app.profile -xipo -o app *.c 
$ app < test_data 
$ cc -O -xprofile=use:app.profile -xipo -o app *.c 

표 2 - 프로프일 피드백을 이용하여 어플리케이션을 최적화

링크-타임 최적화

mapfile은 루틴 레벨에서 작동하고 프로파일 피드백 은 루틴 안에서 사용됩니다;두 가지를 한꺼번에 사용 할 수 있다면 더 간단할 것입니다. 링크-타임 최적화를 통해서 이것이 가능합니다.(post-optimisation이라고도 불림)

링크타임 최적화의 기본 원리는 이렇습니다. 컴파일러가 있고 코드가 있다면 단지 그것을 올바르게 배열 하는 것만이 문제가 됩니다. 코드를 올바르게 배열하기 위해서는 링크-타임 옵티마이져가 자주 사용되는 루틴을 한 군데로 모으고(mapfile을 사용하는것과 비슷) 루틴안에 자주 사용되는 명령어들을 또다시 한 군데로 모으는 것입니다. 이렇게 하여 자주 사용되는 명령어들을 한 군데로 모읍니다. 다음과 같은 방법을 통해서 링크-타임에 최적화가 가능합니다:

• 자주 사용되는 코드가 확인되면 그것들을 한 군데로 모으는것이 가능하고 또한 자주 사용되지 않는 코드들도 모으는 것이 가능하다. 그런후에 다른 루틴에서 자주 사용되는 코드들을 자주 사용되는 한 지역의 메모리로 이동시킨다.

• 변수와 루틴들의 주소가 정확하게 계산이 가능하다면 좀 더 최적화를 할 수 있다. 따라서 링크-타임 옵티마이져가 변수나 루틴의 주소 계산 표현을 간단하게 하여 명령어 카운트를 줄여 줄 수 있다.

그림 4번은 링크-타임 최적화가 수행된 뒤에 어플리케이션의 모습을 보여줍니다. 자주 사용되는 코드는 바이너리의 한 부분에 모여져 있고 자주 사용되지 않는 부분은 나머지에 배열 되있습니다.

링크-타임 최적화 단계는 프로파일 피드백 데이터가 필요합니다. 그래서 다음과 같은 단계를 따라야 합니다:

• flags -xprofile=collect -xipo를 이용하여 어플리케이션을 빌드한다

• Run the application with one or more representative workloads

• -xprofile=use -xipo -xlinkopt를 이용하여 어플리케이션을 리빌드한다
  

$ cc -O -xprofile=collect:app.profile -xipo -o app *.c
$ app < test_data
$ cc -O -xprofile=use:app.profile -xipo -o app *.c -xlinkopt

표 3 - 링크-타임 최적화와 프로파일 피드백을 조합

결론

큰 규모의 어플리케이션에 이러한 기술을 사용하면 엄청난 성능 향상을 얻을 수 있습니다. 물론 빌드타임이 증가하고 빌드의 복잡성이 증가한다는 것은 당연합니다; 결과적으로 추가적인 노력에 비해 성능을 얼마나 향상시킬 수 있는지 따져 본 후에 사용해야 합니다. 또한 모든 어플리케이션이 이러한 코드 레이아웃 최적화 과정을 거쳐야 하는 것도 아니고 개발과정에서의 빌드에서는 이러한 과정이 필요없으며 최종 제품 빌드일때에 사용되어야 한다는 것도 알아야 합니다.

저자에 대하여

Darryl Gove는 썬 마이크로시스템즈의 컴파일러 퍼포먼스 엔지니어링 부서에서 근무하며 현재 그리고 미래의 UltraSPARC 프로레서 상의 어플리케이션 퍼포먼스 최적화를 담당하는 일을 하고 있다. Darryl은 영국의 사우스 햄튼 대학에 석,박사 학위를 가지고 있고 썬에서 근무하기 전에는 영국에서 다양한 소프트웨어 개발에 참여했다.