20180116

2018 컴퓨터 시스템 소사이어티 동계술대회 참석
High-Performance Computing (HPC) Systems for Scalable and Energy-Efficient Deep Learning
딥 러닝이 HPC에서 새로운 문제가 되고 있음. 딥 러닝 어플리케이션 성능 향상을 위해 HW-SW co-design에 대해 연구하고 있음. GPU가 시장을 장악해나가고 있음. 왜 GPU가 딥 러닝에 사용되고 있는가? CPU는 latency-optimized, GPU는 throughput-optimized processor 이다. 시장에서 사용할 수 있는 프로세서 중에서 GPU가 가장 적합하다. Training은 작업 집합이 크기 때문에, GPU가 가장 적합하다. 하지만 inference는 GPU보다는 다른 프로세서가 적합하다. Baidu의 AI 팀에게 필요한 것은 GPU 연산 능력의 향상이 아닌, 메모리 크기의 증가. Dense net의 경우에는 layer 수 N에 대해 메모리 사용량이 O(N^2)로 증가함. 이러한 메모리 사용량 증가 문제를 해결하기 위해 본 연구에서는 vDNN을 제안함. 기존 CPU에서의 메모리 가상화 기능을 GPU로 가져오겠다는 것. 기존 CPU-GPU 메모리 가상화를 쓰지 않는 이유? 너무 느리기 때문이다. 데이터를 CPU 메모리에 저장하려면 PCIe를 통해 데이터를 저장해야 함. 4KB page migration에 20~50microsec 소요됨. PCIe bandwidth가 200MB/sec 정도 나옴. 하지만 실제 딥 러닝 과정에서는 수십 GB의 메모리 할당이 필요함. vDNN에서의 motivation. Forward propagation에 사용된 gradient는 backward propagation에 사용됨. 이로 인해 forward propagation에 사용된 데이터를 버리지 못하고, 이것이 메모리 사용량의 증대를 유발함. vDNN에서는 GPU 메모리를 가상화해서 사용하도록 함으로써, GPU 메모리를 가상 메모리의 캐시로 사용하도록 함. 뉴럴 넷의 그래프 정보를 바탕으로 어떤 레이어를 언제 가져올 것인지 결정에 활용함. vDNN은 기존의 page migration 기반 학습보다 3%의 성능 향상이 있었음. GPU 메모리 사용량의 90%를 줄임. 모든 NVIDIA GPU 카드에서 실행 가능함.


