Protected: 20180213 – Research

This content is password protected. To view it please enter your password below:

Advertisements
Posted in 1) Memo

20180212

* ASPLOS 2018 TLB invalidation 관련 논문 한 번 읽어보기.
* Keynote의 의미는 뭘까?

sigarch-kr-4th_v2_페이지_1.png

1. Datacenter Trend & Memory Architecture, 임의철(SK 하이닉스)
ICT 서비스가 어떻게 바뀌고 있는지, 메모리 시스템은 어떻게 바뀌어야 하는지에 대해 이야기할 것. 최근 새로운 기술 트렌드가 등장하고 있음. 인공지능 비서, 자율주행 자동차 등. 이를 적용할 데이터가 충분해졌기 때문에 가능한 것. 이러한 데이터는 말단 기기들에서 가져와야 함. 이러한 적용 사례에서는 데이터 양이 상당하기 때문에, 메모리에서 직접 처리하는 것이 좋을 수 있음. “Every Minute of the Day” 라는 인포그래픽이 있음. 매 분 생성되는 데이터의 양이 상당히 증가하고 있음. “Data never sleeps”.

데이터 센터의 진화. Centralized Mainframe -> Distributed Computing -> Virtualized Datacenter. Centralized mainframe 수준에서는 large enterprise급 서버를 사용해 데이터센터 구축. Distributed computing에서는 x86 서버를 사용해 데이터센터를 구축함. 최근에는 가상 머신에서 data center를 구축함. Data center의 low utilization에 착안하여 가상 머신에서 deploy하게 됨. 하지만 이같은 시스템에서도 비효율성이 있음. 가상 머신도 서버 단위로 증설을 하게 되는데, 실제로는 더 fine-grained control이 필요할 수 있음 (단위 자원 수준에서의 control).

이러한 요구 사항이 등장함에 따라 Software-defined Data Center (SDDC)가 등장함. 필요한 만큼만 데이터를 뽑아서 사용하자라는 개념. 이상적으로는 가능하지만, 실제로는 되지 않는다. Pool of resources에서 일부 resource를 가져오는 방식으로 진행됨.

메모리 아키텍쳐는 어떻게 변화되어야 할 것인가?
첫째. 메모리 계층이 추가될 것이다. 스토리지는 느리고, DRAM은 너무 비싼데다 scaling에 한계도 있다. 이를 해결하기 위해서 추가 메모리 계층을 도입한다. SCM이라는 2nd-tier memory를 도입해야 한다. Persistent memory의 특성을 가진다.
둘째. Memory disaggregation이 발생할 것이다. 메인 메모리 아래에 pooled memory가 있고, pooled memory는 SCM이 들어간다. 그리고 메인 메모리와 pooled memory 사이에 interconnect가 들어가게 될 것이다. Pooled memory가 한 개의 독립적인 노드로 들어가는 그림을 예제로 보여줌. 하지만 pooled memory가 굳이 물리적으로 독립되어야 할 필요는 없다. 여러 개의 노드에 분산된 PCM이 있고, 이를 pooled memory로 사용될 수 있도록 해야 할 수도 있다.
셋째. Pooled memory 지원을 위한 소프트웨어 측면의 도움이 필요하다. 2nd-tier memory를 어떻게 사용할 것인가에 대한 고민이 필요함. 스왑 디바이스로 사용할 수 있지만, 이렇게 했을 때에는 성능이 그렇게 높아지지 않을 수 있다. 2-tier memory 솔루션을 어떻게 사용할 것인가에 대한 연구가 필요하다. Intel에서는 direct access mode를 지원하는데, 실제로는 사용하지 않을 것. 어플리케이션 레벨에서 이를 지원해야 하기 때문이다. 여러 개의 노드가 한 개의 pooled memory를 어떻게 공유해서 사용하고 관리할 것인가에 대해 연구가 필요함. 한 개의 서버가 master가 되어야 할 수도 있고, 여러 개의 노드가 분산된 방식으로 제어해야 할 수도 있을 것. Pooled memory이자 shared memory인 상황이 제공된다면 가장 이상적이다.

