1회. 컨슈머용 CPU

http://pc.watch.impress.co.jp/docs/column/1month-kouza/20140605_651740.html

 

지난 글에서 GPU의 아키텍처 변화를 소개했습니다. 하지만 GPU보다는 CPU가 더욱 극적으로 변화하고 있지요. 단순하게 말하면 필요로 하는 요구가 최근 몇년 사이에 급변하고 있으며 여기에 맞춰 아키텍처가 급속하게 교체되고 있는 것입니다. 이것은 단순히 내부 구조 뿐만 아니라 명령어 집합 자체의 교체도 포함한 대대적인 이야기가 됩니다. 컨슈머, 서버, x86, ARM으로 나눠 CPU의 상황에 대해 보도록 하겠습니다.

 

 

컨슈머용 CPU의 성능 경쟁 시대

 

컨슈머용 CPU는 스마트폰이나 태블릿이 보급되기 전까지 PC가 주류를 이루었으며 x86 프로세서가 그 중심에 있었습니다. 데스크탑과 노트북처럼 폼펙터-소비 전력 범위-에 차이는 있었으나 기본적인 목적은 얼마나 처리 성능을 높일 수 있느냐였으며, 그 주류인 x86프로세서도 이에 따라 진화했습니다. 간단히 요약하면-

 

명령 세트의 확충
8080→ 8086→ 80286→ 80386→ x64
MMX→ SSE→ SSE2→ SSE3→ SSSE3→ SSE4.1→ SSE4.2→ AVX→ AVX2

 

파이프 라인으로 IPC개선
386→ 486

 

슈퍼 스칼라로 IPC 개선
486→ P5


아웃 오브 오더로 슈퍼 스칼라 효율 개선
P5→ P6

 

슈퍼 스칼라의 규모 확대
코어→ 코어 2
아이비브릿지→ 하스웰

 

파이프 라인/하이퍼 파이프 라인으로 클럭 향상
P5→ P4(넷버스트)

 

SMT 도입으로 성능 개선


P4(넷버스트)→ P4(넷버스트)에 하이퍼스레딩
코어 2→ 코어 i


 

멀티 코어로 성능 개선

P4(넷버스트)→ 펜티엄 D

코어 2 듀오→ 코어 2 Q쿼드 등

 

-이렇게 됩니다.
 

1.jpg

 

펜티엄 4

 

그리고 파이프라인이 P5에서 P4로 가는 것이 잘못 표기한 건 아닙니다. 시장에 출시된 순서대로라면 P5→ P6→ P4(넷버스트)가 되지만, 인텔에서 아키텍트를 맡았던 Robert P. Colwell의 저서 THE PENTIUM CHRONICLES에 따르면 P6을 개발하던 중에 이미 P4의 개발도 시작했다고 합니다. 따라서 P6과 P4를 모두 P5의 후계자로 봐야 한다고 하네요. 먼저 P6이 나오고 이후에 P4가 나왔는데 만약 P6이 애슬론과 성능을 경쟁할 정도로 성능이 뛰어났다면 P4가 나올 일이 있었는지 생각헤 보게 됩니다.

 

이야기를 처음으로 돌아가서 이렇게 다양한 방법으로 성능을 개선했지만, IPC의 개선은 기본적으로 폴락의 법칙에 제약을 받습니다. 따라서 트랜지스터 수에 여유가 없다면 IPC를 올리기가 어렵습니다.

 

그래서 클럭을 높이는 방향으로 가다가 소비 전력의 증가 문제에 직면한 것이 프레스컷 코어의 펜티엄 4입니다. 인텔은 클럭을 더 이상 높이기가 어렵게 되자 다음 단계로 멀티스레딩과 멀티코어로 전체적인 성능을 개선하는 방향으로 가게 됐는데 이번에는 암달의 법칙에 마주하게 됩니다.

 

그 결과 나온 것이 헤테로지니어스-이종 혼합 구성입니다. CPU만으로는 성능 개선에 한계가 있으니 다른 아키텍처를 조합하는 게 바람직하다는 판단에서입니다.

 

원래 PC 이외의 시장에선 전용 가속 장치와 FPGA, DSP등 다양한 요소를 CPU 코어와 조합하는 방식을 오래 전부터 썼으며 PC용도 이를 따라하는 식입니다. 여기에서 GPU가 유력 후보로 오르면서 CPU+GPU의 조합이 나오게 됩니다.

 

2.jpg

 

AMD 카베리의 HSA

 

이런 움직임은 일찌기 2008년부터 시작했으나 2014년인 지금도 크게 벗어난 이야기는 아닙니다. 하드웨어야 어떻게 개선한다 치더라도 소프트웨어, 특히 애플리케이션의 대응에 시간이 걸리기 때문입니다. 하드웨어의 경우 AMD는 카베리에서 HSA의 1단계 목표인 CPU/GPU의 통합 메모리와 캐시 일관성을 실현하고 있으머, 이에 소프트웨어가 따라오길 기다리고 있는 상황입니다.

 

그리고 이러한 진화와 함께 또 다른 움직임이 2008년부터 벌어지고 있습니다. 그 계기는 넷북과 MID지요. 인텔은 아톰을 넷탑이나 넷북에 출시하면서 스마트폰을 경제하는 것 이상의 효과를 기대하진 않았습니다. 왜냐면 이 쪽 시장이 커질수록 수익이 높은 메인스트림 제품 시장이 줄어드니 판매량과 수익 모두 큰 손실을 보기 때문입니다.

 

결과부터 말하면 넷북/넷탑의 트렌드는 오래가지 않아 2009년에는 정리되는 분위기였습니다. 이때까진 애플리케이션의 실행에 클라이언트의 성능이 중요했던 점도 어느 정도 영향을 주었으리라 생각합니다. 운영체제는 물론 메일이나 오피스도 모두 클라이언트에서 처리했고 서버에서 실행하는 건 웹 브라우징 뿐이었습니다. 이 경우 넷탑/넷북의 낮은 성능은 그대로 부족한 애플리케이션 성능으로 이어집니다.

 

3.jpg

 

2008년 봄의 IDF에서 전시된 넷북

 

아무리 저렴하게 살 수 있어도 성능이 낮으면 안됩니다. 이는 초기 크롬북의 보급이 신통찮았던 이야이기도 합니다. 당시 웹 애플리케이션은 PC에서 동작하는 애플리케이션을 모두 대체할 수 있을 정도로 기능이 좋진 않았습니다. 워드 작업을 해도 크롬북에서 지원하는 프린터가 한정돼 있었고 애플리케이션은 오픈오피스밖에 없는 등 사실상 쓸모가 없었습니다.

 

또 넷북/넷탑에서 소프트웨어 자체는 작동하나 메모리 부족이나 스토리지 부족 등으로 폰트를 불러오지 못하거나 속도가 극단적으로 느리는 경우도 있었습니다. 결국 넷탑/넷북이 사리지게 된 것은 메인 PC를 대체할 수 없어서라 보입니다.

 

 

컨슈머용 CPU에 대한 요구가 변화

이 시나리오가 무너지지 않으면 앞으로도 인텔과 AMD는 여전히 잘 나갔을 터지만 그게 무너지고 맙니다. 그것은 스마트폰/태블릿이 급격하게 발전하고 이에 따라 클라우드 기반의 웹 애플리케이션이 활약하게 된 것이지요. 여기에 대해서 자세히 설명할 필요는 없을 것입니다. 웹서핑이나 SNS는 스마트폰만으로도 충분하다는 걸 다들 알고 계실 테니까요.

 

또 PC에 요구되는 성능 수준도 떨어졌습니다. 이것은 주로 안드로이드와 iOS의 보급에 따라 서버에서 처리를 수행하는 애플리케이션이 급속히 늘어나고 수준도 높아졌기 때문입니다. 윈도우조차도 그런 방향으로 나가고 있으며 오피스 온라인을 내놓고 있습니다. 상황이 이렇게 되자 대다수의 사람들에게 더 이상 고성능 CPU는 필요하지 않게 됐습니다. 오히려 저렴한 가격과 저전력이 중요해졌지요.

 

이런 상황에서는 CPU에 요구하는 내용도 달라집니다. 이를 자동차로 비유하자면 지금까지 12기통 엔진을 주로 쓰며 연비를 높일 때는 원래 8000rpm으로 회전해야 하는 엔진을 2000rpm으로 낮추는 식이었습니다. 엔진 자체의 힘이 있으니 2000rpm에서도 쓸만한 속도가 나오고 연비도 높지 않았으나, 원래는 8000rpm으로 회전해야 하는 것이다보니 불필요한 무게도 있고 스펙을 제대로 쓰지 못하는 점이 있었지요.

 

