본문 바로가기
학부생의학부연구생/_paper

[MobiSys 2022] mGEMM: Low-latency Convolution with Minimal Memory Overhead Optimized for Mobile Devices (1)

by 호상 🐧 2022. 8. 12.

# 세미나를 위한 논문 summary

# 2022  MobiSys에서 발표된 논문

# 오역이 있을 수 있습니다.

# 2022 08 30 seminar

 

# ACM reference Format : JongseokPark,KyungminBin,andKyunghanLee.2022.mGEMM:LowlatencyConvolutionwithMinimalMemoryOverheadOptimizedforMobile Devices.InThe20thAnnualInternationalConferenceonMobileSystems, ApplicationsandServices(MobiSys’22),June25–July1,2022,Portland,

https://dl.acm.org/doi/10.1145/3498361.3538940

 

mGEMM | Proceedings of the 20th Annual International Conference on Mobile Systems, Applications and Services

ABSTRACT The convolution layer is the key building block in many neural network designs. Most high-performance implementations of the convolution operation rely on GEMM (General Matrix Multiplication) to achieve high computational throughput with a large w

dl.acm.org

 

##

workload? : 

작업으로 치환하고 읽어도 될듯.

 

user experience priority? :

https://www.nvidia.com/ko-kr/geforce/news/reflex-low-latency-platform/

 

NVIDIA Reflex Low Latency 게이밍 플랫폼을 소개합니다

Apex Legends, Call of Duty: Black Ops Cold War, Fortnite, V\alorant 등에 적용됩니다.

www.nvidia.com

읽어보니까 이해가 좀 되는것 같다.

 

What is Latency in Machine Learning (ML)? :

Latency refers to the time taken to process one unit of data provided only one unit of data is processed at a time.

 

ARM CPU? :

임베디드를 위한 cpu? 모바일 cpu에 많이 사용됨. 

 

what is BLAS? :

(Basic Linear Algebra Subprograms; BLAS) , 최적화된 고차원 선형 대수학 기능을 위한 행렬-벡터 연산들을 제공

 

 

what is memory bound problem? :

메모리 바운드는 주어진 계산 문제를 완료하는 데 걸리는 시간이 주로 작업 데이터를 보유하는 데 필요한 여유 메모리의 양에 의해 결정되는 상황을 나타냅니다. 이것은 기본 계산 단계의 수가 결정 요소인 계산 제한 알고리즘과 대조됩니다.

- wikipedia

 

##

 

ABSTRACT

컨볼루션 레이어는 많은 신경망 설계에서 핵심 빌딩 블록이다. 합성곱 연산의 대부분의 고성능 구현은 GEMM(General Matrix Multiplication)에 의존하여 거대한 워크로드 크기로 높은 계산 처리량을 달성한다. 그러나 모바일 환경에서 사용자 경험 우선 순위는 단일 또는 제한된 배치 크기에 대한 low-latency 추론에 중점을 둔다. 이것은 현재 GEMM 기반 솔루션의 두 가지 주요 문제를 나타낸다.

 

1) GEMM 기반 솔루션은 합성곱 연산을 GEMM에 매핑해야 하므로 계산과 메모리 모두에 오버헤드가 발생

## im2col 을 이용하여 맵핑 -> 메모리 오버헤드 , 맵핑과 GEMM 연산 및 메모리 할당 

## ( C의 경우 malloc / calloc ) 으로 인한 오버헤드를 말하는것 같음.

 

2) GEMM 기반 솔루션은 매핑하는 동안 데이터 재사용의 큰 기회를 잃어 주어진 하드웨어의 활용률이 낮음

## 메모리를 다시 할당하여 im2col을 진행하고 GEMM 연산 후 다시 데이터를 할당하는 과정으로 인해

## 기존 layer 를 통과한 데이터를 재사용하는것이 아님.

 

현재 GEMM 기반 솔루션에 대한 심층 분석을 통해 이러한 문제의 근본 원인을 파악하고 정확도의 변화 없이 앞서 언급한 문제를 극복한 mGEMM 을 제시한다. mGEMM은 기존의 알고리즘이 convolution 연산을 static GEMM 알고리즘으로 변환하는 데 비효율적인 반면, mGEMM은 오버헤드 없이 convolution 연산을 수용할 수 있도록 GEMM의 구조를 확장한다. 다양한 신경망 및 테스트 장치에 대한 광범위한 평가에서 mGEMM이 대기시간, 메모리 오버헤드, 에너지 소비 측면에서 기존 솔루션의 성능을 능가하는 것으로 보여진다. real-world application 실행 중, Yolo V3-Tiny object detection은 mGEMM을 사용 했을 때,  최신 기술에 비해 총 대기 시간과 합성곱 대기 시간에서 최대 1.29배와 1.58배 속도를 향상시켜 에너지 소비를 거의 최소 힢 메모리만 사용하면서 15.5% 줄였다.

 