이러한 pooled memory가 제공되었을 때 어디에 사용할 수 있을 것인가?
첫째로 in-memory DB에 사용할 수 있을 것이다. 데이터베이스는 원래 스토리지에 올려뒀었는데, throughput을 높이기 위해 memory에 저장하게 됨. 이러한 경우에 volatile한 제약점을 해결하기 위해 주기적으로 logging을 수행한다. In-memory DB의 한계가 두 가지 있는데, DRAM의 물리적 확장 한계와 logging으로 인한 bottleneck이다. 이러한 in-memory DB를 pooled-memory에서 제공한다면 메모리 크기 제약을 해결할 수 있을 뿐 아니라, logging으로 인한 오버헤드도 상대적으로 줄일 수 있을 것이라고 기대할 수 있다. 기존 in-memory DB 아키텍쳐에서는 SSD에서 logging을 수행했는데, persistent memory를 사용한다면 상대적으로 더 좋은 성능을 누릴 수 있을 것.
두 번째 사용 예제로는 Memcached가 있을 수 있다. 웹 서비스에서 캐시를 갖고 있는데, pooled memory를 사용하면 memcached의 용량을 늘릴 수 있다. 서버 증설 없이도 pooled memory를 사용하면 성능 향상을 기대할 수 있다.
세 번째 예제로는 multi-tenancy를 더 잘 지원할 수 있다. 기존의 가상 머신 제공 상황에서는 CPU에 달린 메모리에 제약이 있기 때문에 VM overcommit ratio에 한계가 있다. 하지만 pooled-memory를 사용해서 더 많은 메모리를 사용할 수 있다면 더 높은 VM overcommit ratio를 제공할 수 있다. 상대적으로 적은 자원으로 더 많은 가상 머신을 만들 수 있을 것. DRAM의 성능은 상대적으로 떨어지겠지만, 더 많은 overcommit ratio를 제공할 수 있다면 이득이 될 것.

Heterogeneous memory architecture의 challenges.
(1) Fabric Overhead. long latency & BW limitation. Network congestion.
(2) Memory Management. 기존 메모리 관리 기법은 수십 기가 바이트 메모리 관리하였으나, 수십 테라바이트 관리 수준에서도 잘 동작할 것인가? (흥미로움)
– Memory Management의 scalability에 대해 연구하는 것도 의미가 있지 않을까?
(3) Heterogeneous Memory. 이종 메모리를 어떻게 관리할 것인가에 대한 문제가 됨. Persistent mode를 따로 가져갈 것인가? Locality & temperature에 대해 봐야 한다. DRAM은 데이터 유지를 위해서는 refresh가 계속되어야 하지만, pooled memory는 유지 위한 전력은 상대적으로 적게 든다.
(4) 그 외. 랙 디자인, 소프트웨어 디자인, 어플리케이션이 pooled-memory를 unaware한 상태에서 잘 사용할 수 있도록 하는 것.

Question. Pooled memory가 왜 등장해야 하는지 잘 모르겠다. 10년 전에도 disaggregated memory는 이야기가 되었지만, 잘 되지 않았다.
Answer. Storage class memory를 사용하는 것이 시장이 원하는 방향이라면 이쪽으로 끌고가고 싶다. 하이닉스에서는 메모리 트렌드를 이끌어본 적은 없지만, 이쪽으로 끌고 가보고 싶다.

Question. Pooled memory의 문제가 latency가 될 것이라고 보는데, 이를 해결하기 위한 프로토콜은 무엇인가?
Answer. Gen-Z가 가장 적합한 프로토콜이라고 보고 있다. Gen-Z 한 hop당 latency를 어떻게 줄일 수 있을 것인가에 대해 보고 있음.

Question. Pooled memory는 memory 중심 컴퓨팅과는 반대 방향인 것 같은데, 이 방향이 더 맞다고 생각하는 것인지?
Answer. In-memory processing 등에 대한 연구도 하고 있으나, 단기적으로는 프로세서 회사들이 헤게모니를 놓지 않으려 할 것. 따라서 프로세서 수정 없이 지원하는 것을 목표로 하고 있다.

Question. NVM 프로토콜 개발 관련 질문이었던 듯.
Answer. Non-deterministic 프로토콜에 대한 연구도 진행되고 있고 표준화도 되었다고 한 것 같음.

2. The Overview of Machine Learning Accelerator Architectures, 김대현(삼성전자 Research)
머신러닝 가속기가 어떤 방향으로 가고 있는지 이야기한다. 이미지 분류 등에서 딥 러닝 기술을 사용한 것이 우수한 성능을 보이고 있다. AI는 hot potato인데, dangerously hot potato라고 생각한다. Hot하긴 한데 손으로 잡을 수 없는 느낌이다. 가장 큰 이유는 딥러닝이 너무 비싸다는 것이다. 산업계에서 보기에는 딥러닝이 정말 cash cow인지 아니면 tax collector인지 모르겠다는 이야기가 있음. 현실적인 장벽을 고려해야 한다는 점을 이야기하고 싶었다.

