Multi-Core or SMT on Embedded ?

OpenSPARC T1/T2는 각각 32/64개의 thread를 동시에 수행할 수 있습니다. 한 두개도 아니고 이렇게 많은 thread 처리가 embedded 동네에서는 어떨까 생각해 봅니다.


다른 시스템도 마찬가지겠지만 CPU의 성능은 latency와 throughput 두 가지로 나타낼 수 있습니다. latency는 어떤 하나의 일을 완료하는데 걸리는 시간이 얼마인가의 문제이고, throughput은 단일 시간안에 할 수 있는 일의 총 수는 얼마인가의 문제입니다. 이것은 어찌보면 서로 연관이 되어 있지만, 다른 의미를 가질 수 있습니다.

예를 들어 현재 시중에 팔리는 저가형 잉크젯 프린터를 보면 대략 분당 20장, 즉 20PPM의 성능을 가지고 있나 봅니다. 하지만 PC에서 프린트 버튼을 누르고 첫번째 페이지가 출력되어 나올 때까지 걸리는 시간은 3초(60초/20PPM) 보다는 보통 많이 걸리고 프린터의 종류마다 다릅니다. 첫번째 페이지가 나올때까지 걸리는 시간은 latency이고, PPM으로 나타나는 성능이 throughput입니다. 물론 20PPM 프린터 중에 가장 성능이 좋은 것은 첫번째 페이지가 3초만에 출력되는 것입니다. 첫번째 페이지가 1초에 출력된다면 그 프린터는 60PPM(분당 60페이지)이 가능할 것이므로 20PPM 프린터에서는 3초가 가장 좋은 수치입니다.

20PPM 프린터라고 하면 첫페이지를 포함해서 모든 페이지를 3초에 한장씩 프린트할 수 있도록 만들면 좋은데 그렇게 하지 않을까요? 당연히 여러가지 요소 때문에 그렇게 만들 수 없기 때문입니다. CPU도 마찬가지로 latency를 줄이는 일이 힘들어 졌습니다. CPU의 clock frequency를 증가시키더라도 Memory latency로 인해 성능 향상이 적고, Superscalar와 같은 ILP(Instruction Level Parallelism)방법을 더 많이 사용하더라도 instruction dependency로 인해 성능 향상 폭이 매우 적습니다. 따라서 throughput을 증가시키는 방향으로 SMT나 Multi-Core가 대두되고 있습니다. 현재 PC 동네에서도 Intel/AMD에서 나오는 CPU가 4개 Core를 가지고 있고, Intel i7의 경우에는 SMT(intel은 hyperthreading이라 부름)를 적용하여 8개의 thread가 동시에 수행됩니다. 현재 추세로는 core 갯수를 6개나 8개로 더 증가시킬 모양입니다.

OpenSPARC T1/T2는 latency를 줄이는 것은 거의 포기하고 throughput을 높이기 위해 극단적으로 설계된 CPU입니다. ILP라는 개념 자체를 아예 사용하지 않고 설계하였고, clock frequency도 비교적 낮은 편입니다. CPU core를 더 많이 넣기 위해서 core의 설계를 단순화하여 작게 만들려고 노력했습니다. 이런 접근 방법은 server 동네에서는 적절하다고 생각합니다. 예를 들어 web server로 사용한다고 하면, 수 많은 사용자가 web server에 접속을 합니다. 그리고 그 많은 사용자 사이의 dependency는 거의 없습니다. 따라서 사용자 마다(정확하게는 TCP/IP connection 마다) 별도의 thread나 process가 동작하면 되고, 그것이 여러개의 core에 나누어져 수행하면 됩니다. 당연이 여러 사용자를 위한 service가 동시에 동작하면 동시에 수행 가능한 thread가 많을 수록 execution time이 줄어듭니다. 빨리 동작하는, 즉 clock frequency가 매우 빠르고 ILP를 충분히 활용하는 단일 core CPU에 여러 사용자를 번갈아 서비스하는 것보다 유리할 가능성이 큽니다. 산술적으로 64배의 clock frequency로 동작하는 CPU core를 설계해야 동일한 성능을 기대할 수 있지만, memory latency 등을 고려하면 단일 core가 64배 빠른 clock frequeny를 가진다고 해도 64개의 thread가 동시에 동작하는 CPU보다 빠를 가능성은 매우 낮습니다.
또한 T1/T2는 hypervisor mode가 있어서 여러 개의 OS를 특정 CPU에 할당하여 동시에 수행할 수 있는 구조를 가집니다. Windows PC에서 VirtualBox나 VMWare 등을 사용해서 linux를 필요할 때만 사용하는 저로서는 이해하기 힘들지만, server 동네에서는 여러 개의 OS를 돌리면 장점이 많이 있나 봅니다. 수년 전에 ftp service는 FreeBSD에서 가장 빠르다는 뭐 benchmark를 본 적이 있는데, service 마다 다른 OS를 사용하는 것이 이득인 경우가 많이 있나 봅니다. 이렇게 여러개의 OS를 사용할 때도 CPU가 여러개 인 것이 매우 강점이고, service의 비중에 따라서 OS에 할당된 CPU 갯수를 조절하는 것도 가능하므로 상당히 유연합니다.

