ComSys_jh

Near-Memory processing vs In-Memory processing

H/W engineer_ beginner — Mon, 11 Jul 2022 16:43:34 +0900

본 포스팅은 향후 장기적으로 진행될 Processing In Memory 연구의 Base line을 위해 정리한 내용입니다.

Introduction

PIM이 왜 중요한가?

대한민국 정부에서는 인공지능 반도체 선도국가 도약을 위한 초격차 기술 중 하나로 Processing-In Memory(PIM)을 선정하였습니다. 대한민국 뿐 만 아니라 많은 국가의 일류 반도체 기업과 학계에서는 PIM을 주목하고 있는데, 그 이유는 무엇일까요? 일반적으로 컴퓨터에서 가장 중요한 두 가지를 고르라고 한다면 연산을 처리하는 Processing unit과, 처리할 연산 정보를 가져오고 다시 저장하는 공간인 Memory를 선택할 것입니다. 컴퓨터와 반도체 기술이 지금처럼 발달하기 전에는 연산을 처리하는 Processing unit 자체의 성능 혹은 Memory 자체의 성능에 의해 전체 시스템 성능이 좌지우지 되었지만, 이 둘의 기술이 극도로 발전함에 따라 이 두 장치 사이에서 발생하는 데이터의 이동이 시스템 전체 성능에 큰 영향을 미치게 되었습니다. 또한 AI기술의 발달로 정말 많은 양의 데이터 이동이 필요해졌으며, 엄청난 양의 데이터 이동은 곧 큰 전력소모로 이어지기 때문에, 저전력 고효율 환경을 구축해야 하는 서버 등에서 새로운 아키텍쳐의 도입의 필요성이 제기되었습니다. PIM은 이런 상황을 타파할 수 있는 대안 중 하나로 제시되었으며, 현재 산업계와 학계에서 정말 활발히 연구되고 있는 분야 중 하나입니다. PIM이란 Processing-In Memory의 약자로 메모리와 연산 처리 장치를 매우 가까운 위치, 혹은 동일한 공간 상에 위치 시켜 두 장치간 데이터 이동으로 발생하는 오버헤드 및 전력 소비를 획기적으로 줄이는 기술입니다. 저는 본 기술이 앞으로 대한민국 반도체 기술을 선도할 수 있는 핵심 기술이 될 것이라 판단하였고 석사 연구 프로젝트의 주제로 PIM을 선택하였습니다. PIM 기술을 선도하기 위해서는 근본적으로 차세대 메모리 기술이 필수적입니다. 대한민국 정부가 본 기술에 더욱 주목하는 이유는 바로 차세대 메모리 반도체를 만들 수 있는 기업이 우리나라에 두 군데나 있기 때문입니다. (삼*전자, S*하이닉스)

PIM 연구를 진행하기 전 정립해야할 개념

어떤 연구든 정확한 표현의 모호함과 적합한 용어 사용 아주 중요, PIM처럼 최근 활발하게 연구가 시작되는 분야는 더욱이 중요함 그래서 용어 사용과 관련하여 확실한 정립이 선행되어야 함 => Near Memory computing, In Memory computing ~~

Near-Memory computing과 In-Memory computing을 구분해야 하는 이유는 무엇인가?

그림 제작하여 예시로 설명하고 표 및 비교 자료를 첨부하여 상세하고 명확하게 설명

______________________(작성중 22.06.27)___________________________

I. Near-Memory processing

II. In-Memory processing

+ Optimizing / Generel purpose

Reference

[1] Khoram, S., Zha, Y., Zhang, J., & Li, J. (2017, March). Challenges and opportunities: From near-memory computing to in-memory computing. In Proceedings of the 2017 ACM on International Symposium on Physical Design (pp. 43-46).

[2] 한국과학기술기획평가원, ｢2020년도 예비타당성조사 보고서 PIM 인공지능반도체 핵심기술 개발사업｣

Zsim + Ramulator (PIM simulator)

H/W engineer_ beginner — Mon, 20 Jun 2022 17:02:52 +0900

Zsim + Ramulaotor 는 Processing-in-Memory(PIM) 을 시뮬레이션 할 수 있는 프레임워워크로 향후 장기적으로 진행할 PIM 관련 연구의 Base line을 설정하기 위하여 정리했습니다.

I. Introduction

Zsim+Ramulator 은 General-purpose processing-in-memory (PIM) 아키텍쳐를 시뮬레이션 하기 위한 빠르고 유연한 프레임워크 입니다. Ramulator-PIM으로도 불리는 이 프레임워크는 널리 사용되고 있는 두 시뮬레이터(*Zsim, *Ramulator)를 기반으로 만들어졌습니다.

이 프레임워크의 Computing system에는 host CPU core와 General-purpose PIM core가 있습니다. PIM core들은 Ramulator의 HMC model (3D-stacked memory)안에 위치해 있으며, 시뮬레이션을 통해 두 종류의 core에서 실행되는 어플리케이션의 성능 차이를 확인할 수 있습니다. 즉, 동일한 프로그램을 CPU core 만을 사용하거나, General-purpose PIM core만을 사용해 시뮬레이션 하고 이 둘의 성능 차이를 확인할 수 있습니다. 이를 통해 여러 Benchmark program들을 두가지 옵션으로 실행하고 성능의 차이가 큰 프로그램들을 분류하여 분류된 프로그램들의 특징을 분석해보려 합니다.

본 시뮬레이터에서 ZSim은 Ramulator에 보낼 Memory trace를 생성합니다. PIM의 성능 측정을 위해 기존의 ZSim을 변형하여 두 가지 타입의 Memory trace가 생성되는데, 이들은 각각 host CPU trace를 위한 *Filtered traces와 PIM core를 위한 *Unfiltered traces로 불립니다.

Ramulator는 ZSim을 통해 생성된 Filtered traces와 Unfiltered traces를 사용하여 두 코어의 메모리 엑세스를 시뮬레이션 합니다. 본 시뮬레이터에서는 PIM core를 시뮬레이션 하기 위해 Off-chip link overhead 를 피할수 있도록 수정되었습니다.

Figure 1 [Repository Structure of Zsim+Ramulator] / Reference [1]

*Zsim: 널리 사용되는 x86-64 멀티코어 시뮬레이터 입니다.

*Ramulator: DDRx, LPDDRx, GDDRx, WIOx, HBMx 등을 포함한 여러 DRAM 아키텍쳐가 포함된 DRAM 시뮬레이터 입니다.

*Filtered traces: 메모리 컨트롤러의 요청에 의해 수집되는 정보로, host의 캐시 계층구조가 ZSim 내부에서 시뮬레이션 됩니다. ZSim을 통해 *Hardware prefetcher 또한 시뮬레이션 될 수 있습니다. (host CPU core를 위한 memory trace)

*Unfitered traces: 코어 파이프라인에서 Issue되는 즉시 모든 메모리 Request를 수집하는 방법입니다. (PIM core를 위한 memory trace)

*Hardware prefetcher: Software prefetch 처럼 캐시 블록을 인위적으로 제어하는 것이 아니라 하드웨어가 자동으로 프리패치 기능을 수행하는 것으로, 프로세서의 요청에 예상되는 메모리 블록을 미리 캐시에 페치합니다.

II. Setup

i) Installing

ZSim과 Ramulator 모두를 사용하는 본 시뮬레이터를 사용하기 위하여 각 시뮬레이터의 Dependency들을 맞춰 설치하는 작업이 필요했습니다. 이를 위해 각 시뮬레이터의 Git hub Readme.md 의 설명을 참고하였으며 "Git clone" 명령으로 원하는 경로에 설치 파일들을 로드하는 것으로 시뮬레이터 설치를 시작할 수 있습니다. 본 시뮬레이터에서 설명하는 Dependency는 아래와 같습니다.

* ZSim: gcc >=4.6, pin, scons, libconfig, libhdf5, libelfg0

* Ramulator: C++11 compiler (e.g Clang++, g++-5)

필요한 라이브러리들은 본 시뮬레이터의 setup.sh, compile.sh, make file에 모두 있으므로 설치 과정에서 컴파일러를 적합한 버젼으로 설정하는 것과 에러가 발생하는 특정 라이브러리가 맞는 버젼으로 설치될 수 있도록 수정하는 것 정도로 설치를 마무리 할 수 있습니다.

ii) Trouble shooting

(1) 'sh compile.sh' 명령어 입력 시 에러 발생 (aclocal-1.15 is missing on your system)

=> 'sudo apt install automake-1.15' 명령어 입력으로 해결하였습니다.

(2) 'ramulator make' 명령어 입력 시 에러 발생 ('~' can not be used when making a PIE object)

=> 본 에러는 make file의 컴파일러 버젼과 설치되는 리눅스 환경의 컴파일러 버젼이 달라 발생하는 에러로 판단됩니다.

=> ramulator directory 내부에 위치한 make file을 열어서 적합한 컴파일러 버젼을 입력 (CXX := g++5로 변경)

=> 터미널에서 'sudo update-alternatives --config g++/gcc' 명령어를 통해 모든 컴파일러 버젼 5로 맞춘 후 정상 동작하는 것을 확인할 수 있습니다.

III. How to use?

i) Generating Traces with Zsim

ZSim에서 Trace를 생성하기 위해선 세 가지 단계가 필요합니다.

1. zsim-ramulator/misc/hooks/zsim_hooks.h 경로의 파일 내부 코드를 참고하여 어플리케이션에서 측정할 코드 구역을 설정합니다.

2. ZSim을 위한 Configuration file들을 만듭니다.

3. 실행 파일을 실행합니다.

각 단계의 세부 사항은 아래에 정리했습니다.

1. zsim-ramulator/misc/hooks/zsim_hooks.h 경로의 파일 내부 코드를 참고하여 어플리케이션에서 측정할 코드 구역을 설정합니다.

먼저 어플리케이션에서 관심 있는 부분의 코드를 지정합니다. 본 시뮬레이터에서는 이 부분이 'offload region' 이라는 용어로 통용됩니다. 지정한 Region의 code는 PIM Core에서 실행되며 자세한 설명은 밑에 첨부한 코드를 참고 바랍니다.

#include "zsim-ramulator/misc/hooks/zsim_hooks.h"
foo(){
    /*
    * zsim_roi_begin() marks the beginning of the region of interest (ROI).
    * It must be included in a serial part of the code.
    */
	zsim_roi_begin(); 
	zsim_PIM_function_begin(); // Indicates the beginning of the code to simulate (hotspot).
	...
	zsim_PIM_function_end(); // Indicates the end of the code to simulate.
    /*
    * zsim_roi_end() marks the end of the ROI. 
    * It must be included in a serial part of the code. 
    */
	zsim_roi_end(); 
}

2. ZSim을 위한 Configuration file들을 만듭니다.

Configuration file들은 Zsim으로 Application들을 실행시킬 때 사용됩니다. 본 시뮬레이터에서는 Filtered trace와 Unfiltered trace를 위한 Sample code 들을 zsim-ramulator/tests 경로에서 제공합니다. 이 샘플 코드들을 통해 Core의 갯수, 캐쉬 메모리의 사이즈와 갯수, Prefetcher의 갯수 등을 어떻게 설정하는지 확인할 수 있습니다.

*Filtered configuration files: host.cfg, host_prefetch.cfg

*Unfiltered configuration file: pim.cfg

Figure 2 [Important nobs that can be changed in the configuration files]

3. 실행 파일을 실행합니다.

* Trace 생성 명령어

./build/opt/zsim configuration_file.cfg

*Trace format

THREAD_ID PROCESSOR_ID INSTR_NUM TYPE ADDRESS SIZE

Figure 3 [The fileds in the trace file]

**간단하게 요약하자면, 먼저 원하는 Application을 Compile한 후에 ZSim으로 어플리케이션에 대한 Configuration file을 생성해줍니다. Configuration file은 앞서 설명했듯, host CPU core를 위한 두 개의 파일과 PIM core를 위한 한 개의 파일로 구성되어 있습니다. 그 다음 './build/opt/zsim configuration_file' 명령어를 입력하여 Trace file들을 생성해 줍니다. 생성된 Trace file들은 Ramulator를 실행 할 때 사용되게 됩니다.

ii) Running Ramulator

1) To run the host simulation:

./ramulator --config Configs/host.cfg --disable-perf-scheduling true --mode=cpu --stats host.stats --trace sample_traces/host/rodiniaBFS.out --core-org=outOrder --number-cores=4 --trace-format=zsim --split-trace=true

2) To run the PIM simulation:

./ramulator --config Configs/pim.cfg --disable-perf-scheduling true --mode=cpu --stats pim.stats --trace sample_traces/pim/pim-rodiniaBFS.out --core-org=outOrder --number-cores=4 --trace-format=zsim --split-trace=true

* mode 설정을 위해서 Configuration file 내부에 pim_mode 값을 지정해 줍니다.

pim_mode = 0 (for host)

pim_mode = 1 (for pim)

Figure 4 [The important nobs for running ramulator]

IV. Reference

[1] https://github.com/CMU-SAFARI/ramulator-pim

GitHub - CMU-SAFARI/ramulator-pim: A fast and flexible simulation infrastructure for exploring general-purpose processing-in-mem

A fast and flexible simulation infrastructure for exploring general-purpose processing-in-memory (PIM) architectures. Ramulator-PIM combines a widely-used simulator for out-of-order and in-order pr...

github.com

[2] Yoongu Kim, Weikun Yang, and Onur Mutlu, "Ramulator: A Fast and Extensible DRAM Simulator". IEEE Computer Architecture Letters (CAL), March 2015.

[3] Gagandeep Singh, Juan Gomez-Luna, Giovanni Mariani, Geraldo Francisco de Oliveira, Stefano Corda, Sander Stujik, Onur Mutlu, and Henk Corporaal, "NAPEL: Near-Memory Computing Application Performance Prediction via Ensemble Learning". Proceedings of the 56th Design Automation Conference (DAC), Las Vegas, NV, USA, June 2019.

[IEEE.2020] Planaria: Dynamic architecture fission for spatial multi-tenant acceleration of deep neural networks.

H/W engineer_ beginner — Tue, 8 Feb 2022 23:06:34 +0900

Ref.

Ghodrati, Soroush, et al. "Planaria: Dynamic architecture fission for spatial multi-tenant acceleration of deep neural networks." 2020 53rd Annual IEEE/ACM International Symposium on Microarchitecture (MICRO). IEEE, 2020.

본 논문은 진행중인 Auto Driving 관련 프로젝트의
Insight를 위해 읽었기 때문에
필요한 내용만 간추려 요약하였습니다.

Abstract

