안녕하세여 맛게 여러분! 맛게 눈팅종자 싸이아노젠모드라고 해여.

요즘 갤럭시 S 4가 출시되면서 가장 주목받는게 바로 바로 갤럭시 S 4 안의 두뇌라고 생각해여.

옥타코어! 옥타! Octa! 8개의 코어!

 좀 흥분한 것 같다구여? 네 맞아요. 본능이 그런걸. 코어가 8개인건 누구도 부정하지 못할 사실인데!

근데 이 갤럭시 S 4에 들어가는 코어는 아주 '특별한' 옥타코어에여.

왜? 왜 특별한데? 얘 삼성 알바 아냐? 아니아니 막 대만산 정직원 아냐?

그런 사람은 아니니 안심하세여. 저 진짜로 한국사람입니다. 이건희 싫어요! 이씨 가족 + 운영진 ㅗㅗ

각설하고, 왜 삼성의 옥타코어는 '특별한가?' 를 설명하자면

모바일 시장에서 big.LITTLE 방식으로 구동되는 

최초의 애플리케이션 프로세서(AP, CPU코어와 GPU 등등을 포함하는 프로세서의 총칭.)이기 때문이에요. 

빅리틀? 그게 뭔데? 먹는건가?

하시는 분들을 위해 이제부터 알려드릴 것은 빅리틀에 대한 설명이에요.

사실 삼성만을 놓고 얘기하는 것이 상당히 껄끄러우실 분도 있어요. 

그렇기 때문에, 먼저 모바일 AP에 대한 설명을 빼놓을 수는 없겠죠.

우선 표 한 장을 보여드릴게요.

• * ARM11 : 1.25 DMIPS/MHz 

  Cortex-A5 : 1.57 DMIPS/MHz
  Cortex-A7 / Scorpion S1 : 1.9DMIPS/MHz
  Cortex-A8 : 2.0 DMIPS/MHz 
  Scorpion second: 2.1 DMIPS/MHz 
  Cortex-A9 : 2.5 DMIPS/MHz 
  Cortex-A9 MPCore : 2.0 DMIPS/MHz 
  Krait : 3.1 DMIPS/MHz 
  Cortex-A15 : 최소 3.5 ~ 최대 4.01 DMIPS/MHz 로 추정

이건 영국의 ARM 사에서 만드는 Cortex 아키텍쳐 씨리즈의 표입니다.

아키텍쳐가 뭐나면, 씨피유가 동작하는 전자 회로의 체계예요. 사람으로 치면 신경계에 속하죠. 학술 모임에서는 컴퓨터 조직이라는 용어로도 쓰이기도 합니다.

쉽게 말해서 우리가 인텔의 컴퓨터 CPU의 세대를 구분해서 부르는 호칭인 

네할렘, 샌디브릿지, 아이비브릿지, 하즈웰 등등...

이런게 아키텍쳐의 종류에 속하죠.

ARM의 경우 성능에 대한 평가는 주로 DMIPS/MHz 로 표기되어 있는데, 이건 명령어가 해당 단위당 몇 개 처리되느냐를 의미해요.

같은 명령어를 사용하는 CPU 사이에서만 비교가 가능한 지표이지, 절대로 다른 기반의 CPU와 1:1로 매칭이 가능한 지표가 아니라는거죠.

대학생 과수석과, 중학생 학년수석을 1:1로 비교할 수 있을까요?

위를 보면 형형색색의 표가 보이는데, 우리가 주목할 것은 Cortex-A 부분의 라인업이에요.

안드로이드 스마트폰의 태동기에 자주 쓰였던 Cortex-A8 부터 역사가 거슬러 올라가는데, 

이건 싱글코어에만 쓰인거에요. 왜냐하면 애초에 여러개를 붙혀서 쓸 상황을 고려하지 않았거든요.

그래서 만든게 Cortex-A9! 듀얼코어와 쿼드코어에 잔뜩 쓰인 아키텍쳐이고, 성능도 개선됐죠. (2.0 DMIPS/MHz -> 2.5 DMIPS/MHz)