최근 머신러닝 연구가 많이 진행되고 있다. DianNao에서 시작해 Cambricon까지, EIE에서 시작해 ESE까지, Cnvlution, Eyeriss 등의 연구가 진행되고 있음. 먼저 DianNao family에 대해 간단히 소개하고자 한다. 중국이 딥 러닝을 잘 하고 있음. DianNao 공동저자로 Olivier가 있는데, Google에서 TPU를 연구하고 있음. 최근에 Cambricon을 spin-off해서 회사를 설립함. 가장 먼저 나온 논문이 DianNao인데, 여기에서는 뉴럴 넷을 그대로 아키텍쳐로 옮겼다고 볼 수 있음. 뉴럴 연산을 수십만번 반복하는 방식으로 설계함. DianNao 아키텍쳐는 뉴럴 넷 공식을 그대로 아키텍쳐로 옮겨두었다고 볼 수 있음. 곱셈-덧셈-nonlinear function-output buffer에 넣기-input 버퍼에 넣기의 순서를 계속해서 반복한다. 그 다음으로 나온 논문이 ShiDianNao인데, 여기에서는 몇 가지 optimization을 수행한다. 비전 워크로드 가속을 위해 2d structure를 사용해서 CNN에 최적화한다. 다음으로는 Cambricon-X. 행렬 연산에 0이 많다는 점에 착안하여 성능 향상을 시도한다. Non-zero만 찾아내서 계산한다. Non-zero 인덱스를 관리하기 위한 구조를 가진다.

그 다음으로는 Deephi 계열을 살펴보고자 한다. Dally라는 NVIDIA의 유명한 연구자가 공저자로 들어가있다. 학계이지만 실제로는 인더스트리와 긴밀하게 연관되어 있다는 것을 확인할 수 있다. 논문은 그리 많지 않지만, 최근 FPGA’17에 나온 ESE가 가장 앞서있다고 할 수 있다. Han의 접근은 SW-HW를 함께 설계하고자 시도한다. Deephi에서는 sparsity를 중요하게 활용하고자 한다. 곱에서는 0을 무시해도 되므로, sparsity를 활용하여 90% 이상의 연산을 제거한다. Weight value가 0을 중심으로 분포되어 있는데, 0에 가까운 값을 무시하고 나머지 값만 남겨서 활용한다. 아키텍쳐가 훨씬 효율적이게 될 수 있다. Sparsity를 어떻게 활용할 것인지가 아키텍쳐에서 화두가 되고 있다. EIE에서는 non-zero detection이 중요해지고 있다. Input/weight 모두 non-zero인 경우에만 연산하는 것이 목표라고 볼 수 있다.

두 가지 family를 보았을 때 가장 중요한 개념은 quantizationpruning이라고 할 수 있음.
(1) Quantization은 floating point의 데이터 오버헤드를 줄이는 것. 32bit->16bit->binary까지 내려보고 있다. 많은 경우에 딥 러닝 연산이 approximate 가능하기 때문에 이를 활용하고 있음. 초기에 상당히 많이 연구되었던 부분이다.
(2) Pruning은 weight이 non-zero일 때에만 사용하겠다는 것. 크게 weight sparsity / activation sparsity 등이 있음.