Deep Neural Networks(DNNs)이 실생활의 많은 Application에서 사용됨에 따라 빠른 속도로 산업과 시장에 적용되었습니다. 기술이 발전함에 따라, *Inference-as-a-Service(INFaaS)를 제공하는 Cloud 인프라와 AI accelerator는 업계에 혁신적인 변화를 가져 왔습니다. 그 결과 대부분의 INFaaS 기반 Accelerators들은 (ex. Google's TPU, NVIDIA T4, Microsift Brainwave 등) 많은 Real-life application들의 중추적인 역할을 담당하게 되었습니다.

Multi-tenancy 환경에 대한 수요가 Datacenter의 물리적 확장을 이끌었지만, 다양한 Application의 방대한 data들을 효율적으로 처리하기 위하여 단순히 가속기의 수를 늘리는 것은 경제적이지 않습니다. 단순히 더 빠른 속도와 효율성을 위한 경쟁으로 인해 Multi-tenancy 환경에 적합한 DNN Accelerator를 설계하는 것에 대해서는 아직 많은 연구가 필요한 상황입니다. 따라서 이번 연구에서 'Dynamic architecture fission(break)' 으로 불리는 새로운 기술을 적용하였습니다. 위의 기술을 적용하여 여러 DNN models들을 새로운 Demension들로 동적으로 분할하고 재연결했으며, Multitenancy 에 적합한 새로운 DNN runtime engine인 'Planaria' 를 제안합니다.

위의 새로운 Microarchitecture를 통하여 동일한 Hardware 공간에서 여러 DNN Inference serveices들을 공간 효율적으로 배치할 수 있으며, Multi-tenant DNN을 가속할 수 있습니다. 이를 위하여 먼저, DNN 가속을 위하여 분할 가능한 omni-directional systolic array를 찾습니다. 그 다음, Systolic array 기반의 DNN accelerator가 정상적으로 분할 될 수 있도록 Planaria만의 독특한 구성을 사용합니다. (On-chip memory과 Computer resource 간의 상호 연결 구성)

Architecture 수준에서의 분할과 연결 유연성은 Task 기반 Scheduling이 더 자유롭게 이루어질 수 있도록 합니다. 이를 통해 Scheduler는 가속기를 Server load, DNN topology, task priority 등을 고려할 수 있게 됩니다. 이를 통하여 가속기에서 Multi DNN 실행 시 Throughput, Utilization, QOS, Fairness 등을 향상 시킬 수 있습니다.

*INFaaS

: Inference as a service provides a core set of common functionality required to develop various context-aware apps

: INFaaS 안에 사용 가능한 Solution이 존재한다면 개발자는 Training data를 직접 넣지 않아도 되며, 구체적인 model을 구축하지 않아도 됩니다. 자세한 내용은 아래 그림을 참조해 주세요.

[Figure 1] Process of Situation Inference in Tradition way and INFaaS.Ref[1]

Introduction

인공지능 산업이 발전함에 따라 더 빠르고 효율적인 DNN execution의 필요성이 증가했고 이는 DNN Accelerator의 등장으로 이어졌습니다. (Google의 TPU, NVIDIA의 T4, Microsoft의 Brainwave 등) 하지만 빠른 속도와 효율성 증대를 위한 ‘arms race’라 불리는 market에서의 경쟁에 치중한 나머지, Multi-tenancy 환경에 최적화 된 Microarchitecture를 설계하는 것에 대한 연구와 노력이 부족한 상황입니다. 조사에 따르면 Datacenter 에서의 Hardware utilization 은 50%정도에 그치며, 이는 심각한 자원의 낭비를 초래합니다. 때문에 본 논문에서는 ‘Planaria’라는 이름의 새로운 microarchitecture mechanism을 제안합니다. 이어 설명하겠지만 Planaria는 분할된 Logical DNN Accelerators를 통한 Multi-tenant 가속 기법으로 유연한 Task scheduling을 가능하게 하여 Throughput, hardware utilization, QOS, Fairness 등에 최적화된 새로운 메커니즘을 제안합니다. 이를 통해 하나의 가속기 안에서 Multi DNNs Execution을 가능하게 하며 동시에 여러 DNN Task들을 처리할 수 있습니다.

* 참고로 arms race란 군비 경쟁을 일컫는 말로 위의 상황에서는 단순히 더 많은 돈을 들여 더 크고 다양한 가속기를 맹목적으로 도입하는 상황을 설명합니다.

[Figure 2] Multi-tenant Acceleration : Need for shift focus

1999년도, Powerful한 Accelerator인 GPU가 최초로 세상에 나왔습니다. 그 후, 2001년도에는 GPU를 그래픽 처리 뿐만이 아니라, General Purpose computing을 위해 사용한다는 GPGPU라는 개념이 등장했습니다. 2001년도에서 2009년도로 넘어가며 Hardware resource utilization에 대한 문제가 처음으로 제기되었으며 이를 개선하기 위해 Multi tenancy 개념을 도입하였습니다. 하여, 2009년 최초의 Multi tenancy GPU인 Fermi architecture가 등장했습니다. 2014년에는 Spatial multi-tenancy에 관한 150여개의 연구가 발표되었으며 2014년에는 인공지능 열풍에 힘입어 ML Accelerator 설계에 관현 800여개의 연구들이 발표되었습니다. 하지만 이 기간동안의 연구는 실제 가속기에서의 Resource utilization 문제와 Cost effective adoption이 가장 중요한 조건으로 고려되지 않았습니다. 2020년이 되어서야 이 부분을 고려해 설계해야한다는 주장이 제시되며 위의 문제를 고려한 2가지 정도의 논문이 발표되었습니다. 하지만 2020년에 제시된 Temporal Multi tenant 에 관한 연구는 하드웨어 Utilization 문제를 해결하기 위한 근본적인 해결책이 아닙니다. 왜냐하면 한 시점에서 오직 하나의 Task만이 Dispatch되어 처리될 수 있기 때문입니다.

하여 본 연구에서 위 문제에 대한 근본적인 해결책을 제시하기 위하여, Dynamic architecture fission을 통한 새로운 Spatial Multi-tenancy DNN 가속기인 'Planaria'를 제안합니다.

Insight

i) Concept & Overview

[Figure 3] Planaria main concept 

: Planaria의 기본적인 concept은 하나의 DNN accelerator를 여러 개의 Logical DNN accelerator들로 분할하여 가속한다는 것 입니다. Ready queue에 대기하고 있는 여러 DNN model들은 다시 여러 DNN Task로 분할되어 각 Logical DNN Accelerator에 할당되게 됩니다. 할당된 여러 Task들은 가속기에서 동시에 실행될 수 있으며, 이를 통해 한 번에 하나의 DNN model만 실행될 때 발생하는 Lower utilization 문제를 해결하고 Multi DNN execution이 가능한 환경을 조성합니다.

[Figure 4] Dynamic fission into logical accelerators

: 위의 두 그림은 Multi DNN Acceleration을 동시에 실행할 때의 상황을 묘사하고 있습니다. Planaria의 Key idea는 바로 동일한 하드웨어에서 다양한 DNN 추론들을 분해하고 적합한 장소에 배치하는 Dynamic fissioning(분해) 기법입니다. 이는 하나의 가속기 내에서 일어나는 작업입니다. 일반적으로 DNN 가속기는 on-chip memory bank들과 Computing resource인 MAC unit들로 구성되어 있습니다. 위의 그림에서 M과 C가 위의 요소들을 나타내는 그림입니다.

Figure 3의 (a)는 우선순위가 높은 DNN task를 처리하거나 QOS 제약 조건이 큰 경우에 처리되는 상황을 설명합니다. 그림의 중간과 오른쪽에 배치되어 있는 Figure 4의 (b)와 (c)의 경우는 multiple DNN task들이 분할되어 재결합한 구조를 설명합니다. 이는 그림에서 Logical accelerator라는 용어로 표현하고 있으며 이를 통해 DNN들이 높은 Throughput 을 유지하며 QOS 제약을 충족시킬 수 있습니다. (b)는 두 개의 Logical accelerator들을 사용해 2개의 DNN model들을 동시 가속한 상황을, (c)는 세 개의 Logical accelerator들을 사용해 3개의 DNN model들을 동시에 가속한 상황을 묘사하고 있습니다.

ii) Architecture Design

[Figure 5] Main components for Planaria

: 앞에서 설명한 Dynamic fission을 통한 Multi DNN 가속을 위해서는 2 가지의 Main components들이 필요합니다. 먼저 Dynamic fission을 수행하기 위한 microarchitecture를 설계해야 하며, 두 번째로 Dispatched된 task들을 Hardware resource에 할당하기 위한 Spatial task scheduler가 필요합니다.

[Figure 6] Objectives and constraints for desining microarchitecture

: Dynamic fission을 위한 microarchitecture 설계의 목표 4가지와 한계 2가지 입니다.

[Figure 7] Monolithic systolic array

: 위의 그림은 일반적인 Systolic array를 설명하는 그림입니다. Systolic array는 여러 PE들이 하나의 집합으로 연결되어 있으며 Input과 Output을 위한 Buffer가 존재합니다. 이 구조에서는 Data가 오직 한 방향으로만 흐를 수 있다는 제한 조건이 있습니다. 예를 들어 Input activation part에서는 데이터들이 왼쪽에서 오른쪽으로만 이동하고, Partial sum을 위해서는 오직 위에서 아래로만 데이터가 이동하게 됩니다.

[Figure 8] Need for flexible and cost-effective fission of compute resources

: 하여 Planaria architecture에서는 데이터의 흐름이 단방향이 아니라 모든 방향으로 이어질 수 있도록 기존의 Systolic array를 분할하고 재결합 하는 방법이 적용되었습니다. 위의 그림들은 다양한 상황에 적합하게 최적화 될 수 있습니다. 예를 들어 (c)의 경우, 4개의 sub systolic array들로 분해된 것을 확인할 수 있는데 자주 Partial sum을 재활용 하는 경우 가장 효율적으로 이용될 수 있습니다. (a)의 경우는 중간 결과의 합 혹은 입력 값이 자주 재사용 되는 경우 효율적으로 이용될 수 있는 시나리오가 됩니다.

[Figure 9] Omni directional PE

: 이를 통해 전방향으로 데이터가 이동하는 PE를 설계할 수 있었으며 Sub array들의 분할과 재결합을 통해 새로운 Data flow를 만들어낼 수 있었습니다. 하지만 기존의 Systolic array에서 PE를 전방향으로 바꾸어 새로운 데이터의 흐름을 만들어낸다고 하더라도 Input buffer들과 Output buffer들은 각 Sub array들과 상호 연결되어 있어야 합니다.

[Figure 10] Main problems for connection to sub arrays

: 하지만 기존의 구조를 그대로 사용한다면 좌측에 보이는 것처럼 Input buffer와 Output buffer가 모두 연결되는 Sub array가 딱 한개만 존재할 수 있게 되며, 이를 해결하기 위해 오른쪽 그림처럼 각 Sub array들을 Buffer들과 wire로 모두 연결한다면, 이 상황에서도 매우 큰 자원 낭비가 발생합니다.

[Figure 11] Overview of Fission pod

: 따라서 위에서 제기한 문제를 해결하기 위하여 아예 새로운 아키텍쳐의 도입이 필요합니다. Fission pod이라 불리는 이 구조는 4x4 Read/Write buffer들로 이루어져있으며 각 Sub array들은 Fission pod의 자원을 공유하게 됩니다. 4개의 Sub array들은 Fission pod이라 불리는 on-chip memory pod을 공유하며 각 Sub array들은 각각의 PE와 SIMD units을 갖고 있어 분할된 logical accelerator로써의 역할을 수행하게 됩니다. Fission pod은 각 Subarray들의 전방향 Systolic 실행을 가능하게 하며 ifmap과 psum을 공유합니다.

[Figure 12] Overview of fission pod - MUX/DEMUX

: 전 방향 Systolic array를 위해 Sub array 내부의 각 PE는 위와 같은 Switching network가 필요하게 됩니다.

[Figure 13] Overall architecture of Planaria

: 위의 그림은 Planaria micro architecture의 구조를 설명하는 그림입니다.

[Figure 14] Example senario for multi DNN execution

: 위의 Planaria architecture에서는 16개의 Sub array들이 존재할 수 있으며 이를 통해 65가지의 시나리오가 구현될 수 있습니다. 그림에서 볼 수 있는 빨간 박스들은 시나리오 중 하나를 설명하는 그림입니다. 그림과 같이 5개의 DNN Model들이 각 Logical accelerator에 할당되어 동시에 실행될 수 있게 됩니다.

[Figure 15] Spatial task scheduling requirements

: 앞서 설명한 Micro architecture에 여러 DNN Task들을 공간적으로 할당하기 위해서는 새로운 Scheduler의 도입이 필요합니다. 이 Scheduler는 세 가지의 요구 조건들을 충족해야합니다.

[Figure 16] Spatial task scheduler

: 먼저 프로그램을 Compile할 때 실행할 Target DNN들을 어떤 시나리오로 가속기에 할당할지 결정해야 합니다. 이를 통해 컴파일러는 실행 파일과 Configuration table들을 생성합니다. 그 다음 실제 실행 시 Spatial Task Scheduler는 위 두 파일을 통해 처리할 Tast들을 실시간으로 Planaria architecture에 할당하게 됩니다.

[Figure 17]

: 다음 그림은 처리할 Task들이 도착하거나 끝난 경우에 어떤 순서로 처리되는지를 설명하는 그림입니다.

iii) Evaluation

[Figure 18] Evaluation configurations

: Planaria Architecture와 새로운 Scheduler를 설계하고 검증하기 위해 다음과 같은 환경을 조성하였습니다.

[Figure 19]

: 실험에는 세 가지의 INFaaS workload scenario들이 실행되었습니다. Multitenant 환경을 구현하기 위하여 Poisson distribution을 통해 각 요청에 대해 random한 arrival time을 부여하여 datacenter에서 발생할 수 있는 환경과 유사한 환경을 구축하였습니다. 또한 각 DNN benchmark들은 Planaria에서 compile 되었습니다.

Reference

[1] Kim, Moon Kwon, and Soo Dong Kim. "Inference-as-a-service: A situation inference service for context-aware computing." 2014 International Conference on Smart Computing. IEEE, 2014.

[IEEE.2021] AI Multi-Tenancy on Edge: Concurrent Deep Learning Model Executions and Dynamic Model Placements on Edge Devices

H/W engineer_ beginner — Tue, 8 Feb 2022 16:52:08 +0900

Ref.

Subedi, P., Hao, J., Kim, I. K., & Ramaswamy, L. (2021, September). AI Multi-Tenancy on Edge: Concurrent Deep Learning Model Executions and Dynamic Model Placements on Edge Devices. In 2021 IEEE 14th International Conference on Cloud Computing (CLOUD) (pp. 31-42). IEEE.

본 논문은 진행중인 Auto Driving 관련 프로젝트의
Insight를 위해 읽었기 때문에
필요한 내용만 간추려 요약하였습니다.

Abstract

현재 실제로 사용되는 많은 Application들은 Edge computing paradigm을 따르고 있습니다. Edge computing은 Low latency와 Better privacy protection이라는 큰 장점이 존재합니다. 즉 Application들을 빠르게 처리할 수 있고 보안성 면에서 많은 이점이 있습니다. 최근 Artificial Intelligence(AI) 기술과 Deep Learning(DL) 기술의 발전에 힘입어 Edge devices 에서의 추론 능력은 매우 중요해졌습니다. 하여, 많은 연구들은 Edge device에서 Single DL task를 어떻게 하면 효율적으로 처리할 수 있을지에 대해 논의하였습니다. 하지만 최근 다양한 정보를 유기적으로 처리해야할 필요성이 증가함에 따라 Edge device에서 여러 DL task들을 처리할 수 있는 Multi-tenancy 환경에 대해 논의할 필요가 생겼습니다.

때문에 위의 논문에서 진행한 연구에서는 두 가지의 Techniques를 제시합니다. (For AI multi-tenancy executions on edge devices)

i) Concurrent model executions (CME)

ii) Dynamic model placements (DMP)

Introduction

현재 많은 AI Application들은 Autonomous Vehicles(AV), Disaster response, Drone-based surveillance 등의 Edge device 기반 Domain에서 널리 사용됩니다. 위의 Edge device 기반 Domain은 두 가지의 큰 특징이 있습니다. 하나는 엄격한 응답 시간 요구 조건을 충족시켜야 한다는 것이고 또 하나는 연산 환경에 많은 Resource 제약이 있다는 점입니다. 위의 두 요건들이 충족되어야 하기 때문에 AI 연산이 Cloud 환경에서 수행되는 것에는 큰 제약 조건들이 존재합니다. Low bandwidth 연결을 통해 많은 양의 데이터들을 Edge device에서 Cloud 환경으로 전송하는 것은 매우 큰 응답시간을 초래하며, Network 연결 불안정 같은 외부 요인에 의해 연산 자체가 방해받을 수 있습니다. 따라서 위와 같은 제한 조건을 충족해야 하는 Domain에서는 Edge device에서 바로 AI 연산을 수행하는 방향으로 연구가 진행되어 왔습니다. 위와 같은 새로운 Paradigm에 힘입어 Raspberry pi, NVIDIA Jetson nano, Google Edge TPU 등 DL tasks들이 edge device 환경에서 바로 연산될 수 있는 새로운 Platform들이 등장하였습니다. 위의 platform들이 등장한 초기의 많은 연구들은 Single DL task를 최적화 시켜 많은 Throughput을 낼 수 있는 방법을 제시하였습니다. 하지만 System이 복잡해지며 많은 데이터를 유기적으로 처리할 필요성이 증가함에 따라, Edge device에서의 Multi-tenancy 연산의 중요성이 대두되었습니다.

Edge device에서의 효율적인 AI Multi-tenancy execution을 위하여 기본적으로 두 가지 정도의 기술을 사용할 수 있습니다. 첫 번째는 Concurrent model executions(CMEs) 이며 두 번째는 Dynamic model placements(DMPs) 입니다. CME를 통해 다양한 DL models들을 GPU 혹은 Edge TPU중 하나에서 병렬적으로 실행시킬 수 있으며 이를 통해Inference throughput을 향상시킬 수 있습니다. DMP는 여러 DL models들을 다양한 Edge device에서 동시에 실행할 수 있게 하여 Hardware utilization과 Throughput 모두를 향상시키는 방법입니다. DMP는 특히 AI 가속기 환경에서 큰 성능 향상을 이끌어냅니다.

Edge device에서의 Multi-tenancy는 위와 같은 큰 이점을 갖지만 이들의 한계를 명확하게 인지하는 것 또한 시스템 성능 개선에 중요한 요소입니다. 때문의 이번 연구를 통해 몇 가지의 질문에 대한 답을 찾아보려 합니다.

i) AI multi-tenancy의 성능적 이점은? (At the device level)

ii) edge devices and accelerators의 한계

- limit of model concurrency

- limit of resource contention

- limit of resource bottleneck

위의 질문들에 대한 답을 찾기 위해선 Edge device, Edge TPU accelerators에서의 Behavior과 Performance를 측정하기 위한 방법에 대해 고찰해야 합니다. 먼저 위의 환경에서 발생 할 수 있는 Critical한 Resource factors를 규정합니다. 그 다음 앞서 설명한 두 가지의 기술이 성능에 어떤 영향을 미치는지 측정합니다.

* 초기, Edge device에서의 요구 조건을 충족하는 것의 기술적 한계 때문에 많은 AI system들은 Cloud 기반 환경에서 발전해 왔습니다. (ex. Social networks, E-commerce, Finance와 같은 domain들)

Insight

i) System specification

- Edge devices & Edge TPU Accelerators

* Jetson TX2

* Jetson Nano

* Odroid-N2

* Raspberry pi 4

* Coral Dev Board

* Coral USB Accelerator

- DL Frameworks

* Pytorch, MXNet, TensorFlow, TensorFlow Lite

: Pytorch, MXNet, TensorFlow는 CPU와 GPU based DL inference

연산에서 사용되며 TensorFlow Lite의 경우 Edge TPU 연산을 위해 사용됨

- DL Applications and dataset