근데, Cortex-A9으로 모든걸 해결하기엔, 조금 오래됐어요. 

사실, 2011년 초부터 2013년 중순인 지금까지 쓰였다면, 날로날로 바뀌는 모바일 시장에선 꽤 장수한 아키텍쳐라고 할 수 있겠지요. 

이걸 만든 아키텍쳐 제작사인 ARM은, 다음 아키텍쳐의 방향을 고민하기 시작했어요.

'어떻게 만들지? 성능을 우선해서 만들까, 전력 소모 감소를 우선해서 만들까?'

빅리틀의 목적은 진짜 간단해요. 상황에 따라 작업 부하에 맞는 프로세서를 쓰자는 거에요.
그렇다면 왜 그럴 필요가 있을까요. 성능은 무조건 높은게 좋은거 아닌가요?

ARM 기반 코어의 성능이 향상될수록 소비전력도 상승하기 때문입니다.
ARM 기반 코어가 제 아무리 저전력이더라도 일하는만큼 먹어야한다는 반도체의 진리를 비켜갈 수는 없습니다.

쉽게 말해서, 힘이 센 사람은 힘든 일을 하는데 체력을 많이 쓰기 마련이고,

또 그걸 보충하려면, 밥을 많이 먹어줘야하거든요. 

CPU도 마찬가지라서, 성능이 높고 명령어 처리 속도가 더 빠를수록, 전력을 많이 먹어요.

예를 들어 PC에서의 CPU와 모바일 AP의 전력 소모량은 비교가 안될정도로, PC가 많은 편이에요. 

이건 근본적으로 두 씨퓨의 성능 차이도 있거니와, 명령어 차이도 있으니. 

(물론 모든 반도체가 먹는만큼 일하는건 아닙니다. 우리는 그동안 밥값도 못하는 제품을 많이 봐왔지요.)
거꾸로 생각해보면 빅리틀이라는 기술이 등장해야할 정도로 ARM 기반 코어의 성능과 소비전력이 상승한 것이지요.

그리고 이에 대한 ARM의 대답이 빅리틀인거고요.
높은 성능을 요구하는 작업은 높은 성능을 가진 프로세서로 처리하여 높은 성능을 잡고,
낮은 성능을 요구하는 작업은 높은 전력효율을 가진 프로세서로 처리하여 낮은 소비전력을 달성한다는 겁니다.

그래서 ARM은 성능과 전력 소모 감소를 이분화해서, 따로따로 아키텍쳐를 설계하기로 했어요.

그 두 개의 아키텍쳐가 바로 Cortex-A15와 Cortex-A7입니다.

Cortex-A15의 경우, 철저히 성능만을 고려해서 설계한 아키텍쳐에요.

Cortex-A7의 경우에는 저전력을 위해 설계된 아키텍쳐이죠. 그렇다고 성능이 좋지 않은건 아니에요. 이전의 Cortex-A8 정도는 되거든요.

성능을 우선시한 Cortex-A15는 상대적으로 전기를 많이 먹게 되었고, 그렇기 때문에

성능도 놓치고 싶지 않고, 그렇다고 배터리를 빨리 닳게 하고싶지도 않은 사람들 위해 마련된 솔루션이 big.LITTLE 이라는 물건이에요.

big을 어째서 소문자로 쓰고, LITTLE을 어째서 대문자로 쓰냐고 묻는다면, 서로의 상부상조가 간절한 CPU 구조이기 때문이라고 말할 수 있겠네요. 최초는 Cortex-A15, Cortex-A7 의 결합이고, 다음 세대는 Cortex-A57, Cortex-A53 의 결합입니다.

여기서부터 조금 어려워질 수 있습니다. 헉헉... 이제서야 본론에 들어가나요. ㅜㅜ