Intel/AMD에서도 PC용으로 T1/T2와 같이 latency는 어느 정도 포기하고 throughput을 극닥적으로 높인 processor를 설계하는 것은 어떨까요? PC에는 이런 접근이 적합하지 않습니다. PC는 사용자와의 Interface 요소가 많은 부분을 차지하고 있으므로 latency도 매우 중요합니다. 인터넷 서핑중에 web Page가 늦게 화면에 표시될 때 그 기다림은 사용자를 답답하게 합니다. 일반적인 PC 사용자는 여러 개의 web page가 한꺼번에 빨리 열리는 것을 바라지 않고, 자신이 보고 싶은 하나의 page가 빨리 열리기를 바랍니다. 또한 PC의 주용도중 하나로 볼수 있는 game에서도 latency가 매우 중요합니다. 여를 들어 game을 하는데 keyboard나 mouse의 반응이 3초 후에 일어난다고 가정하면, game이 말이 되지 않겠죠. 따라서 PC에서 사용되는 CPU는 latency를 줄이는 것을 기본으로 해야 합니다. 물론 그게 한계를 맞았기 때문에 core를 여러개 넣고 있습니다.

PC에서 multi-core CPU가 도입되면서, multithread programming이 각광을 받고 있습니다. 당연히 windows thread library나 pthread library 등을 직접 사용하는 방법이 있고, OpenMP나 Intel Thread Building Block과 같은 tool/library 등을 사용할 수도 있습니다. PC에서는 이런 방법을 통해서 달성하고 싶은 것은 server의 경우에서 처럼 여러개의 program을 동시에 수행하여 throughput을 올리는 것이 아니라, 특정 프로그램의 execution time을 줄이는 것입니다. PC의 경우 서버와 달리 동일한 작업을 동시에 여러 개 수행하는 경우는 별로 없으므로, 결국은 latency를 줄이기 위해서 노력한다고 할 수 있습니다. 하나의 일을 여러 thread로 나누어 동시에 수행하므로써, 일의 수행을 위해서 소요되는 latency를 줄이는 것이 목표입니다. thread로 나누게 되면 thread 사이의 dependency가 생기게 됩니다. 예를 들어 특정 thread의 작업 결과를 다른 thread가 처리를 하게 되면 앞 thread의 작업이 끝났는지 check하고 뒤 thread가 동작하도록 해야 합니다. 이런 것을 thread synchronization이라고 하는데, thread를 만들고 synchronization을 하는데는 별도의 performance가 요구됩니다. 여러개의 thread로 나누어 동시에 수행하도록 할 때는 될 수 있으면 thread간의 dependency가 없도록 해야 하는데, dependency가 많을 경우 여러개의 thread로 나누는 것이 나누지 않는 것 보다 성능이 더 떨어질 수도 있습니다. 이렇게 multithread programming을 통해 latency를 줄이는 방법은 상당히 골치 아픈 일입니다. T1/T2의 Server 동네에서 TCP/IP connection 별로 core에 돌릴 각각의 작업이 자동으로 나누어지는 반면 multithread programming을 통해 latency를 줄이는 것은 상당히 어렵습니다.