: Image classification / dataset from ImageNet ILSVRC-2012

- Important factors for DL Inferences

[Figure 1] Correlation equation

: 위의 Correlation 공식을 통해 DL 성능과 큰 상관관계를 갖는 요소를 파악했습니다.

[Figure 2] Correlation factors for inference throughput

: 위의 도표는 CPU, GPU, Edge TPU 기반 Inference 시 각 설정 값 들이 성능과

어느 정도의 상관관계를 갖는지 설명하는 그림입니다.

CPU-based inference(Rpi4, ODN2)의 경우, Batch size와 Memory usage가

성능과 가장 큰 상관 관계를 보였으며 GPU-based inference(J.nano, J,TX2)의

경우, Memory usage와 Power consumption이 성능과 가장 큰 상관 관계를

보였습니다. 마지막으로 Edge TPU의 경우, Host edge device와

USB Accelerator 사이의 USB Bandwidth가 성능에 가장 중요한 Factors임을

확인 할 수 있었습니다.

* 참고로 GPU based case의 경우 DL tasks들은 GPU에서 수행되며 CPU에서는

DL 연산을 돕는 co-running applicatio들이 실행됩니다.

ii) DNN models

[Figure 3] DNN models

: 원래 실행할 모델의 복잡성과 Neural networks의 Layer의 수가 증가함에 따라 DL models의 연산 정확도와 size가 증가하지만 위의 실험에서는 Edge device 환경에서의 Resource constrained 를 적용하기 위하여 많은 DL models 중 9 개의 pre trained DL models를 채택하였습니다. (채택한 아홉 개의 모델들은 Edge device에서의 Image classification 추론을 시뮬레이션 하기에 적합한 모델 사이즈를 갖고 있음)

iii) Experimental cofiguration

[Figure 4] Measurement steps

: 본 연구에서는 위와 같은 step을 갖는 새로운 Bench marker를 제시하였고 이를 통해 Edge device에서의 Single tenant case와 Multi tenant case의 성능을 비교하였습니다.

새로운 Micro architecture를 제시하여 이를 multi tenancy 환경에서 실험한 것이 아니라 Benchmarker의 설정 값을 조정하여 실험 환경을 조성하였습니다. 하지만 Multi tenant 환경에서 적용 가능한 CME, DMP 기술의 이론적 설명과 검증 과정에서 큰 Insight를 얻을 수 있다 판단하여 자료 조사에 추가하였습니다.

[PIM] week 01

H/W engineer_ beginner — Fri, 4 Feb 2022 17:59:49 +0900

본 포스팅은 스위스 취리히 연방 공과 대학의 SAFARI Research Group이 주관하는 '2021 Exploring the Processing-in-Memory Paradigm for Future Computing Systems' course를 수강하고 정리한 내용입니다.

The SAFARI Research Group is led by Professor Onur Mutlu. We are part of the Department of Information Technology and Electrical Engineering (D-ITET) at ETH Zurich.

Introduction

최근 컴퓨팅 시스템에서의 프로세서와 메모리간 데이터 이동은 성능을 결정하는 중요한 지표가 되었습니다. 모바일 장치부터 대규모 서버 환경에 이르기까지 데이터 이동 Cost는 Performance와 Power consumption을 결정하는 주요한 요소가 됩니다. 실행할 데이터를 저장하는 Main memory와 연산을 담당하는 Core 사이의 데이터 이동은 전체 Application system energy의 62% 가량을 차지한다고 알려져 있습니다. 따라서 데이터 이동에서 발생하는 오버헤드는 시스템의 전체 성능을 향상시키기 위해 해결해야할 주요한 요소 중 하나입니다. 이와 같은 문제는 근본적으로 프로세서와 메모리를 분리하여 사용함으로써 발생하는 데이터 이동 병목 현상에서 기인합니다.

기계 학습, 복잡한 그래프 처리, 데이터 베이스 분석 및 실시간 영상 데이터 분석 등, 현대의 많은 Workload들은 Data 이동시 발생하는 병목 현상으로 성능 향상에 큰 어려움을 겪고 있습니다. 복잡한 Workload들은 불규칙한 메모리 엑세스, 낮은 데이터 재사용율, 낮은 캐시 라인 사용률, Main memory의 용량을 크게 초과하는 Application 실행 등으로 인해 큰 데이터 병목 현상을 겪고 있습니다. 이러한 문제점을 완화하기 위해서는 프로세서와 메모리를 분리해 처리하는 기존의 폰 노이만 구조에서 벗어나, 새로운 컴퓨팅 구조를 도입해야 합니다. 모든 데이터 처리가 프로세서에서만 이루어지는 것이 아니라 데이터가 실제 위치하는 공간과 가까운 장소에서 연산을 수행할 수 있는 데이터 중심 설계로의 패러다임 전환이 필요합니다. 위와 같은 새로운 컴퓨팅 패러다임을 Processin-In-Memory, PIM이라고 합니다.

하여 2021 Fall SAFARI Seminal를 통해

i) Data movement bottleneck 개념을 이해하고

ii) Bottleneck에 더 취약한 Key workload characteristics에 대해 이해하며

iii) 위의 문제를 해결하기 위한 전통적 방법과 새로운 연구 주제에 대해 공부합니다.

1) Processing in / near memory 개념은 새로운 것이 아니다!

오래 전부터 Memory 가까이에 연산 장치를 배치하여 Data 간의 이동시 발생하는 오버헤드를 줄이기 위한 노력이 있었습니다. IEEE학회에 1969년 발표된 'Cellular Logic-in-Memory Arrays'와 1970년 발표된 'A Logic-in-Memory Computer'라는 제목의 논문에서는 현대의 PIM과 유사한 이론을 제시하였으나, 당시에 크게 주목받지 못했습니다. 그 이유는 당시는 아직 반도체 공정 기술과 메모리 기술 등이 지금처럼 발전하지 않았기 때문에 데이터 이동에서 발생하는 병목현상보다 프로세서 자체 혹은 메모리 자체에서 발생하는 오버헤드를 줄이는 것이 성능을 더 크게 향상시킬 수 있는 요인이었기 때문으로 추측할 수 있습니다.

-작성 진행중-

Reference

processing_in_memory [SAFARI Project & Seminars Courses (Fall 2021)] (ethz.ch)

[AI H/W] What is AI?

H/W engineer_ beginner — Sun, 30 Jan 2022 23:41:21 +0900

[Ref.] https://www.youtube.com/playlist?list=PLm4EZB3VG6zlu1BkFw2DHN58x8QlLHEBu

본 포스팅을 상단 Reference에 첨부한 강의를 수강하고
정리, 수정, 보완한 자료입니다.

[A] Introduction

[Figure 1] : Introduction

AI > ML > Brain-Inspried > Spiking, Neural networks

- AI(Artificial Intelligene) in 1956 : 지능형 기계를 만드는 과학과 공학
- ML(Machine Learning) in 1959 : 컴퓨터가 명시적으로 프로그래밍 하지 않고도 학습 할 수 있는 연구 분야 : 'Training 개념 등장'
- Brain-Inspired : 뇌의 동작 방식에 대한 이해에서 기본 기능을 취하는 알고리즘
- Spiking : Spike와 같은 Purse 신호에 따라 신호를 주고 받는다.
- Neural networks (Digital 개념) : Weighted sum 개념으로 입력이 일정 임계값을 넘으면 출력이 생성되는 비선형함수 (선형대수) 연산

[B] How does the brain works?

[Figure 2] Neuron .Ref[1]

뇌의 구조에서 영감을 받은 Spiking architecture와 Neural networks 개념을 이해하기 전에 뇌 안에서 신호들이 어떻게 전달되는지 신경 세포의 구조에 대해 공부할 필요성이 있습니다.

- 뇌는 약 860억개의 뉴런으로 이루어져있으며 각 뉴런은 시냅스로 연결되어 있다.
- dendrites : 입력 신호를 받는 곳
- axon : 출력 신호를 내보내는 통로
- synapse : 화학적 반응에 의해서 들어오는 입력의 전달 양이 결정된다 : weight(가중치) 라고 한다.

[B-1] Spiking architecture

[Figure 3] Spike response model .Ref[2]

- Spike architecture : 신경망에서 일어나는 메커니즘으로 기억과 학습에 중요한 역할
(1) 뉴런이 자극을 받으면 spike라는 전기 신호 생성
(2) spike가 시냅스에 도착하면 신경전달물질이 분비되어 시냅스가 활성화
(3) 신호를 받는 뉴런의 수용체가 신경전달 물질을 인식해 spike를 발생시킴
(4) 시냅스를 통해 신호가 전달됨
(5) 이 때, 뉴런들의 연결을 강화하거나 약화시켜 정보를 장기기억으로 전환하거나 빨리 잊도록 할 수 있음
(6) 이는 spike가 발생하는 상대적인 간격으로 조절 가능
(7) presynaptic input이 postsynaptic output 이전에 일어나면 이전 시냅스가 다음 시냅스 신호에 영향을 준 것으로 판단되어 시냅스의 연결이 강화됨
(8) presynaptic input이 postsynaptic output 이후에 일어나면 뉴런 사이의 상관성이 적다 판단하여 연결이 억제됨
(9) 이 때 spike의 간격이 좁을수록 입력 spike로 인해 다음 spike가 빨리 나타나게 되고 연결의 변화가 크게 나타남

[B-2] Neural networks

[Figure 4] Weighted sum .Ref[3]

*Neural Networks
- 뇌의 구조에서 영감을 받은 이론이며 Neuron에 Weighted sum의 개념을 도입하여 구조화함
- 입력값(x0)는 synapse의 weight(w0)와 곱해져 cell body로 도달함
- 각 시냅스는 같은 방법으로 cell body로 신호 전달
- 위의 과정들은 '곱하고 더하는' 연산
- 후에 cell body에서 합쳐진 값들이 특정 임계 값(Threshold value)을 넘어야 신호를 전달하는 activation function 존재함

[Fiigure 5] Simple neural network .Ref[4]

- Hidden layer는 1개 이상이 될 수 있음

- 동그라미 하나는 Neuron (node), 동그라미를 연결하는 화살표는 Synaps (edge)라고 부름

- DNN 이란 Neural networks 구조에서 layer가 deep하게 연결되어 있는 구조를 일컫음

[C] Deep Neural Networks (DNN)

[Figure 5] Deep Neural Networks .Ref[5]

*Deep Neural Networks

- 최근 일반적으로 DNN에 쓰이는 Layer는 5개에서 1000여개 임

- Complexity가 높아 더 복잡한 연산을 처리할 수 있음

- Low level features에서 High level features를 추출해내는 과정에서 깊고 복잡한 연산을 수행함

- 점점 더 복잡한 연산에서 더 높은 정확도를 요구하는 최근에는 더 많은 컴퓨팅 파워가 필요함 : 더 많은 GPU가 사용되어야 함

- 2015년에 ImageNet이라는 사진 판별 대회에서 ResNet이라는 DNN 알고리즘을 적용한 모델이 사람의 Error rate (5%)보다 낮은 값을 성취함

*Deep Learning 의 성공 요소

(1) Big Data Availity : 많은 양의 데이터가 필요 , 최근에는 양질의 데이터의 중요성 증가

(2) GPU Acceleratrion : 반도체 장치 및 아키텍쳐의 발전으로 DNN 처리를 위한 컴퓨팅 파워가 증가함

(3) New Techniqes : DNN을 쉽게 처리하기 위한 여러 Framework들이 개발됨 (Tensorflow, caffe, pytorch 등)

*현재 DNN은 High Computing Power를 요구 : AI Hardware를 공부해야 하는 이유

[1] https://www.explainthatstuff.com/introduction-to-neural-networks.html

[2] https://commons.wikimedia.org/wiki/File:Spike_Response_Model_(schematic).jpg

[3] https://www.youtube.com/watch?v=FE6snk8Coec&list=PLm4EZB3VG6zlu1BkFw2DHN58x8QlLHEBu&index=4

[4] https://commons.wikimedia.org/wiki/File:Neural_network_example.svg

[5] http://dlwiki.finfra.com/algorithm:dnn

[CUDA] Multi-Process Service

H/W engineer_ beginner — Wed, 26 Jan 2022 18:32:35 +0900

[1] Introduction :

Multi Process Service (MPS) 개념은 NVIDIA의 Maxwell architecture에서 처음 고안된 방법으로 GPU의 resource utilization 저하 문제를 해결하여 성능 향상(Throughput 증가)을 이끌어내기 위하여 제시되었습니다. GPU가 단순히 그래픽 처리만을 하는 것이 아니라 General purpose computing을 하기 위해 발전해오며 HPC(High Purpose Computing) 응용 프로그램들을 처리하거나 Multi-tenant 환경에서 복잡한 여러 DNN 연산을 수행해야 하는 경우가 생겼습니다. 하여 NVIDIA에서는 한정된 자원을 효과적으로 사용하기 위한 많은 방법을 제시하였으며 ( Stream, Hyper-Q 등 ) 다수의 Process가 하나의 GPU에서 실행될 수 있도록 돕는 런타임 서비스 : MPS 를 도입하였습니다.

MPS는 여러 CUDA process 들이 단일 GPU *Context를 공유할 수 있도록 하는 기능입니다. MPS에 의해 각 프로세스들은 GPU 분할 사용이 가능하도록 사용 공간을 나누어 할당 받게 됩니다. 이를 통해 GPU의 utilization을 최대화 하는 동시에 각 process 들의 kernel 과 memcopy 연산이 동시에 실행될 수 있도록 합니다. MPS 개념 이전에 등장했던 Stream과 Hyper-Q의 개념을 간단히 정리해보자면, Stream이란 CUDA 실행을 위한 비동기 객체로, 각 Stream 내부의 작업들은 순차적으로 실행되며, 각 Stream 들은 디바이스의 자원이 중첩되지 않는 선에서 동시 실행되게 됩니다. Stream을 통해 여러 작업을 서로 다른 Stream으로 분류해 실행하더라도 실제 GPU의 Scheduling queue (work queue)는 하나였기 때문에 False dependency problem이 발생할 수 있습니다. 하여 이를 해결하기 위해 Hyper-Q라는 Multi work queue 개념이 등장하였습니다. Hyper-Q란 다수의 Hardware work queue를 생성하는 Grid management unit을 도입하여 각 Stream이 같은 pipeline으로 유지되게 함으로써 dependency 문제가 없는 Scheduling을 가능하게 했습니다.

[Figure 1] Hyper-Q : Multiple Hardware Work Queues

Hyper-Q를 사용함으로써 device 의 resource utilization은 상당히 개선될 수 있었지만 Hyper-Q를 사용하기 위해서는 task들이 반드시 같은 context 상에 속해야 한다는 제한이 있었습니다. 따라서 다른 어플리케이션 실행이 하나의 device에서 이뤄질 수 있도록 MPS(Multi Process Service) 라는 새로운 개념을 도입하게 되었습니다.

MPS는 서로 다른 커널을 서버에 제출함으로써 서로 다른 Context의 커널들이 단일 Context 내에서 수행되는 것 처럼 보이도록 했습니다.

[Figure 2] How MPS work?

위의 그림은 MPS의 전체적인 Work load를 설명하는 그림입니다. Control demon process에 의해 MPS Server가 시작되고, Server에 의해 만들어진 실행 환경에 MPS client 가 각 kernel의 context를 순차적으로 제출합니다. 이 실행환경은 Shared context로 실행될 수 있기 때문에 MPS server는 client의 요청을 대표하여 디바이스에 작업들을 동시에 실행시킵니다. 이를 통해 여러 개의 CUDA process들이 하나의 GPU context를 공유하는 것이 가능하게 됩니다. MPS 를 통한 Shared context는 원래 여러 개로 나누어져 있던 디바이스의 데이터 저장 공간 혹은 Scheduling unit 또한 서로 공유 될 수 있다는 것을 의미합니다. 이를 통해 MPS 이전에 GPU가 Process 들을 시분할 방식으로 실행할 때 발생하는 overhead를 획기적으로 줄일 수 있으며 결과적으로 MPS를 통한 resource utilization이 향상되고 실행 시간을 감소시킬 수 있습니다.

하지만 여러 MPS의 client가 동시에 실행되는 것과는 달리 MPS의 sever는 오직 한 user만이 실행시킬 수 있습니다. 다시 말해 같은 UID로 서버에 제출된 client만이 GPU에서 동시 실행 될 수 있습니다. 때문에 MPS의 clinet들 중 하나가 비정상적으로 종료된다면, MPS server와 다른 client들이 어떤 상태였는지 알 수 없게 됩니다.

Maxwell architecture에서 처음 제안되었던 MPS는 Volta architecuture가 도입되며 크게 변화했습니다. Volta 이전의 MPS에서는 각 client가 device 주소 공간을 MPS server를 통해 공유하였지만, Volta architecture에서는 Server 대신, 직접 device 에 작업을 제출할 수 있도록 지원하고, 각 cleint를 위한 독립적인 주소 공간을 제공합니다. 또 QoS (Quality of Service)를 위해 실행 자원량을 유기적으로 제한 할 수 있습니다.

[Figure 3] Volta architecture 이전의 MPS (좌), Volta architecture에 적용된 MPS (우)

Maxwell architecture에서 처음 도입된 MPS 는 Architecutre의 발전과 함께 발전해왔습니다. 하여 본 포스팅을 통해 MPS의 발전 과정에 대해 짚어보고, 가장 다이나믹한 변화를 이끈 Volta architectre의 MPS 구조에 대해 집중적으로 논의해보려 합니다.