그럼 무게를 줄이기 위해 엔진 블럭을 줄이면 피스톤이나 콤 로드도 줄여야 하고 이걸 다 줄이면 균형이 무너지게 됩니다. 그러니 처음부터 높은 연비를 위한 작은 엔진을 새로 설계하는 것이 엔진의 크기를 줄일 수 있는 방법이고, 이는 차 전체의 크기를 줄이고 프레임의 무게를 줄이는 것으로 이어집니다. 즉 12기통 엔진을 절약하며 쓰는 게 아니라 처음부터 기름 소비를 줄인 2, 3기통 엔진을 필요로 하는 게 현재 컨슈머 PC 시장의 상황입니다.

 

4.jpg

 

서버 기반 애플리케이션의 대표적인 사례인 아이패드용 오피스.

 

한층 더 들어가, 서버 기반 애플리케이션이 보급되면서 x86 계열 CPU가 갖고 있던 바이너리 호환성이란 장점이 급격히 줄어들고 있습니다. 웹 애플리케이션에서 클라이언트의 CPU가 ARM인지 x86인지는 상관 없이 웹 브라우저가 작동합니다. 어도비 플래시는 이 분야에서 x86의 아성을 지키는 중요 플러그인이 됐지만 바꿔말하면 플래시만 안 쓰면 바이너리 호환성은 별로 따지지 않게 됩니다.

 

또 애플리케이션 중에 아이패드용 오피스가 등장하면서 진입 장벽이 줄었습니다. 오히려 최근에는 ARM 기반의 안드로이드 전용으로 NDK를 사용한 애플리케이션이 많아지면서 블루스택 같은 솔루션이 나오고 있습니다. 즉 x86이 정말 유리하다고 말하기 어려운 상황입니다. 이러다보니 인텔도 아톰의 성능을 높이고 가격을 낮추는 데 서두르고 있습니다.

 

반대로 ARM은 스마트폰과 태블릿으로 새로운 소비자 생태계를 확립하는 데 성공했습니다. 그리고 이런 시장을 더욱 넓히기 위해 주력하고 있지요. 또 서버 분야에서도 보급을 계획 중이며 이러다보니 Cortex-A12가 뒤늦게 나오는 등 복잡한 사정이 있지만, 여기에 대해선 아래 부분에서 자세히 설명하도록 하겠습니다.

 

이처럼 컨슈머용 CPU의 경쟁은 최근 몇년 동안 완전히 달라졌습니다. 사실 이것을 기회로 삼을 수 있는 의외의 회사라면 AMD가 아닐까 생각되네요. 불도저 계열은 성능 경쟁에서 인텔이게 뒤져 시장을 잃어버릴뻔 했지만, 밥캣 계열 코어의 존재와 저전력/저가형 코어로 변환으로 다시 경쟁에 뛰어들 수 있게 됐습니다. 이것도 나중에 설명하지요.

 

 

2회. 서버용 CPU

http://pc.watch.impress.co.jp/docs/column/1month-kouza/20140612_652900.html

 

 

스케일 아웃으로 성능을 높인 구글

 

1회에선 컨슈커용 CPU가 왜 이렇게 됐는지를 이야기했지만, 사실 더 극적으로 바뀐 건 서버용 CPU입니다.

 

서버 분야에서 무엇이 변했냐면 바로 스케일 업에서 스케일 아웃으로 전환됐다는 점입니다. 둘 다 전체 성능을 높인다는 점에서는 비슷하지만 근본적인 부분에서 다릅니다.

 

스케일 업은 서버 자신의 처리 성능을 높여 성능을 개선하는 데 비해 스케일 아웃은 서버 자신의 처리 성능은 그대로 두고 서버의 수를 늘려 성능을 개선하는 것입니다.

 

이 근본적인 방식의 차이로 자주 거론되는 것이 구글입니다. 구글이 스케일 아웃을 따로 고른 건 아니지만 눈에 띄는 스케일 아웃의 성공 사례라는 점에서 주목할 만 합니다.

 

구글이 서비스를 시작한 1990년 후반에는 알타비스타라는 강력한 검색 엔진이 있었습니다. DEC-컴팩의 알파 프로세서를 탑재한 서버에서 작동하는 것으로 당시로선 매우 강력한 검색 엔진이었으나, 이후 구글의 엔진에 비해 성능과 검색 결과에서 뒤쳐지고 DEC에서 분사된 뒤 몇몇 회사가 인수했습니다. 마지막엔 야후의 일부로 서비스를 계속했으나 2013년 7월에는 중단됐죠. 여기서 구글이 알타비스타를 이긴 이유 중 하나가 높은 성능을 내기가 쉬웠다는 점을 간과해선 안되겠습니다.

 

그럼 구글이 어떻게 성능을 높일 수 있었을까요? 처음부터 여러 컴퓨터를 잘 연동해 부하를 분산하는 구조를 생각했다는 데 있습니다. 2000년대 중반까지 구글 검색 엔진의 특징을 나타내는 키워드로는-

 

Google File System(GFS):

다수의 기기/HDD를 대상으로 하는 거대한 파일 시스템입니다. GFS는 Write Once/Read Many라는 사용법을 전제로 해서 여기에 따른 구성을 실현했습니다. 또 오류 보정이 확실하게 들어가는 것도 특징.

 

BigTable:

Google Search Engine에서 쓰이는 데이터베이스의 성격을 지닌 분산 스토리지 시스템. GFS에서 가동되며 그 내부는 태블릿이라 불리는 단위로 분할됩니다. 각각의 태블릿은 태블릿 서버에서 관리되며 이 수를 늘리면 성능이 높아집니다. 

 

Chubby:

분산 고정 서비스. 일종의 파일 시스템이지만 용량이 작아(201KB) 파일 락이나 이벤트 통지 등에 쓰입니다. GFS 이상의 오류 보정 기능이 들어간 것도 특징. 

 

MapReduce:

대규모 분산 처리를 위한 범용 미들웨어.

 

Sawzall:

소규모 분산 처리를 실현하기 위한 전용 프로그래밍 언어.

 

등의 용어가 나옵니다. 이것들은 그전까지의 서버와 완전히 다른 발상이라고 봐도 좋습니다. 물론 이를 지탱하는 OS도 독자적인 것입니다. 구글이 대단한 것은 이러한 OS, 미들웨어, 언어를 자체적으로 구성하기 때문.

 

이 결과 무엇이 생겼는지를 새삼스럽게 설명할 필요는 없을 것입니다. 좀 오래된 통계이긴 한데 구글 I/0 2008에서 제시된 몇 가지 숫자를 소개하지요.

 

1. 전 세계에 36개의 데이터 센터가 있고 각각의 데이터 센터엔 최소 수십개의 컨테이너가 설치되며 그 컨테이너마다 1160개의 서버가 탑재

2. GFS는 수십PB(수천TB)의 파일을 다수 저장합니다. GFS는 2백개 이상의 클러스터로 구성되는데 대부분의 클러스터는 수천대의 서버로 구성

 

그동안 덩치를 늘려 성능을 높이던 서버의 경우 1개의 프로세서에 얼마나 많은 코어를 탑재하고 그걸을 얼마나 밀접하게 결합시키는지가 중요했습니다. 제온을 예로 들면 현재 하이엔드인 제온 E7-8800 시리즈가 최대 15코어에 8프로세서 구성이 가능하기에 120코어의 서버를 구축할 수 있습니다.

 

또 서버 제조사 중에는 이 120코어 프로세서를 1개의 클러스터로 간주해 다수의 클러스터를 독자적인 백플레인에서 연결, 더욱 밀도가 높은 서버를 구축하는 경우도 있습니다. 그러나 이렇게 한다고 해도 구글이 필요로 하며 실제로 운용하는 규모와 비교하면 수백분의 1밖에 안됩니다.

 

이러한 움직임이 구글 뿐이라면 업계 전체의 트렌드가 되지는 않았을 것입니다. 실제로는 트위터, 페이스북, 아마존, 이베이처럼 대규모 서비스를 제공하는 업체는 잇따라 구글처럼 스케일 아웃 쪽으로 가닥을 잡아가고 있는데요. 여기에는 클라우드 컴퓨팅의 보급이 있습니다.

 