그렇다면 Embedded 동네에서는 어떨까요?


Embedded 동네에서는 Server와 같은 상황이 벌어지는 곳이 그렇게 많지 않습니다. Network packet processing과 같은 경우 말고는 그다지 생각나는 영역이 없습니다. 따라서 T1/T2와 같은 엄청난 multi-core 또는 SMT를 사용하는 경우는 극히 적습니다. 하지만 역시 CPU Core IP를 제공하는 ARM/MIPS 등에서 SMT나 Multicore가 꾸준히 나오고 있습니다. 동일한 core를 여러개 연결하는 것을 보통 SMP(Symmetric Multi-Processing), 좀 더 정확하게는 homogenous multi-core라고 하는데 ARM에서 제공하는 ARM11MPCore, 그리고 얼마전에 발표한 Coretex A9 과 같은 것이 그 예입니다. MIPS에서도 core 하나로 5개의 thread를 지원하는 MIPS32 34K와 core당 2개의 thread를 지원하고 core를 4개까지 연결할 수 있는 MIPS32 1004K를 제공하고 있습니다.

또한 TI OMAP과 같은 processor는 ARM+DSP multi-core를 사용하고 있는 경우가 있습니다. 이렇게 다른 architecture를 가지는 core를 연결한 것을 AMP(Asymmetric Multi-Processing), 정확하게는 heterogenous multi-core라고 합니다. ARM과 같은 general purpose CPU에 OS/UI 등의 program을 수행하고, DSP에서는 계산량이 많은 작업을 수행하는 방법입니다. Sony의 게임기 Playstation 3에 사용되고 있는 Cell Broadband Engine은 Power Architecture CPU 하나와 SPE라고 하는 floating point 연산을 주로 처리하는 core가 8개 들어있습니다. Cell과 비슷한 approach로, ziilabs라는 회사에서 금년에 출시한 processor는 독특하게도 ARM9 dual core에 processing elements라고 불리우는 core 24개를 내장하고 있습니다.

이렇게 Embedded 동네에서도 multi-core나 SMT가 개발되는 이유는 우선 CPU의 performance 요구량이 더 커졌기 때문입니다. 특별히 multimedia application은 많은 성능이 요구됩니다. 또한 Embedded 동네는 Server나 PC에 비해서 Power 소모량의 제약이 더 심하기 때문에 clock frequency를 높이거나 ILP를 많이 활용하여 성능을 높이려고 시도하는 것이 더 어렵기 때문입니다. 하지만 당분간은 T1/T2급의 엄청난 숫자의 multi-threading을 일반적인 embedded 시장에서 볼 수는 없을 겁니다.Embedded 동네는 특성은 좀더 높은 성능이 아니라, application에 딱 맞는 성능을 요구합니다. 필요 없이 자원(당연히 돈, power 등)을 낭비하는 것을 지양하는 것입니다. 따라서 성능의 요구량이 많지 않은 application에서는 multi-core는 고사하고 여전히 8bit/16bit MCU가 많이 사용되고, 그런 application이 존재하는 한 없어지지 않을 겁니다.



==
참고로 homogenous multi-core의 경우, 즉 동일한 CPU core를 여러개 사용하는 system이라도 꼭 SMP(symmetric multi processing)일 필요는 없습니다. 각 CPU 별로 별도의 OS를 동작시키고 CPU 사이에는 별도로 interrupt 등으로 message를 주고 받는 구조를 취할 수 있습니다. 일반적으로 SMP라고 하면 단일 OS에서 모든 core에 서로 task를 scheduling을 통해서 동작시키는 것을 말합니다.


==
관련 사이트
ARM

MIPS

IBM Cell Boradband Engine Resource Center

Ziilabs