*Context : 실행되고 있는 Process 및 Thread의 상태 정보

[2] When to use MPS :

MPS 기술은 크게 세 가지의 장점을 사용자에게 제공합니다.

i) GPU utilization

ii) Reduced on-GPU cintext storage

iii) Reduced GPU context switching

i) GPU utilization

GPU에서 하나의 process 만을 수행된다면 모든 연산을 위한 memory-bandwidth 용량 및 사용 가능한 GPU의 resource들을 최대로 사용할 수 없을 것입니다. 때문에 MPS를 사용하여 여러 process들의 kernel과 memcopy 연산들이 GPU 상에서 overlap되게 하여 GPU의 높은 utilization을 확보하고 더 빠른 running time으로 process 들을 처리 하는 것이 가능해집니다.

ii) Reduced on-GPU cintext storage

MPS를 사용하지 않는다면, 여러 CUDA process들은 구별된 각각의 storage와 scheduling resource들을 할당 받을 것 입니다. 하지만 MPS를 사용하게 된다면 MPS server는 모든 clinets가 하나의 storage와 scheduling resource들을 공유할 수 있습니다. 특히 Volta architecture부터는 MPS clinet들의 독립된 메모리 공간을 사용하도록 지원하여 GPU이 resource 사용을 더 현저하게 줄일 수 있었습니다.

iii) Reduced GPU context switching

MPS를 사용하지 않는다면, Multi processing 수행 시 각 process 들을 위한 scheduling resource들이 모두 지워졌다가 다시 사용되기를 반복해야 합니다. 이는 GPU 실행 성능에 큰 영향을 미치게 됩니다. 하지만 MPS를 사용한다면 MPS server는 모든 clinet들에게 하나의 scheduling resource 세트를 제공하여 여러 clinet가 swiping 될 때 발생하는 overhead를 획기적으로 줄였습니다.

하지만 MPS의 client-sever connection에는 정해진 한계가 존재합니다. pre-Volta architecture에서는 각 device 당 16 client CUDA context 까지 지원하며 Volta architecture의 MPS sever의 경우는 48 clinet CUDA context 까지 지원합니다. 만약 connection limit을 넘은 요청을 실행하면 MPS server에 'failed connection' log가 생성될 것입니다.

[3] MPS Architecture :

CUDA란 General purpose를 위한 병렬 컴퓨팅 플랫폼입니다. NVIDIA에서는 많은 복잡한 문제들을 CPU보다 GPU에서 훨씬 효율적으로 처리하기위하여 병렬 컴퓨팅 엔진을 위한 Programming model을 제시합니다.

CUDA program은 CUDA context를 생성하는 것으로 시작됩니다. context는 CUDA program이 해당 GPU의 메모리를 관리하고 작업을 시작하는데 필요한 모든 하드웨어 리소스를 캡슐화합니다.

GPU에서 작업이 시작되는 것은 일반적으로 할당된 GPU의 메모리 공간에 필요한 데이터를 복사하는 것과 그 데이터 위에서 CUDA kernel이 실행되는 것, 그리고 나서 GPU 메모리에서 시스템 메모리 공간으로 그 결과를 다시 복사하는 것을 포함합니다.

GPU에서 CUDA를 통해 실행되는 모든 작업들은 CUDA stream(병렬 실행을 위한 비동기 객체) 이라고 불리는 공간으로 이동하게 됩니다. Stream이란 여러 kernel의 Command들을 순서대로 처리하기 위한 S/W 추상화 개념입니다. 만일 작업이 서로 다른 두 Stream으로 실행된다면 이 둘은 병렬적으로 동시에 처리가 가능합니다.

CUDA stream은 GPU의 driver에 의해 하나 혹은 그 이상의 'work queue'라는 이름으로 불리 수 있습니다. Work queue란 GPU의 특정 engine에 의해 실행될 Stream의 command의 순서를 나타내는 H/W resource 입니다. 하지만 하나의 work queue만을 사용해 생기는 비효율이 확인되었고 Hyper-Q라는 Multi work queue 개념이 등장하게 되었습니다. Hyper-Q란 다수의 Hardware work queue를 생성하는 Grid management unit을 도입하여 각 Stream이 같은 pipeline으로 유지되게 함으로써 dependency 문제가 없는 Scheduling을 가능하게 했습니다.

GPU는 time sliced scheduler를 갖고있습니다. 일반적으로 서로 다른 CUDA context가 존재하는 work queue에서 실행된 작업은 동시에 실행 될 수 없습니다. 따라서 이 scheduler를 사용하여 work queue에서 다른 CUDA context들이 실행 될 수 있도록 scheduling 합니다.

[Figure 4] MPS가 적용되지 않은 MPI scheduling 방법

위의 diagram은 MPS를 사용하지 않고 Multiple OS process가 포함된 MPI application을 수행할 때 CUDA kernel들이 scheduling 되는 방법을 설명하고 있습니다. 각 MPI process 들에 속한 CUDA kernel들은 동시에 예약 될 수 있지만 각 MPI process 들은 time-slice scheduler에 의해 순서대로 실행됩니다. 따라서 MPS가 적용되지 않은 환경에서는 동시에 여러 kernel을 실행하는 것이 불가능 했습니다.

[Figure 5] Volta architecture 이전의 MPS를 적용한 Client-server architecture

Volta architecture 이전의 MPS 를 적용한 Client-sever architecture의 다이어그램은 다음과 같습니다. MPS server를 이용하여 여러개의 context들을 공유하는 하나의 CUDA context는 하드웨어 resource를 관리하게 됩니다. MPS client에 포함된 CUDA context는 MPS server를 통해 작업을 퍼널링 하게 되며 이를 통해 Client의 CUDA context들은 time sliced scheduling과 관련된 H/W 제한을 우회하고 동시에 다른 Kernel들을 실행 시킬 수 있습니다.

Volta architectre 에서부터는 새로운 Hardware capabilities를 제안합니다. 이를 통해 MPS server가 관리하던 Hardware 공간을 획기적으로 줄일 수 있었습니다. 한 client CUDA context는 대부분의 하드웨어 resource를 사용할 수 있게 되며, 작업을 하드웨어에 직접 전달해 실행시킬 수 있습니다. Volta MPS sever는 Hardware resource에서 실제로 실행되는 데에 사용되는 공간을 제외한 최소한의 공간만을 사용하게 되며, 개별 client가 제출한 작업을 동시에 예약하고 필요한 나머지 Hardware resource들을 조정합니다.

[Figure 6] System-wide provisionging with multiple users (Provisioning Sequence)

[4] Background

(1) Process vs Thread

Process란 실행을 위하여 메모리에 Load된 Program을 의미하며, OS에 의해 자원을 할당받는 작업의 단위 입니다. Thread는 이것보다 더 작은 단위의 작업으로, 할당 받은 자원을 이용하는 실행의 단위를 의미합니다. 따라서 하나의 Process 내에는 1개 이상의 Thread가 발생할 수 있습니다. 즉, Application 하나의 실행이 Process가 되며 Process 내에서 분기 실행 되는 단위가 Thread 입니다.

[Figure 7] Process

Process는 위의 그림과 같이 각각의 독립된 메모리 영역을 할당 받습니다. (Code, Data, Stack, Heap 등) 각 Process는 별도의 주소 공간을 할당 받으며 일반적으로 다른 Process의 변수나 자료 구조에 접근할 수 없습니다. 따라서 다른 Process 의 자원에 접근하기 위해서는 Process 간 통신 방법인 IPC (Inter-Process Comunication)을 사용해야 합니다.

Thread란 Process 내에서 실행되는 여러 흐름의 단위로, Process 가 할당받은 자원을 사용하는 실행의 단위입니다.

[Figure 8] Thread

위의 그림처럼 각 Thread는 Process 내에서 Code, Data, Heap 영역을 공유하게 됩니다. (Stack 영역을 Thread 별로 따로 할당 받음) Thread는 Process 와 다르게 한 Process 내의 자원이나 주소 공간을 공유하며 실행되게 됩니다. 각 Thread는 유일하게 따로 할당받은 Stack 영역과 레지스터를 갖고 있지만 나머지 공간들이 서로 공유되어 Process의 더 유연한 실행을 가능하게 합니다.

(2) Multi process vs Multi thread

[Figure 9] Multi process vs Multi thread

Multi-processing란 하나의 응용 프로그램을 수행하기 위하여 프로그램을 여러 개의 Process로 나누어 실행하는 방법으로, 각 프로세스가 하나의 작업(Task)를 수행하게 됩니다. Multi process 환경에서는 최초의 단일 프로세스를 부모 Process라 하며 부모 Process에서 파생된 다양한 자식 Process가 존재하게 됩니다. 때문에 여러 자식 Process 중 하나가 문제가 발생하더라도 다른 Task에 영향을 끼치지 않는다는 장점이 존재합니다. Multi process를 H/W적인 관점에서 바라보게 되면 Context switching 개념을 이해해야 합니다. Context switching이란 Processor(CPU)에서 여러 Process들을 번갈아 가며 실행하는 행위를 의미합니다. 즉 지금 실행되는 Process의 상태 (Context)를 잠시 저장하고 대기하던 다른 Process를 실행하게 되며 이 과정에서 이전에 보관하였던 이전 Process의 상태 (Context)가 다시 복구됩니다. Multi process를 실행하게 된다면 Context switching 과정에서 overhead가 발생할 우려가 존재합니다. 각 Process들은 각각의 독립 메모리 공간을 할당받기 때문에 Context switching 수행 시 Cache에 있는 모든 Data를 삭제하고 새롭게 불러와야 합니다. 이는 각 Process 사이에 자원과 변수들을 공유하지 않는다는 특징에 기인합니다.

Multi-threading이란 하나의 응용 프로그램을 수행하기 위하여 여러 Thread로 나누어 실행하는 방법으로, 각 Thread는 하나의 작업을 맡아 처리하게 됩니다. 즉 하나의 작업을 처리하기 위하여 여러 프로그램을 켜서 처리하는 것이 아니라 한 프로그램 내에서 그 작업들을 세분화해 처리한다는 개념입니다. Window와 Linux등 많은 OS에서 Multi thread를 지원하며 Web-server 환경은 대표적인 Multi thread 환경입니다. Multi thread의 경우 프로세스를 할당해 자원을 공유하는 System call이 줄어들고 Thread 간의 data 공간을 공유하기 때문에 자원 활용에 있어 많은 이점이 있습니다. 하지만 자원을 공유하는 특성 때문에 하나의 Thread에 문제가 생기면 전체 Process에 영향을 끼칠 수 있으며 Thread간의 자원 공유시 전역 변수를 사용하기 때문에 함께 사용시 충돌이 발생할 수 있다는 단점이 있습니다. 하지만 일반적으로 Process 간 통신 (IPC)의 처리 비용보다 Thread 간의 통신에 대한 처리 비용이 훨씬 적게 든다는 장점이 존재합니다. (Multi thread 환경에서는 Context switchig시 Stack 영역만 처리하면 됨)

(3) GPU Context switching

Context switching의 개념은 한정적인 자원인 Processor에서 여러 Process 및 Thread들을 효과적으로 처리하기 위한 방법으로 현재 진행하고 있는 Task(Process or Thread)의 상태를 저장하고 다음에 진행할 Task의 상태를 읽어들여 실행하는 방법입니다. Processor는 Context Switching 처리를 통해 현재 Task가 수행되는 동안 다음 Task를 대기시키는 것이 아니라 사용자에게 여러 Task가 동시에 처리되도록 보여지게 합니다. 하지만 Context switching에는 cost가 존재합니다. (일반적으로 Process의 Context switching이 Thread의 Context switching보다 큰 cost가 듭니다.)

GPU의 Context switching은 CPU에서 실행되는 것과 상황이 조금 다릅니다. CPU에서의 Context switching은 상당히 큰 cost가 드는 반면에, GPU에서는 비교적 자유로운 환경에서 실행되게 됩니다. 기본적으로 Processor 내부에서 Context switching이 발생할 때 Register 값을 새롭게 저장하거나 변경해야 합니다. GPU에서는 CPU보다 훨씬 많은 Register가 존재하기 때문에 Context switching에 대한 Overhead가 거의 발생하지 않습니다. 또한 GPU에서는 Warp 단위로 Context switching이 발생하는데 최대한 많은 Warp를 할당하여 Task 수행에 드는 Latency를 hiding하게 됩니다.

(4) MPI : Message Passing Interface

[Figure 10] Message Passing Interface

Message Passing Interface란 병렬 처리에 사용되는 표준 라이브러리를 의미합니다. Message passing이란 지역적으로 구별된 메모리 공간을 갖는 process 들이 data들을 공유하기 위하여 메세지(공유할 data 들)를 송수신 하는 방법을 의미하며 Parallelism을 위한 여러 부분을 programmer가 직접 수행하게 되며 복잡하지만 유연한 적용이 가능하다는 장점이 있습니다. 즉 위의 그림처럼 하나의 프로세스를 n개의 프로세스로 쪼개어 병렬 처리한 후에 그 출력 값을 다시 모아 최종적인 결과 값으로 도출해내는 일련의 과정이 Message passing 기술로 수행되며, Message passing을 위한 라이브러리 중 하나가 바로 MPI 입니다.

MPI : 메세지 패싱 병렬 프로그래밍을 위해 표준화된 데이터 통신 라이브러리

[5] Reference :

(1) https://on-demand.gputechconf.com/gtc/2015/presentation/S5584-Priyanka-Sah.pdf

(2) Multi-Process Service :: GPU Deployment and Management Documentation (nvidia.com)

(3) https://levelup.gitconnected.com/diy-multithreading-vs-multiprocessing-in-python-fb93698ca7f3

(4) https://hayunjong83.tistory.com/17

(5) http://ap2.khu.ac.kr/download/mpi_lec.pdf

[Linux] time 명령어

H/W engineer_ beginner — Thu, 20 Jan 2022 17:35:03 +0900

리눅스에서는 특정 프로그램의 실행시간 측정을 위하여 time 명령어를 자주 사용합니다.

명령어 입력 시 'real', 'user', 'sys'로 통칭되는 3가지의 정보가 출력되는데 각 time이 의미하는 바는 서로 상이합니다.

따라서 프로그램의 time 측정 시 각 시간이 의미하는 바를 명확하게 이해하고 사용해야 합니다.

Real :

Actual elapsed time(실제 경과 시간)으로 wall clock time으로 불립니다. 이는 순수하게 측정된 전체 실행시간을 의미하므로 환경과 상황에 따른 변수가 작용할 수 있어 이론적 예측이 어렵습니다. 이는 call 을 실행한 순간부터 마치는 순간 까지를 의미하며 여러 프로세스들이 실행되는 시간과 프로세스들이 블락되는 시간을 포함합니다. ( I/O을 위해 대기하는 시간 등 )

User :

프로세스 내부의 user-mode code가 실행되는데에 걸린 CPU time입니다. 이는 Kernel 밖에서 실행되는 시간이며 실제 프로세스가 실행되는데 걸린 CPU time을 의미합니다. ( 연산이 진행되는 동안 CPU가 소비한 누적 시간의 합 ) user time에는 프로세스가 블락되어 대기하는 시간은 포함되지 않습니다. 따라서 테스크가 실제로 연산되는 시간 외의 대기 시간은 User 시간에 포함되지 않습니다. 정리해보자면 user time은 명령어를 실제로 실행하여 연산한 시간의 총 합입니다.

Sys :

프로세스 내부의 커널에서 실행된 CPU time의 결과입니다. 이 시간은 user-mode에서 실행되는 라이브러리 코드와는 달리 Kernel 내부에서 system call에 사용된 CPU time만을 의미합니다. 예를 들어 메모리 할당과 같은 시스템 관련 작업 동안 CPU가 소비한 누적 시간 입니다. sys time의 경우 단일 프로세스라면 real time과 동일하겠지만, 멀티 프로세스로 작업이 처리되는 경우 프로세스들이 데이터 엑세스를 위해 경쟁하기 때문에 단일 프로세스의 경우보다 더 늘어나게 됩니다. 정리하자면, Sys time은 실행 중인 명령어를 지원하기 위해 시스템 차원에서 이루어지는 메모리 할당 및 파일 I/O등의 작업을 처리하기 위해 Kernel 단에서 실행되는 시간의 총 합입니다.

* User + Sys time : 프로세스가 사용한 실제 CPU time 입니다. 여러 프로세서가 병렬로 동작할 수 있기 때문에 때때로 real time보다 user + sys time이 더 클 수도 있습니다. 즉 프로세스 안에 여러 thread가 존재하고 이 프로세스가 둘 이상의 연산 프로세서에서 처리된다면 real time보다 더 큰 값으로 측정될 수 있습니다.

* A brief primer on Kernel vs. User mode

On Unix, or any protected-memory operating system, 'Kernel' or 'Supervisor' mode refers to a privileged mode that the CPU can operate in. Certain privileged actions that could affect security or stability can only be done when the CPU is operating in this mode; these actions are not available to application code. An example of such an action might be manipulation of the MMU to gain access to the address space of another process. Normally, user-mode code cannot do this (with good reason), although it can request shared memory from the kernel, which could be read or written by more than one process. In this case, the shared memory is explicitly requested from the kernel through a secure mechanism and both processes have to explicitly attach to it in order to use it.