INTRODUCTION

종종 합성곱 신경망(CNN)으로 표현되는 심층 신경망(DNN)은 이미지 분류[40], 객체 감지[38], 비디오 분석[22] 및 시계열 예측[51]과 같은 일반적인 추론 지향 문제뿐만 아니라 컴퓨터 비전 문제에 대한 다양한 학습 기반 솔루션의 기반이 되었다. 이러한 네트워크는 AlexNet[24]의 도입 이후 크게 개선되었으며, CNN 기반 솔루션이 상업적으로 배포되어 스마트폰, 자율 주행 차량 또는 산업용 IoT 장치와 같은 모바일 플랫폼을 사용하는 최종 소비자를 지원하는 단계에 이르렀다. 모바일 장치는 ARM CPU를 기반으로 하는 경우가 많은데, ARM CPU는 고성능 프로세서에 비해 전력 효율은 높지만 하드웨어 용량은 적다. 이와 같이, 합성곱 알고리즘의 빠르고 효율적인 구현은 최종 사용자에게 원활한 DNN 기반 서비스를 제공하는 데 있어 더욱 중요해지고 있다. 가능한 구현 중에서 GEMM(General Matrix Multiple) 기반 솔루션은 가장 널리 채택된 기술로 알려져 있다. 이러한 솔루션은 im2col(이미지 대 열)[5]와 같은 변환을 통해 conv tensor 를 행렬로 매핑하여 합성곱 연산을 행렬 곱셈 연산으로 효과적으로 변환한다. 이는 주어진 프로세서에 최적화된 BLAS(기본 선형 대수 하위 프로그램) 라이브러리에 의해 크게 가속될 수 있다[4, 21, 33, 50].

 

행렬 크기가 충분히 클 경우, 이러한 고도로 최적화된 GEMM은 기본 하드웨어를 쉽게 포화시켜 최대 계산 처리량을 달성할 수 있다. 이러한 대규모 행렬을 제공하기 위해 GEMM 기반 합성곱은 종종 워크로드를 일괄 처리하여 여러 이미지를 단일 대형 행렬로 매핑한다. 따라서 각 워크로드의 평균 처리 시간이 단축되지만 단일 워크로드의 완료 시간이 지연되어 이미지당 지연 시간이 길어진다.

 

이를 위해, 우리는 모바일 플랫폼의 특성을 고려할 때 현재의 GEMM 기반 합성곱 설계가 모바일을 위한 가장 효율적인 솔루션인지 의문을 제기한다. 우리가 아는 한 im2col+GEMM[5] 또는 implicit GEMM[34, 46]과 같은 기존 GEMM 기반 솔루션의 대부분은 고성능 프로세서를 통해 신경망 훈련 및 batch 추론과 같은 대규모 워크로드를 처리하기 위해 풍부한 계산 능력으로 높은 처리량을 달성하는 데 중점을 두었다. 기존 GEMM 기반 솔루션의 이러한 설계 목표는 배치 크기가 제한된 단일 이미지 또는 데이터에 대한 사용자 경험 우선 순위가 낮은 low-latency 추론에 있는 모바일 환경에서 예상되는 것과 극명한 대조를 보인다. 이 격차에 대한 우리의 관찰은 다음과 같이 모바일 최적화 GEMM 기술을 설계하는 데 두 가지 문제를 제기한다.

 

Minimizing the preprocessing overhead :

행렬 곱셈으로 합성곱을 매핑하려면 im2col과 같은 방법을 사용하여 텐서를 사전 처리해야 한다. 이러한 매핑 단계에는 데이터의 복제 및 재정렬이 필요하며, 이로 인해 계산 시간과 메모리 오버헤드가 발생한다. 특히 더 큰 워크로드를 처리할 때  메모리 대역폭과 용량이 더 큰 고성능 시스템에서 이러한 오버헤드는 주요 계산 루프에 비해 사소한 것으로 간주되어 왔다. 그러나 모바일 플랫폼에서 이러한 오버헤드는 특히 대기 시간에 중요한 추론을 할 때 갑자기 커진다. 우리는 나중에 모바일 추론을 실행할 때 이러한 오버헤드가 총 계산 시간의 최대 29%를 차지한다는 것을 보여준다.

 

Maximizing the data reuse rate :