Processing in Memory: Opportunities and Challenges
Processor-memory performance gap이 계속해서 증가하고 있다(Hennessy and Patterson). 2000년대 이후로 어떻게 상황이 변화했나? Transistor density는 지속적으로 증가하고 있음. 2000년대 중반에 Dennard scaling이 끝남. 이전까지는 Dennard scaling에 따라 operating voltage가 지속적으로 낮아졌었으나, 지금은 Denard scaling이 안 됨. Clock frequency가 2000년대 이후로 크게 증가하지 못함. 공냉식으로는 clock frequency를 추가로 높이지 못함. CPU-memory performance gap이 줄어들고 있음. Memory의 성능은 지속적으로 증가하고 있지만, processor 성능은 크게 증가하지 못하고 있음. Thread performance를 증가시키지 못하니, thread의 수를 증가시키고 있고 이것의 extreme이 GPU가 됨. 멀티 프로세싱을 고려한다면 코어 당 메모리 성능은 크게 저하되고 있음. 따라서 메모리 대역폭을 충분히 늘림으로써 코어에 충분한 데이터를 제공해주는 것이 필요하다. 지금까지 DRAM 산업에서는 비트 당 비용을 줄이는 방식으로 개선되어왔음. 셀 수가 증가함에 의해 bit line이 늘어나고, 이에 따라서 latency는 느려짐. 코어 수가 계속해서 증가하고 있으므로 대역폭을 증가시키는 것이 중요함. 코어의 수는 빠르게 증가하지만, 메모리 양은 크게 증가하지 못하고 있으므로, 코어 당 메모리는 계속해서 줄어들고 있음. 연산에 사용되는 에너지보다 데이터 이동에 사용되는 에너지가 더 크다 (중요한 듯? 계속해서 언급되고 있는 내용). DRAM scaling에 따라서 referesh를 이전에 비해 더 자주 해주어야 되게 됨. 따라서 이러한 문제를 해결하기 위해 NVM으로 대세가 이동하고 있음. Processing-in-memory(PIM)는 90년대부터 이야기되던 내용. 80-90년대에는 DDR 인터페이스가 더 중요했었기 때문에, 잠시 주목만 받고 더 진행되지 못함. Scaling이 잘 되던 시대이기 때문에 scaling만 하면 됨. 3D stacking이 가능해짐에 따라 PIM이 다시 주목받게 됨. HBM/HMC가 있는데, HBM쪽으로 가는 것처럼 보임. 3D-stacked memory를 사용하는 방식은 다양함. 간단한 연산은 코어로 가져오지 않고 바로 처리하려 하는 것이 HMC를 사용한 방식인 듯. HBM과 기존 DRAM을 비교해보면 10배 정도의 대역폭을 제공하는 것으로 보임. HBM은 낮은 frequency와 voltage에서도 동작한다. PIM은 네 가지로 구분해볼 수 있음. Non-computational / bounded operands / compound operations / programmable. 궁금하다면 관련 논문이 있으면 찾아보기. PIM의 여러 문제점이 있는데, 첫째로는 cache coherence 문제가 있음. Cache에도 데이터가 존재하고 메모리에도 존재한다면 어떻게 할 것인가? Cache flushing을 한 다음에 PIM에서 연산 수행할 수도 있고, cache coherence protocol을 사용할 수도 있음. PIM에서 가상 주소 변환을 어떻게 해결할 것인가의 문제가 있음. 페이지 폴트가 발생하면 CPU에서 이것이 처리가 되어야 하는데, 병렬적으로 PIM이 사용되지 못하고 CPU로 계속 컨트롤이 넘어가게 됨. 프로그래밍 모델도 문제이다. 어떤 방식으로 PIM을 사용할 수 있도록 할 것인가? PIM을 사용해 domain-specific computing을 하고자 함. PIM을 뉴럴 넷에 사용할 수 있나? Capacity 문제를 어떻게 해결할 것인지가 문제이다.


Security Analytics of Container Clouds
Container 수준의 보안을 이야기하려 함. 실제 산업계에서는 컨테이너를 많이 사용하고 있음. 가상화 클라우드는 지고 있고, 컨테이너 클라우드는 뜨고 있음. 구글은 이전부터 내부적으로 컨테이너를 사용했었고, 최근에 공개함. 컨테이너를 사용하면 개발해서 deploy까지 걸리는 시간을 줄일 수 있음. 하지만 보안 문제가 있음. 컨테이너를 사용했을 때의 가장 큰 문제는 보안. 어이없을 정도의 보안 문제가 있음. Isolation이 잘 되지 않는다는 점도 문제이다. Unikernel을 사용해서 isolation 수준을 높이려는 시도도 있음. 실제 현실 컨테이너에서 어떤 보안 문제가 있는지 확인하고 공유하고자 함. Compliance rule을 따르는지 검사한다. 패키지가 제대로 패치되었는지 검사한다.