The privileged mode is usually referred to as 'kernel' mode because the kernel is executed by the CPU running in this mode. In order to switch to kernel mode you have to issue a specific instruction (often called a trap) that switches the CPU to running in kernel mode and runs code from a specific location held in a jump table. For security reasons, you cannot switch to kernel mode and execute arbitrary code - the traps are managed through a table of addresses that cannot be written to unless the CPU is running in supervisor mode. You trap with an explicit trap number and the address is looked up in the jump table; the kernel has a finite number of controlled entry points.

The 'system' calls in the C library (particularly those described in Section 2 of the man pages) have a user-mode component, which is what you actually call from your C program. Behind the scenes, they may issue one or more system calls to the kernel to do specific services such as I/O, but they still also have code running in user-mode. It is also quite possible to directly issue a trap to kernel mode from any user space code if desired, although you may need to write a snippet of assembly language to set up the registers correctly for the call.

* More about 'sys'

There are things that your code cannot do from user mode - things like allocating memory or accessing hardware (HDD, network, etc.). These are under the supervision of the kernel, and it alone can do them. Some operations like malloc orfread/fwrite will invoke these kernel functions and that then will count as 'sys' time. Unfortunately it's not as simple as "every call to malloc will be counted in 'sys' time". The call to malloc will do some processing of its own (still counted in 'user' time) and then somewhere along the way it may call the function in kernel (counted in 'sys' time). After returning from the kernel call, there will be some more time in 'user' and then malloc will return to your code. As for when the switch happens, and how much of it is spent in kernel mode... you cannot say. It depends on the implementation of the library. Also, other seemingly innocent functions might also use malloc and the like in the background, which will again have some time in 'sys' then.

Reference : https://stackoverflow.com/questions/556405/what-do-real-user-and-sys-mean-in-the-output-of-time1

[IEEE.2014] LEoNIDS: A low-latency and energy-efficient network-level intrusion detection system.

H/W engineer_ beginner — Thu, 20 Jan 2022 12:41:45 +0900

Reference :

Tsikoudis, Nikos, Antonis Papadogiannakis, and Evangelos P. Markatos. "LEoNIDS: A low-latency and energy-efficient network-level intrusion detection system." IEEE Transactions on Emerging Topics in Computing 4.1 (2014): 142-155.

본 논문은 현재 진행중인 Auto Driving 프로젝트 관련
유관 연구 조사로 읽었기 때문에
필요한 부분만 발췌하여 요약하였습니다.

Abstract :

데이터 센터와 모바일 디바이스들이 발전해온 지난 10년 동안 low-power system을 구축하는 것에 매우 많은 노력이 기울여젔습니다. 하지만 그것에 비해 security system을 구축하는 것에는 아직 많은 노력이 필요합니다. 하여 이번 연구에서는, 현대 컴퓨터 네트워크의 secure operation을 향상시킬 수 있으며 적은 power consumption 을 사용할 수 있는 새로운 *network-level instruction detection system (NIDS)를 제안합니다. 과거 전통적인 low-power consumption system은 (frequency scaling 같은 방법) packet processing 과 queuing times의 불균형을 야기시켰습니다. 따라서 이번 paper를 통해 이런 방법이 detection latency와 timely reaction을 향상시킴을 보이고 이를 해결할 새로운 아키텍쳐인 low-latency and energy efficient NIDS (LEoNIDS)를 제안합니다.

* NIDS 관련 paper : Heady, Richard, et al. The architecture of a network level intrusion detection system. No. LA-SUB-93219. Los Alamos National Lab., NM (United States); New Mexico Univ., Albuquerque, NM (United States). Dept. of Computer Science, 1990.

Introduction :

NIDS는 일반적으로 멀티 코어 시스템 혹은 서버 클러스터에서 널리 사용됩니다. 하지만 NIDS 같은 security system의 에너지 효율에 관련해서는 많은 연구 개발이 이루어지지 않았습니다. 하여 이번 연구를 통해 현재 가장 흔히 사용되는 cyber security 기법인 NIDS의 에너지 효율을 향상시킬 수 있는 새로운 아키텍쳐를 제안합니다. : LEoNIDS

우선, low traffic 환경에서 적은 에너지를 쓰기 위하여 Dynamic Voltage and Frequecy scaling (DVFS) 방법과 sleep states (C-states)를 제안합니다.

본 연구 내용 중, AD 프로젝트에 도움이 되는 개념 및 실험 결과 :

1) 연산을 위해 더 많은 Core를 사용하고 더 느린 frequency를 사용하게 되면 Energy consumption 측면에서는 이득이지만 더 높은 detection latency를 야기시킵니다.

[Figure 01] Trade off of number of cores and lower frequency

2) Detection latency에서 queuing delay는 매우 critical한 요소입니다.

[Figure 02] The main cause of increased detection time is queuing delay

Packet latency는 세 가지 파트로 나뉠 수 있습니다. (i) interrupt handling time : OS kernel에서 packet을 핸들링하는 시간, (ii) queuing delay : packet이 queue에서 전송되기 위해 대기하는 시간, (iii) processing time : user level에서 NIDS가 실행되는 시간, 이 세가지 요소 중 interrupt handling time은 다른 요소에 비해 매우 작기 때문에 무시할 수 있는 요소이며 실제 연산 처리 시간인 processing time을 제외하고 연산 성능에 가장 큰 영향을 미치는 요소는 바로 Queuing delay임을 실험을 통해 확인할 수 있었습니다.

3) Queuing delay를 구하는 공식

c : Tne number of active cores

λc : The rate of packets arrived at each core ( = λ / c )

μc : The rate of queued packets served from each core ( = μ / cmax )

pc : The core's utilization ( = λc / μc )

[Figure 03] The average queuing delay

4) 본 연구에서 제시하는 LEoNIDS 아키텍쳐

[Figure 04] LEoNIDS Architecture

[IEEE.2018] Processing-in-memory for energy-efficient neural network training: A heterogeneous approach.

H/W engineer_ beginner — Fri, 14 Jan 2022 15:39:53 +0900

출처 : Liu, Jiawen, et al. "Processing-in-memory for energy-efficient neural network training: A heterogeneous approach." 2018 51st Annual IEEE/ACM International Symposium on Microarchitecture (MICRO). IEEE, 2018.

Abstract :

Nerural Networks(NNs)는 Image classification, speech recognition, object detection, computer vision 등 다양한 분야의 application에 활용되고 있습니다. 하지만 현재 Neural Networks 를 Training하는 데에는 시간적, 에너지적 비효율성이 존재합니다. (특히 DNNs 분야) 왜냐하면 많은 데이터들이 메모리와 프로세서 사이를 이동하기 때문입니다. (예전에는 Processor의 성능 자체, Memory의 성능 자체가 프로그램 실행 속도에 큰 영향을 미쳤지만, 현재 엄청난 성장을 이룬 Processor와 Memory Architecture로 그 자체의 성능이 아니라 그 둘 사이를 이동하는 Data의 병목현상이 프로그램 실행 성능에 Critical한 요소가 되었습니다.) 또한 DNNs의 Training에는 아주 복잡한 Fine-grained operation이 처리되어야 하기 때문에 현재의 방법으로 이를 빠르게 병렬 처리하는 데에 어려움이 존재합니다. 하여, 이 논문을 통해 Software/Hardware co-design인 Heterogeneous processing-in-memory(PIM)를 제시합니다.

PIM의 H/W 모델에는 기본적으로 Heterogeneous PIM Architecture 구현을 위한 Logic layer가 존재합니다. 이 Logic layer는 3D die-stacked momory 구조로 설계되었으며 그 위에 수백개의 Fix-function을 위한 arithmetic units과 프로그래밍이 가능한 ARM based cores가 존재합니다. 3D die-stacked memory 구조란 평평한 Silicon 위에 연산을 위한 Logic layer을 쌓고 그 위에 DRAM을 순차적으로 올려 쌓는 구조를 의미합니다. (앞서 설명했듯이 Logic layer에는 Fixed-function cores와 Programmable cores가 존재합니다.) 또한 같은 Silicon 위에 CPU가 존재하기 때문에 Heterogeneous PIM Architecture라고 이름을 명명하였습니다.

[Figure 1] PIM Architecture

PIM의 S/W design은 프로그래밍 모델과 함께 다양한 Neural Networks를 training하기 위한 runtime system을 제공합니다. 이는 CPU와 Heterogeneous PIM compute resources를 사용하는 것을 용이하게 합니다. 또한 OpenCL 프로그래밍의 확장을 통해 간단하게 프로그래밍 할 수 있는 환경을 제공하며 높은 프로그램 이식성을 갖추고 있습니다. 또한 Heterogeneous H/W를 관리하고 최적화 하는 데에 도움이 되며 이를 통해 시스템 에너지 효율성 증대 및 H/W Utilization 증가를 도모할 수 있습니다.

*OpenCL : Heterogeneous(이기종) 플랫폼에서 실행되는 프로그램을 작성하기 위한 개방형 범용 병렬 컴퓨팅 Framework, 이를 통해 task-based 병렬 컴퓨팅 혹은 data-based 병렬 컴퓨팅을 할 수 있음

Introduction :

오늘날, Neural networks 연산에는 매우 많은 parameters와 data sets가 이용됩니다. 예를 들어 VGG와 AlexNet의 경우 각각 138M과 61M의 parameters를 image classification을 위해 사용합니다. 이와 같은 복잡한 model을 Training하는 경우에 엄청난 Computing resource와 Memory resource를 필요로 합니다. (많은 에너지와 시간 또한 필요합니다.) 많은 Resource를 사용하는 경우에 가장 성능에 가장 Critical한 요소 중 하나는 바로 NNs를 Training하는 경우 발생하는 Bottleneck 현상입니다. (System 안에서 많은 양의 Data 가 이동하며 발생하는 병목 현상) 현재의 NN model은 더욱 커지고 복잡해지고 있습니다. 때문에 성능을 개선하기 위한 아래 설명한 연구처럼 다양한 방면의 노력들이 있었습니다.

[1] Low-precision data를 사용해 연산 성능을 개선하는 방법

[2] Prune NN models를 사용해 연산 성능을 개선하는 방법

하지만 위의 연구들은 NN model의 간략화에 대한 영향을 정량화 하는 데에 어려움이 존재하며, 근본적으로 NN model을 Training 할 때 발생하는 Data의 이동을 다루지 않습니다. (데이터의 이동에 의해 발생하는 병목현상을 해결하기 위한 근본적인 해결책이라 볼 수 없음.) 따라서 이번 연구를 통해 이를 해결하기 위한 조금 더 근본적인 해결책인 Heterogeneous PIM Architecture를 제시하려합니다. 최근의 PIM 관련 연구는 다양한 app 실행시 발생하는 데이터 이동 병목 현상을 해결하기 위한 유망한 솔루션을 제시하고 있습니다. 하지만 PIM Architecture 관련 연구의 경우 Programming 방법과 System runtime과 관련하여 몇 가지 어려움이 존재하고 있습니다.

첫 번째로 NNs Training을 가속하기 위해 PIM을 programming 하는 것은 매우 어렵습니다. 오늘날의 Tensorflow같은 Machine Learning framework들은 다양한 하드웨어에서 NN 작업을 구현하기에 용이합니다. 하지만 PIM software interface의 경우 PIM Architecture에 대한 심도 있는 하드웨어적 이해를 필요로 합니다. 때문에 PIM의 programming method를 개선하여 프로그래머들의 생산성을 높이는 과정이 필요합니다.

두번째로 PIM의 Fixed-function logics과 Programmable cores를 통합적으로 디자인하는 것은 매우 복잡합니다. 이 두 Core는 매우 다른 Programming model로 구현되었습니다. Fixed-function logics의 경우 Assembly-level intrinsics를 통해 ISA-level로 디자인되었습니다. 하지만 Programming cores의 경우 통상적인 프로그래밍 패러다임을 따릅니다. (Threading packages 혹은 GPGPU programming interfaces 같은) 최근의 제시된 대부분의 PIM Architecture의 경우 Homogeneous PIM 구조를 하고 있습니다. (Fixed-function 혹은 Programmable cores 중 하나의 종류만 존재) 그렇기에 더 간단한 Software interface 설계가 가능하지만 Heterogeneous PIM Architecture 설계 시 이 두 가지 요소를 모두 고려하여 설계를 진행해야 합니다. 본 연구에서 더 복잡한 Heterogeneous PIM Architecture를 제시하는 이유는 에너지 효율을 향상시키고, Parallelism과 Programmability 사이에 Balance를 제시하기 위함입니다.

마지막으로 PIM에서 NN Training처럼 큰 연산 규모는 Hardware utilization의 불균형을 야기시킬 수 있습니다. 이상적으로는 Hardware utilization을 높이기 위하여 NN Training 연산의 dependency를 어기면 안되지만 (Host processor와 PIM 전반에 걸친 operation-level parallelism 방법을 통해) Heterogeneous system에서는 명확한 Hardware scheduling이 어렵기 때문에 이를 이상적으로 실현하기 어렵습니다.

PIM Architecture 연구에서 발생하는 위와 같은 어려움들을 개선하기 위해 본 paper에서는 몇가지 방법을 제시합니다. 먼저 PIM-based NN Training accelaration system을 효율적으로 운용하기 위해 Tensorflow처럼 널리 사용되는 Machie learning framework의 도입을 제시합니다. 위의 목표를 성취하기 위해서는 software/hardware co-design Heterogeneous PIM 설계가 필요합니다. 이번 연구의 설계는 세 가지의 요소를 포함합니다. 먼저 Fixed funcion logic과 Programmable cores를 둘 다 사용하는 Heterogeneous PIM Architecture의 도입입니다. 두 번째로 OpenCL의 기능을 확장하여 PIM programming의 어려움을 개선하려 합니다. 마지막으로 PIM의 H/W Utilization을 최대화 할 수 있는 runtime system을 제시합니다.

-------------------------------------------------------------------------------------------------------------------

작성중 - 미완성

[NVIDIA] GPU Architecture

H/W engineer_ beginner — Thu, 13 Jan 2022 17:22:13 +0900

NVIDIA GPU Architectures

[Figure 0] Jenson Huang NVIDIA CEO

NVIDIA GPU의 Architecture는 세대를 거듭하며 빠른 속도로 발전해 왔습니다. 과거 그래픽 처리를 주 목적으로 했던 GPU에서 벗어나, 현재 (2022년) 전 세계 인공지능 반도체 시장을 선도하고 있는 NVIDIA GPU의 발자취를 따라가보며, GPU의 Architecture가 어떻게 발전되어 왔는지 정리해보려 합니다. (본 포스팅은 Instruction이 수행되는 Streaming Multiprocessor를 중심으로 정리하였습니다.) GPU는 인공지능 분야가 발전함에 따라 많은 양의 데이터를 병렬로 빠르게 처리하기 위하여 도입되었습니다. Throughput 기반의 Architecture라 불리는 GPU는 현재 높은 처리량이라는 강력한 장점을 내세워 인공지능 생태계에 빠르게 적응했고 현재 가장 강력한 인공지능 연산 장치(학습 및 추론)중 하나로 사용되고 있습니다.

초기 Tesla Architecture부터 Volta Architecture까지 GPU Architecture는 세대를 거듭하며 발전해왔습니다. 공정 기술의 발전과 메모리 기술의 발달에 힘입어 초기 3D 그래픽 가속을 위한 기술들은 다양한 형태의 새로운 기술의 발전으로 이어졌습니다. 세대를 거듭하며 그래픽 처리 뿐 만 아니라 GPGPU(General Purpose GPU)를 위한 기술이 추가되었고, HPC(High Performance Computing) 응용을 고려한 기술들이 추가었습니다. 최종적으로는 강력한 연산 처리 장치인 Tensor Core를 적용한 GPU가 등장하여 DL(Deep Learning)/AI Computing 분야의 대표주자로 우뚝 설 수 있었습니다. 현재 인공지능 처리를 위한 데이터 센터의 대부분은 NVIDIA의 GPU가 섭렵하고 있습니다. 향후 Google의 TPU처럼 필요한 상황에 최적화된 커스텀 칩과 경쟁을 벌이며 최후의 승자를 가리게 되겠지만, 현재 인공지능 기술 발전을 견인하고 있는 NVIDIA의 GPU Architecture 분석은 분명 유의미 한 공부라 판단됩니다.

* 본 포스팅은 Reference [1] [2]의 창작물을 참고하여 만든 2차 창작물입니다.

* 최근 NVIDIA에서 제시한 'Turing Architecture'와 'Ampere Architecture'는 별도의 포스팅으로 다루겠습니다.

[1] Tesla(G80) / 2006

Tesla Architecture에서 최초로 Vertex shader와 Pixel shader의 기능이 결합된 Unified shader가 등장했습니다. 이를 통해 프로그램 유연성이 증가할 수 있었습니다. 추가적으로 새로운 개념인 *GPGPU가 등장했고 GPU 상에서 그래픽 연산 외에 일반 연산을 가속할 수 있는 CUDA API가 등장하였습니다. 이 Architecture에서 Unified shader 혹은 GPGPU Program을 수행하는 기본 단위는 *Streaming Multiprocessor(SM)으로 각 SM 마다 독립적인 Instruction Scheduler를 사용하여 최대 768개의 Thread를 병렬로 동시에 실행 할 수 있습니다. 각 SM은 8개의 CUDA Cores로 구성되어 있으며 추가적으로 2개의 SFU, Shared memory가 부착되어 있습니다. 아래의 그림을 통해서 SM 하나가 Multi-thread 실행이 가능한 unified shader임을 확인할 수 있습니다. (하나의 TPC에 2개의 SM이 존재하다고 해서 두 SM이 동일 연산을 수행하는 것은 아닙니다.)