클라우드 컴퓨팅이라는 말을 처음 쓴 것은 구글의 전 CEO인 Eric Schmidt입니다. 2006년에 처음 한 말이지요. 이후  2011년에 NIST(미국 국립 표준 기술 연구소)가 The NIST Definition of Cloud Computing(http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf)라는 문서를 통해 클라우드를 정의했습니다.

 

다만 그 전에도 비슷한 일은 있었습니다. Salesforce는 1999년에 서비스를 시작했고 아마존은 Amazon EC2를 2006년에 베타 테스트하는 등 다양한 회사가 클라우드 컴퓨팅을 향해 발전해 왔습니다. NIST은 어떤 의미에서 이런 상황을 정리한 것이라 할 수 있겠습니다. 그 결과 클라우드를 제공하려면 기존의 스케일 업 형태의 서버론 무리고 스케일 아웃 아키텍처가 필요하다고 명확하게 드러났음이 중요하다 할 수 있겠습니다.

 

물론 이론적으로는 스케일 업으로도 에서도 여러가지 클라우드의 서비스를 제공할 수 있지만, 이렇게 하면 스케일 아웃에 비해 시스템 구축 비용이 2, 3자리수 늘어나게 되기에 스케일 업을 선택해야 할 이유는 거의 없습니다.

 

 

x86 서버에 달려드는 클라우드 컴퓨팅의 물결 

 

그 결과 기존의 x86서버 시장은 두가지 충격을 입게 됩니다. 첫번째는 x86의 소프트웨어 호환성이 꼭 필요하지 않게 됐다는 것입니다. NIST의 정의를 보면 클라우드에 SaaS, PaaS, IaaS의 3종류가 있습니다. 이 중 IaaS(Infrastructure as a Service)은 하드웨어, OS/미들웨어를 제공하는 형태가 되기에 기존의 애플리케이션을 그대로 실행하는 경우가 많고 호환성은 있는 편이 좋습니다. 기본적으로 가상화 환경이라 하드웨어 호환성이 없어도 소프트웨어 에뮬레이션으로 해결할 수 있지만 하드웨어에서 직접 실행하는 게 당연히 효율은 좋거든요. 

 

그런데 SaaS(Software as a Service)과 PaaS(Platform as a Service)의 경우 우선 제공되는 환경에서는 기존의 소프트웨어가 작동하지 않습니다. 데이터베이스 액세스만 해도 클라우드의 표준 사용 데이터베이스는 애시당초 SQL이 아니기 때문입니다. 이를 이용해서 구글은 클라우드에서 작동하는 MySQL을 구글 클라우드 SQL이란 이름으로 2012년부터 제공해 화제를 불러 일으켰는데, 이것이 화제가 됐다는 건 그만큼 드문 사례라는 말이 되겠습니다.

 

따라서 지금까지 서버에서 동작하는 각종 애플리케이션을 클라우드에서 실행할 경우 기본적으로는 개발과 설계를 다시 해야 합니다. 이용할 수 있는 기능과 사용 방법이 그 동안의 서버 OS에서 제공했던 것과 상당히 다르기 때문입니다. 그 결과 기존 애플리케이션과의 호환성은 없다고 봐도 무방합니다. 기존 애플리케이션과의 호환성이 x86 계열 프로세서의 가장 큰 장점이었는데 그것이 사라진 것입니다. 실제 성능만 나온다면 PowerPC건, MIPS건, ARM만 상관 없게 됐습니다. 

 

사실 이러한 트렌드는 클라우드가 나오기 전부터 있었습니다. 웹 기반 애플리케이션의 경우 자바 등의 프로그래밍 언어로 작성되는 경우가 많고, 그 경우 서버 아키텍처가 뭐건 그저 자바가 빠르게 동작할 수 있기만 하면 됩니다. 이러한 트렌드가 클라우드의 진화에서 더욱 퍼지고 있는 것입니다.

 

두번째 충격은 스케일 아웃 구성의 경우 각 노드의 성능이 그리 높을 필요가 없다는 것입니다. 오히려 수가 늘어나는 만큼 어떻게 하면 소비 전력을 줄이는지가 중요합니다. AMD가 2006년에 주장한 전력 대 성능비가 중요하다고 한 것이 현실이 된 것이지요. 그 결과 지금까지는 서버라고 할 경우 인텔 제온과 AMD 옵테론처럼 하이엔드 구성의 코어가 필요했던 것이 성능은 낮지만 가격이 저렴한 코어만으로도 구성 가능하게 됐습니다. 즉 ASP(평균 소매 가격)이 급격히 떨어져 버린 셈입니다. 물론 CPU의 수 자체는 분명히 기존보다 늘어났지만 수익이 줄어 박리다매로 가지 않을 수가 없게 됐습니다.

 

인텔을 예로 들면 제온 E7등의 상위 제품의 비율이 극단적으로 줄어면서 제온 E5나 E3로도 충분하고, 경우에 따라서는 데스크탑용 펜티엄 등에서도 된다는 것입니다. 그렇게 되면 인텔은 펜티엄 정도의 가격대로 서버용 시장에서 수익을 제대로 낼 수 있는 제품이 필요하게 됩니다.

 

이런 상황에 따라 나온 것이 In-Memory Processing입니다. 그동안 데이터베이스는 하드디스크를 비롯한 스토리지에 데이터를 저장하고 이를 불러와 처리했습니다 하드디스크에 추가로 SSD를 넣고 캐시로 쓰거나 하드디스크를 SDD로 바꿔 속도를 높이기도 했지만 당시 SSD의 속도와 용량을 바꾸면 SSD로의 전면 교체는 상당히 리스크가 높았습니다.

 

그러다보니 차라리 하드디스크를 쓰지 않고 모두 메모리에 상주시켜 속도를 높이는 발상이 나오게 되는데 이것이 바로 In-Memory Processing입니다. 허나 2006~2008년의 메모리 용량을 보면 제온 급의 멀티 프로세서 시스템이 고작 64GB 정도였으며 평범한 기기는 1,2GB였기에 절대적인 메모리 용량이 부족했습니다.

 

그러나 다행히 이를 보완하는 Memcached라는 소프트웨어가 2003년부터 배포됐습니다. 탑재된 메모리를 최대한 사용해 데이터베이스를 캐싱하는 것이지요. 물론 장착된 메모리가 2GB일 경우 캐싱되는 용량은 1.5GB 정도였지만 여러대의 기기를 조합할 수 있다는 게 컸습니다. 1대당 1.5GB라 해도 100대라면 150GB의 데이터베이스 캐시를 실현하는 것이죠. 데이터베이스를 통째로 캐싱하긴 부족하나 데이터베이스 액세스는 인덱스나 일부 테이블을 자주 쓰는 경우가 많기에 그것만 캐싱해도 속도를 크게 높일 수 있었습니다.

 

더군다나 이 Memcached라는 것은 리퀘스트를 받아->거기에 해당하는 데이터를 메모리에서 불러와->결과를 보고하는 것이 전부라서 높은 처리 성능이 필요한 것도 아니었습니다. 

 

페이스북의 경우 앞서 소개한 것들을 더욱 스케일 업한 형태로 활용합니다. 그리고 인텔이 아보톤에서 도입한 것이 바로 이러한 스케일 아웃과 CPU 연산이 집중되지 않는 작업을 위한 것임을 알 수 있습니다. 특히 빅 데이터를 취급하는 시장의 경우 처리의 대부분은 분석보다 데이터의 정리에 소모됩니다. 이 경우 메모리 액세스의 성능이 더욱 중요합니다. 한편 스케일 아웃이 진행되면서 CPU 코어끼리의 공동 작업은 그 빈도가 훨씬 줄어들게 됩니다.

 

원래 인텔이 생각했던 시나리오는 이랬습니다.

 

1.  기존 서버의 하드웨어만 최신 시스템으로 교체해 시스템 구동 원가를 줄인다(성능 대 소비 전력의 향상). 이 경우 기존에 사용하던 소프트웨어를 바꿀 필요는 없으며, 서버의 수는 줄어들게 된다.

 

2. 그러나 처리해야 할 데이터의 용량이나 데이터의 복잡도는 시간이 흐를수록 늘어나기에 이를 감당하려면 기존과 동일한 수량의 서버를 도입해야 한다. 따라서 지속적인 매출이 가능하다.

 

허나 클라우드가 등장하면서 이렇게 바뀌었지요.

 

