원문 : https://software.intel.com/en-us/top-down-microarchitecture-analysis-method-win
주의 : 허락받고 번역한 것이 아니므로 언제든 내려갈 수 있습니다.
주의 : 번역이 개판이므로 이상하면 원문을 참조하십시오.
Tuning Applications Using a Top-down Microarchitecture Analysis Method
애플리케이션이 CPU 마이크로아키텍쳐의 이점을 취할 수 있도록 하기 위해서는, 애플리케이션이 이용가능한 하드웨어 리소스들을 활용하는 방법에 대해서 알 필요가 있습니다. 이러한 지식은 on-chip Performance Monitoring Units( PMUs )를 통해서 획득할 수 있습니다. PMUs 는 CPU 코어에 내장된 전용로직인데요, 이것은 특정 하드웨어 이벤트가 시스템에서 발생할 때마다 그것을 카운트합니다. 이러한 이벤트들의 예로는 캐시 미스( Cache Miss )나 분기 예측 실패( Branch Misprediction ) 등이 있습니다. 이러한 이벤트들은 Cycles per Instruction( CPI )와 같은 유용한 고수준 지표( metrics )들을 생성하기 위해서 관찰되고 병합될 수 있습니다.
특정 마이크로아키텍쳐는 그것의 PMU 를 통해서 수천개의 이용가능한 이벤트들을 만들 것입니다. 그러나 그것은 특정 성능 이슈들을 검출하고 수정하는 데 있어서 유용한 이벤트들이 어떤 것인지를 결정하는데 있어서 보통 불분명합니다. 보통 원본( raw ) 이벤트 데이터로부터 유용한 정보를 획득하기 위해서는 마이크로아키텍쳐 설계와 PMU 명세에 대한 깊은 지식을 요구합니다. 그러나 여러분은 그 데이터들을 행동 정보( actionable information )들로 변환하기 위해 미리 정의된 이벤트들과 지표들, 그리고 top-down 특성화( characterization ) 기법들을 사용하는 것으로부터 이점을 취할 수 있습니다.
Top-down Microarchitecture Analysis Method Overview
현대 CPU 들은 리소스들을 가능한한 효율적으로 활용하기 위해서 하드웨어 스레딩( hardware threading, 역주 : hyper-threading 인듯 ), 비순차실행( out-of-order execution ), 명령어 수준 병렬화( instruction-level parallelism )뿐만 아니라 pipelining 을 도입합니다. 이러한 관점에서 볼 때, 어떤 유형의 소프트웨어 패턴들과 알고리즘들은 여전히 비효율적입니다. 예를 들어, linked data 구조는 소프트웨어에서 일반적으로 사용되지만, 그것은 하드웨어 프리패쳐( prefetcher )를 무시( defeat )하는 indirect addressing 을 발생시킵니다. 많은 경우에, 이러한 동작은 데이터를 획득하는 동안 파이프라인 내에 bubbles of idleness 를 생성할 수 있으며, 실행할 다른 명령들이 존재하지 않습니다. Linked data 구조는 소프트웨어 문제에 대한 적절한 해결책이 될 수 있지만, 비효율적입니다. 소프트웨어 수준에서 기저 CPU 파이프라인에 영향을 줄 수 있는 다른 많은 예들이 존재합니다. Top-down Characterization 기법에 기반하는 Top-down Microarchitecture Analysis Method 는 여러분이 알고리즘과 데이터 구조를 현명하게 선택할 수 있도록 하기 위한 관점을 제공한다는 목적을 가지고 있습니다. Top-down Microarchitecture Analysis Method 에 대한 세부사항에 대해 알고자 한다면 Intel(R) 64 and IA-32 Architectures Optimization Reference Manual, Appendix B.1 을 참조하십시오.
Top-down 특성화는 이벤트 기반 지표들의 계층적 조직화를 의미하는데, 이는 응용프로그램에서의 주요 성능 병목을 표현합니다. 그것의 목적은 응용프로그램이 실행되는 동안 CPU 파이프라인이 얼마나 잘 활용되고 있었는지를 평균적으로 보여주는 것입니다. 이전 프레임워크에서는 이벤트를 해석하기 위해서 CPU 클락틱( clocktick )을 카운팅하는데 의존했습니다 - CPU 클락틱들의 얼마만큼이 어떤 유형의 연산( 예를 들어 L2 캐시 미스때문에 데이터를 회수 )을 위해서 사용되었는지를 확인. 대신에 이 프레임워크는 파이프라인의 리소스들을 카운팅하는데 기반합니다. Top-Down 특성화를 이해하기 위해서, 몇 가지 구조적( architectural ) 개념을 고수준에서 살펴봅시다. 마이크로아키텍쳐의 많은 세부사항들은 이 프레임워크에서 추상화되었으며, 이는 여러분이 하드웨어 전문가가 되지 않고도 그것을 사용하고 이해할 수 있도록 해 줄 것입니다.
현대 고수준 CPU 의 파이프라인은 매우 복잡합니다. 아래의 간략화된 뷰에서, 파이프라인은 개념적으로 두 부분으로 나뉘는데, 프론트엔드( Font-end )와 백엔드( Back-end )입니다. 프론트엔드는 architectural instruction 으로 표현된 프로그램 코드를 패칭( fetching )하고 그것들을 micro-op( uOps )라 불리는 하나 이상의 저수준 하드웨어 연산으로 디코딩( decoding )합니다. 그리고 나서 uOp 들은 할당( allocation )이라 불리는 과정을 통해 Back-end 에 넘겨집니다. 일단 할당이 되고 나면 백엔드는 uOp 의 데이터 명령들이 이용가능한 시점이 언제인지를 모니터링하고 이용 가능한 실행 유닛( execution unit )에서 uOp 를 실행할 책임이 있습니다. uOp 실행의 완료는 retirement( 은퇴 ) 라 불립니다. 그리고 retirement 가 uOp 의 결과가 architectural state( CPU 레지스터나 메모리 )에 반영되는 곳입니다. 보통 대부분의 uOp 들은 완전히 파이프라인을 통해 통과하고 리타이어됩니다. 그러나 종종 예측적으로 패치된 uOp 들은 리타이어 전에 취소될 수도 있습니다 - 예를 들면 mispredicted branche 의 경우입니다.
최신 인텔 마이크로아키텍쳐의 파이프라인의 프론트엔드는 사이클당 4 개의 uOp 들을 할당할 수 있으며, 백엔드는 사이클당 네 개의 uOp 를 리타이어시킬 수 있습니다( 역주 : 나중에 나올라나 모르겠지만, 그래서 이상적인 CPI 는 0.25 입니다 ). 파이프라인 슬롯은 하나의 uOp 를 처리하기 위해서 필요한 하드웨어 리소스를 표현합니다. Top-Down 특성화는 각 CPU 코어와 각 클락 사이클에 대해 4 개의 파이프라인 슬롯이 활성화된다고 간주합니다. 그리고 나서 그것은 특별히 설계된 PMU 를 사용해서 그러한 파이프라인 슬롯들이 얼마나 잘 활용되고 있는지를 측정합니다. 파이프라인 슬롯의 상태들은 할당 위치( 위 그림에서 별표로 표시 )에서 수집되는데, 여기에서 uOp 들은 프론트엔드를 떠나 백엔드로 가게 됩니다. 애플리케이션의 런타임 동안에 이용가능한 각 파이프라인 슬롯은 위에서 기술된 간략화된 파이프라인 뷰에 기반에 4 개 중 하나의 카테고리들로 구분될 것입니다.
사이클 동안에, 파이프라인 슬롯은 비어있을 수도 있고 uOp 로 채워져 있을 수도 있습니다. 만약 슬롯이 한 클락 사이클 동안 비어 있다면, 이것은 스톨( stall, 멈춤 ) 때문입니다. 이 파이프라인 슬롯을 분류하는데 필요한 다음 단계는 스톨을 발생시킨 것이 파이프라인의 프론트엔드인지 백엔드인지 여부를 결정하는 것입니다. 이는 설계된 PMU 이벤트와 공식들을 사용해서 수행됩니다. Top-Down 특성화의 목적은 주요 병목을 식별하는 것이므로, 스톨이 프론트엔드 때문인지 백엔드 때문인지를 아는 것은 매우 중요합니다. 일반적으로 프론트엔드가 uOp 를 슬롯에 채울 수 없는 상황때문에 발생했다면, 그것은 이 사이클에 대해 프론트엔드 바운드( bound ) 슬롯으로 분류됩니다. 이것이 의미하는 것은, 프론트엔드 바운드 카테고리에 있는 어떤 병목에 의해 성능이 제한된다는 것입니다. 프론트엔드가 uOp 를 이미 가지고 있지만 백엔드가 그것을 다룰 수 있는 상황이 안 되기 때문에 uOp 를 건네줄 수 없다면, 비어있는 파이프라인 슬롯은 백엔드 바운드로 분류될 것입니다. 백엔드 스톨은 일반적으로 백엔드가 일부 리소스를 사용할 수 없는 경우에 의해 발생합니다. 예를 들면 버퍼를 로드하고 있다든가 하는 경우입니다. 그러나 프론트엔드와 백엔드가 모두 스톨되었다면, 그 슬롯은 백엔드 바운드로 분류될 것입니다. 왜냐하면 이 경우에 프론트엔드에서의 스톨을 해결하는 것은 애플리케이션의 성능을 개선하는데 거의 도움이 되지 않기 때문입니다. 백엔드는 블락킹 병목( blocking bottleneck )입니다. 그리고 그것은 어떠한 효과를 발생시킬 수 있는 프론트엔드에서의 이슈를 해결하기 전에 먼저 제거될 필요가 있습니다.
만약 프로세서가 스톨되지 않았다면, 파이프라인 슬롯은 할당 지점에서 uOp 로 채워질 것입니다. 이 경우에는 슬롯을 분류하는 방법을 위한 결정 요인( determination factor )은 uOp 가 결과적으로 리타이어되어야 하는 슬롯이 무엇인가에 달려 있습니다. 만약 그것이 리타이어를 했다면, 그 슬롯은 Retiring 으로 분류됩니다. 만약 프론트엔드에 의한 부정확한 분기 예측이나 Self-Modifying-Code 때문에 파이프라인 플러쉬같은 클리어 이벤트 때문에 리타이어를 안 했다면, 그 슬롯은 Bad Speculation 으로 분류됩니다. 이 네 개의 카테고리는 Top-Down 특성화의 상위 수준을 구성합니다. 응용프로그램을 특성화하기 위해서, 각 파이프라인 슬롯을 정확히 네 개 중의 하나로 분류합니다.
네 개의 카테고리로 파이프라인 슬롯을 분산시키는 것은 매우 유용합니다. 이벤트에 기반한 지표들을 여러 해동안 이용해 왔음에도 불구하고, 이 특성화 이전에는 가장 영향력이 있는 이용가능한 성능 이슈들이 무엇인지 식별하는 접근법이 없었습니다. 성능 지표들이 이 프레임워크로 배치될 때, 여러분은 어떤 이슈가 가장 먼저 문제가 되는지 알 수 있습니다. 파이프라인 슬롯들을 네 개의 카테고리로 분류하기 위해 필요한 이벤트들은 Sandy Bridge 라는 마이크로아키텍쳐 코드 네임을 가진 코어부터 이용할 수 있습니다 - 그것은 2 세대 인텍 코어 프로세서 패밀리와 인텔 제온 프로세서 E5 패밀리에서 사용되었습니다. 그 다음에 나온 마이크로아키텍쳐들은 이 고수준 카테고리들을 더 세부적인 성능 지표들로 분리하는 것을 허용합니다.
Top-Down Analysis Method with VTune Amplifier
Intel(R) VTune TM Amplifier 는 General Exploration analysis type 을 제공하는데, 이것은 Top-Down 특성화에서 정의된 이벤트를 수집하기 위해서 미리 구성되어 있으며, Ivy Bridge 라는 코드 네임을 가진 마이크로아키텍쳐부터 이용할 수 있습니다. General Exploration 은 다른 유용한 성능 지표들을 계산하기 위해서 요구되는 이벤트들을 수집하기도 합니다. General Exploration analysis 의 결과는 기본적으로 General Exploration viewpoint 에서 기보여집니다.
General Exploration 결과는 특성화의 top-down 성질을 강화하기 위해서 계층적 칼럼( column )에서 보여집니다. Summary window 는 전체 응용프로그램을 위해 각 카테고리에 있는 파이프라인 슬롯에 대한 백분율을 제공합니다. 여러분은 여러 가지 방식으로 결과를 탐색할 수 있습니다. 가장 일반적인 방식은 함수 수준에서 지표를 보기 위해 결과를 탐색하는 것입니다.
각 함수에 대해, 각 카테고리에 있는 파이프라인 슬롯들이 보여집니다. 예를 들어 위에서 선택된 price_out_impl 함수는 그것의 파이프라인 슬롯의 2.2 % 가 Front-End Bound 카테고리에, 7.4% 가 Bad Speculation 카테고리에, 64.2% 가 Memory Bound 카테고리에, 8.4% 가 Core Bound 카테고리에, 17.8% 가 Retiring 카테코리에 속해 있습니다. 각 카테고리는 그 카테고리 아래의 지표를 보기 위해서 펼쳐질 수 있습니다. 잠재적으로 문제가 되는 영역에 대해서 주의를 주기 위해 자동으로 하이라이트가 사용되는데, 이 경우에는 price_out_impl 를 위한 Memory Bound 파이프라인 슬롯이 너무 높은 비율을 가지고 있습니다.
Microarchitectural Tuning Methodology
성능 개선을 수행할 때, 중요한 것은 응용프로그램의 최고 핫스팟( hotspot )을 찾는 것입니다. 핫스팟들은 거의 대부분의 CPU 시간을 많이 소비한 함수들입니다. 이 스팟들에 초첨을 맞추는 것은 전체 응용프로그램 성능에 영향을 주는 최적화를 보장할 것입니다. VTune Amplifier 는 이를 위해 두 개의 특정 분석 유형을 가지고 있는데, Basic Hotspots 와 Adavanced Hotspots 입니다. General Exploration viewpoint 에서 핫스팟들은 가장 높은 클락틱( clockticks ) 이벤트 카운트를 가진 함수나 모듈을 결정함으로써 식별될 수 있습니다. 그 클락틱은 CPU 클락틱에 대한 수치를 측정합니다. 마이크로아키텍쳐 수준에서의 성능 개선의 최대 이점을 취하기 위해서는, 병렬화를 추가하는 것과 같은 알고리즘적 최적화가 이미 적용되어 있어야 합니다. 일반적으로 시스템 성능 개선이 먼저 수행되고, 응용프로그램 수준 알고리즘 개선이, 그리고 나서 구조적 및 마이크로아키텍쳐 수준 성능 개선이 수행됩니다. 이 과정 역시 Top-Down software tuning methodology 에서 "Top-Down" 이라 불립니다. 그것은 workload selection 과 같은 성능 개선의 다른 중요한 관점들과 함께 De-Mystifying Software Performance Optimization 기사에 설명되어 있습니다.
- 핫스팟 함수를 선택( 응용프로그램의 전체 클락틱에서 큰 비율을 차지하는 것 ).
- Top-Down 기법과 아래 설명된 가이드라인을 사용해 핫스팟의 효율성을 평가.
- 비효율적이라면 주요 병목을 표현하는 카테고리로 파고 듬. 그리고 원인을 식별하기 위해 다음 수준의 하위 병목을 확인.
- 이슈를 최적화. VTune Amplifire tuning guides 는 각 카테고리 내의 많은 기저 성능 이슈들에 대한 특정 개선 제안을 포함함.
- 중요한 핫스팟들이 평가될 때까지 이를 반복함.
VTune Amplifier 는 미리 정의된 문턱값 외의 값이 있거나 핫스팟을 발생시키면 자동으로 GUI 내에서 지표값들을 하이라이팅합니다. VTune Amplifier 는 응용프로그램을 위한 전체 클락틱의 5% 보다 큰 값을 가진 함수를 핫스팟으로 분류합니다. 파이프라인 슬롯이 병목인 것으로 여겨지는 특정 카테고리에 존재하는지 판단하는 것은 workload( 역주 : workload : 주어진 시간에 처리한 작업의 양 )에 의존적입니다. 그러나 일부 일반적인 가이드라인들은 아래 표에 제공되어 있습니다.
이 문턱값들은 인텔의 연구소에서 일부 workload 들을 분석한 것에 기반합니다. 핫스팟에 대해 ( Retiring 이 아닌 ) 카테고리 내에서 소비한 시간이 가장 높거나 지시된 범위보다 크다면, 이 연구는 유용할 것입니다. 만약 이것이 하나 이상의 카테고리에 대해서 참이라면, 가장 톺은 시간을 소비한 카테고리는 가장 먼저 연구되어야 할 것입니다. 핫스팟은 각 카테고리에서 소비된 시간을 가질 것이며 일반적인 범위 내에 있는 값들을 가지고 있다면 문제가 되지 않을 것입니다.
Top-Down 기법을 깨닫는 데 있어서 중요한 것은 병목으로 식별되지 않은 카테고리에 있는 이슈들을 최적화하기 위해서 시간을 소비할 필요가 없다는 것입니다 - 그렇게 하는 것이 중대한 성능 증진으로 이어지지는 않습니다.
Tuning for the Back-End Bound Category
개선되지 않은 응용프로그램의 대부분은 Back-End Bound 를 가지고 있을 것입니다. 백엔드 이슈를 해결하는 것은 보통 필요 이상으로 리타이어까지의 시간이 길어지는 지연( latency )의 원인을 해결하는 것입니다. Sandy Bridge 라는 코드 네임을 가진 인텔 마이크로아키텍쳐에서, VTune Amplifier 는 높은 지연을 가지는 원인들을 찾기 위한 백엔드 바운드 지표들을 가지고 있습니다. 예를 들어 LLC Miss( Last-Level Cache Miss ) 지표는 데이터를 위해 DRAM 에 접근할 필요가 없는 코드의 영역을 식별하며, Split Loads 와 Split Store 지표는 좋지 않은 성능을 유발할 수 있는 메모리 접근 패턴들을 지적합니다. Sandy Bridge 의 지표들에 대해 더 많은 정보를 얻고 싶으면 Tuning Guide 를 참조하십시오. ( 3 세대 인텔 코어 프로세서 패밀리에서 사용된 ) Ivy Bridge 부터는 Back-End Bound 분류의 이벤트들이 Memory Bound 와 Core Bound 라는 하위 지표로 분리됩니다. 네 개의 카테고리 하의 지표는 파이프라인 슬롯 영역( domain )이 아닌 영역에서 사용될 것입니다. 각 지표는 기저 PMU 이벤트에 기반해 가장 적절한 영역을 사용할 것입니다. 더 많은 세부사항을 원한다면 documentation for each metric or category 를 참조하십시오.
Memory Bound 와 Core Bound 하위 지표는 실행 유닛( execution unit )에 대한 활용과 관련한 이벤트를 사용해 결정됩니다 - 최상위 분류에서는 할당 단계가 사용되는 것과는 대조적입니다. 그러므로 이 지표들의 합은 상위 수준에서 결정되는 Back-End Bound 비율과 일치하는 것은 아닙니다( 뭐 대충 맞기는 합니다 ).
Memory Bound 카테고리에서의 스톨은 메모리 서브시스템과 관련해 발생합니다. 예를 들어 캐시 미스와 메모리 접근은 Memory Bound 스톨을 발생시킬 수 있습니다. Core Bound 스톨은 각 사이클 동안에 CPU 에서 이용가능한 실행 유닛들을 최적이 아닌 형태로 사용함( less-than-optimal use )으로써 발생합니다. For example, several multi-cycle divide instructions in a row competing for the divide units could cause Core Bound stalls. For this breakdown, slots are only classified as Core Bound if they are stalled AND there are no uncompleted memory accesses. 예를 들어 pending loads 가 존재하면 그 사이클은 Memory Bound 로 분류됩니다. 왜냐하면 실행 유닛들이 loads 가 데이터를 반환하지 않고 있는 동안 굶주리고( starved ) 있기 때문입니다. 이러한 유형의 분리( breakdown )을 특별히 허용하기 위해 PMU 이벤트들이 하드웨어야 설계되었는데, 그것은 응용프로그램 내의 진짜 병목을 식별하는데 도움을 줍니다. Back-End Bound 이슈의 대부분은 Memory Bound 카테고리에 존재할 것입니다.
Memory Bound 카테고리 하의 대부분의 지표들은 L1 캐쉬부터 메모리까지의 메모리 계층에서 어떤 레벨이 병목인지를 식별합니다. 다시 말해, 이 판단을 위해서 사용된 이벤트들은 주의깊게 설계되었습니다. Back-End 가 스톨되고 나면 그 지표들은 특정 레벨의 캐시나 in-flight store 에 대한 pending loads 의 스톨의 영향인지 확인하려 합니다. 만약 핫스팟이 주어진 레벨에서 발생했다면, 그것은 캐시나 메모리 레벨에서 그것의 데이터의 대부분을 받고 있음을 의미합니다. 최적화는 데이터를 코어에 가깝게 이동하는 것에 초점을 맞춰야 합니다. Store Bound 가 하위 카테고리로서 호출될 수도 있는데, 그것은 의존성을 표시합니다 - 파이프라인에서의 loads 가 이전 store 에 의존하는 것과 같은 상황. 이러한 각 카테고리 내에는 Memory Bound 실행을 발생시키는 특정 응용프로그램 동작을 식별할 수 있는 지표들이 존재합니다. For example, Loads Blocked by Store Forwarding and 4K Aliasing are metrics that flag behaviours that can cause an application to be L1 Bound.
Core Bound 스톨은 보통 Back-End Bound 보다는 적습니다. 이는 이용가능한 컴퓨팅 리소스들이 많은 메모리를 요청하지 않은 상태에서 충분히 활용되거나 사용되지 않을 때 발생할 수 있습니다. 예를 들어 캐시에 들어 맞는 데이터 상에서 부동소수점( FP ) 수학 계산을 수행하는 tight loop. VTune Amplifer 는 이 카테고리 내의 동작들을 검출하기 위한 일부 지표들을 제공합니다. 예를 들어 Divider 지표는 divider 하드웨어가 매우 많이 사용되고 있을 때의 사이클을 식별합니다. 그리고 Port Utilization 지표는 분리된( discrete ) 실행 유닛을 위한 경쟁을 식별합니다.
주의 : 회색 지표값들은 이 지표를 위해 수집된 데이터가 신뢰할 수 없음을 의미합니다. 예를 들어 PMU 이벤트들을 위해 수집된 샘플들의 개수가 너무 적거나 할 때 발생할 수 있습니다. 여러분은 이 데이터를 무시하거나 collection time, sampling interval, workload 를 수정한 다음에 다시 데이터를 수집할 수 있습니다.
Tuning for the Front-End Bound Category
Front-End Bound 카테고리는 몇 가지 유형의 파이프라인 스톨을 다룹니다. 파이프라인의 프론트엔드 부분이 응용프로그램 병목이 되는 경우는 일반적이지 않습니다; 하지만 프론트엔드가 머신 스톨의 중대한 이유가 되는 경우가 몇 개 있습니다. 예를 들어 JIT 된 코드와 인터프리트된 코드는 프론트엔드 스톨을 발생시킬 수 있습니다. 왜냐하면 명령어 스트림이 진보된 컴파일러 코드 레이아웃의 이점을 취하지 않고 동적으로 생성되기 때문입니다. Front-End Bound 카테고리에서 성능을 개선하는 것은 일반적으로 코드 레이아웃( co-locating hot code )와 컴파일러 기술과 관계가 있습니다. 예를 들어 branchy 코드나 큰 footprint 를 가진 코드는 Front-End Bound 카테고리에서 하이라이팅될 수 있습니다. Code size optimization 과 compiler profile-guided optimization( PGO )와 같은 기술들은 많은 경우에 스톨을 제거할 것입니다.
Ivy Bridge 와 그 이후의 마이크로아키텍쳐에서 Top-Down 기법은 Front-End Bound 스톨을 2 개의 카테고리로 나누게 됩니다. 그것은 Front-End Latency 와 Front-End BandWidth 입니다. Front-End Latency 지표는 프론트엔드에 의해 제출된 uop 들이 하나도 없는데 백엔드는 그것들을 이미 소비하고 있는 사이클을 기록합니다. 프론트엔드 클러스터는 사이클당 4 개의 uop 들을 제출할 수 있다는 점을 기억하십시오. Front-End Bandwidth 지표는 4 개 미만의 uop 들이 제출된 사이클을 기록하는데, 이는 프론트엔드의 능력을 효율적으로 사용하고 있지 못하다는 것을 표현합니다. 더 많은 지표들을 각 카테고리 아래에서 확인할 수 있습니다.
대부분 Bad Speculation 카테고리로 계산되는 분기 예측 실패는 프론트엔드에서의 비효율성으로 이어질 수도 있는데, Ivy Bridge 부터는 Front-End Latency 아래의 Branch Resteers 병목 지표에 의해 표기됩니다.
VTune Amplifier 는 Front-End Bound 코드의 원인을 식별할 수 있는 지표들을 열거합니다. 만약 이러한 카테고리들이 결과에서 매우 많이 보인다면, 그것들의 원인과 해결방법을 결정하기 위해서 지표들을 더 깊이 살펴 봐야 합니다. 예를 들어, ITLB Overhead ( Instruction Transition Lookaside Buffer Overhead ) 와 ICache Miss( Instruction Cache miss ) 지표들은 Front-End Bound 실행을 겪고 있는 영역을 가리킬 것입니다. 개선 제안을 확인하고 싶으면 VTune Amplifier tuning guides 를 참조하십시오.
Tuning for the Bad Speculation Category
세 번째 최상위 수준 카테고리인 Bad Speculation 은 파이프라인이 도움이 되지 않는 연산들을 패치하거나 실행하느라 바쁘다는 것을 표현합니다. Bad Speculation 파이프라인 슬롯은 절대 리타이어되지 않는 uop 들이 제출되거나 부정확한 예측으로부터 머신이 복구되느라 스톨되기 때문에 낭비되는 슬롯입니다. Bad Speculation 은 분기 예측 실패와 머신 클리어에 의해서 발생하며, 많이 발생하지는 않지만 Self-Modifying-Code 같은 경우에도 발생합니다. Bad Speculation 은 Profile-Guided Optimization( PGO )와 같은 컴파일러 기술들에 의해 줄어들 수 있는데, 이는 간접 브랜치들을 피하고 머신 클리어를 발생시키는 에러 조건들을 제거합니다. Bad Speculation 을 교정하는 것은 Front-End Bound 스톨을 줄이는데 도움이 되기도 합니다. 여러분의 마이크로아키텍쳐를 위한 특정 개선 기법들은 VTune Amplifier tuning guide 에서 찾아볼 수 있습니다.
Tuning for the Retiring Category
최상위 수준의 마지막 카테고리는 Retiring 입니다. 이것은 일반적으로 유용한 연산들로 파이프라인이 바쁘다는 것을 의미합니다. 이상적으로 응용프로그램은 가능하면 이 카테고리로 분류된 슬롯을 많이 가지고 있어야 합니다. 그러나 파이프라인 슬롯의 많은 부분들이 Retiring 인 코드라고 할지라도 더 개선할 여지가 있습니다. Retiring 카테고리 하에서 성능 이슈가 발생하는 한 가지 경우는 micro-sequencer 를 너무 많이 사용하는 것입니다. Micro-sequencer 는 이는 특정 조건을 발생시키기 위해 uop 들의 긴 스트림을 생성함으로써 Front-end 를 돕습니다. 이 경우 Retiring uop 들이 많이 존재함에도 불구하고, 그것들 중 일부는 회피될 수 있습니다. 예를 들어 Denormals 이벤트에서 적용하는 FP Assists 는 주로 컴파일러 옵션( DAZ 나 FTZ )을 통해 줄어들 수 있습니다. 이러한 이슈들을 마이그레이션하는 것을 돕기 위해서 Code generation choice 들이 사용될 수 있습니다 - 더 많은 세부사항은 VTune Amplifier tuning guides 에서 확인하십시오. Sandy Bridge 에서 Assists 는 Retiring 카테고리 하의 지표로서 식별됩니다. Ivy Bridge 이상에서는 이상적인 retirement 카테고리 내의 파이프라인 슬롯은 두 개의 하위 카테고리로 나뉘는데, 그것들은 각각 General Retirement 와 Microcode Sequencer uops 입니다.
만약 아직 병렬화( parallelization )나 벡터화( vectorization )과 같은 알고리즘적 개선 기법을 사용하지 않았다면, 그것을 적용하는 것은 코드 영역의 성능이 Retiring 카테고리로 가도록 만드는데 도움을 줄 것입니다.
Conclusion
Top-Down 기법과 VTune Amplifier 에서의 그것의 기능은 PMU 들을 사용하는 성능 개선을 위한 새로운 방향성을 제시합니다. 이러한 특성화에 익숙해지기 위해 연구하는 개발자들의 시간은 노력을 들일 가치가 있을 것입니다. 왜냐하면 그것에 대한 지원이 최신 PMU 들에 설계되어 있으며 인텔 마이크로 아키텍쳐에서 가능하면 앞으로 그 계층이 더 확장될 것이기 때문입니다. 예를 들어 Sandy Bridge 와 Ivy Bridge 에서의 특성화는 매우 차이가 납니다.
Top-Down 기법의 목적은 응용프로그램 성능에 있어 주요 병목을 식별하는 것입니다. VTune Amplifier 의 General Exploration 분석과 visualization 기능은 여러분이 응용프로그램을 개선할 수 있도록 하기 위한 행동 정보들을 제공합니다. 또한 이러한 기능들은 응용프로그램의 성능 뿐만 아니라 여러분의 최적화 생산성을 매우 신장시켜 줍니다.
Parent topic : Tuning Methodology
See Also
Interpreting General Exploration Data
Tuning Guides and Performance Analysis Papers
Clockticks Vs. Pipeline Slots-Based Metrics