이 두 가지 개념을 통해 가져가고자 하는 것은 (1) computation saving, (2) memory size & BW saving이다. 아키텍쳐 수준에서 sparsity를 지원하는 것이 중요함을 실험 결과를 통해 보여줌.
사업에서는 레드 오션이 아닐까 하는 생각도 듦. 이전에는 딥 러닝 컴퓨팅 개발을 위해서 스타트업을 찾아 나서야 했으나, 최근에는 너무 많은 스타트업이 연락을 주고 있다. 중요한 것은 정말 많은 회사들이 이미 업계에 존재하고 있다는 점이다(정말 많은 것 같다. 이렇게까지 이야기하는 것을 보면). Cambricon, Deephi, Graphcore, Wave Computing, Intel, NVidia, Qualcomm, Apple, Google, Microsoft, Amazon… NVidia에서는 Xavier라는 자율주행용 가속기를 만들고 있음. 구글이 왜 TPU를 개발했을까? GPU가 너무 비싸서가 가장 정확한 이유라고 함.
미래 트렌드는 어떻게 될 것인가? 알고리즘이 어떻게 발전하고 있는지를 봐야 한다. 결국에는 application-specific accelerator이다. Fully-connected NN으로 시작했다가, CNN-RNN까지 확장되고 있다. 미래는 어디로 갈 것인가? 발표자의 생각일 뿐인데, 메모리 네트워크로 갈 것 같다. 메모리와 연산 두 방향으로 나뉘어져있다고 한다면, 메모리쪽으로 갈 것. End-toEnd Intelligent Assistant가 될 것이고, 따라서 메모리가 중요하다.

기술 트렌드 측면에서는 analog circuit 기술 쪽 접근을 수행하고자 하고 있음. Analog circuit을 활용한다면 적은 연산 오버헤드로 같은 연산을 수행할 수 있음. 발표자는 FPGA와 ASIC 사이의 어딘가에서 가속기가 위치하게 될 것이라고 생각함. 인공지능 엔진을 클라우드에서 임베디드로 옮기고자 하고 있는데, 전체 다를 옮길 수는 없을 것 같다. 클라우드와 임베디드 사이에서 연산을 수행하는 것에 대해서도 연구가 진행되고 있음. 발표자의 개인적인 의견으로는 세 부분 모두에서 AI 엔진이 진행될 것 같음.
Hardware Architectures for DNN tutorial, Efficient Processing of Deep Neural Network를 추천함!

Question. 딥 러닝에서 flexibility를 가져야 하는 부분이 어디인가?
Answer. Overview는 간단하지만, CNN에서 filter size가 바뀐다거나 stride가 바뀌는 경우가 많고, 이들이 상당히 성능에 중요하다. Corner case가 중요함. FPGA를 사용하면 상품 개발까지의 시간이 훨씬 단축된다.

Question. 딥 러닝의 수익성은 어떤가?
Answer. 딥 러닝이 상품 판매에 크게 도움이 되지 않을 수 있지만, 그렇다고 버릴 수는 없는 입장이다. 기회를 본다면 투자할 가치가 있다고 생각한다. 단기적으로는 스마트폰 판매량에 도움이 되지 않을 것. 시장이 커지지 않으므로. 하지만 경쟁사가 인공지능 기능을 넣는 상황에서 이를 빼놓을 수는 없다.

구글은 어플리케이션을 모두 알고 있고, 어플리케이션에 필요한 것을 직접 넣을 수 있다. 기업 입장에서 가장 중요한 것은 어떤 어플리케이션을 쓰는지이다. CNN쪽 연구가 많은데, 실제로는 CNN을 사용하는 경우가 많지는 않다. 구글은 정확하게 필요한 것을 보고 그것을 만들었다.

3. TWiCe: Time Window Counter-Based Row Refresh to Prevent Row Hammering, 안정호(서울대학교)
Meltdown, Spectre. 이 두 가지 공격이 컴퓨터 아키텍쳐에 기반하고 있다. Row hammering에 대해 간단히 알아보자. DRAM에서는 cell에 데이터를 저장한다. Cell에 charge가 얼마나 들어있느냐에 따라 저장된 값이 달리 해석된다. DRAM은 leaky하므로 charge가 시간에 따라 사라진다. 따라서 주기적인 refresh가 필요하다 (64 micro seconds). 이 때마다 refresh하지 않는다면 데이터를 잃게 된다. 10억개의 cell을 한 순간에 refresh하려면 너무 많은 에너지가 필요하고, refresh는 row group 단위로 발생한다. Row-hammering은 특정한 DRAM row를 계속적으로 activate시키다보면 주변 row의 값이 변경되는 현상을 이야기한다. 회사에서는 이미 알고 있던 내용이었다. 중요한 점은 데이터 변조가 발생한다는 점인데, 이 특징을 사용해서 compromise할 수 있다는 점이다.