1. 기존 서버의 애플리케이션을 클라우드로 이행시켜 기업이 따로 보유한 서버 수가 줄어듬. 클라우드로 가지 못한 애플리케이션은 계속 기존 하드웨어로 처리하나, 새로 도입되는 경우는 클라우드에서 수행하는 쪽으로 나가고 있음. 결국 서버의 수가 줄어듬.

 

2. 클라우드 서버는 스케일 아웃을 기반으로 하기에 하이엔드 서버의 수요가 점점 줄어듬.

 

따라서 아보톤이 나온 이유는 2번 시장을 사수하기 위해서라고 보면 되겠습니다. 

 

 

Cotex-A15의 조기 출시로 서버 시장에 포석을 깔은 ARM

 

이러한 시장 변화는 새로운 기업에게 있어 큰 기회를 제공하게 됩니다. ARM이 2010년에 Cortex-A15 설명회를 열었을 때의 슬라이드를 보면 이 코어가 ARM이 서버 시장에 진출하기 위한 초석으로 나왔음을 알 수 있습니다. 

 

5.jpg

 

당시만 해도 클라우드라는 용어를 쓰진 않았습니다.

왜 초석이라고 하냐면 갑자기 새로운 CPU가 나온다고 해도 바로 채용이 이루어지는 건 아니기 때문입니다. 이는 x64(x86-64)때도 그랬지만 새로운 플랫폼을 도입하고 싶다면 먼저 하드웨어를 만든 후 거기서 실행되는 인프라를 갖춘 후 애플리케이션이 옮겨지고 나서야 도입을 하게 됩니다.  AMD는 해머 아키텍처에서 x86-64를 도입했지만 윈도우가 이를 지원한 건 64비트 버전의 XP가 나온 후이며 본격적인 보급이 시작된 건 윈도우 비스타를 거쳐 윈도우 7이 나온 후입니다. 

 

ARM도 같은 입장이었습니다. 당시엔 서버에서 ARM의 플랫폼이 없는 것이나 마찬가지였지요. 그래서 우선 서버에 쓸 수준의 하드웨어로서 Cortex-A15를 발표하고 다양한 제조사가 OS와 미들웨어를 지원하길 추진한 후 겨우 애플리케이션이 등장하게 됐습니다. 

 

실제로 ARM 서버는 Cortex-A15의 다음 제품인 Cortex-A57에서 본격적으로 64비트 지원을 추진하게 되는데 이를 실현하기 위해선 우선 Cortex-A15를 내놓고 시장을 다질 필요가 있었습니다. Cortex-A15를 바탕으로 본격적인 서버가 나올 것이라고는 ARM 스스로도 기대하지 않았습니다.

 

다만 이 시기엔 ARM도 고생하고 있었음을 짐작할 수 있습니다. Cortex-A15는 3.5 DMIPS/MHz의 높은 성능을  실현하기 위해 4명령의 슈퍼 스칼라/아웃 오브 오더로 구성돼 있습니다. 이것은 분명 모바일용치고는 성능과 소비 전력이 모두 높은 편이며 그 때문에 Cortex-A7와 조합하는 big.LITTLE로 소비 전력을 억제할 필요가 있었습니다. 다만 Cortex-A7은 1.9 DMIPS/MHz 정도의 처리 성능을 지녀 Cortex-A15와는 성능 차이가 제법 납니다.

 

2014년에 출시된 Cortex-A12는 3 DMIPS/MHz 정도로 성능을 억누른 대신 소비 전력을 모바일에서 쓸만한 수준으로 낮춘 코어로 Cortex-A7와 성능의 균형도 좋습니다. 실제로 모바일 버전만 따지면 Cortex-A12만으로도 쓸만한 수준이며 Cortex-A15는 다소 스펙이 높습니다. 다만 ARM도 Cortex-A12와 Cortex-A15를 동시에 개발하는 건 무리기에 하나를 먼저 할 필요가 있었습니다. 그 결과 어찌됐던 간에 서버용 제품을 빨리 내놓지 않으면 안 된다고 판단해서 Cortex-A15이 먼저 나왔다고 추측해 봅니다.

 

그래서 어떻게 됐을까요? 아래 사진과 같은 프레젠테이션을 2012년 말에 내놓을 정도가 됐습니다. 이것은 서버용이라고 뭉뚱그려 말해도 용도에 따라 적절한 코어가 다르다는 이야기인데, 파란색으로 표시한 Static Web나 CDN(Contents Delivery Network), Caching/NoSQL은 ARM 아키텍처가 효율적이라는 이야기입니다.

 

이 Caching/NoSQL가 바로 Memchached입니다. ARM과 인텔 중 어느 쪽이 먼저일지는 판단하기 어렵지만 결과적으로 Cortex-A15 기반 SoC와 인텔 아보톤은 같은 시장을 공략하며 구성도 비슷하기에 서로 경쟁하게 되는 셈입니다.

 

6.jpg

 

ARM Techcon 2012의에서Keith Clarke(VP, Embedded Processor, Processor Division)이 제시한 슬라이드

 

여기서 매우 재밌는 것이 AMD의 입장입니다. 불도저 계열 제품은 원래 서버용이며 멀티 스레딩에 특화된 아키텍처입니다. 다만 시도는 좋았으나 실제로는 여러가지 문제가 있어, 지금은 다들 아시는 대로 AMD는 서버 시장에서 영향력을 거의 잃어버리게 됐습니다.

 

그러던 것이 클라우드나 스케일 아웃 같은 같은 트렌드, 그리고 ARM 아키텍처의 발전에 따라 AMD는 부활할 계기를 찾은 것으로 보입니다. 2014년 5월에 발표된 로드맵에선 내년 내놓을 스카이브릿지에서 밥캣 계열의 퓨마+ x86 코어를 사용한다고 밝혔습니다.

 

퓨마+는 아보톤에 쓰이는 실버몬트와 비슷한 성능/소비 전력/다이 크기를 지닌 코어로 만약 x86 아키텍처가 필요할 경우 아보톤과 경쟁해 볼만 합니다. 그리고 그게 안된다 하더라도 Cortex-A57 기반 코어를 제공하면 됩니다. 그러나 인텔과 ARM 중 유리한 쪽을 고를 수 있게 되는 것입니다. 위에선 클라이언트 쪽에 치중해 이야기했지만 서버용에서도 저가형/저전력의 분위기에 일단은 AMD가 줄을 잘 선것처럼 보입니다.

 

 

3회. x86 계열 프로세서

http://pc.watch.impress.co.jp/docs/column/1month-kouza/20140619_654007.html

 

 

위에선 시장이 어떻게 변화했는지를 소개했습니다. 이번에는 그 결과 프로세서가 어떻게 바뀔 것인지를 설명하려 합니다. 우선 x86, 그것도 본가인 인텔부터 보도록 합시다.

 

7.jpg

 

코어 i7/i5/i3 브랜드의 1세대가 되는 네할렘

 

2006년에 CPU에 대한 인텔의 입장은 어쨌든 IPC(클럭 당 성능)을 올리는 것이었습니다. 다만 x86 명령 자체의 IPC를 올리기는 쉽지 않습니다. 그래서 멀티 코어나 SIMD 명령의 확장, 또는 가속기를 도입하는 식으로 성능의 인상을 높여 왔습니다.  IPC를 높이기가 어렵다는 건 SSE4 명령과 가속기에서 볼 수 있는 인텔 CPU의 방향성 부분에서 언급됐던 Joel S. Emer의 말을 봐도 알 수 있습니다.

 

"싱글 코어의 ILP는 앞으로도 계속 늘어납니다. 하지만 그렇게 눈부신 변화는 아닙니다. ILP를 높이기 위한 댓가가 갈수록 늘어나기 때문입니다. 우리는 앞으로 코어를 계속 확장해 나갈 것이나, 실리콘을 보다 효율적으로 사용하기 위해 CPU 코어의 수도 늘립니다. 이렇게 LIP과 TLP 조합의 균형을 잡는 것입니다."

 

또 아키텍처적으로 보면 아직까진 밀접한 결합을 통해 스케일 업 쪽으로 확장하는 것을 전제로 하고 있습니다. 이것은 2007년의 네할렘 프로세서 확장에 대한 것만 봐도 알 수 있습니다. 스케일 업의 경우 기본적으로는 메모리 공간이 UMA(Unified Memory Address 공유 메모리)구성이 아니라 만들기 어렵고, 이를 실현하기 위해선 메모리 컨트롤러가 넓은 대역/낮은 레이턴시의 인터커넥터로 연결될 필요가 있습니다. AMD의 하이퍼트랜스포트에 이어 인텔이 CSI(나중의 QPI:QuickPath Interconnect)을 도입한 것은 스케일 업할 때 충분한 성능을 확보하기 위한 수단입니다.

 