[Figure 1] Tesla Architecture의 SM 구조 : Reference [3]

* SM의 구성요소

하나의 Streaming Multiprocessor는 8개의 SP(Streaming processor)와 2개의 SFU(Special-Function units)로 이루어져있습니다. 추가적으로 하나의 MT issue(Multithreaded Instruction fetch and issue unit) 공간과 instruction cache, Read만 가능한 Constant cache, 16KByte 크기의 Read/Write shared memory가 존재합니다. 그림에 보이는 SM 하단의 Texture unit은 SM과 외부 메모리 간의 Load/Store 명령어 수행 시에 사용됩니다.

- SP : 기본적인 Logic / Arithmatic 연산 수행, MAD(Multiply-Add) 명령어를 지원하여 한 clk당 최대 2회 연산 가능

- SFU : 초월함수, Pixel arrtibute 보간 등의 연산 수행, 4개의 부동 소숫점 곱셈기 포함

- Shared memory : Graphics input buffers 또는 병렬 컴퓨팅을 위한 shared data 존재, 이를 통해 실행되는 Thread 간의 Data 교환을 가능하게 함

*GPGPU : General Purpose GPU

*SM : Streamin Multiprocessor : Multi thread를 실행할 수 있는 Unified shader

[2] Fermi / 2010 : 'GPGPU를 위한 발판'

Fermi Architecture에서는 이전 Architecture에 비해 General Purpose Computing(GPGPU)을 위한 요소들이 대폭 적용되었습니다. 즉 GPGPU를 용이하게 하기 위한 요소들이 추가된 것인데 기존에 각 SM마다 제공되던 Shared memory의 용량을 추가했으며(16KB => 64KB), 이 중 일부를 L1 Cache로 설정해 사용할 수 있게되었습니다. (Cache를 사용한다면 Memory 계층구조의 특성을 통해 용량 제한에서 자유로워집니다.) 또한 SM 외부의 Texture unit에 의해 수행되었던 Load/Store 명령이 SM 내의 LD/ST Units으로 대체되며 SM 자체적으로 이 명령어들을 수행할 수 있게 되었습니다.

[Figure 2] Fermi Architecture의 SM 구조 / Reference [4]

위의 그림은 Fermi Architecture의 SM 구조를 보여주는 그림으로 원래 SP(Streaming Processor)라 표기되었던 부분이 CUDA Core라는 이름으로 변경되고 그 수도 8개에서 32개로 증가했습니다. 한 SM 내에서 32개의 CUDA Core는 각 16개씩 2개의 그룹으로 나눠져있으며 LD/ST 1그룹과 SFU 1그룹을 포함해 총 4개의 그룹으로 나누어져 있습니다. 또한 Tesl Architecture에서는 하나의 SP 내부에 분산되어 존재하던 Register file들을 모아 밖으로 모아 CUDA Core 외부에 공간을 할당하여 배치하였으며 이를 통해 Register를 보다 효율적으로 사용할 수 있습니다.

Core(이전 Architecture에서는 SP 개념)의 수가 증가했다는 것은 GPU 내부적으로 더 많은 명령어들을 빠르게 공급해야할 필요가 생겼다는 것을 의미합니다. 따라서 *Warp Scheduler가 2개로 증가했으며 각 Warp Scheduler는 독립적으로 Dispatch Unit을 통해 명령어를 보낼 수 있습니다. 이론적으로 Dispatch Unit이 2개 이기 때문에 한 SM 내에서 2개의 명령어가 독립적으로 실행될 수 있지만 특별한 경우에 한해서는 하나의 SM 내에서 하나의 명령어만 처리하게 됩니다. (특별한 경우라 함은 1. 두 Warp Scheduler에서 사용하려는 실행 유닛 그룹이 겹치는 경우 2. 64Bit 부동소수점 연산을 사용하는 경우)

Warp의 단위는 32개의 Thread인데 CUDA Core가 32개 단위로 묶인 것이 아니라 16개로 묶인 이유는 CUDA Cores와 LD&ST, SFU가 Warp Scheduler의 2배 클럭으로 동작하기 때문입니다. 때문에 한 Warp의 32개의 Thread 집합은 두 배 빠르게 동작하는 16개의 CUDA Cores에 할당되어 동작하게 됩니다. 이는 Tesla Architecture도 동일하며 Kepler Architecture에서는 Power Consumption 문제가 대두되며 Scheduler와 동일 클럭으로 동작하도록 변경됩니다.

*Warp : 같은 명령어로 동시에 실행되는 32개의 Thread의 모음으로 NVIDIA에서는 이를 'Warp'라고 칭함 (AMD의 'Wavefront'와 동일한 개념) 추가적으로 Warp가 존재한다는 것은 한 명령어로 여러 Thread가 실행됨을 의미함으로, 이 동작을 'SIMT(Single Instruction Multi Thread)'라고 함

[Figure 3] MAD(Multiply-Add) vs FMA(Fused Multiply-Add) / Reference [5]

위의 그림은 Fermi Architecture에서 적용된 부동소수점 연산인 FMA(Fused Multiply-Add)를 설명하는 그림입니다. 이 연산 방법의 적용으로 부동소수점 연산의 정확도 향상을 성취할 수 있었습니다. 위 그림을 통해 MAD 연산과 FMA 연산의 차이를 확인할 수 있는데 MAD의 경우 중간 계산 결과의 하위 Bits를 버린 다음 최종 결과를 계산하는 반면, FMA 에서는 중간 결과의 모든 하위 Bits를 보존한 상태로 최종 결과를 계산합니다. 기존의 MAD 연산은 계산 결과가 FMA에 비해 부정확하여 그래픽 연산에는 문제가 없었지만 General purpose computing에는 적합하지 않았습니다. 하지만 Fermi Architecture에서 FMA 연산이 지원되며 GPGPU Computing에 대한 지원이 강화되었습니다.

추가적으로 CUDA Core 내부에 부동소수점 연산 지원이 추가되어(FP unit) 부동소수점의 성능 또한 향상되었습니다. Tesla Architecture에서는 각 SM 마다 64Bit 부동소수점 연산 유닛을 Core 외부에 별도로 두었지만 Fermi Architecture에서는 CUDA Core 내부에 부동소수점 연산을 위한 Unit을 도입하여 32Bit 부동소수점 연산을 수행하는 CUDA Core 2개를 사용해 효율적으로 64Bit 부동소수점 연산을 수행할 수 있게 되었습니다.

[3] Kepler / 2012

: 'Performance와 Power Consumption을 개선' HPC(High Performance Computing)를 위한 도약

Kepler Architecture는 이전 Architecture에 비해 성능과 전력 효율을 개선시키는 것을 목표로 개발되었습니다. 클럭의 동작 속도는 전력 소모와 비례 관계에 있습니다. 그렇기 때문에 이전 Architecture에서는 CUDA Cores, LD&ST units, SFU 등이 다른 부분보다 2배 빠르게 동작했지만 Kepler Architecture 부터는 GPU 전체가 동일 클럭으로 동작하도록 변경되었습니다. 이는 GPU의 전반적인 클럭 속도 향상으로 이보다 두배 빠른 속도로 클럭을 동작시키는 것이 어렵고 전력 소모 면에서 큰 문제가 있기 때문입니다. 이전에는 2배 빠른 속도의 클럭을 사용해 성능 향상에 사용하였지만 절반 속도의 클럭으로도 동일한 성능 혹은 더 좋은 성능을 내기 위해선 실행 유닛의 갯수가 2배 이상이 되어야 합니다. 그렇기 때문에 Kepler Archiecture에서는 훨씬 더 많은 실행 유닛을 도입하였습니다.

[Figure 4] Kepler Architecture의 SMX 구조 / Reference [6]

위의 그림은 Kepler Architecture의 Streaming Multiprocessor(SM)의 구조를 나타냅니다. Kepler Architecture부터 SM이 SMX라는 이름으로 변경되었으며 2배의 클럭 속도를 사용하지 않고 성능을 향상시키기 위하여 훨씬 많은 실행 유닛들을 도입했음을 확인할 수 있습니다. Kepler의 SMX에서는 192개의 CUDA Cores, 64개의 *64-Bit DP units, 32개의 LD&ST units, 32개의 SFU로 구성되어 있습니다. 늘어난 실행 유닛을 효과적으로 사용하기 위하여 Warp Scheduler의 갯수도 2개에서 4개로 증가했으며 각 Warp Scheduler unit에 대응되는 Dipatch unit 또한 1개에서 2개로 증가해 SMX에서는 동시에 최대 8개의 명령어를 처리하는 것이 가능해졌습니다. 또한 Register file 크기도 최대 128KB로 4배 가량 증가했으며 L1 Cache의 크기 또한 128KB로 Fermi SM의 2배가 되었음을 알 수 있습니다. 추가적으로 하나의 Thread가 사용할 수 있는 최대 Register의 수가 63개에서 255개로 늘어났는데 이는 DP unit의 갯수가 증가한 것과 더불어 그래픽 연산보다 High Performance Computing(HPC) 응용 분야의 성능 향상을 위한 변화라고 판단됩니다.

또한 명령어 처리 효율 향상을 위하여 명령어 Scheduling 방법에도 많은 변화가 생겼습니다. 아래의 그림은 이전 Architecture인 Fermi와 새롭게 제시된 Kepler의 Scheduling 방법을 비교한 그림입니다.

[Figure 5] Fermi Architecture scheduling vs Kepler Architecture scheduling / Reference [7]

Fermi Architecture의 경우 CUDA Core, LD/ST unit, SFU 내부의 파이프라인 상에서 진행중인 명령어들의 수행이 완료되었는지 확인하는 Scoreboard 회로와 이를 바탕으로 다음에 실행될 명령어 사이의 Dependency를 동적으로 확인하는 Dependency Check 회로가 존재했습니다. 이는 명령어들이 파이프라인 상에서 진행될 때 명령어 사이의 Dependency 때문에 Data hazard가 발생하는 상황을 예방하기 위한 회로입니다. 하지만 Kepler Architecture에서는 한 번에 처리하는 명령어가 4개에서 8개로 늘어나고 실행 유닛 그룹의 갯수 또한 크게 증가했기 때문에 위의 조건을 모두 고려해 회로를 설계한다면 Scheduling 회로의 복잡성이 너무 증가하게 됩니다. 하여 Kepler에서는 Compiler에 미리 명령어 실행을 완료하기 위한 필요 Cycle 수를 명령어와 함께 사용하여 다음에 실행할 명령어를 선택함으로써 Scoreboard와 Dependency check 회로 없이 간단한 방법으로 Scheduling을 구현할 수 있었습니다.

*64Bit DP Units : 64Bit 부동소수점 연산을 위한 Double Precision units으로 High Performance Computing(HPC)를 위해 도입됨, Fermi Architecture과 달리 32-Bit 연산과 64-Bit 부동소수점 연산이 동시에 실행될 수 있어 성능이 크게 향상됨

[4] Maxwell / 2014, 2015 : '미세 공정 도움 없이 Kepler Architecure 최적화'

Maxwell Architecture가 발표되던 시기는 이전 세대의 GPU Architecture가 발전하던 방향과 조금 다른 방향으로 GPU의 개발이 이루어졌습니다. Kepler Architecture 까지는 데스크탑에서의 사용을 최우선으로 고려하여 발전이 진행되었다면 Maxwell Architecture 에서는 이를 Mobile device에 최적화 하려는 노력이 있었습니다. 또한 이전 Architecture의 경우 세대를 거듭하며 공정 기술의 발달이 동반되며(전보다 더 적은 공간에 더 많은 Tr을 배치할 수 있었음) 클럭 속도를 높이거나 CUDA Core의 갯수를 늘려 성능을 향상시키는 것이 가능했다면 Maxwell Architecture가 도입되는 시점에는 반도체 공정이 28nm에 머물러 있었습니다. 때문에 Maxwell Architecture에서는 공정 기술의 발달에 의한 이득을 볼 수 없었기에 Kepler Architecture를 최적화 하는 방향으로 개발이 진행되었습니다.

[Figure 6] Maxwell Architecture의 SMM 구조 / Reference [8]

위의 그림은 Maxwell Architecture의 SMM 구조입니다. Kepler Architecture의 SMX에서 192개였던 CUDA Cores의 갯수가 128개로 크게 줄었는데 이는 Kepler Architecture의 SMX에서 Dispatch Unit에 비해 CUDA Cores의 갯수가 너무 많아 CUDA Cores utilization 저하가 발생했기 때문으로 판단됩니다. (Dispatch unit에 비해 너무 CUDA Cores가 많아 연산이 실행될 때 쓰이지 않고 놀게 되는 CUDA Cores가 발생함) NVIDIA의 분석에 따르면, CUDA Cores의 수를 192개에서 128개로 대폭 줄이더라도 SMM의 성능 저하는 10%정도 밖에 되지 않는다고 합니다. Shared memory 관련해서도 변화가 있었는데 이전 Architecture에서는 Shared memory의 일부를 L1 Cache로 설정해 사용할 수 있었지만 Maxwell 부터는 Shared memory와 L1 Cache가 분리되었습니다. (L1 Cache는 texture cache로도 사용됩니다.)

SMM 내부의 CUDA Cores의 갯수가 줄어들었기 때문에 하나의 SMM이 차지하는 면적 또한 줄어들었습니다. 따라서 SMM의 갯수를 두배로 늘렸지만 칩 전체가 차지하는 면적을 이전 아키텍쳐의 2배보다 작게 배치할 수 있었습니다. Kepler Architecture의 GK104 GPU의 경우 8개의 SMX를 탑재하여 1536개(8 x 192)의 CUDA Cores를 갖고 있는 반면 Maxwell Architecture의 GM204의 경우 그 2배인 16개의 SMM을 탑재하고 있습니다. 따라서 GM204는 총 2048개(16 x 128)의 CUDA Cores를 갖게 됩니다. 칩의 면적은 두 모델 모두 CUDA Cores의 수에 거의 비례하지만 Maxwell Architecture에서 SMM의 수가 두배로 늘었기 때문에 1.8배에 준하는 성능 향상을 도출할 수 있었습니다. (이론상 Peak 성능은 아닙니다.)

Maxwell SMM에 적용된 큰 변화 중 하나는 64Bit 부동소수점 연산을 위한 Double precision unit의 갯수가 Kepler의 SMX에 비해 크게 줄어들었다는 점입니다. Warp Scheduler 하나 당 1개의 DP 유닛이 존재하는 것으로 판단되는데 이 때문에 Maxwell Architecture와 64Bit 부동소수점 연산 성능은 32Bit 연산 성능에 비해 1/32 수준으로 크게 후퇴하였습니다. 이는 많은 사용자들이 사용하는 FP32 연산의 중요성을 강조한 조치라 판단됩니다.

[Figure 12] Kepler Architecture의 data path(좌) vs Maxwell Architecture의 data path(우) / Reference [14]

Maxwell Architecture에는 전력 효율을 위한 최적화 기법 또한 적용되었습니다. 위의 그림은 Kepler Architecture의 Dispatch Unit과 실행 유닛 사이의 연결 구조와(좌) Maxwell Architecture의 연결 구조(우)입니다. 그림을 통해 알 수 있듯이 Kepler Architecture의 경우 모든 실행 유닛이 하나의 crossbar 스위치로 연결되어 있습니다. 이런 경우 8개의 Dispatch unit들은 각각 어떤 실행 유닛이든 자유롭게 접근 할 수 있는 장점이 있지만 모든 node를 연결한 crossbar가 칩에서 큰 면적을 차지하게 됩니다. 많은 면적을 차지하기에 많은 전력을 소비하게 되고 전력 소비를 효율적으로 하기 위해서 Maxwell Architecture에서는 Dispatch unit과 실행 Unit들 사이를 구분해 배치하였습니다. Maxwell Architecture의 경우 SMM에서 실행 유닛들을 4 그룹으로 분류하고 4 쌍의 Ditpatch unit이 각 그룹 중 하나만 접근할 수 있도록 제한하였는데 이런 경우 한 쌍의 두 Dispatch unit이 동일 실행 unit을 사용하려 하는 경우 하나의 명령어밖에 실행하지 못할 가능성이 높아지지만 이로 인한 성능 저하보다 전력 소모와 칩 면적 감소에 더 집중하였음을 알 수 있습니다.

전력 소비 효율 증대를 위한 또 다른 변화는 L2 Cache의 크기가 이전 Architecture에 비해서 512KB에서 2MB로 크게 늘었다는 것입니다. 프로세서 외부 메모리인 GDDR5의 전력소모는 얼마나 자주 메모리에 접근하는 지에 영향을 받게 되는데 L2 Cache의 용량을 늘림으로써 외부 메모리 사용을 줄여 GPU 전체의 전력 소모를 줄일 수 있었습니다.

[5] Pascal / 2016 : 'Deep Learning Boom, GPU를 새로운 혁신으로 이끌다.'