Accelerating Critical OS Services in Virtualized Systems with Flexible Micro-sliced Cores
하이퍼바이저 프로세서 관리에 대한 연구. 컴퓨팅 자원의 효율성을 높이고자 하는 연구가 지속되어왔음. 여러 대의 가상 머신을 하나의 물리 머신에 통합해서 운영 비용을 줄이고자 하고 있음. 여러 대의 가상 머신을 하나의 물리 머신에 통합함으로써 사용률을 높일 수 있음. 하지만 가상 머신의 입장에서는 자원을 경쟁해서 사용해야하기 때문에 성능이 떨어짐. 다양한 자원 중에서도 CPU 공유에서 발생하는 문제에 대해 초점을 맞춰 연구를 진행함. 시분할 방식으로 CPU를 공유해 사용하게 됨. vCPU에 인터럽트가 발생하면 스케쥴 될 때까지 처리가 되지 않을 수 있음. 이러한 문제는 요즘의 가상화된 시스템에서 많이 해결되었으나, 여전히 문제가 되고 있음. 그 다음으로 락 동기화 문제가 있음. 락 경쟁으로 인해 성능 저하가 발생할 수 있음. vCPU가 선점된 락을 계속해서 대기해야 할 수 있음. 이러한 문제를 해결하기 위해 소프트웨어와 하드웨어에서 여러 기법을 사용하고 있음. SW에서는 yield 기법을 사용하고 있음. 일정 시간동안 특정 이벤트를 오래 기다리면 그냥 자신의 runtime을 양보하는 것. 무의미한 일을 하지 않고 다른 프로세스들이 자원을 쓸 수 있도록 함. 하드웨어 수준에서는 pause-loop exiting을 제공함. Yield하는 시점에 어디를 실행하고 있는지 RIP를 보고 파악함(심볼 테이블과 결합). Yield exception handler에 xentrace를 사용해 트레이스를 추출하고, yield의 원인을 파악함. Systemtap을 사용하면 TLB synchronization이 지연됨을 확인할 수 있음. Turn around time은 (vCPU 갯수 – 1) * time slice가 되는데, time slice를 줄이면 turn around time을 줄일 수 있음. 하지만 architectural component의 오버헤드가 발생함. 따라서 이를 해결하기 위해 shortened time slice group을 두고 여기에 critical component를 스케쥴링한다. Microsliced core group의 core 수 또한 동적으로 조절한다.


How to survive in the era of AI
정말로 연구비가 인공지능으로 몰리고 있나? 좋은 소식은 컴퓨터 시스템이 항상 높은 수준의 연구비를 받고 있다. 하지만 나쁜 소식은 연구비가 늘어나고 있지 않다. 신임 교수가 연구비를 받기 쉽지 않음. 인공지능은 2010년에 비해 2017년에는 10배 증가한 연구비. 앞으로도 인공지능 연구비는 증가할 것. 어쩌면 AI 교수님들은 더이상 연구 프로젝트를 받을 수 없을 수도 있다. AI 쏠림에 대한 부담감이 있음. 일시적인 유행인가? 아니면 근본적인 변화인가? 아날로그에서 디지털에서 넘어가는 것처럼, AI 시대로 넘어간다고 생각함. 큰 흐름에서의 이해할 필요가 있다.


Warp Instruction Reuse for Repeated Computations in GPUs
CUDA 기술이 무르익음에 따라 포팅이 쉬워짐. 워프별로 동일한 연산이 반복되며, 레지스터 값이 동일한 경우도 많음. 같은 값을 가진 레지스터가 여러 곳에 존재함. 병렬성은 높였는데, 반복되는 연산이 일어난다는 점이 문제이다. 이를 해결하면 10.7%의 에너지 절감 가능하고, 18.7%의 명령어를 넘길 수 있음. 실행 시간은 실제로는 크게 줄어들지 못했음.