그러나 그렇다고는 해도 이 시점에선 기본적인 방향이 IPC의 향상으로 가고 있었습니다. 네할렘의 내부 구조는 전력 절약화-소비 전력을 크게 늘리지 않는 선에서-을 지키면서 IPC를 올리는 방향으로 최적화됐습니다. 또 이 세대까지는 스케일 업 규모를 어디까지 늘릴지 확실하게 정하지 않았으며 지금보다 큰 규모로 확장할 여지를 남겨두는 식이었습니다. 

 

이와 함께 인텔은 저전력 제품의 포트폴리오도 확충하기 시작했습니다. 바로 아톰입니다. 2007년에는 첫 코어인 본넬이 나왔습니다. 저가형, 저전력의 시장을 겨냥한 모바일 CPU로 소비 전력을 낮추기 위해 트랜지스터를 줄여야 했는데, 그래서 인 오더 구성을 사용했습니다.

 

이는 초대 LPIA(Low Power IA) 프로세서인 도썬이 아웃 오브 오더/슈퍼 스칼라 구성이었던 것과 비교하면 반대 방향의 진화라고 말할 수 있겠습니다. IPC를 낮추지만 파이프라인을 늘려 빠른 클럭으로 보완한다는 기존의 접근 방법과도 다릅니다. 인텔은 이 코어를 모바일 외에도 SoC 등에 널리 쓰는 것을 염두에 두고 있었는데 그 1세대가 Tolapai, 2세대가 Lincroft입니다.

 

8.jpg

 

Diamondville의 초대 아톰

 

9.jpg

 

아톰 기반 SoC인 Tolapai의 다이

 

그런데 여러가지 의미로 아톰은 불우했습니다. 이 글의 첫머리에서 설명한 대로 당시엔 아직 스마트폰 같은 환경이 없어 넷북/넷탑으로 활로를 찾았고 그 결과 아톰은 인텔의 기존 저가형 시장과 경쟁하게 됩니다. 그 결과 넷탑/넷북용 아톰 시장은 인텔의 기대만큼 늘어나진 않았습니다.

 

네할렘으로 돌아가서, 네할렘의 아키텍처가 굳어진 것은 2003년이라고 합니다. 이 시점에서 프로세서 개발의 트렌드는 멀티 코어에 의한 스케일 업이었기에, 이때는 스케일 아웃까지 생각이 미치지 못했을 수도 있습니다. 그리고 이후엔 Tick-Tock 모델로 매년 새로운 코어를 출시하는데 이 때문에 피할 수 없는 한계가 생겨나게 됩니다. 

 

Tick-Tock의 경우 새 프로세스와 새 아키텍처를 2년 주기로 내놓는 것인데요. 프로세스에 어쨌든 간에 프로세서 아키텍처로 새로 만드는 데엔 4~5년에 걸립니다. 이걸 거꾸로 말하면 2년마다 새로운 아키텍처를 내놓기 위해선 적어도 3개의 팀이 번갈아가며 개발을 해야 합니다. 인텔은 미국 오레곤주와 이스라엘 하이파에 설계팀을 갖고 있으나 이 외에도 개발할 것이 있으니 2년 주기로 완전히 새로운 아키텍처 개발을 할 여력은 없습니다. 그러다보니 기존 세대 제품을 일부 개량하는 식이 될 수밖에 없습니다.

 

그 결과 샌디브릿지는 네할렘을 충실하게 확장한 제품이 됐고, 아이비브릿지는 22nm FinFET 프로세스를 도입했을 뿐 아키텍처 자체는 샌디브릿지와 비교해서 그렇게 큰 차이가 나진 않았습니다.

 

10.jpg

 

하스웰. 4세대 코어 프로세서

 

이 때부터 인텔의 미래엔 먹구름이 드리우기 시작합니다. 데스크탑용 제품의 판매가 줄어들고 모바일 부분이 늘어난다는 시나리오는 2006년부터 계속해서 나왔던 것이지만, 여기에 더해 PC의 수요 그 자체가 줄어들면서 제품 라인업을 재검토하지 않으면 안되게 됐습니다. 특히 중요한 건 그동안 높은 성능, 많은 소비 전력의 프로세서 위주로 흘러가던 것이, 모바일 시장의 발전으로 상대적으로 저전력 제품이 주류가 됐다는 것입니다.

 

이것은 물론 인텔도 예측한 것입니다. 허나 인텔이 예측하지 못한 것이 있다면 서버까지 저전력 위주가 됐다는 것입니다. 그렇다고 해서 프로세서의 마이크로 아키텍처를 급속하게 바꿀 수도 없고 제조 공정 역시 단기간에 바꿀 수 없는 것입니다. 그 결과 하스웰에선 전력 절약을 강화함과 동시에 전압 조정기를 통합해 효율을을 개선하고, 일부 제품군에는 eDRAM 솔루션을 제공함으로써 절대적인 성능의 향상 외에도, 클럭을 줄인 모델에서도 성능을 유지하는 데 성공했습니다. 

 

또 새로 등장할 브로드웰 세대에선 제조 공정 자체를 저전력 쪽으로 옮겨가 전력 절약의 수요에 부응하게 됩니다. 기존의 인텔 제조 공정은 짝수 번호(P1266/1268/1270)가 CPU, 홀수 번호(P1267/1269/1271)가 SoC용이며, 이 규칙에 맞춰 가면 14nm 공정의 P1272는 CPU용으로 속도가 빠르고 소비 전력이 높은 제조 공정이 될 것이었지만, 실제로는 SoC의 속도가 느리고 소비 전력이 낮은 프로세스를 먼저 도입하기로 결정했습니다.

 

이에 따라 데스크탑용 브로드웰이 등장하는 건 2015년 이후가 됐고 그 결과 데스크탑에는 하스웰 리프레시가 나오게 됩니다. 또 처음으로 등장하는 브로드웰은 대부분이 저전력 제품으로 채워집니다.

 

 

인텔은 14nm 세대에서도 이 노선을 강화해 갑니다. 처음으로 출시되는 코어는 에어몬트로 Tick에 해당하는 프로세스 미세화 버전이라 그리 큰 기능 추가는 없을 것이라 보입니다. 다만 이후에는 골드몬트라 불리는 기능 확장 코어도 예정돼 있어 인텔이 이쪽에 주력하는 것으로 나타났습니다. 스카이레이크에 이어 Cannonlake라는 기존의 메인스트림 코어가 앞으로도 높은 IPC/높은 소비 전력을 유지할 것인지, 아니면 경량화된 코어로 나갈지는 아직 밝혀지지 않았습니다.

 

 

밥캣과 재규어로 살아난 AMD

 

그럼 다른 x86 프로세서 개발사인 AMD는 어떨까요. AMD는 ATI 인수로 APU라는 카테고리를 만들기로 결정하며 이에 따라 라노->트리니티/리치랜드->카베리라는 라인업을 메인스트림용으로 제공했습니다. 그리고 이제 남은 건 서버 시장의 점유율 확대지요. 실제로 인텔이 코어 마이크로 아키텍처 기반을 내놓기 직전에 AMD의 서버 시장 점유율은 30%를 넘었습니다. K8 기반의 멀티 코어-넷버스트 기반 멀티 코어는 성능은 물론 전력 대 성능 비에서도 넷버스트보다 기반 멀티코어보다 뛰어난 게 당연하지만요.

 

그런데 인텔이 코어 마이크로아키텍처 기반 우드크레스트를 투입하면서 절대 성능은 물론 성능/소비 전력 대비에서도 K8 기반의 옵테론을 웃돌게 됩니다. AMD가 출시한 바르셀로나 코어는 내부 구조를 크게 강화했으나 전력 소비량 역시 급격히 늘어나 시장에서 외면받았습니다. 45nm인 상하이와 이것의 6코어인 이스탄불이 출시되며 상황은 다소 개선됐지만, 결과적으로 AMD는 서버 시장을 조금씩 잃기 시작했습니다.

 