Pascal Architectue가 등장한 시기는 이미 전세계 적으로 딥러닝 붐이 일어났던 시기입니다. 많은 기업들이 AI 분야에 GPU를 사용하였고 이와 관련한 개발자도 빠르게 늘었습니다. NVIDIA는 GPU에 국한된 것이 아니라 AI회사로 불리기 원했는데 '2016 GPU Tech Conference' 내용을 보더라도 3D 그래픽 관련 내용보다 딥러닝과 AI에 관련된 내용에 훨씬 많은 발표 시간을 할애함을 알 수 있습니다. 따라서 NVIDIA에서는 딥러닝 프로그램에 적합한 Architecture 구현을 위해 많은 노력을 했습니다. Pascal Architecture의 Streaming Multiprocessor는 이전 세대와 달리 두 가지 종류로 나뉘어 발표되었는데 이는 HPC(High Performance Computing) 분야와 그래픽 분야에서 요구되는 성능이 달라졌기 때문입니다. 딥러닝 혹은 HPC 응용 프로그램들은 FP64연산과 FP16연산(64bit, 16bit 부동소수점 연산) 성능이 중요하며 하나의 Thread가 많은 레지스터를 사용하는 것이 중요하지만, 그래픽 분야의 Shader 프로그램에서는 FP32만을 주로 사용하고, 프로그램이 상대적으로 간단하기 떄문에 레지스터 수를 늘려도 성능에 큰 영향을 미치지 않습니다.

[Figure 7] GP100 Pascal Architecture의 SM 구조 / Reference [9]

위 그림은 GP100 Pascal Architecture의 Streaming Multiprocessor의 구조를 보여주고 있는데 Maxwel의 SMX에 비해 한 SM 당 CUDA Cores를 비롯한 실행 유닛의 갯수는 반으로 줄었습니다.(64개) 실행 유닛의 수가 반으로 줄어들었지만 레지스터 파일의 크기는 그대로 유지되었는데 이를 통해 Warp Scheduler 하나 당 접근할 수 있는 레지스터는 두배로 늘어 Pascal의 SM에서 실행되는 Thread는 이전보다 더 많은 레지스터를 사용할 수 있습니다. 또한 공정 기술이 28nm에서 16nm로 발전하여 GPU 내에 탑재되는 SM의 수가 크게 증가했는데 Kepler Architecture의 경우 16개 혹은 24개의 SMM을 탑재했지만 Kepler Architecture의 경우 무려 56개의 SM을 탑재하고 있습니다. 많은 SM을 사용하여 DL 연산의 경우 신경망 연산에서 12배 이상 빨라졌고 이전 Architecture에 비해 딥러닝 추론 처리량이 약 7배 증가했습니다.

GP100모델에 적용된 Pascal Architecture의 경우 HPC(High Performance Computing) workroad 지원을 목표로 설계되었기 때문에 FP64의 성능이 다시 강조되었습니다. (정확한 연산 결과를 요구하는 HPC 분야의 경우 Double precision인 FP64연산이 중요합니다. ex.정확한 과학적 연산 결과 도출 등) Maxwell Architecture에서 FP32 성능 대비 1/3 혹은 1/32였던 FP64 성능이 Pascal에서는 1/2로 크게 향상되었습니다. 추가적으로 딥러닝 연산에서 더 많은 연산을 빠르게 하기 위하여 FP16연산을 새롭게 도입하였는데, 이는 FP16 연산을 통해 딥러닝의 Traning과 Inference에서 더 높은 Throughput을 내기 위한 조치라 판단됩니다. FP100 Pascal에 사용된 CUDA Core의 경우 FP16연산을 처리할 때 한 Cycle에 두 명령어를 처리할 수 있기 때문에 FP16 연산은 FP32 연산에 비해 두 배 빠르게 처리될 수 있어 계산 속도 면에서도 큰 장점이 있습니다. (기존의 Architecture에서는 FP16연산을 위해서 32Bit 크기의 공간 중 16Bit만 사용하고 나머지 16Bit는 버리는 공간이었음) FP16연산의 경우 *Half precision에 사용되는 연산인데 연산의 정확도가 결과에 큰 영향을 미치지 않는 DL 분야에서 Half precision의 경우 매우 효율적으로 사용될 수 있음이 많은 연구 결과로 밝혀졌습니다. (높은 precision의 연산을 수행할 경우 연산의 정확도는 높지만, 낮은 precision을 사용하여 더 많은 Throughput을 내는 것이 DL 연산 성능에 더 큰 영향을 미침)

[Figure 8] NVIDIA 에서 사용하는 Precision format / Reference [10]

*Half precision : 컴퓨터에서 소수를 표현하는 방식 중 하나로 소수를 32bit data로 표현하는 것이 Single precision, 64bit data로 표현하는 것이 Double precision, 마지막으로 16bit data로 표현하는 것이 Half precision

*HPC 연산 vs DL 연산 : HPC 연산의 경우 정확한 연산 결과를 요하기 때문에 Double precision(FP64) 연산을 요하지만, DL 연산의 경우 높은 처리량이 목표이기 때문에 Half precision(FP16) 연산이 효율적임. 이 두 연산은 이론적으로 상반되는 워크로드를 가짐

[6] Volta / 2017 : 'Tensor Cores의 등장, NVIDIA를 Deep Learning acceleration의 정점으로'

Volta Architecture의 경우 12nm의 FinFET 공정으로 구현되었으며 엄청난 수(약 211억개)의 Transistor를 탑재하고 있습니다. 또한 DL 가속을 위한 새로운 연산 유닛인 Tensor Cores의 도입으로 Volta Architecture에서 혁신적인 성능 향상을 이룰 수 있습니다. Tensor Cores의 경우 DL 가속을 위해 특별히 제작된 Core 입니다. Tensor Cores는 16Bit의 부동소수점 연산으로 이루어진 매트릭스 D를 계산하는 동작을 Pascal에 비해 12배 높은 Throughput으로 처리할 수 있습니다. 딥러닝 연산의 경우 Neural Network의 각 Layer와 Node 사이의 Weight를 이용해 다음 Layer로의 출력을 계산할 때 매트릭스 연산이 사용되기 때문에 이를 가속하기 위한 전용 Core의 존재는 DL 연산에 매우 혁신적인 요소입니다.

(Volta architecture의 경우 공정기술의 성장과 새로운 연산 유닛의 도입 외에도 Thread 실행, Thread Scheduling 기법, Core layout, Memory controller, ISA 면에서도 기존의 Architecture에 비해 상당한 차이를 보입니다.)

[Figure 9] Tensor Core / Reference [12]

아래의 그림은 Volta architecture의 SM 구조를 나타내고 있습니다. 새로운 Architecture에서 Chip당 84개의 SM이 포함되어 있습니다. 기존의 CUDA Cores의 경우 FP32 Cores로 이름이 변했고 기존 Architecture에서 가장 많은 부분을 차지했던 FP32 Core와 동일한 수의 정수 연산 Cores(INT Core)가 추가되었는데 이는 DL 연산의 가속을 위한 요소입니다. FP64 Cores의 경우 Pascal Architecture와 동일한 비율로 FP32 Cores의 절반이 탑재되었으며 Warp Scheduler마다 2개의 Tensor Core가 짝을 이루고 있음을 확인할 수 있습니다. 추가적으로 전에 없던 L0 Cache가 추가되었음을 확인할 수 있습니다.

[Figure 10] Volta Architecture의 SM구조 / Reference [13]

추가적으로 Pascal Architecture 까지는 하나의 Warp를 이루고 있는 32개의 Thread는 반드시 동시에 진행을 했지만 Volta Architecture의 경우 아래 그림과 같이 하나의 Warp 내에서 32개의 Thread 각각이 독립적인 PC(Program Counter)를 갖고 독립적으로 진행하는 것이 가능해졌습니다. 이는 원래 Warp scheduler와 짝을 이루던 Dispatch unit의 수가 변한 이유중 하나로 판단됩니다. 위와 같은 변화가 생겼던 이유는 실행 유닛의 종류가 다양해지면서 (FP16, FP32, FP64, INT Core, LD&ST, Tensor Core, SFU) 각 실행 유닛 별 Latancy 차이로 발생하는 비효율을 피하기 위한 조치라 판단됩니다.

[Figure 11] Volta Architecture의 Thread Scheduling 변화 / Reference [13]

Conclusion

Streaming Multiprocessor의 구조는 GPU Architecture가 발전하며 함께 성장해 왔습니다. 초기 Tesla, Fermi Architecture 시기에는 GPU의 동작 속도가 현재보다 느렸고 공정상의 제약 때문에 칩 면적을 효율적으로 사용하는 것이 중요했습니다. 때문에 SM을 두배 빠른 속도로 동작시켜 원하는 성취를 이룰 수 있었습니다. 하지만 Kepler Architecture가 도입되며 칩이 차지하는 면적보다 전력 효율 문제가 대두되며 SM을 두배 빠르게 동작시키는 방법 대신 CUDA Cores의 수를 두배로 늘려 원하는 성취를 이루었습니다.(이는 공정 기술의 발달에 영향을 받았습니다.) 하지만 다음 Architecture인 Maxwell의 경우 Kepler와 동일한 28nm의 공정을 계속 사용했기 때문에 Kepler Architecture를 철저하게 분석해 SM 하나 당 필요한 CUDA Core의 갯수를 최적화 했으며 효율성과 성능을 향상시켰습니다. (하지만 FP64 연산 성능은 이전보다 안좋아졌습니다.) 딥러닝 붐이 일어난 시기에 등장한 Pascal Architecture는 DL 연산을 위한 자원을 늘리기 위하여 FP16 연산 성능을 FP32 연산에 비해 두 배로 늘렸으며(FP16연산은 FP32 연산보다 정확도는 떨어지지만 더 많은 Throughput을 낼 수 있습니다.) Warp Scheduler 하나가 접근할 수 있은 Register 파일 또한 두 배로 늘렸습니다. Volta Architecture의 경우 DL 연산을 더욱 가속하기 위해 새롭게 도입된 개념인 Tensor Core가 적용되었으며 4x4 매트릭스 연산을 Pascal 보다 무려 12배 빠르게 수행할 수 있었습니다. *Tensor Core 관련 자세한 내용은 이전 포스트를 참고해주세요.

Reference

[1] http://www.donghyun53.net/nvidia-gpu-%ec%95%84%ed%82%a4%ed%85%8d%ec%b2%98-%eb%b3%80%ec%b2%9c%ec%82%ac-%ec%83%81%ed%8e%b8/

[2] http://www.donghyun53.net/nvidia-gpu-%ec%95%84%ed%82%a4%ed%85%8d%ec%b2%98-%eb%b3%80%ec%b2%9c%ec%82%ac-%ed%95%98%ed%8e%b8/

[3] Lindholm, Erik, et al. "NVIDIA Tesla: A unified graphics and computing architecture." IEEE micro 28.2 (2008): 39-55.

[4] Aila, Timo, Samuli Laine, and Tero Karras. "Understanding the efficiency of ray traversal on GPUs–Kepler and Fermi addendum." Proceedings of ACM High Performance Graphics (2012): 9-16.

[5] “NVIDIA’s Next Generation CUDA Compute Architecture: Fermi”, White Paper

[6] “NVIDIA’s Next Generation CUDA Compute Architecture: Kepler TM GK110/210”, White Paper

[7] https://www.anandtech.com/show/6446/nvidia-launches-tesla-k20-k20x-gk110-arrives-at-last/3

[8] https://developer.nvidia.com/blog/maxwell-most-advanced-cuda-gpu-ever-made/

[9] "Whitepaper, NVIDIA Tesla P100, The Most Advanced Datacenter Accelerator Ever Built Featuring Pascal GP100,

the World’s Fastest GPU”

[10] https://www.nvidia.com/en-us/data-center/pascal-gpu-architecture/

[11] https://blogs.nvidia.com/blog/2020/05/14/tensorfloat-32-precision-format/

[12] Youtube "GTC 2017: NVIDIA Announces Tesla V100 (NVIDIA keynote part 6)”

[13] https://www.anandtech.com/show/11367/nvidia-volta-unveiled-gv100-gpu-and-tesla-v100-accelerator-announced

[14] http://www.donghyun53.net/nvidia-gpu-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EB%B3%80%EC%B2%9C%EC%82%AC-%ED%95%98%ED%8E%B8/

[NVIDIA] CUDA Cores vs Tensor Cores

H/W engineer_ beginner — Fri, 7 Jan 2022 19:48:35 +0900

Introduction

GPU(Graphics proccessing unit)는 그래픽 연산을 빠르게 처리하기 위해 고안된 그래픽 처리 장치입니다. 이 용어는 1999년 NVIDIA사에서 'geforce 256 model'을 발표하며 처음 사용하기 시작했으며 현재는 다양한 Data sets를 병렬로 처리해야하는 인공지능 연산 분야에서 그 사용성이 입증되며 광범위한 분야로 확장되고 있습니다. NVIDIA는 이런 GPU의 범용성을 인지하고 GPU를 단순히 그래픽 연산을 처리하기 위한 장치가 아닌, CPU처럼 'General Purpose(범용적)'으로 사용하기 위해 많은 공을 들였습니다. 또한 C, C++와 같은 고급 언어로 프로그래밍할 수 있도록 *CUDA라는 병렬 컴퓨팅 플랫폼을 세상에 공개했습니다.

[Figure 1] CPU vs GPU

CPU와 마찬가지로 GPU 내부에도 연산을 처리할 수 있는 Core들이 존재합니다. 하지만 CPU와 GPU Core 구성에는 큰 차이가 존재합니다. CPU는 하나의 Core가 순차적으로 직렬 처리되는 프로세스를 효율적으로 처리하기 위해 만들어졌습니다. 즉, 단일 Core 성능을 GPU와 비교한다면 월등히 뛰어나다고 할 수 있습니다. 하지만 GPU는 병렬 처리를 기반으로 한 아키텍쳐를 채택해 설계되었기 때문에 여러 Data들을 병렬로 효율적으로 처리할 수 있습니다.(위의 이유로 GPU를 Throughput 기반의 Architecture라고 부르기도 합니다.) CPU보다 더 단순한 Core들로 구성되어 있지만 CPU가 일반적으로 1에서 8개의 Core를 갖는 것에 비해 GPU는 보통 수백에서 수천 개의 Core를 갖습니다. 때문에 많은 양의 Data sets를 병렬로 처리해야 하는 AI 연산에 GPU가 선호되고 있습니다. GPU의 Core는 더 작은 용량의 Cache, 작은 Instruction set, 낮은 Clock rate를 갖습니다. 그렇지만 CPU보다 매우 많은 Core가 밀집되어 있기 때문에 병렬 처리에 유용합니다. GPU 내에서 CUDA Core의 수는 더 좋은 Computing performance를 낼 수 있다는 말과 동일합니다. 하지만 GPU의 서로 다른 세대 간의 성능을 비교할 때는 단순히 Core의 수 만으로 비교할 수는 없습니다. GPU 안에서도 세대를 변화하며 단일 Core의 성능이 달라지기 때문입니다. 최신 NVIDIA GPU 안에는 세 가지 종류의 Core가 존재합니다. (1) CUDA cores (2) Tensor cores (3) Ray-Tracing cores 각 Core 들은 서로 다른 목적을 위해 설계되었습니다. 하여, 이번 게시글을 통해 CUDA cores와 Tensor cores 의 차이점에 대해 알아보고 각 Core가 GPU 성능에 미치는 영향에 대해 고찰하려 합니다.

*CUDA : Compute Unified Device Architecture

CUDA cores?

GPU 상에서 CUDA Cores가 하는 일은 근본적으로 CPU 내부의 Core가 하는 일과 유사합니다. (하지만 CPU와 달리 Instruction을 가져오거나 Decodeing 할 수는 없습니다.)

[Figure 2] CPU vs GPU

구조적으로 CPU는 큰 크기의 Cache memory와 함께 한 번에 몇 개의 Thread를 처리할 수 있는 소수의 Core로 구성됩니다. 이와 대조적으로 GPU는 수천 개의 Thread를 동시에 처리할 수 있는 수백에서 수천 개의 CUDA Core로 구성됩니다. 이를 통해 GPU는 CPU보다 훨씬 많은 작업을 빠르게 처리할 수 있으며 이런 특징을 통해 AI분야의 Deep Learning 연산에서 핵심적인 역할을 맡을 수 있었습니다. 일반적으로 CUDA Cores는 Tensor Cores에 비해 느리지만 fp32 연산을 수행하기 때문에 더 정확한 연산을 수행할 수 있습니다. (Tensor Cores 는 fp16 연산이기 때문에 계산 정확도를 어느 정도 희생해야 합니다.)