우선 사진 몇 장을 좀 보세요. 구현 방식이 크게 3가지입니다. (출처는 http://gamma0burst.tistory.com/ 입니다. 감마님 감사합니다!)

(1) Cluster Migration (클러스터 마이그레이션)

클러스터 단위로 전환하는 거에요.
그런데 이렇게 말하면 뭔 말인지 이해하기 어렵지요.
특정 DVFS 포인트 (DVFS : Dynamic Voltage and Frequency Scaling, 부하에 따라 전압과 클럭이 변화하는 것을 말합니다.)를 기점으로 빅 부분의 쿼드코어와 리틀 부분의 쿼드코어 간에 전환이 일어나는데, 그 단위가 각 CPU 클러스터인 거에요. 

이 경우에는 빅 클러스터와 리틀 클러스터 간의 전환만 가능합니다.
Cortex-A15 4코어 + Cortex-A7 4코어 구성이라면,
Cortex-A15 4코어 만으로 쓰거나, Cortex-A7 4코어 만으로 쓸 수 있을뿐, 각각 2개씩 쓴다거나 하는 조합은 불가능한 셈입니다.

장점으로는 구조가 간단한 편이에요.
단점으로는, 가변성이 적은 탓에 필요 이상의 성능이 제공되고, 그로 인해 소비전력 이득이 작아집니다.
필요 이상으로 전력을 사용할 수 밖에 없는 거죠.
또한 클러스터 단위로 전환되기 때문에, 빅 클러스터와 리틀 클러스터의 코어 수가 같아야하고, 이는 다이 사이즈를 증가시킵니다.

현재 엑시노스 5 옥타는 이 구동을 완벽히 지원하고, 현재도 이 상태로 구동이 지속되고 있을걸로 추정되고 있어요.

(2) CPU Migration (씨피유 마이그레이션)
코어 단위로 전환하는 거에요. 

클러스터 마이그레이션의 경우처럼 특정 DVFS 포인트(전압과 클럭)을 기점으로 빅 코어와 리틀 코어 간에 스위칭이 일어나는 것은 같지만,
빅 코어 하나와 리틀 코어 하나로 구성된 단위 내에서 이루어지죠.

가상의 쿼드코어 CPU 하나를 만들어, 거기에 서로 다른 코어를 집어 넣는 거에요.
Cortex-A15 4코어 + Cortex-A7 4코어 구성이라면, 상황에 따라 Cortex-A15 1코어, Cortex-A7 3코어를 사용하는 식으로 이용할 수 있습니다. 

8개의 코어를 4개로 묶어 쓸 수 있다면, 수학적으로 경우의 수가 꽤 많은 편이겠죠? 그런 가변성이 있는 게 이 모드의 장점입니다.

장점은 최적화된 소비전력의 구현이 가능합니다.
빅 코어와 리틀 코어가 하나씩 네 개로 묶인 것인 한 단위이기 때문에 여기서도 빅 코어와 리틀 코어의 수가 같아야 하지만, 이렇게 효율적으로 사용된다면 문제가 되지 않아요. 
단점으로는 DVFS 드라이버를 수정하는 게 필요해요. 근데 이 과정이 꽤나 복잡합니다. 

현재 엑시노스 5 옥타는 이 구동을 소프트웨어 상으로 지원하고, 엑시노스 5 옥타가 처음 선보였을 때 시연한 구동도 이 모드였지만, 갤럭시 S 4에도 이 모드로 구동이 되고있는지는 '미지수' 에요. (아니라는 말은 아닙니다.)

(3) big.LITTLE Multi Processing (빅리틀 멀티 프로세싱)
빅코어, 리틀코어 동시에 다 쓰는겁니다.
빅코어와 리틀코어의 수가 달라도 상관이 없는거죠.

서로 다른 코어를 하나하나씩 써서, 최적의 효율을 발휘하는 - 그러니까 A15 코어와 A7 코어를 하나하나씩 쓰는게 가능하다던지 - 기술이기 때문에, 이 중에서는 끝판왕 (!) 기술입니다.

장점으로는 단연 성능과 배터리 효율을 동시에 잡는 것.
단점은, 각 작업의 부하에 따라 최적의 코어에 작업을 분배해야하기 때문에 OS 수준에서 

각 작업을 단계별로 스케줄링(Scheduling: 쉽고 어려운 일을 적절히 배분하는 '일정표' 와 같은 개념)을 최적화해줘야 합니다.

현재 엑시노스 5 옥타는 이 구동을 하드웨어 상으로 지원하지만, 갤럭시 S 4는 이 기능을 지원하지 않아요.

그럼 '빅리틀은 효과가 있는 걸까요?'

이 글은 2012년 7월 16~19일 간 그리스에서 열린 12회 SAMOS 에서 The homogeneity of architecture
in a heterogeneous world 라는 제목으로 발표된 자료를 바탕으로 작성되었습니다.
매끄러운 내용 전개를 위해 일부 슬라이드의 순서가 바뀐 부분이 있습니다.
(SAMOS는 Systems: Architectures, MOdeling and Simulation 의 약자로 임베디드 컴퓨터 관련 국제 컨퍼런스입니다.)

왼쪽은 A15가 A7에 비해 성능이 얼마나 높은지를 보여주고,
오른쪽은 A7이 A15에 비해 전력효율이 얼마나 좋은지 보여줍니다.
(맨 위의 Dhrystone이 ARM 코어의 성능 얘기 나올 때마다 언급되는 DMIPS에요. Dhrystone Million Instructions Per Second 의 약자)

하지만 빅리틀의 발상이 실제 사용환경에서 유효한지 검토가 필요하겠지요.
실사용에서 요구되는 성능이 예상보다 높으면 대부분 A15 로 돌아가게되고 그렇다면 A7의 역할이 축소되면서 전력효율을 잡겠다는 꿈은 물거품이 될테니까요.

그것을 확인하기 위해 가정한 것이 위의 사용패턴이에요.

음성통화 90분
이메일 60분
웹서핑 30분
동영상 감상 30분
게임 50분
음악 감상 + GPS 기록 90분
동영상 녹화 10분
수면 (알람 설정) 7시간
OS에 항상 돌아가는 백그라운드 프로세서 28개

딱 봐도 상당히 빡세게 쓰는 편이에요.
아마 오유 분들 중 대부분은 이렇게 열심히 맛폰을 쓰시겠죠?
순수하게 스마트폰을 쓰는 시간만 6시간이에요.
표본으로 이 정도 가정이면 충분하겠지요.

각종 작업을 할 때의 CPU 사용률입니다.
300MHz 이상, 즉 노란색부터 위까지가 실제 로드(부하)가 걸리는 상태로 볼 수 있어요.

보면 알 수 있듯이 대부분 심하게 로드가 걸리는 비율이 적습니다.
브라우저 벤치마크의 경우, 벤치마크앱답게 90% 이상이 최대 로드 상태입니다만, 그건 벤치마크니까 당연한 결과겠지요?
주목할 것은 게이밍 벤치마크입니다.
CPU 로드는 크지 않습니다. 게임이니 GPU 로드가 클 거에요.
게임이라고 무조건 CPU 사용률이 높고 CPU의 소비전력이 높아질 거라고 생각하면 안 된다는 거죠.

앞에도 언급했듯이 빅리틀 모델은 3가지입니다.

빅코어 클러스터(코어군)와 리틀코어 클러스터끼리 전환되는 클러스터 마이그레이션.
빅코어 하나와 리틀코어 하나끼리 전환되는 CPU 마이그레이션
빅코어, 리틀코어 모두 사용할 수 있는 빅리틀 멀티 프로세싱.
 
그 중에서 우리가 만나게될 것은 CPU 마이그레이션이겠죠.

실제 칩으로 안드로이드에서 CPU 마이그레이션을 시연한 결과에요.

이 말은, 실제로 안드로이드에서 빅리틀을 구현하는 게 소프트웨어 상으로 별 문제가 없다는 말이에요.

빅리틀이 SMP와 뭐가 다를까요?
(SMP는 Symmetric Multi-Processing의 약자인데, 기존의 일반적인 멀티코어 제품들을 생각하면 돼요.)

SMP는 사용가능한 모든 코어에 일괄적으로 작업을 분배하여 최대 성능을 얻는게 목적이지만,
빅리틀은 작업의 요구성능에 맞는 코어에 작업을 분해하여 최대 전력효율을 얻는게 목적입니다.
목적이 다른만큼 방식도 달라진거죠.

이러면 빅리틀이 유용하다고 말할 수가 없겠죠.

용어가 복잡한데 내용은 별거 없어요. ㅎㅎㅎ
대부분의 프로세스가 실제 처리시간보다 처리 대기시간이 더 길고, 작업 우선순위에 따라 대기시간이
길어진다는 겁니다.

그래서 빅코어와 리틀코어를 사용하는 기준을 정합니다.
구체적으로 적혀있는데 간단히 정리하면, 가능하면 리틀코어를 사용하되, 

고정된 우선순위가 높거나하는 등의 다양한 이유로 인해 리틀코어가 버거워하는 작업은 빅코어로 처리한다는 거에요.

Vanilla 커널의 스케줄러에 의한 결과.

(안드로이드는 리눅스 커널 위에서 구현하는 가상머신으로 구동됩니다.)

1~7 까지의 프로세스를 처리한 결과입니다.
1, 2 는 idle 수준의 백그라운드 작업.
3, 4 는 무거운 작업.
5, 6, 7 은 가벼운 작업.

이상적인 빅리틀이라면 3, 4 에서 빅코어가 동작하고, 1, 2, 5, 6, 7 에서 리틀코어가 동작해야 합니다.
하지만 왼쪽 아래 결과를 보면 3번 프로세스에서 빅코어가 아닌 리틀코어가 동작하고 있죠.
그 결과 실행 시간이 길어졌어요. (세로가 시간축)
그리고 5, 6번 프로세스가 빅코어가 동작하고 있고, 리틀코어가 동작해야 할 1, 2번 프로세스에서 빅코어가
동작하고 있습니다.

총체적 난국이네요. ㅇㅊㅈ 처럼...

오른쪽 아래 그래프는 각 코어별 idle 상태에서 동작상태로 전환된 횟수로 보이는데, 빅코어의 전환 횟수가 많습니다.
쓸데없이 빅코어를 자주 사용했다는 말이 되네요.

이는 왼쪽 위의 그래프를 통해서도 확인됩니다.
왼쪽 위는 각 코어별로 idle 상태에서 동작 상태로 전환될 때까지의 시간 분포로 보입니다.
빨간색(동작상태)과 아주 어두운 색(100ms 이상)의 비중이 높은게 좋습니다.
전환 시간이 짧으면 그만큼 쓸데없이 동작했다가 안 했다가 한다는거니까요.
빅코어의 전환 시간 중에서 짧은 시간의 비중이 높으니 이 경우에는 문제가 있다는 말이에요.

빅리틀에 최적화된 스케줄러에 의한 결과입니다.

각 코어에 제대로 프로세스가 분배되었고, 빅코어의 전환 횟수도 크게 줄었습니다.
대신 리틀코어의 전환 횟수가 증가했지만 빅리틀에서 중요한건 빅코어의 제어이니 큰 문제는 없습니다.

그 결과 빅리틀로 4코어 SMP와 비슷한 수준으로 처리 시간이 단축되었어요.

위에서 본 실물 제품에서 테스트한 결과에요.
300MB 파일을 읽어와서 MD5 해시값을 계산하는 테스트입니다.

첫번째 작업(1st Run)은 MMC에서 파일을 읽어오는겁니다. (디스크 액새스 상태를 보면 알 수 있지요.)
부하가 낮은 작업이기때문에 A7만 동작합니다.

두번째 작업(2nd Run)은 해시값을 계산하는겁니다.
부하가 있으니 A15가 동작합니다.

빅리틀이 제대로 돌아간다는 얘기겠지요. ㅎㅎㅎ

좀 어려우셨나요? 사족이 좀 달린 경우도 있지만, 어쨌거나 이 글이 좀 도움이 되셨으면 좋겠네요.

그럼 눈팅러는 다시 눈팅하러 안녕!