이러한 row hammering을 해결하기 위해 refresh를 더 자주하는 것이 해결책이 될 수 있다. 성능은 떨어지지만 보안 문제를 해결할 수 있음. 가장 간단한 솔루션은 row activate할 때마다 counting을 하는 것. 특정 row가 집중적으로 접근될 때 (특정 row의 counter가 집중적으로 오를 때) 공격당하고 있다고 판단할 수 있다. 이것의 가장 큰 문제점은 row마다 counter를 가져야 한다는 점이다. 메모리 컨트롤러 안에 카운터를 넣는다면 1GB bank에 131,072 on-chip counter가 필요하게 된다 (높은 area cost). DRAM에 카운터를 넣는다면 카운터를 접근하기 위해 DRAM을 다시 접근해야 한다는 문제점이 있다. Counter-based row activation에서는 locality에 착안하여 카운터를 활용함.

Counter-based tree architecture도 제안되었음. 자주 접근되는 영역에 대해서는 더욱 조밀하게 사용하는 것이다. 좋은 솔루션인 것처럼 보이지만, 코너 케이스가 있다. Row hammering을 해결하기 위해 activation할 때, 주기적으로 주변의 row를 active하고자 하는 연구가 있었음.

여기서 제안하는 시스템인 TWiCe에서는 적은 오버헤드로 row hammering을 해결하는 것이 목표. 하나의 카운터는 하나의 row를 counting한다. 자주 접근되는 row에 대해서만 counting을 하자는 것이 핵심 아이디어. Row hammering은 아주 많은 접근을 해야만 옆의 데이터가 flip된다 (적어도 10만번). tREFW 이내에서 9 번의 접근만 확인할 수 있다면 문제 해결이 가능하다. Activate 되어 있을 때에만 counter를 유지한다. 모든 active된 row를 유지하지 않더라도 false negative 없이 row hammering을 해결할 수 있다. 수학적인 모델링을 통해서 이를 보여준다.

Question. ECC가 있는 경우에는 공격이 잘 안 된다고 들었는데, 그 경우에도 문제가 되는가?
Answer. ECC가 있다고 하더라도 coding에서 벗어난다면 해결될 수 있다. ECC가 mitigation technique은 아니다. 한 bit flip은 될 수 있지만, 여러 bit flip은 해결할 수 없을 수 있다.

4. Virtual Memory for Heterogeneous Memory, 허재혁(KAIST)
시스템에 장착된 메모리 크기가 늘어나고 있다. 메모리가 flat한 구조를 갖기보다는 이종성을 갖게 되고 있다. 가상 메모리가 왜 문제가 되느냐? 물리적인 메모리를 그대로 사용할 수는 없으므로, 가상 메모리를 통해야만 한다. 컴퓨터 시스템 연구가 발명한 것 중에 중요한 것 중 하나. 가상 메모리는 기본적으로 indirection이다. 가상 주소를 물리 주소까지 바꾸는 indirection. 주소 변환 과정에서 translation을 위해 caching architecture인 TLB가 있음. 매핑 변경 과정에서는 TLB shootdown이 발생한다.

한 가지 문제로 TLB scalability issue가 있음. Intel에서 L2 TLB size를 1000개 이상으로 늘리면서 많이 해결된 문제인다, 대용량 워크로드를 실행할 때 상당 시간을 주소 변환에 사용된다는 것을 확인하였음. 가상 메모리를 위해 아키텍쳐 연구가 진행되고 있음. 2000년대 중반이 되면서 가상화가 되었을 때의 가상 주소 변환 오버헤드를 해결하기 위한 연구가 진행됨. 다음으로 메모리 크기가 커질 때, TLB coverage를 어떻게 향상할 것인가에 대한 연구가 진행됨. 셋째로 메모리 이종성을 어떻게 지원할 것인지에 대한 연구가 진행됨. 넷째로 이종 컴퓨팅 환경에서 어떻게 주소 변환을 지원해줄 것인가에 대해 이야기가 진행됨.