그렇다면 CUDA Cores 가 GPU의 성능에 어떤 영향을 미칠까요? 단순히 CUDA Cores의 수로 GPU의 성능을 판단하기에는 많은 제한 조건들이 있습니다. 어떤 GPU Architecture를 채택했는가 부터 *GPU Clock speeds, Memory Bandwidth, Meory speed, TMUs, *VRAM, ROPs 등은 성능에 영향을 미치는 요소들 입니다. 하지만 동일한 GPU Architecture 내에서는 이런 조건들이 비슷하기 때문에 CUDA Cores의 수로 성능을 비교할 수 있습니다. 많은 CUDA Cores는 Performance bottleneck 현상을 일으키는 다른 요인이 없는 경우 같은 Generation에서 더 좋은 성능을 의미합니다. 하지만 다른 Generation 사이에서 성능을 비교하는 경우는 이와 상황이 다릅니다. 예를 들어 GTX 1070은 GTX 780과 거의 동일한 수의 CUDA Core를 갖고 있지만 성능 면에서 월등한 차이를 갖고 있습니다. 이런 성능 차이는 단일 Core의 성능 차이와 세대를 거듭하며 발전하는 제조 공정 차이, 트랜지스터의 크기 차이 등에 기인한 것으로 판단됩니다. GTX 980 Ti(Maxwell architecture)와 GTX 980 Ti(Pascal architecture)의 경우는 비슷한 수의 CUDA Core와 Transistor가 존재하지만 트랜지스터의 크기가 이 둘의 성능을 비교하는 데에 결정적인 역할을 했습니다. 더 작은 Transistor를 사용하는 Pascal architecture의 전력 소비 감소로 작은 공간에 많은 트랜지스터를 집적할 수 있었으며 이를 통해 최대 Clock frequency를 증가시킬 수 있었습니다. Clock frequency의 증가로 단일 Core가 더 빠르게 작업을 수행할 수 있었으며 이는 두 Architecture 간의 성능 차이로 이어졌습니다.

NVIDIA에서 자사의 GPU Cores를 CUDA Core로 명명한 것 처럼 AMD 사에서는 이를 Stream Processor라고 부릅니다. 두 회사의 Architecture가 근본적으로 다르게 설계되었기 때문에 CUDA Cores의 수와 Stream processor의 수만 보고 성능을 비교할 수는 없습니다. 하지만 Benchmark simulation을 통해 두 Architecture의 성능을 보다 정확히 비교할 수 있습니다.

*GPU Clock speeds : Core Clock speed(GPU 동작 속도)와 Memory Clock speed(VRAM 동작 속도)

*VRAM : GPU를 통해 처리되는 assets, textures, shadow maps등을 포함한 모든 Data를 저장합니다. DRAM, SSD, HDD에 비해 접근성이 좋고 빠릅니다.

Tensor cores?

Tensor cores란 NVIDIA에서 개발한 행렬 곱셈 프로세스를 가속하는 처리 장치 입니다. CUDA Cores가 1 Core Clock에 하나의 fp32 부동소수점 연산을 수행하는 것에 비해 Tensor Cores는 같은 Term 동안 4 x 4 크기의 fp16 행렬 두 개를 곱하고 그 결과를 4 x 4 fp32 행렬에 더하는 Matrix multiply-accumulate 연산(A와 B를 곱하고 C를 더하는 과정을 하나의 연산으로 수행)을 수행합니다.

[Figure 3] Matrix Multiply-Accumulate 연산

이 과정에서 fp16 행렬을 입력 받고 fp32 행렬을 출력하기 때문에 Mixed precision이라고 불립니다. 또한 이 연산은 Rounding이 한번 일 때 FMA(Fused Multiply-Add)라고 불리기도 합니다. 각 Tensor core는 한 번의 GPU Clock에 64개의 부동소수점 연산을 하는데 이는 출력 행렬의 한 원소를 계산하기 위해 4 개의 FMA 연산이 필요하고 총 4 x 4 (16개)의 원소가 존재하기 때문입니다.

[Figure 4] FMA 연산

Tensor Cores라는 이름에서 'Tensor' 의 의미는 무엇일까요? Tensor란 다차원의 Data sets 를 저장할 수 있는 컨테이너로 행렬의 확장으로 생각할 수 있습니다. 행렬은 숫자를 포함한 2차원 구조이지만 Tensor는 숫자의 다차원 집합으로 표현됩니다.

[Figure 5] Tensor

모든 마이크로 프로세서는 산술 및 논리 연산을 수행합니다. 이 중 중요도가 높은 산술 연산 중 하나는 바로 행렬 곱셈 입니다. 하지만 2개의 4 x 4 행렬의 곱셈을 수행하려면 이론적으로 64개의 곱셈 연산과 48개의 덧셈 연산이 필요합니다. 그렇기 때문에 NVIDIA는 연산의 정확도를 희생하여 더 많은 연산을 빠르게 수행할 수 있는 Tensor Cores를 세상에 출시하였습니다. NVIDIA의 Volta Architecture에서 이 기술이 최초로 적용되었으며 그 이후의 Architecture에도 이를 적용하여 훨씬 빠르게 연산을 수행할 수 있게 되었습니다.

[Figure 6] Turing Tensor Cores (Int8, Int4 연산 추가)

Tensor Cores는 Clk 주기 당 여러 작업을 한 번에 수행할 수 있으며 CUDA Cores 보다 훨씬 높은 처리량(Throughput)을 수행합니다. 기계 학습 분야의 경우 비용과 계산 속도 면에서 Tensor Cores의 성능은 CUDA Cores를 크게 앞지르고 있으며 AI 연산 분야와 그 응용 분야들에서 널리 사용되고 있습니다.

CUDA Toolkit에서 제공하는 라이브러리인 cuBLAS와 cuDNN에서는 Tensor Cores를 지원하고 있습니다. cuBLAS는 행렬과 행렬의 곱셈 연산인 GEMM 연산에 Tensor Cores를 이용하고 cuDNN 에서는 Convolution 연산에 이를 이용하고 있습니다. 실험 결과 Tensor Cores는 cuBLAS에서 4에서 9배, cuDNN에서 4에서 5배의 성능 향상을 이끌었습니다. Tensor Cores가 처음 적용된 Architecture인 Volta의 model 중 Titan V는 5120개의 CUDA Cores와 640개의 Tensor Cores를 갖고 있습니다. 하나의 Tensor Core 는 한 Cycle에 64개의 FMA를 수행하며 이는 한 번에 128개의 부동소수점 연산을 수행하는 것과 같습니다. 따라서 Titan V 의 경우 640개의 Tensor Cores가 있으므로 Cycle마다 128 x 640 개의 부동소수점 연산을 수행할 수 있습니다. Turing Architecture의 경우 딥러닝 추론 속도 향상을 위하여 INT8과 INT4 연산을 추가했는데 이를 통해 연산에 필요한 비트 수를 대폭 줄이고 연산 속도를 극적으로 향상시키는 Quantization 기법을 적용하였습니다.

Reference

[1] https://blogs.nvidia.com/blog/2009/12/16/whats-the-difference-between-a-cpu-and-a-gpu/

[2] https://www.techcenturion.com/nvidia-cuda-cores/

[3] https://www.techcenturion.com/tensor-cores/

[4] https://developer.nvidia.com/blog/programming-tensor-cores-cuda-9/

[NVIDIA] NVIDIA에서 제공하는 AD 관련 DNN networks

H/W engineer_ beginner — Thu, 6 Jan 2022 17:15:06 +0900

경로 탐색 DNN

=> 차량 주행 위치를 결정하고 전방의 주행 가능한 경로 계획

1) OpenRoadNet : 차선 또는 인접 차선에 관계 없이 차량 주변의 모든 주행 가능 공간 식별

2) PathNet : 차선 표시가 없는 경우에도 차량 전반의 주행 가능 경로 표시

3) LaneNet : 차선과 차선 경로를 정의하는 다른 표식들 감지

4) MapNet : 차선과 고화질 지도를 업데이트하고 만드는데 사용할 수 있는 랜드마크 식별

객체 탐색 및 분류 DNN

=> 신호등과 도로 표지판, 잠재적인 장애물을 감지

1) DriveNet : 도로의 다른 차량, 보행자, 신호등, 도로 표지판 인지 (종류는 인지X, 종류만 인지)

2) LightNet : 신호등의 상태를 빨간색, 노란색, 초록색으로 분류

3) SignNet : 정지, 양보, 일방통행 등 신호의 종류를 구분

4) WaitNet : 교차로같이 차량이 정지하고 기다려야 하는 장소의 상태 탐색

인지 능력 향상을 위한 DNN

=> 차량 부품과 조종석 상태를 감지하고 주차와 같은 조작을 용이하게 할 수 있도록 도움

1) ClearSightNet : 차량 카메라를 모니터링하여 비, 안개, 직사광선 같이 시야 제한 조건 감지

2) ParkNet : 주차 가능한 장소를 식별

[IEEE.2021] Deep Learning Inference Parallelization on Heterogeneous Processors with TensorRT

H/W engineer_ beginner — Wed, 5 Jan 2022 14:59:39 +0900

출처 :

Jeong, Eun Jin, et al. "Deep Learning Inference Parallelization on Heterogeneous Processors with TensorRT." IEEE Embedded Systems Letters (2021).

본 논문은 향후 진행할 AD(Auto Driving) 프로젝트의 연구 방향에 대한 유관 연구 조사로 읽었기 때문에 방법에 대한 이야기는 빼고 문제 상황과 연구 방향 등에 초점을 맞춰 요약하였습니다.

Abstract: 임베디드 디바이스에서 Deep Learning Application의 사용이 증가함에 따라 디바이스는 CPU와 GPU 외에 NPU(Neural Processing units)라는 새로운 연산 unit을 도입하게 되었습니다. 빠르고 효과적으로 Deep Learning Application을 개발하기 위하여 NVIDIA에서는 NVIDIA Hardware platform에서 구동되는 '*TensorRT'라는 *SDK(Software Development Kit)를 제공합니다. 하지만 현재 TensorRT를 포함한 대부분의 Deep Learning Framework는 Deep Learning Inference(추론)을 위해 Single proccessor만 사용하고 있습니다. (GPU와 NPU를 동시에 사용하지 않음.) 하여 이 paper를 통해, 추론에서 최상의 Throughput을 내기 위한 새로운 방법을 제시합니다. : TensorRT상에서 하나의 Deep Learning App을 구동할 때, GPU와 NPU를 Parallelization methology를 사용하여 동시에 추론하는 방법을 새롭게 도입해 실험을 진행했고, 실험 결과 81% 에서 391% 가량의 성능 향상 결과를 확인할 수 있었습니다.

*TensorRT : 학습이 완료된 Deep Learning model을 최적화하여 NVIDIA GPU 상에서 추론 속도를 향상(수 ~ 수십 배)시키는 모델 최적화 엔진 (딥러닝 추론 가속 엔진)*SDK : Software Development kit로 API를 포괄하는 개념입니다.

Introduction: 임베디드 디바이스에서 DL(Deep Learning) inference application의 사용이 증가하며 많은 임베디드 디바이스들은 추가적인 Hardware resource들을 장착하기 시작했습니다. 예를 들어 본 논문에서 사용할 NVIDIA의 Jetson AGX Xavier는 multi-core CPU와 GPU 외에 추가적인 하드웨어 리소스인 deep learning accelerators(*DLAs)를 장착하고 있습니다. 본 논문에서는 학습이 완료된 network를 임베디드 디바이스에서 실행하기 위하여 TensorRT로 불리는 SDK를 사용합니다. 지금까지의 많은 연구들은 DL applications를 가속하기 위하여 software optimization을 사용해왔습니다. (예를 들어 quantization, low-rank approximation, layer fusion 등이 있으며, 이 중 몇몇의 최적화 기법들은 TesorRT에 적용되었습니다.) 이번 연구에서는 DL application의 throughput을 최대로 올리기 위하여 *network-level optimization을 진행합니다. 해당 기법은 Hardware platform과 Objective function에 의존적이며 이와 관련한 많은 연구들이 있었습니다. 앞 줄의 내용을 설명하기 위해 본 논문에서 인용된 다른 논문들은 아래와 같습니다.

[2] : multicore cpu의 자원을 최대로 활용하기 위한 방법

[3] : Heterogeneous cpu core에서 Throughput을 증가시키기 위한 방법

[4] : Mobile platform에서 GPU를 사용해 Single execution을 가속하기 위한 방법 (Deep X)

[5] : Mobile platform에서 GPU를 사용해 Single execution을 가속하기 위한 방법 (CNNdroid)

[6] : CPU/GPU Pipelining으로 Throughput 향상시키는 방법 (pre/post 기법으로 GPU에서 network body 실행되는 동안 cpu로 task 처리)

[7] : multiple deep neural networks (DNNs)을 CPU-GPU heterogeneous system에서 실행하여 Throughput 증가

[8] : multiprocessor system에서 conventional parallel scheduling을 통해 CNN model을 dataflow graph로 변환

[9] : 각 network가 single PE에 매핑되었다 가정했을 때 multiple DNN instances를 scheduling하는 방법

[10] : multiple DNN instances가 GPU와 NPU를 포함한 Heterogeneous system에서 구동될 때 각 network에 task-level parallelism을 적용해 Throughput을 증가시키는 방법 (그러나 single DL applicarion에서 GPU와 NPU를 동시에 지원하는 SDK가 존재하지 않는 한계가 있습니다.)

하여, 본 논문에서는 single DNN application의 throughput을 최대치로 올리기 위하여 TensorRT를 기반으로 한 parallelization 기법을 제시합니다. (GPU와 NPU를 동시에 사용할 수 있도록) 최종적으로 GPU와 NPU를 동시에 사용해 두 network instances를 concurrently하게 실행하여 Heterogeneous processors의 사용성을 향상시킬 수 있습니다.

*DLA : Deep learning accelerators로 neural porcessing units(NPUs)라고 불리기도 합니다.

*network-level optimization : 본 논문에서 제시하는 개념으로, task-level parallelism과 pipelining을 포함한 다양한 레벨에서의 Parallelism 기법입니다. 이 기법은 하드웨어 플랫폼과 objective function에 큰 영향을 받습니다.

Conclusion: 여섯 개의 real-life benchmark를 사용하여 성능을 측정한 결과 81%에서 391% 가량의 성능 향상을 확인할 수 있었습니다. 기존까지 임베디드 디바이스에서 pipelining과 multi-threading의 parallelism이 적용된 연구는 거의 없거나 존재하지 않았습니다. 이번 연구가 특정 하드웨어 플랫폼(Jetson)을 통한 검증 결과이긴 하지만 다른 Platform에도 확장 가능할 것이라 판단하며, 유용한 결론을 도출했다고 생각합니다.

소개

H/W engineer_ beginner — Mon, 3 Jan 2022 16:34:51 +0900

Jihak.lee Notion Link : https://gigantic-radio-6d0.notion.site/Profile-0c4a2f2c3f254ae08e2f4b335835e118

안녕하세요! 제 블로그에 방문하신 모든 분들 환영합니다 :)

저는 현재 성균관대학교 전자전기공학부에 학사로 재학중이며,

Computer Science & System Software 관련 Lab에서 프로젝트를 진행 중에 있습니다.

연구와 프로젝트를 하며 공부하는 내용을 기록하고

여러 사람들과 공유하고 싶다는 생각이 들어 블로그를 열게 되었습니다.

부족한 점이 많겠지만 서로 소통하며 함께 성장하는 기회가 되었으면 좋겠습니다.

제 관심 분야는

#PIM #GPU #Auto_Driving #CUDA #AI_Hardware #AI_Accelerator #FPGA #Jetson #DNN

등 입니다.

이 블로그에는 연구 분야 관련 내용과 개인적인 공부 관련 (영어 회화?) 포스팅을 할 예정입니다.

ComSys_jh

Near-Memory processing vs In-Memory processing

Zsim + Ramulator (PIM simulator)

I. Introduction

II. Setup

III. How to use?

IV. Reference

[IEEE.2020] Planaria: Dynamic architecture fission for spatial multi-tenant acceleration of deep neural networks.

Abstract

Introduction

Insight

Reference

[IEEE.2021] AI Multi-Tenancy on Edge: Concurrent Deep Learning Model Executions and Dynamic Model Placements on Edge Devices

Abstract

Introduction

Insight

[PIM] week 01

Introduction

Contents

Reference

[AI H/W] What is AI?

[A] Introduction

[B] How does the brain works?

[B-1] Spiking architecture

[B-2] Neural networks

[C] Deep Neural Networks (DNN)

[CUDA] Multi-Process Service

[1] Introduction :

[2] When to use MPS :

[3] MPS Architecture :

[4] Background

[5] Reference :

[Linux] time 명령어

[IEEE.2014] LEoNIDS: A low-latency and energy-efficient network-level intrusion detection system.

Abstract :

Introduction :

본 연구 내용 중, AD 프로젝트에 도움이 되는 개념 및 실험 결과 :

[IEEE.2018] Processing-in-memory for energy-efficient neural network training: A heterogeneous approach.

Abstract :

Introduction :

[NVIDIA] GPU Architecture

NVIDIA GPU Architectures

[1] Tesla(G80) / 2006

[2] Fermi / 2010 : 'GPGPU를 위한 발판'

[3] Kepler / 2012

: 'Performance와 Power Consumption을 개선' HPC(High Performance Computing)를 위한 도약

[4] Maxwell / 2014, 2015 : '미세 공정 도움 없이 Kepler Architecure 최적화'

[5] Pascal / 2016 : 'Deep Learning Boom, GPU를 새로운 혁신으로 이끌다.'

[6] Volta / 2017 : 'Tensor Cores의 등장, NVIDIA를 Deep Learning acceleration의 정점으로'

Conclusion

Reference

[NVIDIA] CUDA Cores vs Tensor Cores

Introduction

CUDA cores?

Tensor cores?

Reference

[NVIDIA] NVIDIA에서 제공하는 AD 관련 DNN networks

경로 탐색 DNN

객체 탐색 및 분류 DNN

인지 능력 향상을 위한 DNN

[IEEE.2021] Deep Learning Inference Parallelization on Heterogeneous Processors with TensorRT

소개