불도저는 이 상황에 제동을 걸고 역적하기 위한 무기였으나 동시에 AMD의 실수라고도 할 수 있습니다. 불도저의 설계 목표와 판단 자체는 틀리지 않았습니다. 문제는 급격하게 스케일 아웃으로 향해가는 시장을 그리 고려하지 않았다는 것입니다. 그 결과 불도저는 스레드 당 성능은 몰라도 절대 성능은 별로 높지 않은 코어가 됐습니다. 이 낮은 성능을 커버하기 위해 클럭을 높이다보니 소비 전력이 늘어나, 바르셀로나의 악몽이 재현됐다는 상황에 빠지게 됐습니다.

 

12.jpg

 

불도저 모듈

 

돌아보면 불도저는 너무 미온적인 것이었습니다. 디코더는 4명령/사이클로 네할렘에 견줄 만했으나 강제적으로 2개의 스레드에 나누면서 실제로는 2명령/사이클밖에 안되 절대적인 성능은 스펙을 따라가지 못했습니다. 오히려 멀티 스레드에 최적화된 애플리케이션에서 나름대로 성능이 나왔지만 클라우드에서 요구하는 스케일 아웃 형태의 애플리케이션을 작동하기엔 CPU의 소비 전력이 많고, 스케일 아웃을 요구하는 현장에선 프로세서 수를 크게 늘릴 수 없다는 게 단점이 됐습니다.

 

즉 불도저는 어디까지나 스케일 업의 사용법에 맞춰 멀티 스레드에 특화한 코어일 뿐이라, 이 판단이 잘못됐다는 게 드러난 순간에 버려진 자식 취급받은 건 어쩔 수 없는 일입니다. 이 결과 안그래도 낮은 AMD의 서버 시장 점유율은 거의 0에 가깝게 떨어지게 됐습니다.

 

AMD는 불도저의 차기작인 스팀롤러에서 디코더를 약간 강화하고 디코더를 분리해 성능을 강화했으나, 디코더와 실행 유닛을 조합해 쓰지 않으면 별 의미가 없는 것이었고, 그렇게 만들면 불도저의 장점인 '상대적으로 작은 코어'와는 멀어지게 됩니다. 그 결과 기존의 로드맵에서 제시됐던 스팀롤러의 후속작 Excavator는 로드맵에서 사라지게 됐습니다

 

13.jpg

 

AMD의 구세주. 밥캣 코어

 

이는 AMD에게 심각한 상황으로 x86 사업이 위기에 빠질 뻔 했으나 의외로 그 영향은 크지 않았습니다. AMD의 구세주는 불도저와 동시에 개발된 밥캣 코어입니다. 임베디드와 모바일 등의 저전력 시스템을 위해 개발된 코어로, 크기가 작으면서 슈퍼 스칼라/아웃 오브 오더의 균형 잡힌 구조를 지녔으며 같은 세대의 공정을 쓴 아톰보다도 더 작습니다. 말하자면 인텔의 실버몬트 코어를 3년 먼저 내놓은 것이 밥캣이라 할 수도 있을 것입니다. 이 결과 급격히 늘어난 스케일 아웃 형태의 서버 시장에 AMD는 밥캣을 바탕으로 한 SoC를 공급하게 됩니다.

 

뒤이어 AMD는 이 밥캣 코어를 개량한 재규어를 출시합니다. 최대 성능에서 따지자면 아톰보다 나은 수준밖에 안 되니 메인트스트림에 넣기엔 무리가 있으나, 로우엔드나 태블릿에서 쓰기엔 충분하며 또 쿼드코어 구성을 하면 전체적인 성능은 그리 나쁘지 않게 됐습니다. 게다가 이 재규어 코어는 플레이스테이션 4와 Xbox One에도 쓰이는 등 AMD가 당초 생각했던 것보다도 많이 쓰이게 됩니다. 이 결과 AMD는 x86 프로세서 사업을 재규어와 그 후속작인 퓨마+ 코어 위주로 재편하게 됐습니다.

 

이렇게 불도저 기반의 옵테론이 지지리도 팔리지 않은 덕분인지 AMD는 빠르게 64비트 ARM 코어로 갈아탄다는 결정을 내릴 수 있었습니다. 만약 불도저가 조금만 더 성적이 좋았다면 이런 결단을 내릴 수 있었을진 모를 일입니다. 더 잃을 게 없으니 아키텍처를 바꿀 시기로 삼았고, 그 결과 64비트 ARM 서버 시장에 먼저 뛰어들 수 있게 되면서 현 시점에선 그나마 다행이라 말할 수도 있겠습니다.

 

14.jpg

 

AMD의 로드맵

 

PC용 메인스트림에서는 APU가 나름 잘 싸우고 있습니다. 순수하게 CPU 성능만 따지자면 하스웰에 미치는 수준은 아니지만, 위에서 말한대로 절대적인 CPU 성능을 요구로 하는 상황이 줄어들고 있기에 이는 치명적인 문제가 되진 않습니다. 또 GPU 코어의 성능은 인텔을 압도했고 균형이 잘 잡혀 있기 때문입니다.

 

이러한 상황이 합쳐지면서 재무 상태는 어떻든 간에, AMD가 제공하는 제품 포트폴리오라는 점에서 보면 AMD는 주요 시장에서 인텔과 대등한 라인업을 제공할 수 있게 됐습니다. 게다가 앞으론 ARM 시장도 접할 수 있게 되면서 한때 위태위태하던 상황에서 벗어낫다고 볼 수 있을지도 모르겠습니다. 

 

 

4. ARM 계열 프로세서

http://pc.watch.impress.co.jp/docs/column/1month-kouza/20140626_655176.html

 

지금까지 x86 계열에 대해 소개했습니다. 마지막은 ARM에 대해 소개하도록 하겠습니다. 
 
15.jpg

 


ARM 아키텍처와 Cortex 시리즈의 변화
 
2004년 10월 ARM은 ARMv7 아키텍처를 발표했습니다. ARM은 그 전까지 기본적으로 제어 장치용과 PDA/핸드폰 등의 모바일 디바이스에 같은 CPU 코어를 제공했지만, 수요가 다양해지면서 더 이상 같은 아키텍처/코어로 모든 것을 충당하기란 어렵다고 판단했습니다. 그 결과 애플리케이션 프로세서인 ARMv7-A, 실시간 제어용인 ARMv7-R, 마이크로 컨트롤러 전용인 ARMv7-M이라는 3종류의 아키텍처가 ARMv7 세대에 나오게 됐습니다. 참고로 위 제품의 끝에 붙은 영문자를 모두 합치면 ARM이 되는데 ARM 경영진은 그냥 우연이라고 주장합니다.

 

이 ARMv7-A을 기반으로 한 첫 제품이 2005년에 발매된 Cortex-A8입니다. 이전 세대에 해당하는 ARMv6 세대의 하이엔드 프로세서인 ARM11만 해도 아이폰 초기형에 들어갈 정도의 성능은 갖추고 있지만, 반대로 말하면 그것이 한계라고 할 수도 있습니다. 기본적으로 싱글 이슈(1명령 발행)에 인 오더의 파이프라인 구조이며 동작 클럭은 프로세스 등의 한계로 500Mhz 정도에 그쳤습니다.

 

반면 Cortex-A8은 인 오더며 듀얼 이슈(2명령 발행)으로 최대 1GHz정도의 클럭이 가능한 설계라서 성능은 크게 올랐습니다. 여기에 따라 성능만 놓고 보면 x86 프로세서의 하위 모델과 비슷한 수준이 됐습니다.
 
이 Cortex-A8의 2.0 DMIPS/MHz가 어느 정도의 성능인지가 비교하기 위해, 출시 시기는 좀 다르지만 인텔의 초기형 아톰이 어땠는지를 보면 1.6GHz의 클럭에 3,849 DMIPS였으니까 이걸 가지고 거꾸로 계산하면 1GHz로 작동하는 Cortex-A8의 성능은 830MHz로 작동하는 아톰과 비슷하다는 이야기가 나옵니다. 이게 충분한 것인지 부족한 것인지는 용도에 따라서 다르겠지만, 기존의 ARM에선 성능이 부족해 넘볼 수 없던 시장까지도 공략할 수 있게 된 건 사실입니다.

 

뒤이어 출시된 것이 2007년의 Cortex-A9입니다. 스테이지 수는 13개에서 8개로 줄었지만, 실제로는 가변 스테이지나 2사이클을 필요로 하는 스테이지가 있으니 실질적인 사이클 수는 Cortex-A8과 다름 없습니다. 이쪽은 아웃 오브 오더를 구현하여 성능을 2.5 DMIPS/MHz까지 끌어올리는 데 성공했습니다. 또 본격적으로 다중 처리 장치 확장을 도입해 최대 4코어까지 동작할 수 있게 됐습니다. 1GHz로 작동하는 4코어가 총 10000 DMIPS니 이전의 아톰과 비교하면 2GHz로 작동하는 듀얼코어 아톰 정도의 급이 됩니다.
 