TLB coverage를 향상하는 부분, 이종 메모리의 주소 변환을 지원하는 것에 대해 이야기할 것. 먼저 TLB coverage를 향상하기 위해 어떻게 할 것인지에 대해 이야기할 것. 첫 번째로는 large page를 사용하자는 것. 하지만 strict alignment, Size match 제약 등이 있음. OSDI 논문에 따르면 large page 할당에 문제가 있다고 함(fairness..). 이를 해결하기 위해 하드웨어 측면 연구가 진행됨. Coalesced TLB가 있음. 연속된 매핑 영역이 있으면 CoLT가 이를 그룹지어서 변환해줄 수 있도록 하는 것. Buddy allocator가 연속된 공간을 할당하면 coalesced TLB가 이를 묶어준다. 다음으로 cluster TLB가 있었음. 그 다음으로는 direct segment가 있었음. 큰 연속된 공간을 segment로 할당해 사용하자는 것. 이종 메모리 환경에서는 TLB 성능 향상을 위해서는 coverage를 높여야 하지만, heterogeneous memory 이용을 위해서는 작은 단위로 관리해야만 한다. 이를 해결하기 위해 hybrid TLB coalescing을 제안함. TLB coverage를 SW 측면에서 변경하도록 하는 것. 페이지 테이블의 일정 단위마다 anchor라는 것을 넣고, 연속성을 coding한다. L1 TLB miss가 발생하면 L2 TLB 접근시에 anchor TLB를 확인해 주소 변환을 수행하도록 한다. 이러한 시스템에서는 anchor coverage를 어떻게 조절하느냐에 대해 운영체제가 결정해주어야만 한다.
다음으로 virtual caching을 사용하고자 하는 시도도 해보았음. 매번 주소 변환을 할 필요가 없다는 장점이 있다. L3 크기가 워낙 크다 보니, TLB의 coverage를 벗어나는 경우가 있다. TLB miss가 발생했을 때에도 cache에 데이터가 존재하는 경우가 있음. 하지만 virtual caching은 synonym problem이 있는데, 한 개의 물리 주소가 서로 다른 가상 주소에 의해 공유될 때 문제가 발생할 수 있음. Hybrid virtual caching은 synonym filter를 사용해서 synonym이라면 traditional translation을 수행하고, synonym이 아니면 virtual caching을 사용하도록 한다.

다음으로 heterogeneous memory management 문제도 있음. 이종 메모리 환경에서의 성능 향상을 위해 연구가 진행되고 있다. Large page를 쓰는 경우에 현재 상황에서 어디가 사용되고 있는지 알 방법이 없음. Large page내에서 어떤 페이지가 접근되는지 확인하기 위해 Thermostat이 제안됨. Sampling을 사용해서 쪼갠 뒤 얼마나 접근되는지 확인하는 방법. 다음으로 NVM의 object translation을 수행한 연구. NVM을 사용할 때 memory persistency를 제공하는 것이 의미가 있어짐. Object마다 ID 주소를 갖게 하고, 이를 사용해 메모리에 접근하도록 하는 것. OID – VA – PA의 단계가 됨. 이를 변환하기 위한 아키텍쳐를 제안함. 다음으로 LATR에 대한 소개. 멀티 코어 시스템에서는 page table update할 때 tlb invalidation이 발생하는데, TLB invalidation이 expensive하다. 따라서 이를 해결하기 위해 lazy reclaim을 수행한다.
클래식한 문제라 하더라도 환경이 변화하면 풀어야 할 문제가 있을 수 있다.

Question. Simulation 환경을 어떻게 쓰고 있는가?
Answer. TLB에 대한 시뮬레이션이 모델링이 잘 되어있지 않은 경우가 있다. Real machine에서 실험해서 modeling을 하기도 하고, badger trap을 사용할 수도 있다.

Question. Huge page가 linux system에 들어왔는데, 여기에 시간이 오래 걸렸음. 최근 연구되고 있는 것들도 오래 걸리고 있는 건 아닌가?
Answer. 아무래도 실제 시스템에 도입되기까지엔 오래 시간이 걸림. Thermostat이 아직 의미를 갖지 못한 이유는 이종 메모리 시스템이 없기 때문인 듯 하다. 이후에 도입이 되면 Thermostat이 실제로 적용될 수 있을 것이라 생각함.

Question. 소개해준 연구 방향이 translation 단위를 늘림으로써 translation 오버헤드를 줄이고자 하는 것들이었음. Fine-grained management의 장점을 살릴 수 있는게 좋지 않은지?(deduplication, low fragmentation…)
Answer. 상대적으로 메모리가 저렴한 자원으로 인지되고 있기 때문에, 메모리 손해를 보고 성능을 향상시키고자 하는 것이 아닌지?

