Abstract
GPU 가속 프로그램은 HPC, 개인용 컴퓨터 및 휴대용 장치에서 점점 보편화되고 있으므로 에너지 효율성을 최적화하는 것이 중요합니다. 그러나 GPU 코드의 전력 소비량을 정확하게 프로파일링하는 것은 간단하지 않습니다. 실제로 K20 GPU의 온보드 파워 센서를 사용할 때 여러 가지 이상을 확인했습니다. 예를 들어, 커널의 런타임을 두 배로 늘리면 에너지 사용량이 두 배 이상 늘어나고, 커널이 실행을 중지 한 후 에너지를 소비하며, 두 개의 커널을 시간적으로 가깝게 실행하면 나중에 에너지 소비가 증가한다는 사실을 발견했습니다. 핵심. 또한 전력 샘플링 주파수가 크게 변하고 GPU 센서가 가끔씩 전력 판독을 수행하는 것을 관찰했습니다. 이러한 문제에도 불구하고 순간 전력과 에너지 소비를 정확하게 계산하는 방법론을 제시합니다.
Keywords
Power measurement, energy measurement, GPU power sensor.
1. INTRODUCTION
가속기, 특히 컴퓨팅 GPU가 도입 된 이후로 컴퓨팅 환경이 크게 변경되었습니다. 예를 들어, 현재 세계 최고의 슈퍼 컴퓨터에는 가속기가 포함되어 있습니다. Kepler 아키텍처를 포함한 모든 새로운 GPU 세대는 제공되는 성능과 에너지 효율성을 향상시킵니다. 결과적으로 GPU가 있는 장치의 수와 GPU 가속 응용 프로그램의 수가 향후 몇 년 동안 빠르게 증가 할 것입니다. 그러나 GPU 코드의 에너지 효율성을 최적화하려면 먼저 정확한 전력 프로파일링이 필요한 이러한 프로그램의 에너지 소비를 잘 이해해야합니다.
실시간 전력 정보를 제공하기 위해 최신 GPU(예 : Tesla K20)에는 런타임시 전력 소비량을 쿼리하는 온보드 센서가 있습니다. 정확한 전력 데이터를 얻을 수 있으면 GPU 프로그래머가 코드의 에너지 효율성을 평가하고 개선 할 수 있습니다. 그러나 이 분야에 게시된 대부분의 작업은 모델을 사용하여 전력 소비를 추정하는데 초점을 맞추고 있습니다. 아마도 대부분의 GPU에는 아직 내장 센서(built-in sensor)가 포함되어 있지 않기 때문일 것입니다. 우리가 아는 한, 내장형 파워 센서를 사용하여 K20과 같은 최신 GPU의 에너지 소비를 측정하는 방법을 종합적으로 조사한 출판된 작업은 없습니다.
이러한 측정은 보이는 것 만큼 사소한 것이 아닙니다. 특히 전력을 샘플링하고 평균을 계산하고 GPU 코드의 런타임을 곱하는 간단한 접근 방식은 큰 오류와 무의미한 결과를 생성 할 수 있습니다. 예를 들어 이 접근 방식을 사용하면 GPU 커널의 런타임을 두 배로 늘리면 사용되는 에너지 양이 두 배 이상 늘어납니다. 마찬가지로 커널의 에너지 소비는 다른 커널이 바로 전에 실행될 때 증가하는 것처럼 보입니다.
간단한 접근 방식은 전력 측정이 GPU 활동(즉, 커널 코드가 실행 중일 때)을 밀접하게 추적하고, 샘플링 간격이 동일하며, 응용 프로그램 코드만 GPU 활동을 유발한다고 가정합니다. 그러나 실제 GPU는 더 복잡합니다. 특히 이 논문은 다음과 같은 공헌을 합니다.
GPU의 전력 소비를 측정 할 때 예상치 못한 여러 동작에 대해 논의하고 설명합니다.
K20 전력 샘플로 작업 할 때 고려해야 할 중요한 관찰을합니다.
센서 데이터를 사용하여 실제 전력 및 에너지 소비를 정확하게 계산하는 방법론을 제시합니다.
다양한 방법으로 방법론을 검증하고 Kepler 기반 K20c, K20m 및 K20x GPU에서 테스트합니다.
이 방법론을 구현하는 GPU 에너지 측정 도구를 만듭니다. publicly available in open source at http://cs.txstate.edu/~burtscher/research/K20power/.
논문의 나머지 부분은 다음과 같이 구성됩니다. 섹션 2에서는 관련 작업에 대해 설명합니다. 섹션 3은 테스트 베드를 설명합니다. 섹션 4에서는 GPU 전력 센서 측정의 잠재적 인 문제를 분석합니다. 섹션 5에서는 이러한 측정을 'correct'하는 방법을 설명합니다. 섹션 6에서는 유효성 검사 결과에 대해 설명합니다. 섹션 7은 결론을 요약하고 도출합니다.
2. RELATED WORK
컴퓨터 구성 요소의 에너지 소비량은 직접 또는 간접적으로 얻을 수 있습니다. 간접 측정은 전력을 하드웨어 성능 카운터 또는 기타 이벤트와 연관시키는 모델을 사용하여 전력 소비를 추정합니다. 이 접근 방식은 컴퓨팅 GPU를 사용할 수있게되기 전에 이미 CPU에 사용되었습니다. 널리 사용되는 두 가지 CPU 전력 모델은 단일 코어 CPU 용 Wattch와 멀티 코어 CPU 용 McPAT입니다. GPU 용 전력 모델 개발에 대한 연구는 아직 초기 단계입니다. 성능 카운터를 사용하는 대부분의 GPU 전력 모델은 통계에 의존하여 전력과 성능을 연관시킵니다. Hong과 Kim은 주어진 애플리케이션에 대한 최적의 활성 GPU 프로세서 수를 예측하기 위해 통합 된 전력 및 성능 예측 모델을 제안했습니다. Song et al. 인공 신경망의 훈련 결과를 기반으로하는 GPU 전력 모델을 제안했습니다. Choi와 Vuduc은 GPU 에너지 소비를 추정하기 위해 루프 라인 모델을 제안했습니다. Sohan et al. 최근 출시 된 GPUSimPow, GPU 전력 소비 모델링 프레임 워크 및 Leng et al. 주기 수준 시뮬레이션을 기반으로 구성 가능한 GPU 전력 모델 인 GPU-Wattch를 개발했지만 Kepler 기반 GPU는 아직 지원되지 않습니다. 모델을 사용하여 전력 소비량을 추정하는 이점은 저렴한 비용으로 배포 할 수 있고 단기 실행 코드에 적용 할 수 있다는 것입니다. 그러나 이러한 모델의 매개 변수는 새 하드웨어를 위해 재교육되어야합니다. 또한 전력 추정은 상대적으로 부정확 할 수 있습니다. 예를 들어 GPUWattch는 실제 하드웨어에서 측정 된 전력과 9.9 %에서 13.4 %까지 다릅니다.
직접 측정 방법은 전류 및 전압 샘플을 주기적으로 수집합니다. 전력은 두 값을 곱하여 계산되고 총 에너지는 실행 시간 동안 전력의 적분으로 계산됩니다. 예를 들어, WattsUP와 같은 간단한 전력계를 사용하여 전체 노드의 전력 판독 값을 수집하고 일정 기간 동안 해당 노드에서 소비한 총 에너지를 계산할 수 있습니다. WattsUP는 사용하기 쉽지만 최대 샘플링 주파수는 다소 낮습니다 (1Hz). 개별 구성 요소 (예 : GPU)의 전력 소비를 얻으려면 노드의 기본 전력을 빼야합니다.
복잡한 특성을 가진 코드의 에너지 효율성을 최적화하기에는 종종 대략적인 전력 측정만으로는 충분하지 않습니다. 따라서 세분화된 전력 소비 정보를 제공하기 위해 여러 도구가 개발되었습니다. 가장 잘 알려진 도구는 아마도 현재 largest power-aware cluster인 Virginia Tech에서 System G용으로 개발된 PowerPack 일 것입니다. PowerPack은 노드 내 개별 구성 요소 (예 : CPU 또는 DRAM)의 전력 소비를 측정 할 수 있습니다. 그러나 하드웨어-소프트웨어 전력 프로파일링 접근 방식은 상당히 비싸고 구현하기도 어렵고 확장하기도 어렵습니다. 널리 사용되는 또 다른 도구는 마더 보드에 연결되는 전원 모니터링 카드로 구성된 PowerMon입니다. PowerPack에 비해 PowerMon은 단일 집적 회로 (배선 또는 납땜 필요 없음) 만 포함하기 때문에 더 저렴하고 구현하기 쉽습니다. 그러나 PowerPack의 약점을 계승하여 전원 공급 장치에 직접 연결된 구성 요소의 전력 소비 만 측정 할 수 있습니다. Sandia National Laboratory는 대규모 시스템에 배포하기위한 구성 요소 수준 전력 측정 도구를 탐색하고 있습니다. 최근에는 PCI 버스 및 외부 전원 공급 장치에서 전력을 끌어 오는 가속기를 계측 할 수있는 PowerInsight 도구를 발표했습니다. 또 다른 주목할만한 추세는 파워 센서를 가속기에 직접 통합하는 것입니다. 예를 들어 Tesla C2075 (Fermi 아키텍처) 및 Tesla K20 (Kepler 아키텍처)과 같은 컴퓨팅 GPU에는 GPU의 전력 소모량을 직접 측정 할 수있는 온보드 전력 센서가 포함되어 있습니다.
테일 에너지를 포함하여 이 백서에서 GPU에 대해 수행한 일부 관찰은 모바일 애플리케이션의 세분화 된 에너지 측정을 복잡하게하는 스마트 폰의 디스크, WiFi, 3G 및 GPS 구성 요소와 같은 다른 장치에서도보고되었습니다. 매우 짧게 실행되는 커널의 전력 소비를 정확하게 캡처 할 수 없다는 점은 과거 CPU 작업에서도 확인되었으며 하드웨어 성능 카운터를 기반으로하는 앞서 언급 한 모델링 접근 방식 중 일부에 동기를 부여했습니다.
3. BENCHMARKS, SYSTEM, AND ENERGY MEASUREMENT
3.1. Benchmark Description
우리는 두 개의 매우 다른 n-body 구현에서 테스트 프로그램을 도출했습니다. 두 알고리즘 모두 사용자가 선택한 수의 타임 스텝에 대해 성단에서 중력에 의해 유발된 별(a.k.a. bodies)의 움직임을 시뮬레이션합니다. 별의 위치와 속도는 구상 성단의 밀도 분포를 모방 한 경험적 Plummer 모델에 따라 초기화됩니다.
NB라고하는 첫 번째 코드는 정확한 쌍별 힘 계산을 수행합니다. n개의 바디와 함께 O(n^2)상호 작용을 고려해야합니다. 그러나 모든 n개의 바디에 대해 동일한 작업이 수행되어 GPU에 잘 매핑되는 매우 일반적인 구현으로 이어집니다. 또한 힘 계산이 독립적이므로 많은 양의 병렬 처리가 발생합니다. 우리의 NB 코드는 단일 K20c GPU에서 2 테라 플롭 이상에 도달하며 CUDA 5.0 SDK의 n-body 코드 성능을 능가합니다.
두 번째 코드인 BH는 Barnes-Hut 알고리즘을 사용하여 힘을 대략적으로 계산합니다. 그것은 n개의 body 주위의 부피를 세포라고 불리는 연속적으로 더 작은 입방체로 계층적으로 분할하여 가장 안쪽의 세포 당 하나의 몸체가있을 때까지합니다. 결과 공간 계층 구조는 불균형 octree에 기록됩니다. 각 셀은 포함된 body에 대한 정보를 요약합니다. 이 계층은 알고리즘의 복잡성을 O(n log n)로 줄입니다. 왜냐하면 충분히 멀리있는 셀의 경우 셀 내부의 각 바디에 대해 하나의 계산을 수행하는 대신 셀에 대해 하나의 힘 계산 만 수행하는 것으로 충분하기 때문입니다. LonestarGPU 제품군 [34]에서 BH 코드를 얻었습니다.
NB 코드는 비교적 간단하고 계산 밀도가 높으며 공유 메모리의 우수한 캐싱으로 인해 주 메모리에만 자주 액세스합니다. 대조적으로 BH 코드는 매우 복잡하고 계산 밀도가 낮으며 대부분 불규칙한 포인터 추적 메모리 액세스를 수행하며 여러 개의 다른 커널로 구성됩니다. 그 결과 '단지' 약 200 기가 플롭에 달합니다. 그럼에도 불구하고 시간 복잡성이 낮기 때문에 백만 개의 별을 시뮬레이션 할 때 NB 코드보다 약 33 배 빠릅니다. 두 코드 모두 최신 Xeon 멀티 코어 시스템에서 실행되는 해당 병렬 OpenMP CPU 코드보다 30 배 이상 빠릅니다.
3.2. GPU and Compiler Description
우리의 기본 GPU는 NVIDIA Tesla K20c입니다. 5GB의 글로벌 메모리와 2496개의 PE(precessing elements)가있는 13 개의 스트리밍 멀티 프로세서 (SMXs)가 있습니다. 또한 두 번째 K20c GPU, 한 쌍의 Tesla K20m GPU, 한 쌍의 Tesla K20x GPU를 연구에 사용했습니다. K20c와 K20m의 주요 차이점은 전자에는 팬이 장착되어 있지만 후자는 수동 냉각이 필요하다는 것입니다. 반면 K20x에는 6GB의 메인 메모리와 2688개의 PE가있는 14개의 SMX가 있습니다. nvcc 5.0과‘-O3 -arch = sm_35’플래그를 사용하여 CUDA 코드를 컴파일했습니다. 실험에 따라 별의 개수가 다른 프로그램을 한 번에 실행했습니다.
3.3. Energy measurement
테스트 커널의 에너지 소비량을 얻기 위해 GPU 전력 센서를 사용합니다. 전력 판독 값을 밀리 와트 단위로 반환하는 NVIDIA Management Library (NVML) 인터페이스를 통해 센서를 쿼리하는 자체 도구를 작성했습니다. 일관성을 위해 우리는 항상 전력 및 메모리 사용량을 모두 샘플링하고 대부분의 실험에이 데이터가 모두 필요하지는 않지만 각 샘플에 고해상도 타임 스탬프를 포함합니다. 달리 명시되지 않는 한,보고 된 모든 시간은 측정 된 애플리케이션 또는 첫 번째 GPU 커널이 시작된시기가 아니라 도구를 시작한시기를 기준으로합니다.
테스트 커널의 에너지 소비량을 얻기 위해 GPU 전력 센서를 사용합니다. 전력 판독 값을 밀리 와트 단위로 반환하는 NVIDIA Management Library (NVML)인터페이스를 통해 센서를 쿼리하는 자체 도구를 작성했습니다. 일관성을 위해 우리는 항상 전력 및 메모리 사용량을 모두 샘플링하고 대부분의 실험에 이 데이터가 모두 필요하지는 않지만 각 샘플에 고해상도 타임 스탬프를 포함합니다. 달리 명시되지 않는 한, 보고된 모든 시간은 측정된 애플리케이션 또는 첫번째 GPU 커널이 시작된시기가 아니라 툴을 시작한시기를 기준으로합니다.
4. MEASUREMENTS AND OBSERVATIONS
이 섹션에서는 GPU 센서에서 얻은 전력 프로필의 흥미로운 측면을 강조하고 몇 가지 의미에 대해 논의합니다.
4.1. Power Lag and Distortion
Figure 1은 일반 커널 실행 전, 실행 중 및 실행 후 GPU 전력 센서를 샘플링 할 때 얻은 특성 프로필(characteristic profile)을 보여줍니다. 커널은 시간 t1에서 실행을 시작하고 시간 t2에서 중지합니다. 전력 프로파일은 NB 코드에서 forcecalculation 커널의 단일 호출에서 비롯됩니다. 다른 일반 커널의 프로필은 비슷해 보입니다. 더 긴 런타임은 점 t2를 오른쪽으로 밀어 전력 곡선의 평평한 부분을 확장합니다. 더 짧은 런타임은 점 t2를 왼쪽으로 밀어서 점차 평평한 부분을 제거합니다(Figure 2 참조). 곡선이 접근하는 점근적인 수준은 커널마다 다릅니다.
전력 프로필에서 가장 눈에 띄는 두 가지 측면은 (1) 전력 소비가 커널 활동에 뒤쳐지고 (2) 프로필의 모양이 커널 활동과 일치하지 않는다는 것입니다. 커널 런타임은 5.346 초이므로 거시적 효과입니다. 실제 커널 활동은 거의 순간적으로 증가하고 실행 기간 동안 일정한 수준에 머물렀다가 다음 실험에서 알 수 있듯이 거의 즉시 0으로 떨어집니다. 커널의 워크로드를 X%로 줄이면 런타임도 X%(수 밀리 초 이내)로 떨어지므로 실행 중에 전력 수준이 일정하게 유지되어야 함을 나타냅니다. 대신 런타임의 첫 X%에 대한 전력 프로필은 Figure 1의 프로필 시작 부분과 동일합니다. 마찬가지로 커널이 중지 된 후 프로필의 모양도 Figure 2의 점선에서 볼 수 있듯이 부분적으로 동일합니다.
전력 프로필의 지연 및 실제 커널 활동과의 차이로 인해 전력을 통합하여 에너지 소비를 얻을 때 문제가 발생합니다. 예를 들어, 측정된 전력이 순간적으로 증가하는 대신 점진적으로 증가하기 때문에 똑같은 계산을 두 번 수행하는 커널의 런타임을 두 배로 늘릴 때 t1에서 t2까지의 적분은 두 배 이상이됩니다. 예를 들어, Figure 1의 데이터에서 계산된 에너지는 732J이지만 동일한 커널을 두 배 더 오래 실행할 때 에너지는 1579J, 즉 115J 또는 2배 보다 약 8% 더 많습니다. 이것은 직관적이지 않습니다. 결국 에너지는 캐싱 효과로 인해 두번이 아닌 한번만 발생하는 등의 요인으로 인해 두 배 미만으로 증가하거나 두 배로 증가해야합니다.
전력이 기본 커널 활동보다 뒤쳐지기 때문에 시간 t2 (아마도 전력 곡선이 계단 모양으로 변경되는 시간 t3, 또는 idle 전력에 도달한 시간 t4)를 넘어서 통합해야 할 수 있습니다. 안타깝게도 Figure 1에 표시된 간단한 경우에는 적분의 종료 시간이 명확하지 않으며, GPU 가속 응용 프로그램에서 흔히 발생하는 여러 커널을 연속적으로 호출하거나 더 복잡한 커널의 경우에는 더 명확하지 않습니다. 이 후자의 경우(multiple kernels)는 특히 흥미롭습니다. 두 번째 커널이 시간 t4 이전에, 즉 idle 전력에 도달하기 전에 호출되면 전력 프로필이 더 높은 수준에서 시작됩니다. 그림 2의 시간 t1_b에서 두 번째 커널 호출은 이 경우를 보여줍니다. 여기서 첨자 'a'는 첫 번째 호출을 나타내고 아래 첨자 'b'는 두 번째 호출을 나타냅니다. 점선은 t2_b와 t3_b 사이의 기간을 제외하고 첫 번째 및 두 번째 호출의 전력 프로파일이 그림 1의 더 오래 실행되는 커널의 모양을 정확하게 따른다는 것을 보여줍니다 (다음 하위 섹션 참조). 그러나 두 번째 호출은 더 높은 전력 레벨에서 시작하여 더 높은 최대 값에 도달합니다. 따라서 두 번째 호출의 통합 에너지는 첫 번째 커널이 중지되는 시간 (t2_a)과 두 번째 커널이 시작되는 시간 (t1_b) 사이의 시간과 반비례하는 양만큼 더 높습니다. 예를 들어, 그림 2의 데이터를 사용하면 첫 번째 호출의 에너지 소비는 114J이고 두 번째 호출의 에너지 소비는 147J로, 동일한 값에 대해 동일한 독립적인 계산이 수행 되더라도 29 % 증가합니다.
4.2. Tail Energy
Figure 3은 NB force 계산 커널의 6개 실행에 대한 부분 전력 프로파일을 보여줍니다. 커널이 실행을 중지하는 지점 t2가 모두 16.5초가 되도록 이동됩니다. 다른 입력 크기를 사용하여 다른 런타임을 생성하고 따라서 커널이 종료 될 때 다른 전력 수준을 생성했습니다.
Figure 3은 t2와 t3 사이의 전력 프로파일이 시간 t2에서 전력 레벨의 함수인 것처럼 보인다는 것을 보여줍니다. 반대로 t3와 t4 사이의 프로필은 거의 동일하며 커널 런타임 또는 도달한 전력 수준과는 무관합니다. 또한 프로파일의 모양에 눈에 띄는 변화가 시간 t3에서 발생하며, 여기서 곡선에서 계단 함수로 변화합니다. 분명히 에너지 소비를 얻기 위해 시간 t3 이후의 전력을 통합하면 단순히 일정한 양의 에너지 (약 130J)가 추가되어 이 에너지가 포함되어야하는지 의심 스럽습니다. 기껏해야 커널 활동과 관련이없는 고정 된 오버 헤드로 간주 될 수 있습니다.
시간 t3에서 모양의 놀라운 변화를 제외하고, 이러한 프로파일의 가장 주목할만한 점은 시간 t3에서 모두 동일한 전력 수준 (약 52.5W)에 정착한다는 것입니다. 이는 시간 t2의 전력 수준이 52.5W 미만인 경우에도 마찬가지입니다. 이 경우 계산이 중지된 후 전력 소비량이 실제로 증가합니다. 이러한 반 직관적인 동작은 전력 지연을 보상하기 위해 t2를지나 통합 할 때 단기 실행 커널의 에너지 소비를 부풀립니다.
지연된 전력 소비로 인해 단기 실행 커널에 더 많은 'missing'에너지가 발생하기 때문에 커널이 종료 된 후 잠시 동안 전력 소비량이 증가하는 것이 합리적이라고 주장 할 수 있습니다. 그러나 다음 실험에서 알 수 있듯이 이것은 잘못된 것입니다. 95,000 개의 바디에서 커널 런타임은 0.107 초, 최대 전력은 35.7 와트, t1에서 t2까지의 통합 에너지는 3.25J 입니다. 테일 에너지의 첫 번째 부분 (t2에서 t3)을 더하면 119J입니다. 코드가 실행되는 동안 1.1kW 이상의 실제 전력 소비가 발생합니다. 이 숫자는 GPU의 최대 전력 등급을 훨씬 초과합니다. 온보드 배터리 및 커패시터도 1/10 초 동안 킬로와트의 전력을 제공 할 수 없으므로 전력 지연을 보상하기 위해 시간 t3 이상까지 통합하는 것은 올바른 방법이 될 수 없습니다. 따라서 '테일 에너지'라고 부르는 시간 t2 이후의 에너지 소비는 커널 활동에 직접적으로 기인 할 수 없습니다.
4.3. Sampling Intervals
Figure 4는 연속 전력 샘플 사이의 경과 시간, 즉 Figure 1의 전력 프로파일 위에 중첩된 샘플링 간격 길이를 보여줍니다. 16.6 초에서 차단 스파이크(cut-off spike)는 130ms까지 증가합니다. 이러한 결과는 재현 가능하며 최대 속도로 전력을 샘플링 할 때 얻은 것입니다.
Figure 4의 인터벌 길이는 몇 가지 흥미로운 특징을 보여줍니다. 첫째, 0.266ms에서 130ms까지 거의 500배 정도 다양합니다. 명백하게, 간격이 동일하다고 가정 할 수는 없습니다. 둘째, 커널이 실행되기 직전과 직후뿐만 아니라 t3-t4 단계에서 전력이 감소 할 때마다 명백한 스파이크가 발생합니다. 셋째, 간격 길이는 커널이 실행되는 동안과 t2-t3 단계, 즉 전력 프로파일이 곡선인 두 단계에서 빠르게 변동합니다.
t3-t4 단계의 스파이크는 GPU가 낮은 전력 수준으로 내려가는 것과 일치하므로 드라이버가 이 기간 동안 빠르게 응답하지 않는 결과라고 가정합니다. 즉, 하드웨어 또는 소프트웨어가 GPU 전력 수준을 변경하느라 바쁠 때마다 전력 샘플 요청이 지연됩니다. 사실, 그러한 활동은 또한 가장 큰 스파이크의 원인인 것 같습니다. Figure 4에서 측정된 CUDA 코드는 결과를 호스트로 다시 전송하지 않기 때문에 이 스파이크는 GPU에서 CPU로 데이터를 전송하기 때문이 아닙니다. 실제로 데이터를 전송하지 않거나 일부 또는 많이 전송하는 모든 실험에서 전력 판독 값에 큰 변화가 발생하지 않았습니다. 따라서 측정된 전력 도메인에는 PCI-express 하드웨어가 포함되어 있지 않다고 생각합니다. 추가 실험에 따르면 호스트 코드가 종료 될 때 항상 큰 스파이크가 발생합니다. 또한 GPU에서 사용 가능한 메모리 양을 쿼리하여 스파이크가 해제되는 시스템 할당 메모리와 일치함을 발견했습니다. 이것은 전력 샘플링 요청을 지연시키는 드라이버 활동을 다시 나타냅니다. 마찬가지로 GPU 코드가 실행되기 전의 스파이크는 커널 실행을 설정하기위한 드라이버 활동 때문이라고 추측합니다. 다시 말하지만, 메모리 소비 측정은 이 가설을 뒷받침합니다. 특히 t1 이전의 가장 큰 스파이크는 애플리케이션이 자체 메모리를 할당하기 전에 발생하는 GPU 메모리 사용량의 수 메가 바이트 증가와 일치합니다.
t1과 t3 사이의 간격 길이가 빠르고 일관되게 변동하는 이유도 드라이버와 관련이 있습니다. 이러한 변동의 원인을 더 잘 이해하려면 Figure 4의 발췌 부분을 크게 확대한 Figure 5를 참고해야 합니다.
Figure 5는 t1-t3 단계 전체에서 반복되는 패턴을 보여줍니다. 특히, 약 38개의 짧은 간격 및 동일한 측정이 있으며, 다음 세트의 밀접하고 동일한 측정 이전에 비교적 큰 간격이 뒤따릅니다. Figure 5의 첫 번째 전력 판독 값 세트는 모두 109.325W이고 두 번째 세트의 판독 값은 모두 110.176W입니다. 이러한 세트 내의 샘플링 간격 길이는 약 0.283ms입니다. 세트 사이의 간격은 약 4.7ms입니다. 전력 측정은 갭 후에만 변경되므로, 응답 시간이 더 오래 걸리는 이유로 GPU 센서가 새로운 측정을 수행하기 때문이라고 생각합니다. 따라서 짧은 간격의 측정은 단순히 최근 측정의 반복인 것처럼 보입니다. 이를 염두에 두고 하드웨어에서 지원하는 실제 최대 샘플링 주파수는 약 66.7Hz (15ms 샘플링 간격)입니다.
이 발견은 흥미로운 결과를 가져옵니다. 잘 동작하는 전력 프로파일을 가정하고 5%의 오차를 기꺼이 받아들일 것이라고 가정하면 에너지를 계산하는데 최소한의 전력 샘플이 10개 정도 필요합니다. 15ms per sample에서, 이는 많은 커널의 런타임을 초과하는 150ms의 런타임에 해당합니다. 즉, 내장형 파워 센서로 많은 실제 커널의 에너지 소비량을 정확하게 측정하는 것은 런타임이 너무 짧기 때문에 어렵습니다.
또 다른 흥미로운 점은 간격 길이의 큰 변동으로 인해 단순히 전력 판독 값의 평균을 계산하고 이를 에너지를 얻기 위한 실행시간으로 곱할 수 없다는 것입니다. Figure 6은 간격 길이의 차이를 정확하게 설명하는 Figure 1의 전력 프로파일과 동일한 전력 판독 값을 t1과 t4 사이의 간격이 고정 된 상태로 표시하여 이 문제를 보여줍니다.
분명히 두 프로필은 겹치지 않습니다. 또한 통합될 때 동일한 에너지를 생성하지 않습니다. Figure 6의 실선은 시간 t1과 t4 사이에 1066J의 에너지 소비를 산출하는 반면 점선은 동일한 기간 동안 13 %의 불일치인 1205J의 에너지 소비를 나타냅니다.
5. PROPOSED APPROACH TO CORRECT THE POWER AND ENERGY MEASUREMENTS
이전 섹션에서 설명한 관찰을 기반으로 GPU 커널의 실제 전력 및 에너지 소비를 정확하게 계산하는 방법론을 개발했습니다. 핵심적인 통찰은 파워 센서가 즉각적인 것이 아니라 점차적으로 실제 파워 레벨에 접근한다는 것입니다. 시간 t1과 t3 사이의 '곡선' 전력 판독 값은 커패시터 충전 및 방전을 상기 시켰으므로 전력 프로파일을 동일한 공식으로 설명 할 수 있는지 여부를 테스트했습니다. 이것은 매우 잘 작동하는 것으로 밝혀졌습니다. 파워 센서 하드웨어가 일종의 커패시터를 사용하기 때문에 이것이 사실이라고 가정 할 수 있습니다.
이러한 통찰력을 바탕으로 측정된 데이터와 모델링된 데이터 사이의 오류를 최소화하여 파워 센서의 '커패시턴스'를 결정하는 것은 간단합니다. 예를 들어, 단일 커패시터 함수를 사용하여 Figure 1의 시간 t1과 t2 사이의 곡선을 근사화하고 측정된 값과 함수 값 간의 차이의 합을 최소화하는 커패시턴스 값을 결정했습니다. 커패시턴스가 일정하기 때문에 주어진 GPU에 대해 한 번만 설정하면됩니다. 테스트된 모든 K20 GPU에서 C = 833.333s를 찾았습니다. 실제 순간 전력 P_true를 계산하면 전력 프로파일 dP / dt의 기울기와 시간 t_i에서 측정된 전력 P_meas의 간단한 함수가 됩니다. 다음은 C가 위 GPU의 커패시턴스인 symmetric discrete solution입니다.
P_true(t_i) = P_meas(t_i) + C × (P_meas(t_i+1) - P_meas(t_i-1)) / (t_i+1 - t_i-1)
이 방정식을 기반으로 GPU의 실제 성능을 측정하고 계산하기 위해 다음 접근 방식을 권장합니다.
1. 최소 66.7Hz에서 샘플링하고 타임 스탬프를 포함합니다.
2. 새 데이터를 구성하지 않으므로 간격이 4ms 이하인 동일한 값의 연속 샘플을 제거합니다.
3. 기울기를 근사화하기 위해 인접한 전력 샘플을 사용하여 위의 방정식으로 실제 전력을 계산합니다.
4. 전력 수준이 'active idle' 임계값인 52.5W를 초과하는 모든 간격에서 타임 스탬프를 사용하여 실제 전력을 통합하여 실제 에너지 소비를 계산합니다.
6. VALIDATION RESULTS
이 섹션에서는 우리의 접근 방식으로 얻은 결과를 제시하고 여러 방법으로 검증합니다. 먼저 위의 연구 중 일부를 반복하고 우리의 접근 방식이 발견된 이상함을 해결하는지 확인합니다. 그런 다음 우리의 접근 방식을 다른 시스템과 GPU에 적용합니다. 마지막으로 복잡한 GPU 애플리케이션을 조사합니다. 최대 속도로 전력을 샘플링합니다.
6.1. Single homogeneous kernel
전력 곡선은 커널이 실행되는 시간에 관계없이 동일한 속도로 상승하고 (4.1 절 참조), 커널 중지 후 동작도 커널과 거의 무관하기 때문에 (4.2 절 참조), 이러한 기이함의 영향은 실행 시간을 충분히 늘림으로써 총 에너지를 미미하게 만들 수 있습니다. 결국, 매우 긴 실행의 경우 전력 곡선은 대부분의 런타임에서 점근 전력 수준에 가깝습니다. 동종 커널의 경우 에너지는 런타임에 점근적 전력을 곱한 최소 오류로 계산할 수 있습니다. 이 에너지를 적절하게 확장함으로써 우리는 더 짧은 실행에서 예상되는 실제 에너지 소비를 얻습니다. 즉, 매우 규칙적인 커널의 경우 에너지 소비를 점근적 전력의 런타임 곱으로 가정합니다. NB force 계산은 일반적인 커널이므로 이에 대한 접근 방식을 검증 할 수 있어야합니다.
우리의 접근 방식은 NB force-calculation 커널에 대해 Figure 7에 표시된 수정된 전력 프로필을 생성합니다. 점선은 기존 전력 측정을 나타내는 반면 흔들리는 실선은 시간 t1과 t3 사이에 계산된 전력 소모량을 나타냅니다. 프로파일은 t1 이전과 t3 이후에 직사각형이므로 계산된 전력과 실제 전력은 해당 영역에서 동일합니다.
마침내 계산된 전력 프로필이 GPU 커널 활동을 밀접하게 따르는 것을 관찰합니다. 특히 커널이 시작될 때 거의 즉각적으로 작동하고 실행 중에 (다소 또는 더 적은) 일정한 수준을 유지하며 커널이 중지 된 후 거의 즉시 앞서 언급 한 52.5W로 떨어집니다. 중요한 것은 실행 중 전력 수준이 t1과 t2 사이의 점근적 전력과 일치하여 위의 가설을 확인한다는 것입니다.
실행 후의 전력 수준은 t2와 t3 사이의 점근적 전력과 일치하므로 우리의 접근 방식을 더욱 검증합니다. 이 전력 레벨은 t3 ~ t4 단계 시작시 52.5W의 'active idle' 레벨과 동일합니다 (섹션 4.2 참조). t3에서 t4 단계로 전력 수준을 낮출 때 드라이버 / 하드웨어가 바쁜 것처럼 보인다는 사실과 함께 이제 우리는 새 커널 launch를 예상하여 잠시 동안 active idle 전력이 GPU에 의해 유지 될 가능성이 높다고 확신 할 수 있습니다. 3.5 초 정도의 주어진 시간 내에 커널이 실행되지 않으면 드라이버는 유휴 전력에 도달 할 때까지 매초마다 전력을 단계적으로 낮춥니다.
이것이 정확하다고 가정하면 커널의 에너지 소비를 얻기 위해 시간 t1에서 시간 t2까지 전력을 통합해야한다는 것이 이제 분명합니다. 커널 실행 전후에 GPU의 모든 에너지 소비는 유휴 상태 (다른 전력 수준에서)로 인한 것이며 시간 함수이지만 커널과는 독립적입니다.
Figure 7에서 수정된 전력 프로파일은 직사각형이 아니지만 흔들림(wobbles, oscillation)이 있습니다. 이는 파워 센서 (해상도가 약 10mW 인)의 유한 정밀도 측정 오류이며 곡선의 기울기로 확대됩니다. 이것이 커브가 더 가파른 곳에서 흔들림이 더 큰 이유입니다. 다행히도 이러한 오류는 평균을내어 정확한 에너지 적분을 생성하는 경향이 있습니다. 흔들림은 고차 공식을 사용하여 기울기를 계산 즉, 두 개 이상의 인접한 전력 샘플을 사용하여 쉽게 부드럽게 할 수 있습니다.
6.2. Revisiting the Anomalies
In Section 4.1, we noted two anomalies. The first was that doubling the kernel runtime resulted in more than twice the energy consumption. Looking at the corrected power profile from Figure 7, we now find that doubling the runtime doubles the energy, as we would expect. Hence, the first anomaly is resolved, which further validates our approach.
The second anomaly was that running the same kernel twice in close temporal proximity inflates the energy consumption of the second invocation. Figure 8 shows that our approach also resolves this anomaly as the two corrected profiles are now at the same level (and the power level between the kernel runs is at the active-idle level). In other words, the computed power profile of a kernel is unaffected by prior kernel runs, which is an important advantage of our approach. This means that we do not have to delay kernel runs until the GPU reaches its idle power level before we can measure the energy consumption of the next kernel.
7. SUMMARY AND FUTURE WORK
프로그래머가 GPU 코드의 에너지 소비를 연구하고 줄일 수 있으려면 정확한 에너지 측정이 필요합니다. 그러나 전력을 샘플링하고 평균을 계산하고 런타임을 곱하는 간단한 접근 방식은 K20의 내장형 전력 센서를 사용할 때 큰 오류를 초래할 수 있습니다. 이것은 여러 가지 complications 때문입니다. 예를 들어, 우리의 연구에 따르면 1) 전력 프로파일이 커널 활동과 관련하여 왜곡되고, 2) 측정된 전력이 커널 활동보다 뒤처지고, 3) 여러 커널을 차례로 실행하면 나중 커널의 전력 소비가 증가합니다. 4) 짧은 실행 커널 후 잠시 동안 전력 소비가 증가 할 수 있습니다. 5) 커널이 중지 된 후 식별 가능한 시간에 전력을 통합해도 전력 지연을 올바르게 보상하지 않습니다. 6) 샘플링 간격 길이가 크게 변화합니다. 7) GPU 센서가 가끔 전력 측정을 수행하고, 8) 실제 샘플링 속도가 너무 낮아 단시간 실행 커널을 정확하게 측정 할 수 없음, 9) PCI 버스 활동이 센서 측정에 포함되지 않음.
본 논문에서는 위의 문제가 존재하더라도 정확한 전력 및 에너지 측정 방법론을 제안하고 평가합니다. 측정된 전력 샘플에서 실제 순간 전력 소비를 계산하고, 샘플링 주파수의 변화를 고려하고, 커널이 실행중인 시기와 GPU가 다음 커널 시작을 기다리는 active idle 모드에 있는 시기를 정확하게 식별합니다. 또한 동일한 GPU의 이전 활동에 민감하지 않으며 다양한 유형의 K20 GPU에서 작동합니다. 또한 정확한 에너지 결과를 얻기 위해 커널 런타임이 최소로 유지되어야하는 시간에 대한 지침도 제공합니다. 우리는 여러 시스템, GPU 유형, 시나리오 및 CUDA 프로그램을 사용하여 방법론을 검증했습니다.
향후 작업에서 우리는 방법론을 사용하여 다양한 GPU 애플리케이션의 전력 및 에너지 소비와 다양한 코드 최적화의 에너지 효율성을 조사 할 계획입니다. 또한 도구에 multiGPU 노드에 대한 평활화 및 지원을 추가하려고합니다. 마지막으로 여러 컴퓨팅 노드의 결과를 자동으로 결합하여 클러스터 환경에서 총 에너지 수치를 제공하려고합니다.