이 정도로 빨라지면서 상당히 광범위한 용도로 쓸 수 있게 됐습니다. 좀 뒤로 가서 2013년에 ARM은 Cortex-A12를 대만에서 발표했었는데요. Cortex-A12에 대해 James Bruce가 설명하면서 나온 말이 "원래 Cortex-A9는 모바일에 초점을 맞춰 설계된 코어였지만 실제로는 광범위한 임베디드에도 쓰이게 됐다" 입니다. 실제로 예를 들어보면 프리스케일의 i.MX6은 Cortex-A9를 기반으로 하며 자동차부터 정보 처리 가전까지 넓은 범위를 커버하고 있으며, 텍사스 인스트루먼트는 Cortex-A8과 Cortex-A9을 바탕으로 한 OMAP4을 현재도 넓은 분야에서 쓰고 있습니다. 스마트폰에서는 철수했지만요.

 

실제로 모바일과 임베디드는 비슷한 점이 많습니다. 중요한 건 소비 전력을 줄인다는 것이지요. 임베디드도 좁은 기계 안에 넣으면 쿨링팬은 고사하고 히트싱크도 붙이지 못하며 자연 대류도 기대할 수 없는 경우가 있는데 이는 스마트폰과 같습니다. 또 시간이 흐를수록 높은 성능을 필요로 한다는 점도 스마트폰과 같지요. 저가형 프로세서의 수요가 늘어나는 상황에서 다이 크기가 작은 Cortex-A9는 좋은 선택지가 됩니다

이야기를 되돌려서 2009년에는 Cortex-A5가 나옵니다. 이는 그 동안 ARM11정도에 머물러 있던 애플리케이션 프로세서의 대체품이기도 합니다. 전에는 ARM11를 MCU와 MPU에도 썼지만, ARMv7에서 MCU용 Cortex-M계열로 나오면서 기존의 애플리케이션 프로세서용으론 쓰지 못한다고 봅니다. 사실 ARM11+α 정도의 성능으로도 충분한 시장인데 Cortex-A8/A9는 성능이 지나치게 높으니 여기에 맞춰서 내놓은 것이라 봐도 될 듯 합니다. 
 
 
2개의 개발을 병행할 필요를 느끼다 

 
이후 ARM은 2개의 개발을 동시에 하게 됩니다. 하나는 ARMv7-A의 메모리 주소 확장입니다. ARM은 공식적으로 메모리 주소 확장이 ARMv7-A에서 있었다고 말하지만 실제로는 ARMv7-A의 확장판(ARMv7e-A)으로 취급하는 경우가 많습니다.

 

이와 병행해 64비트 확장도 비슷한 시기(2007년)에 이루어지며 2011년에 ARM v8-A란 이름으로 발표됩니다. 이 결과 ARM은 각각의 아키텍처를 위해 서로 다른 CPU 코어를 준비할 필요가 생겼습니다. 이렇게 되면서 ARM도 여유가 없으니 우선 순위를 매겨 개발을 실시할 필요성을 느끼게 됩니다.

 

두 종류의 아키텍처를 왜 동시에 준비했느냐 하면 앞으로 5년 동안의 사업과 10년 이상 계속될 사업 모두를 다 고려해야 했기 때문입니다. 우선 앞으로 10년 이상 지속될 사업이라면 말할 것도 없이 서버 시장에 참가하는 것입니다. 윗부분에서 이야기한대로 서버용 CPU가 요구하는 트렌드가 앞으로는 고성능에서 저전력/고효율/저비율로 향하게 되니 ARM이 진입하기애 좋은 조건이라 할 수 있지요.


그렇다고 64비트 코어를 내놓으면 바로 시장이 바뀌느냐 그건 또 아닙니다. 우선 OS, 뒤이어 미들웨어의 지원이 있어야 하고 마지막으로 애플리케이션의 지원이 나와야 합니다. 여기까지가 1단계입니다. 다음에는 그 64비트 CPU를 사용한 시스템을 서버 제조사가 구축해야 합니다. 이 때 추가로 필요한 다양한 디바이스의 드라이버 역시 64비트 ARM에 맞춰 만들 필요가 있습니다. 이것이 2단계지요. 마지막으로 그 시스템을 사용해 실제로 운용할 수 있는지를 확인해야 겨우 사업이 시작하게 됩니다.


물론 1단계와 2단계는 다소 겹칠 수 있으나 그래도 CPU 코어를 내놓고 사업을 시작하기까지는 최소 3~4년 정도 걸립니다. 아래에 나온대로 Cortex-A57/A53은 2012년에 발표됐지만 이를 탑재한 CPU가 나온 건 2014년이며 본격적으로 시장이 발전하는 건 2015년 이후가 될 것이라 생각됩니다.


그 때까지 시간을 벌기 위해서 ARM은 32비트 코어도 강화할 필요가 생겼는데 여기선 오직 모바일만 공략하게 됩니다. 먼저 출시되는 것이 Cortex-A15라 보면 됩니다. 예를 들어 인텔은 2009년에 아톰을 기반으로 한 Moorestone SoC가 ARM 기반 제품보다 뛰어난 성능을 지녔다고 강조했습니다. 성능 향상이 꼭 필요했습니다. 재밌는 건 그 때 인텔 아톰의 성능 향상을 강조했던 아난드 찬드라시켜는 퀄컴의 수석 부사장으로 자리를 옮겼다는 것?


Cortex-A15는 고급형 모바일 뿐만 아니라 서버용에 써도 버틸 수 있는 제품군입니다. 실제로 ARM은 발표 때 이 Cortex-A15를 사용해 로우엔드 서버를 노리고 있음을 밝힌 바 있습니다.

 

16.jpg

 

2010년 9월에 열린 Cortex-A15 설명회 자료

 

물론 '노리는' 것 만으로 시장 진입이 되는 건 아니며 그것은 ARM도 잘 알고 있습니다. ARM이 원하는 건 OS 개발사와 협업 체제의 확립, 미들웨어의 지원과 미들웨어 개발사의 관계를 맺는 것이지요. 그런 의미에서 Cortex-A15는 Cortex-A57 이후를 위한 밑거름이라 해도 틀리지 않을 것이라 봅니다. 앞에서도 말한 거지만요.


뒤이어 Cortex-A7이 2011년에 출시됩니다. 이 제품이 나온 이유는 간단합니다. 미디어텍이 공략하는 저가형 SoC에 맞서기 위한 코어입니다.

 

17.jpg

 

Cotex-A13

 

18.jpg

 

Cotrex-A7

 

스마트폰에서 보급형의 시장이 넓어진다는 건 100달러 미만의 시장이 크게 늘어난다는 것을 의미합니다. 이곳을 경쟁상대(MIPS라던가)에게 뺐겨선 안되니 이 쪽도 강화할 필요가 있었습니다.


다만 이 결과 나온 Cortex-A7과 기존의 Cortex-A15는 성능, 다이 크기, 소비 전력의 차이가 너무 심했습니다. 순수하게 모바일 시장만 보면 Cortex-A15가 아니라 Cortex-A12가 먼저 나왔어야 했고 여력이 있으면 그랬을지도 모릅니다. 그러나 ARM은 Cortex-A50 시리즈의 개발도 병행했기에 Cortex-A12가 나올 때까지 기다릴 순 없었습니다.


그 결과 두 코어의 간격을 매꾸기 위해 나온 것이 바로 big.LITTLE입니다. 모바일에서 저전력 기술은 매우 중요하지만 현실적으로 Cortex-A15는 회로 규모가 너무 큽니다. 또 그렇다고 해서 인텔이 네할렘 이후 도입한 파워 게이팅 같은 기술을 쉽게 도입하기도 힘듭니다. 단순하게 회로 설계의 문제가 아니라 제조 공정 기술도 관련돼 있어 파운드리 차원에서의 대응이 필요하게 됩니다.


big.LITTLE은 그런 상황에서 태어난 고육책이라고 할 수도 있지만 오히려 이를 도입함으로서 헤테로지니어스 구성에서 전력 절약 기술이 늘었다는 점은 긍정적으로 평가할 수 있겠습니다.