5. Performance Modeling for Real-World Computer Systems, 김장우(서울대학교)
실제 시스템을 어떻게 모델링을 해야 하는지에 대한 연구 소개. 우리는 실험이 정확한지 잘 모르고, 관심도 없는 것이 대부분이다. 하지만 회사에서는 중요한 문제이다. 시뮬레이션을 바탕으로 판단을 수행하므로, 시뮬레이션의 정확도는 상당히 중요하다. 예측했던 성능이 나오지 않으면 상당한 자원 손해가 발생함 (프로세서 개발에 4년 정도의 시간이 걸리는데). 시뮬레이션은 정확하고 빨라야 하며, 저렴해야 한다. 세 가지 요구사항이 상충한다. 실제로 회사에서는 성능 비교하는 연구자의 수가 아키텍쳐 개발하는 연구자의 수보다 많다. 회사에서는 3%의 성능 개선이라도 나오면 좋은 상황이다. 시뮬레이션이 어려운 이유? 시뮬레이터를 만들기 위해서는 하드웨어와 소프트웨어를 모두 알아야 하기 때문. 모두 알고 있는 상태에서 불필요해보이는 것을 추상화해서 빠르게 만들어야 한다. 하드웨어 복잡도는 계속해서 증가하고 있는데, 시뮬레이터는 많이 없다. 워크로드도 계속해서 바뀌고 있다. SPEC 아닌 대용량 워크로드가 실행되어야 함(CloudSuite). 이런 시뮬레이션은 더욱 어려운데, 운영체제가 들어가야 하기 때문이다.

Simulation speed / simulator accuracy / workload accuracy / modeling cost 등에 대해 연구를 진행하고 있음. 먼저 fast CPU performance modeling에 대해 이야기할 것. 디자인 평가 프로세스를 어떻게 빠르게 할 수 있을 것인가? RpStacks. 명령어의 의존성과 실행 시간을 기록해두면 실행 시간을 확인할 수 있다(critical path). 특정 오버헤드가 빠졌을 때 얼마나 성능이 향상되는지를 평가한다.

다음으로 accurate simulator modeling 연구에 대해 소개. I Don’t Believe Your Simulator라고 제목을 썼더니 자꾸 떨어졌음. DiagSim으로 제목을 변경함. 시뮬레이션은 더욱 복잡해지는데, 시뮬레이션은 parameter에 민감하게 성능이 변화함. 실제 회사에서는 프로세서의 validation을 위해 issue queue 크기를 확인하기 위한 코드를 실행하곤 함. 이와 같은 방식을 시뮬레이터에 적용하고자 하는 것이 DiagSim. Load-to-Used는 메모리에서 데이터를 가져왔을 때 명령어가 해당 데이터를 사용할 수 있을 때까지의 cycle을 의미함. 이를 통해 architectural parameter를 예측할 수 있음.

gem5에서 상당한 버그를 확인할 수 있었다. Physical register의 수, BTB size, latency 등이 달라질 수 있음. 정말 정확하게 평가하려면, 시뮬레이터에 대해 평가를 해야 함.
Accurate workload modeling도 중요함. StressRight에서는 워크로드에 얼마나 많은 thread를 생성해야 하는지에 대해 연구한 것. Stress를 증가시킬 때 latency와 throughput의 변화를 보면 특정 지점부터 saturation이 발생함. Ideal하게는 시뮬레이터도 워크로드도 직접 만들어서 tuning해야 함. 회사에서는 워크로드를 functional model로 만듦. QEMU와 같은 것. Simics가 이러한 기능을 잘 만들어 줌. Timing model을 집어넣은 튜닝을 해야 한다. 실행 중에 정확하게 모델링하고, 반복되는 패턴은 묶어냄.

Low-cost datacenter modeling. 구글에서 실제로 사용하는 연구 결과. Datacenter에서 성능 측정이 어려운 문제이다. 클러스터에 CPU를 더 넣었을 때 성능이 얼마나 향상될지 모름. 투자를 해야하는지 아닌지 알 수가 없음. Live WSC evaluation은 expensive하고 risky하다. Workload sizing은 회사 입장에서 중요한 문제이다. 워크로드가 죽어서도 안 되고, 정확하게 하자니 너무 많은 비용이 듦. 이러한 문제를 해결할 수 있는 솔루션이 지금까지 없었다. Homogeneous machine으로 구성한 클러스터에서도 인스턴스마다 throughput이 크게 다름. 평균 성능은 일정해보이지만, 편차가 있음. 워크로드를 특정해서 잡기도, 머신을 특정해서 잡기도 어려움. 몇 가지 observation. (1) 중요한 워크로드가 많지 않고, 이들이 대부분의 utilization을 차지함. (2) CPU 점유율을 의미있는 metric으로 잡음. (3) 그리고 작은 클러스터 크기를 변화시켜가며 statistical confidence를 얻어냄 (central limit theorem 활용). 100개의 머신만을 사용해서 6.5%의 성능 향상을 +- 3% error로 평가해낼 수 있음. 구글에서 WSMeter로 쓰고 있음. Heterogeneous 환경으로 확장하고자 하고 있음.

Question. 회사 입장에서는 baremetal 성능 향상이 중요한 것이 아니다. 사용자 수준의 성능이 더 중요하다. 시뮬레이터 성능이 아주 정확한게 인더스트리 측면에서 중요하지 않다.
Answer. 다른 연구라고 생각한다. 시뮬레이터를 정확하게 만드는 것이 중요한 곳이 있고(인텔), 그 외에서는 중요하지 않을 수 있다. 정성우 교수님의 답변. 정확도가 중요할 수 있다. 어떤 configuration A가 B보다 실제로 좋은데 simulation에서 반대의 결과를 내면 잘못된 결론을 낼 수 있으므로, 중요하다.

Question. spec 벤치마크에 대해 negative하게 이야기해주셨지만, 실제로는 좋은 벤치마크이다. 벤치마크가 어떤 의미가 있는지 알고 사용하는 것이 중요하다.

6. High-Performance Computing(HPC) Systems for Scalable and Energy-Efficient Deep Learning, 유민수(포항공대)
SCNN에 대해 발표할 것. 딥 러닝이 실제 제품들에 적용되고 있는데, 알고리즘 뿐 아니라 아키텍쳐 연구도 필요함. Convolution 연산은 입력에 convolution filter를 dot product하는 것. Activation과 weight에 0값이 많다 (high sparsity). Convolution에서 sparsity가 높으면 효율적으로 연산할 수 있다(저전력, 고성능). Sliding window를 사용한 연산 과정에서 nonzero 위치를 확인하고, 연산을 제외할 수 있다. 하지만 이같은 방식에서는 연산 유닛이 충분히 활용되지 못할 수 있다. SCNN에서는 weights, activation에 대한 zero-skipping을 수행하면서, sliding-window 방식이 아닌 cartesian product를 사용한다. 최종적으로 해야하는 연산은 non-zero 값끼리의 곱. SCNN에서는 데이터를 재정렬하여, 연산 유닛을 최대한 활용하도록 해서 한 번에 계산한다. SCNN 아키텍쳐에 대한 소개. 2D spatially arranged processing elements로 구성하고, 각각의 PE는 CNN model을 갖는다. PE가 각각 갖는 이유는 모델을 압축하면 크기가 크지 않기 때문이다. SCNN PE microarchitecture는 크게 PE backend / frontend로 나뉜다. Evaluation. 뉴럴 넷 모델은 실제로 학습을 통해 얻어냄. DCNN / DCNN-opt / SCNN을 평가함. 아키텍쳐 시뮬레이터로 성능 평가해봤더니 실험에서는 최대 15배 성능이었지만, 실제로는 50% 정도의 성능 향상밖에 없음. 시뮬레이션은 적은 자원 투입만으로 아키텍쳐의 개발 필요/불필요를 판단할 수 있음 (절약).

Question. 실험한 워크로드(뉴럴 넷)가 어떤 것이었나? 최신 뉴럴 넷의 sparsity도 이와 같은가? 활용할 수 있는가?
Answer. HPCA에 sparsity를 분석해서 낸 논문이 있음. 회사에서는 최신 뉴럴 넷을 사용하진 못했음.

일반적으로 simple한 아이디어가 가장 효율적이다. CNN의 sparsity가 60%, RNN의 sparsity가 80-90% 정도 됨. Sparsity가 생각보다 높지 않은 경우도 있나봄.

Posted in 1) Memo

Protected: 20180207 – Research

This content is password protected. To view it please enter your password below:

Posted in 1) Memo

Protected: 20180206 – Research

This content is password protected. To view it please enter your password below:

Posted in 1) Memo

Protected: 20180205 – Research

This content is password protected. To view it please enter your password below:

Posted in 1) Memo

Protected: 20180204 – Research

This content is password protected. To view it please enter your password below:

Posted in 1) Memo

Protected: 20180203 – Research

This content is password protected. To view it please enter your password below:

Posted in 1) Memo
누적 방문자 수
  • 110,113 hits