알쓸신잡: 컴퓨터와 발열
발열에 대해 잘못 이해하고 있는 것에 대해 이야기하고 싶었음. 시뮬레이터가 사실은 부정확하다. 눈에 보이는 연구를 해보고 싶었음. 요즘은 연구 방향이 조금 바뀌고 있다. 들어올 때에는 박수치지만 뒤에서 실현 가능성에 대해 의문을 많이 가짐. On-chip thermal sensor를 읽으면서 실험을 시작함. 요즘에는 IR 카메라로 발열을 확인하고 있음. CPU/GPU 모두 발열 문제를 겪고 있음. Top conference에 나오는 논문 중에서 말이 안 되는 것이 많음. DAC에 나오는 논문들을 보면 시뮬레이션 논문은 모두 떨어질 것. 칩에서도 하나의 전력 선이 버틸 수 있는 공급량이 있음. 온도가 늘어나면 leakage power가 늘어남. 제조 공정 미세화됨에 따라 전력 밀도가 높아짐. 칩당 소모 전력은 줄어들고 있지만, 칩의 단위 면적당 전력은 높아지고 있음. 발열을 줄이기 위해서는 쿨링 시스템을 쓸 수도 있고, DVFS와 같은 동적 발열 관리 기법을 쓸 수도 있음. 20도의 온도 차이는 성능 2.5배 정도의 차이를 만들 수 있음. 정확한 발열 모델이 필요한 이유? 온도 센서 자체는 area overhead가 적으나, analog-digital converter가 상당한 영역을 차지함. 라우팅에 문제가 될 수 있음. 전력소모는 바로 온도 상승으로 이어지는가? 전력 소모가 온도 상승으로 바뀌기까지 얼마나의 시간이 필요한가? 런닝머신에서 뛴다고 해도 땀이 나기까지 더 오랜 시간이 걸림. 전력과 온도 관계도 비슷함 (ms 단위). 전력과 온도 변화에 시간 딜레이가 있음. 온도 시뮬레이터는 정확한가? Parameter만 정확하면 3~4도 정도밖에 차이나지 않음. 하지만 parameter를 정확하게 결정하기가 쉽지 않음. 정확하지 않게 사용된 parameter가 너무 많음. 이전까지의 논문에서 썼다고 해서 정확하지 않음. 컴퓨터 시스템에서 어떤 thermal research가 의미없나? 아주 짧은 순간동안 온도 상승을 방어하고자 하는 연구는 무의미하다. 10ns동안 130도까지 올라가는 경우를 막는다는 연구는 무의미함. Thermal hotspot이 아닌데 연구하는 것도 무의미. 실제 산업에서 누가 thermal problem을 연구하나? Architecture team / design team / place and routing team / packaging team이 될 것. 꼭 하나가 되어야 한다면 packaging team이 될 것. 앞으로 thermal problem이 중요해지나? 아마도 그럴 것이다. 학계에서 할 일이 늘어날지 아닐지는 의문이지만. 앞으로는 2.5D 또는 3D로 넘어가게 될 것이므로. 아이폰은 안드로이드에 대비해 고온에 더 강한가? 아이폰은 고온에서 빨리 꺼짐. Design margin이 적은 것으로 보임. 배터리 이슈에서 왜 디스플레이가 아닌 AP를 건드렸나? AP의 voltage design margin이 적지 않았을까 추정함. 온도가 낮으면 배터리가 빨리 방전될까? 저온에서는 배터리에서 공급 가능한 전압이 빠르게 떨어진다. 반대로 온도가 높을 때 배터리가 빨리 떨어지는 느낌이 있는데, 그 이유는 다른 곳에 있다. 무의미한 연구를 하지 말라.


주기억장치의 이해: 프로그래머의 관점에서
메모리가 전체 시스템에서 사용하는 전력량이 많지 않음. 이전에 메모리의 전력 사용량이 많다는 논문이 있었지만, fully-buffered DRAM을 사용했기 때문. Latency를 줄일 때 성능이 두 배 정도까지 향상될 수 있음. Latency가 늘어나는 이유 중에 가장 큰 것은 sensing이고 그 다음으로 데이터 전송에 소요되는 path이다. 일부만 sensing time을 빠르도록 하자는 아이디어도 있었음. 시뮬레이터 성능을 신뢰하지 않으므로, 리얼 머신에서 실험을 해 봄. 메모리도 네트워크처럼 사용량에 따라 latency가 영향을 받음. 특정 BW load에서 latency를 측정해야 함. DRAM을 빠르게 동작할 수는 없지만, 느리게 동작하도록 할 수는 있다. 따라서 이를 활용해 성능을 평가해 봄.