2012년은 이러다보니 Cortex-A50 시리즈에 매진했지만 일단 이것이 끝나자 ARM은 개발 능력을 다시 32비트 코어에 넣기 시작했고, 그 결과 나온 것이 2013년에 나온 Cortex-A12입니다.


Cortex-A12는 중급형 제품이지만 시장의 상당 수준을 커버할 만큼의 성능을 지니고 있습니다. ARM 스스로도 시장 전체의 70%는 Cortex-A7과 A12로 커버하고 있습니다. 50~80제곱mm의 다이, 멀티 프로세싱 CPU 코어와 L2 캐시를 더한 크기가 5~10제곱mm인 제품을 목표로 하며, CPU 코어 한개의 크기는 1~1.5제곱mm, 소비 전력은 멀티코어 CPU와 L2 캐시를 더해 400~450mW입니다. 이 정도 조건에서 Cortex-A12는 Cortex-A9보다 상당히 높게 성능을 높일 수 있는 유력한 CPU 코어인 것입니다. 그래서 그동안 Cortex-A9를 사용하던 SoC가 부드럽게 이행할 수 있는 솔루션이지요.


도 하나 재밌는 건 28nm 공정이 오랬동안 쓰이는 것을 전제로 깔아두고 이 코어가 나왔다는 것입니다. 앞에서도 설명한 대로 그 동안은 임베디드용으로 Cortex-A9가 널리 쓰이고 있었습니다. 이 코어는 65nm에서 40nm 정도의 프로세스를 이용해서 생산되지만 앞으로는 이것이 28nn 공정으로 만들어진 Cortex-A12로 대체될 것이라고 미리 계획했다는 이야기입니다.


반대로 말하자면 Cortex-A12가 임베디드에 맞춘 것이니 스마트폰이나 태블릿에서 쓰기엔 다소 부족할 수도 있습니다. 그럼 여기에 Cortex-A15를 넣느냐 하면 그건 또 아닙니다. 그 대신 ARM은 올해 Cortex-A17을 발표했습니다.

 

19.jpg

 

Cotex-A17

 

ARM은 아직 Cortex-A17의 자세한 정보를 발표하진 않았지만 11스테이지+α의 파이프 라인에 아웃 오브 오더로 구성됩니다. 프론트 엔드는 Cortex-A12과 비슷한데 백엔드를 상당 부분 고쳐 Cortex-A15와 같은 4.0 DMIPS/MHz에 가까운 성능을 낸다는 이야기도 있습니다. 다이 크기는 Cortex-A12보다 약간 큰 정도에서 끝난다고 알려졌으며 Cortex-A12 대신 중급/고급형 SoC로 나온다는 이야기가 있습니다.


재밌는 건 ARM의 Cortex-A15 페이지(http://www.arm.com/ja/products/processors/cortex-a/cortex-a15.php)에서 그 용도를 보면 스마트폰과 모바일 컴퓨팅, 디지털 홈 엔터테인먼트, 홈서브와 웹 2.0 서버, 무선 인프라 구축이라 나오는데 비해, Cortex-A17(http://www.arm.com/ja/products/processors/cortex-a/cortex-a17-processor.php?tab=Performance)를 보면 스마트폰과 태블릿, 스마트 TV와 셋탑 디바이스, 산업용/차량용 정보 기기라 나온다는 것입니다. 즉 Cortex-A17은 서버용으로 쓰진 않는다는 게 ARM의 판단이라 할 수 있겠습니다.

 

 

64비트로 ARM 명령을 다시 정의한 ARMv8 아키텍처

 

마지막으로 ARMv8의 이야기입니다. 사실 ARM이 ARMv8을 내놓으면서 64비트로 나아가는 업계 동향에 맞추겠다는 의미도 있지만, 그것 외에도 ARM의 명령어를 다시 정의하려는 의도도 있었음을 잊어선 안될 것입니다. 

 

20.jpg

 

Cortex-A57

 

32비트->64비트 확장을 하는 아키텍처야 적진 않지만 대부분은 x64처럼 '기존의 32비트 명령에 64비트 어드레스를 확장'하는 형태이며 명령을 다시 정리하는 건 보기 드문 편입니다. 기존 아키텍처는 여태껏 쓰던 소프트웨어를 64비트 환경으로 이행하는 것이 큰 과제이며, 이 때문에 명령 셋트의 호환성을 유지할 필요가 있습니다. x64도 범용 레지스터의 확장은 벌어지고 있지만 기존의 32비트 명령은 기본적으로 모두 계승되고 있습니다.

 

다만 ARM의 경우 64비트의 첫 목표인 서버 분야에선 기존의 소프트웨어가 거의 존재하지 않기에 호환성이 문제될 것이 없습니다. 그렇다고 아예 문제가 없는 것은 아니고 장기적으로 봤을 때 모바일로 이행을 생각할 필요가 있지만 이는 32비트 호환 모드로 대응할 수 있으며, 그보다는 명령을 빨리 실행할 수 있도록 튜닝을 했습니다.

 

여기에는 의외의 장점도 있습니다. 그것은 ARMv8-A의 아키텍처 라이선스를 받은 업체에서 구현하기가 쉽다는 것입니다. 최근 x86 프로세서는 x86 명령을 그대로 실행하지 않고 적절한 내부 명령으로 변환 처리하는 것이 당연한 일인데, 이는 x86 뿐만 아니라 다른 프로세서도 마찬가지입니다. ARMv8-A는 APM(AppliedMicro) X-Gene, NVIDIA의 덴버, 애플의 A7, AMD의 K12 외에도 Cavium Network와 브로드컴이 이미 아키텍처 라이센스를 받아 쓰고 있습니다.

 

APM은 PowerPC를 Cavium/Broadcom은 MIPS64를 기반으로 한 64비트 프로세서를 이미 갖고 있으며, 극단적으로 말해서 디코더만 쓰면 독자적인 ARMv8-A 지원 코어가 나오게 됩니다. 실제 상황은 좀 더 성가시긴 하지만 아키텍처 라이센스를 받은 제조사에게 64비트 명령 세트가 들어온다는 건 제법 큰 장점입니다. 실제로는 32비트 호환 모드도 넣어야 합니다. 이것 때문에 실장이 까다롭다는 지적도 있지요. 32비트 성능을 얼마나 중요시하느냐에 따라 달라질 것입니다.

 

그런 이유로 64비트는 많은 제조사가 아키텍처 라이센스를 받아 구현하고 있지만, ARMv8-A을 발표할 때 아키텍처 라이센스를 받은 APM마저도 X-Gene의 양산은 아직 시작되지 않았습니다. 현재 유일하게 양산되고 있는 것은 애플의 A7과 그 후속작 뿐이며 대부분의 제품은 2015~2016년에 출시됩니다. 이를 기다리다보니 시장은 좀처럼 발전되지 않고 아키텍처 라이센스를 받을 업체들은 ARM 고객 중엔 많지 않으며 대다수는 IP 코어를 기다리고 있습니다. 그래서 Cortex-A57과 Cortex-A53을 2012년에 제공 시작했으며 빠르면 올해에나 양산 제품이 나올 듯 합니다.

 

현실적으로 모바일 시장에서 본격적으로 64비트를 지원하려면 우선 OS와 드라이버가 64비트를 지원하고 애플리케이션도 이를 지원해야 합니다. 메모리가 4GB를 넘지 않는다면 큰 의미가 없겠지만 여기에는 시간이 더 걸릴 듯 합니다.

 

다만 안드로이드의 64비트 지원은 이제 시작했으며 iOS는 이미 64비트로 가고 있으니 OS와 드라이버의 진입 장벽은 2015년 쯤에 해소될 것입니다. 스마트폰, 태블릿 전용 SoC 제조사는 이를 노리며 64비트의 라인업을 조금씩 확충하고 있습니다. 아마 앞으로 5년 정도는 32비트와 64비트 양쪽 모두이 코어가 있지만 그 시기를 지나면 시장은 64비트로 갈 것입니다. 이를 위해 2015년 쯤엔 Cortex-A53과 A57의 간격을 좁힐 새로운 IP가 나올지도 모르겠습니다.

기글하드웨어(http://gigglehd.com/zbxe)에 올라온 모든 뉴스와 정보 글은 다른 곳으로 퍼가실 때 작성자의 허락을 받아야 합니다. 번역한 뉴스와 정보 글을 작성자 동의 없이 무단 전재와 무단 수정하는 행위를 금지합니다.