섹션 2에서 보듯이, 합성곱 연산은 본질적으로 계산 루프 간에 많은 양의 데이터의 재사용을 포함하는 연산이다. 반면에 행렬 곱셈은 계산 횟수가 같을 때 데이터 재사용이 훨씬 적다. 따라서 기존의 GEMM 기반 솔루션은 불가피하게 매핑 프로세스 중에 데이터 재사용의 큰 기회를 잃을 수 밖에 없다. 이는 대규모 작업에 대한 training 이나 inference 시 심각한 문제가 되지 않는다. 의도적으로 배치 크기를 증가시켜 작업이 메모리에 국한되지 않고 계산에 종속되는 지점까지 데이터 재사용을 쉽게 늘릴 수 있다.  그러나 사용자에게 즉각적인 추론 서비스를 위해 배치 크기 1개를 휴대하는 경우가 많은 모바일 플랫폼에서는 이 전략이 적용되지 않는다. 제한된 메모리 대역폭과 결합하여 메모리 재사용의 비효율성으로 인해 기존의 GEMM 기반 솔루션은 모바일 플랫폼에서 메모리를 상당히 제한하게 된다. 

 

이러한 중요한 과제를 해결하기 위해 모바일 플랫폼에 맞게 조정된 짧은 대기 시간(즉, 낮은 입력당 대기 시간)과 최소 메모리 오버헤드에 중점을 둔 새로운 GEMM 기반 컨볼루션 솔루션인 mGEMM을 제안한다. 우리는 GEMM을 기반으로 설계를 하여 GEMM 알고리즘이 사용하는 기존 최적화 기술과 광범위한 하드웨어 지원을 활용할 수 있다. 주요 차이점은 mGEMM이 기존 솔루션의 비효율성의 근본 원인에 대한 우리의 관찰 결과를 활용한다는 것이다. 합성곱 연산의 필터 공간 차원은 행렬 곱셈에서 표현할 수 없다. 이러한 요소를 고려하여 static GEMM 커널로 강제 변환하지 않고 GEMM 커널에 적응 확장이 적용된 합성곱 차원을 적용한다. 이 접근법은 합성곱 계산에 필요한 메모리 footprint 와 메모리 접근을 크게 줄이면서 결과의 정확도는 영향을 받지 않는다. 모바일 메모리 시스템은 성능이 제한되고 SoC의 하드웨어에 의해 공유되기 때문에, 메모리 트래픽과 계산 공간을 줄이면 사용 중인 하드웨어에 관계없이 전체 시스템에 상당한 이점을 제공한다.

 

기성 모바일 플랫폼에서의 테스트로 이를 확인한다.

우리는 mGEMM의 구현이 메모리 바인딩 문제를 크게 개선하여 모바일 플랫폼, 특히 ARMv8 아키텍처에서 다양한 성능 메트릭의 효율성을 가져온다는 것을 발견했다. 비록 우리의 테스트는 CPU에서 수행되지만, 우리는 mGEMM의 이점이 GPU와 NPU와 같은 다른 모바일 하드웨어에도 적용될 수 있다고 믿는다. 이러한 하드웨어는 종종 CPU보다 높은 연산 한도를 가지고 있으며, mGEMM으로부터의 메모리 트래픽의 알고리즘적 감소는 이러한 하드웨어가 동일한 메모리 대역폭으로 더 높은 연산 속도에 도달할 수 있게 한다. mGEMM을 사용하는 것의 효율성의 사례는 ARM의 ARMNN[3] 및 Google의  XNNPACK[12]과 같은 최신 모바일 신경망 라이브러리와 비교하여 그림 1에 설명되어 있다.

 

그림 1

 

이 그림은 mGEMM 및 기타 GEMM 기반 솔루션을 사용하여 라즈베리 파이 4의 CPU에서 YoloV3-Tiny[38]를 실행하는 동안 발생하는 총 네트워크 지연 시간, 최대 힙 메모리 사용량 및 그에 따른 에너지 소비량을 나타낸다. 빨간색 점선은 YoloV3-Tiny를 실행하는 동안 모든 컨볼루션 계산을 건너뛰어 얻은 총 지연 시간과 메모리의 이상적인 수치를 나타낸다. ARMNN[3]의 두 번째로 빠른 방법과 비교하여 mGEMM은 총 대기 시간에서 1.29배, 컨볼루션 대기 시간에서 1.58배 속도를 달성하여 총 에너지 소비량을 15.5% 줄였다. mGEMM은 이상적인 사용량인 111.717MB보다 0.018MB만 더 많은 힙 공간 사용으로 이러한 탁월한 성능을 달성한다. 자세한 결과는 섹션 5에 나와 있다.

 

The main contributions of this paper are as follows:

 - 합성곱 계산 및 기존 GEMM 기반 솔루션의 깊이 분석, 모바일 플랫폼에서 기존 솔루션의 문제점을 나타냄.

 

 -  이전 GEMM 기반 방법의 한계를 극복하면서도 GEMM 알고리즘을 위해 집중적으로 개발된 기존 최적화와 하드웨어 지 원을 활용하는 새로운 컨볼루션 알고리즘(mGEMM)의 제안.

 

 - mGEMM에 대한 개념 증명은 다양한 기성 모바일 플랫폼에서 테스트된 실제 구현을 통해 최신 GEMM 기반 솔루션보다 성능이 향상되었음.

 

 

댓글