Enlightening the I/O Path: A Holistic Approach for Application performance
FAST에 발표된 논문. 여기에서 타게팅하는 것은 data-intensive applications. 시스템이 얼마나 많은 데이터 요청을 처리할 수 있느냐가 중요한 문제임. 일반적으로 어플리케이션은 사용자의 요청을 처리하는 쓰레드와, 직접 요청을 처리하지는 않지만 필요한 기능(로깅, 체크포인팅)으로 구성됨. 문제는 백그라운드 쓰레드가 실제 메인 쓰레드 성능에 악영향을줄 수 있다는 점이다. 실제로 시계열로 보면 워크로드의 처리 성능이 뚝 떨어지는 것을 볼 수 있는데, 이 시점에 checkpointing이 일어난다. 백그라운드 작업의 우선순위를 낮춰보기도 했으나, 성능 향상에 큰 도움이 되지 않음을 확인함. 이 문제는 priority inversion이라고 이야기할 수 있음. 여러 개의 레이어들이 독립적으로 설계되었다는 점도 문제. 소프트웨어 레이어 (커널 수준)에서 foreground job과 background job을 분리하지 못하고 보는 것이 문제. Foreground / background task가 동일한 lock을 공유하는 경우에는 이 문제가 더욱 심해짐. 동일한 파일에 대해서 I/O를 하는 경우에 foreground task가 background task의 작업을 기다려야 할 수도 있다. 실제로 ext4 파일 시스템의 저널링에서 이같은 문제가 발생한다. 이를 해결하기 위해 request-centric I/O prioritization을 제안한다. Critical path를 정의하고, critical path에서 발생하는 request를 우선적으로 처리한다. 어떻게 critical I/O를 판별해낼 것인가? Critical thread를 정의하고, 해당 thread에서 발생하는 I/O를 critical I/O로 본다. 하지만 background thread가 일으키는 I/O라 하더라도, foreground task가 기다리고 있으면 critical I/O 이다. Foreground task가 background task를 기다리고 있는 경우에는 background task에 criticality를 inherit해주면 된다 (lock). Condition variable에 대해서는 같은 방식으로 구현하되, 특정 condition variable이 일반적으로 누군가에게 wake 되는지를 보고 판단한다.


Pado: A Data Processing Engine for Harnessing Transient Resources in Datacenters
데이터센터에서 자원 관리. 자원 관리자가 이를 관리한다. 어플리케이션에서 사용할 수 있도록 할당함. Latency-critical 작업에 많은 자원이 할당되는 경향이 있음. 하지만 실제로는 그 자원을 다 사용하는 경우가 많지는 않음. Transient resources라는 개념이 등장함. Latency-critical task가 자원을 사용하지 않을 때 유휴 자원을 best-effort 작업에 할당하게 됨. 하지만 다시 LC task가 이를 필요로 할 때에는 모든 자원을 BE task에서 빼앗아오게 됨. 이 때 연산 상태가 사라지게 됨. Data processing engine이 transient resource에서 실행되면 어떻게 되나? Eviction이 자주 일어나면 작업이 완료되지 않기도 함. Motivation. 데이터 처리 과정을 보았더니, 어떤 것들은 더 소중한 연산들이다. One-to-one, one-to-many는 not so valuable하고, many to one, many to many의 경우에는 valuable할 가능성이 높다. 컨테이너를 두 가지 종류로 분류해서 실행하는 것을 제안함. Transient container / non-transient container(Reserved). Non-transient container는 transient 자원을 사용하지 않지만 비싼 컨테이너, transient container는 transient 자원을 사용하며 저렴한 컨테이너이다. 이같은 조건을 활용해 자원 활용률과 성능을 동시에 향상한다. Checkpointing이 한 가지 해법이 될 수 있음. Reserved container에 checkpoint를 두는 방식으로 구현 가능. 하지만 데이터 이동 오버헤드가 있을 수 있음. 이같은 기본 아이디어를 확장해 Pado를 제안함.


Mobile Plus: Multi-device Mobile Platform for Cross-device Functionality Sharing
지난 2015년 동계학술대회에서 떠오른 아이디어임. 전산학에서 가장 중요한 개념은 추상화. 추상화는 무엇인가? 디테일을 숨긴 모델을 만드는 과정. 추상화의 한 가지 사례 연구를 발표할 것. 개인이 여러 개의 모바일 장치를 소유하는 경우가 많아지고 있었음 (2015년). 옛날에는 한 개의 장치가 여러 사용자를 서빙하고 있었다면, 요즘에는 한 명의 사용자가 여러 개의 장치를 사용하고 있음. Single-device abstraction을 제공할 수 있을까 라는 질문에서 연구를 시작하게 됨. 여러 개의 장치를 한 개의 장치처럼 쓸 때의 이점은 무엇일까? 스마트폰을 원격 센서로 사용할 수도 있을 것. 여러 개의 장치가 있을 때, 한 쪽의 결제 요구가 다른 쪽에서 승인되도록 하는 것. 아이에게 태블릿을 주어도 문제가 없을 것. 어플리케이션 수준에서 이를 구현하려면 소스 코드 수준의 수정이 많다. 시스템 수준에서 개발하면 좋을 것. 기존 연구는 앱 수준의 기능을 지원하지 않았음. Mobile plus에서는 multi-device mobile platform에서 소스 코드 수정 없이 single-device abstraction을 제공하고자 한다. 안드로이드에서 RPC scheme을 수정하였음. 다른 프로세스에 있는 함수를 호출하도록 해 줌. Binder IPC driver를 통해 RPC가 전달됨. 함수가 실행된 다음에 클라이언트에 결과가 전달됨. 안드로이드의 바인더를 확장하여 single device abstraction을 제공하고자 함. Mobile plus가 RPC channel 사이에 위치하여 소스 코드 수정 없이 가능하도록 함. 하지만 단순 구현으로는 잘 되지 않았고, RPC argument passing이 잘못되거나, execution context가 유지되지 않거나 함에 따라 문제가 발생했음. 얼마나 많은 어플리케이션에 대해 잘 동작하는지 확인했음. 어떤 어플리케이션은 채널을 두 개 이상 사용했고, Mobile Plus의 구현에 맞지 않아 잘 동작하지 못했음. 동작하지 않는 경우도 찾아서 그 원인을 알려주는 것이 리뷰에서 좋은 점수를 받을 것. 안드로이드 버전에 따라 다른 RPC 함수 이름을 가지기 때문에 그런 경우에도 잘 되지 않았다.


Esperanto: Intelligent SW/HW Cooperative Framework for the IOT
사물인터넷에 대한 컴파일러 최적화가 어떤 것들이 소개할 것. 수많은 기기들이 연결되고 있고, 프로그래머는 이러한 기기들을 연결해 실행되도록 하고 있음. 기기들이 분산되어 있고, 이들을 어떻게 쉽게 개발하도록 할 것인가에 대해 연구할 필요가 있음. 모바일 기기의 성능을 어떻게 높일 것인가에 대해 연구함. 배터리가 제약되어 있는데, 이를 어떻게 효율적으로 쓰면서 센서를 쓸 수 있는지에 대해 연구함. 하나의 서비스를 제공하기 위해 프로그래머는 다양한 기기에 프로그램을 해야 함. 이를 동기화하기는 쉽지 않음. 하나의 컴퓨터에서 프로그래밍하는 것처럼 추상화하는 것이 필요하다. 전구 하나도 회사마다 인터페이스가 다르다. 장치 추상화가 필요함. 기존에는 클라우드 중심의 접근이 있었음. 클라우드에서 인터페이스를 통일해주고, 여기에 등록하도록 한다. 선택적으로 추상화하기를 제안함.

Advertisements
Posted in 1) Memo

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

Recent Posts
누적 방문자 수
  • 121,980 hits
%d bloggers like this: