진정한 64bit CPU의 승자는... Itanium? SledgeHammer?

2000년10월에 쓰인 글같은데, 왜 난 모르지; ㅠㅠ
http://www.pcbee.co.kr/contents/hs/sa/11997.html



http://www.chip-architect.com/news/2000_09_27_double_pumped_core.html
---------------------------------------------------------------

진정한 64bit CPU의 승자는... Itanium? SledgeHammer? | 컴퓨터구조  2005.11.21 13:28  

헌구리(hungoo99)   http://cafe.naver.com/hungooricafe/28  


장수하고 있는 32bit x86 아키텍쳐

글을 시작하기에 앞서 퀴즈를 하나 풀어보자. 우리가 현재 사용하고 있는 32bit의 원조격인 80386의 발표연도는 과연 몇 년일까? 조금 나이가 있는 독자가 아니라면 쉽게 대답할 만한 질문이 아닌 듯 하다. 정답은 1985년! 우리는 386으로부터 시작된 32bit x86 환경을 만 15년이나 사용하고 있는 것이다.
386의 최대 동작 주파수는 33MHz(AMD에서 40MHz 버전을 제조한 적도 있음)에 그쳤지만, 현재 Penium III는 1GHz 이상의 동작 주파수를 기록하고 있기 때문에 수치상으로 30배 이상 빨라졌다. 그리고 386에서 물리적으로 지원되는 최대 메모리 용량인 4GB는 그 당시 실로 엄청나게 방대한 양이었지만, 물론 지금에 와서는 서버급에 수 GB의 메모리를 탑재하는 경우가 적지 않으니 실로 격세지감이라 하지 않을 수 없다. 그러나 격세지감이라고 감탄할 수만은 없는 법… 수 GB로 제한된 물리적 메모리의 한계는 현재의 급변하는 컴퓨팅 환경에 제약이 되고 말았다.
그러면 인텔은 15년간 내내 놀고만 있었는가? 다들 알겠지만 인텔은 착실하게(?) 새로운 64bit 아키텍쳐를 개발해왔다. 인텔의 새로운 아키텍쳐는 IA-64라고 불리어지며, 첫번째 작품의 명칭은 Itanium(아이테니엄)이다. 인텔은 RISC에서 상당한 기술을 쌓아왔던 HP와 손잡고 HP의 PA-RISC 아키텍쳐를 기반으로 Itanium라는 개발코드명을 통해 Itanium을 개발해왔던 것이다. Itanium은 수 차례의 발표 연기를 통해 올해 사사분기 정도에 선을 보일 것이라고 한다. (그러나 Itanium이라는 브랜드명이 소개된 1999년 10월 4일로부터 딱 1년이 지나도록 그 누구도 Itanium의 발표 일자를 모른다.) 하지만 이미 인텔은 Itanium의 데모를 시연하는 수준에 도달했다 한다.
인텔이 Itanium을 개발하는 동안 누구나 Itanium이 무난히 64bit 시장을 장악할 것이라고 당연시 해왔다. 그러나 의외의 복병이 등장했으니 그 주인공은 늘 인텔의 골치를 썩여왔던 AMD의 SledgeHammer다. 물론 SledgeHammer는 개발코드명이고, 아직 실제 이름이 공개된 바는 없다. (필자가 생각하는 바로는 아마 SledgeHammer의 이름도 Athlon, Duron과 마찬가지로 –on으로 끝나는 단어가 되지 않을까 한다. ^^)
인텔 Itanium이 기존 IA-32 아키텍쳐에서 벗어나 완전히 새로운 IA-64로 시작하는 것과 달리 AMD는 인텔이 386을 통해 64bit으로 이전할 때와 같은 접근 방법을 시도하고 있다. 이에 대한 자세한 얘기는 뒤에 하기로 하자. Itanium과 SladgeHammer는 이렇게 서로 다른 접근 방법을 택하고 있는데, 과연 누가 승자가 될지 사뭇 궁금해지지 않을 수 없다. 이에 필자는 두 CPU 중 어느 것이 올바른 선택인지 조명해보고자 한다. 아직 CPU의 샘플조차 공개되지 않은 상황에서 섣불리 승자를 예측하는 것이 매우 성급한 판단일 수는 있으나, ‘역사적’으로 비슷한 경쟁 관계에서 유추해보는 것도 나쁘진 않을 것이다.



Itanium과 SledgeHammer의 근본적인 차이에 대해서는 명령어 집합과 프로세서 아키텍쳐를 빼놓고서는 절대 이야기할 수 없을 것 같다. 명령어 집합과 프로세서 아키텍쳐에 대해 어느 정도 기본적인 지식이 있다면 좋겠지만, 그렇지 않은 독자를 위해서 간략하게나마 설명을 하고 넘어가려 한다. 좀 어려운 내용이 될 수도 있겠지만, 잘 모르고 넘어가도 세상 사는데 큰 어려움은 없을 것이다. ^^

CISC ? RISC ?

기존 CPU는 명령어 집합의 성격에 따라 크게 CISC(Complex Instruction Set Computing)와 RISC(Reduced Instruction Set Computing)로 구분되었다. CISC CPU의 대표격인 X86의 명령어(Instruction) 중 길이가 가장 짧은 것은 8bit만을 차지 하는 반면 가장 긴 것은 120bit에 달한다. 1970년대에는 메모리가 매우 귀했던 이유로 CISC는 메모리의 단 한 바이트라도 아끼려는 최선의 설계 방법이었던 것이다. 그러나 이토록 가변적인 길이의 명령어는 디코딩을 까다롭게 할 뿐이었다.


대표적인 RISC 프로세서인
Sun의 UltraSparc 시리즈

CPU의 등장은 메모리 가격의 하락과 때를 같이 한다. 1980년대에는 그 이전보다 훨씬 방대한 메모리의 장착이 가능해진 까닭으로 굳이 메모리를 아끼고자 가변적인 길이의 명령어 집합(Instruction Set)을 사용할 필요가 없었던 것이다. 고정된 길이의 명령어만을 사용함으로써 명령어의 디코딩은 복잡한 마이크로코드를 벗어서 간단한 회로(Hard Wired Logic)로 구현 가능하게 되었다. 이 때문에 CISC에서라면 명령어 디코딩에 소요되었을 트랜지스터들을 내부 캐쉬, 명령어 파이프라인(Instruction), 수퍼스칼라(Superscalar) 등에 할애할 수 있게 되었다. 특히 RISC는 범용 레지스터(General Purpose Register)의 개수를 확대함으로써 시스템 성능을 저하시키는 메모리 액세스의 회수를 줄일 수 있게 하였다. x86 프로세서의 범용 레지스터 개수는 8개에 그치는 반면, RISC 프로세서에는 대개 수십 개의 범용 레지스터가 존재한다.

RISC가 복잡해진 이유

RISC 프로세서에서는 1클럭에 명령어 하나를 실행시키기 위한 명령어 파이프라이닝과 명령어 레벨의 병렬처리인 수퍼스칼라(Superscalar)가 가능해졌지만, 그에 따라 명령어간의 데이터 의존성(Data Dependency)으로 인한 데이터 해저드(Data Hazard)와 분기 명령에서 발생하는 컨트롤 해저드(Control Hazard)를 해결해야 할 필요가 대두되었다. 이 때문에 RISC 프로세서에는 데이터 해저드를 해결하기 위한 데이터 포워딩(Data Forwarding)과 컨트롤 해저드를 위해 분기 예측(Branch Prediction) 등의 제어 로직이 추가된다. RISC 프로세서의 파이프라이닝 동작 방식에 대해서는 기회가 닿는 대로 추후 독자들께 설명하도록 하겠다.
그리고 RISC 프로세서에서는 하드웨어적인 제어 로직의 중요성 못지 않게 컴파일러(Compiler)의 비중이 커졌다. 컴파일러가 명령어를 적절히 배열함으로써 파이프라인의 작동이 원활해질 수 있기 때문이다.

차세대 CPU 디자인으로 떠오르는 VLIW




베일에 싸인 VLIW 프로세서, Transmeta Crusoe TM5400

Very Long Instruction Word)는 RISC의 복잡성을 해결하기 위한 최신의 해결책이라 할 수 있다. 어떻게 VLIW가 RISC의 복잡성에 대한 해결책이 될 수 있을까? 현재의 RISC 프로세서 아키텍쳐에서의 컴파일러는 순차적인 코드를 생성한다. 그러면 프로그램을 실행할 때 프로세서 내부의 하드웨어는 컴파일러가 생성한 코드를 다시 번역해 병렬 처리가 가능한지 조사하여 실행하게 된다. 그러나 이런 방법은 하드웨어가 컴파일러의 의도를 언제나 정확히 알 수는 없을 뿐 아니라 제어 로직의 공간을 낭비하기 때문에 비효율적이다. 그러나 앞에서 설명한 바와 같이 대부분의 RISC 프로세서들은 소프트웨어 코드로부터 병렬 처리의 가능성 여부를 알아내기 위해 상당량의 하드웨어 리소스를 낭비하고 있는 것이 현실이다.
VLIW 프로세서들은 소프트웨어 코드의 병렬 처리를 위하여 보다 효과적인 방식을 택한다. 즉 컴파일러가 프로세서의 실행 단위인 ‘번들(Bundle)’ 내에 동시에 실행해야 할 2개 이상의 명령어를 명시적으로 표현함으로써 프로세서가 별도의 판단 과정 없이 병렬 처리를 할 수 있게 하는 것이다. 그러나 컴파일러가 명령어들의 병렬 처리에 직접적으로 관여해야 하는 까닭에 절대적으로 그 비중이 높아진다. 이것은 VLIW 아키텍쳐가 그 어느 CPU 아키텍쳐보다도 똑똑한 컴파일러를 요구하는 이유이기도 하다.
이와 같이 VLIW 아키텍쳐는 프로세서를 보다 심플하게 디자인하는데 도움을 주기 때문에 칩 생산시의 코스트가 억제되고, 동작 전력 소비가 줄어드는 효과가 있다. 뛰어난 성능을 발휘할 수 있음은 물론이다. 이와 같은 장점으로 인해 모바일 시장을 겨냥한 Transmeta의 Crusoe 프로세서가 VLIW 아키텍쳐를 사용한 것이 우연은 아닌 것이다.

EPIC = VLIW !!

EPIC(Explicit Parallel Instruction Computing)은 인텔 Itanium 패밀리의 아키텍쳐이다. 그 이름의 뜻은 VLIW가 추구하는 바를 그대로 나타내 준다고 해도 과언이 아니다. 다음 그림에서 보여지는 것과 같이 EPIC의 번들은 128bit의 길이를 가지며, 하나의 번들은 41bit 길이의 명령어 3개와 5bit 길이의 템플릿으로 구성된다. 전형적인 VLIW 번들의 구성이다.


  

IA-64의 명령어 번들 포맷

인텔은 또한 Itanium에 Predication과 Speculation과 같은 기능을 추가하였는데, 이러한 기능들에 대해 자세히 파고들면 너무 기술적인 내용이 될 듯 하여 이 글에서는 굳이 설명하지 않겠다. (CPU 아키텍쳐 강좌가 아닌 관계로… ^^)



32bit 호환성을 강조한 SledgeHammer

이제 64bit 후발주자 SledgeHammer에 대한 얘기를 꺼낼 때가 되었다. 인텔의 Itanium이 기존 32bit x86과의 호환에 매우 소극적인 것에 비해 SledgeHammer는 적극적으로 32bit 어플리케이션을 포용하는 정책을 추진하고 있다. Itanium이 translator를 이용하여, 즉 하드웨어 에뮬레이션과 같은 방식으로 32bit 어플리케이션을 수행하는 것에 반하여 SledgeHammer는 직접적으로 32bit x86 명령어를 지원하고 있다. 더불어 16bit 호환 모드(Compatibility 16-bit Mode) , 32bit 호환 모드(Compatibility 32-bit Mode)가 지원되어 64bit 하에서도 16bit 및 32bit 어플리케이션을 실행시킬 수 있다. 과거에 인텔이 386에서 ‘가상 86모드’라는 것을 통하여 32bit 확장 모드에서 DOS 어플리케이션을 실행시킬 수 있도록 한 것과 같은 접근 방법이라 할 수 있다.
AMD가 왜 이러한 방식을 택했을까? 아마도 기존의 32bit 어플리케이션을 그대로 지원하면서 ‘점진적으로’ 64bit로 이전해갈 계획을 세우기 있기 때문이 아닐까? 역사적으로도 16bit에서 32bit으로의 이전에는 상당히 오랜 기간이 걸린 바 있다. 심지어 아직 16bit 코드의 잔재가 남아 있는 윈도우 95/98을 사용하는 유저들이 아직도 도처에 산재해 있다. 이러한 상황에서 32bit를 버린다는 것은 커다란 모험이므로 AMD로서는 보다 안전한 길을 택한 것으로 보인다.
그러나 AMD가 32bit 호환성을 유지하는 선에서 안주할 것 같지는 않다. 이른바 듀얼 펌프 코어(Dual Pumped Core)라 불리는 기술을 준비하고 있기 때문이다. 듀얼 펌프 코어는 2개의 프로세서 코어를 하나의 칩 다이에 집적하여 SMP(Symmetric Multi-Processing)를 구현한 것이라 생각하면 된다. 그러나 단순히 2개의 마이크로 프로세서를 하나의 칩으로 집적해 놓은 것이라 생각하면 오해다. 아래 그림에서 볼 수 있듯이 듀얼 펌프 코어에는 명령어의 페치(Fetch)와 디코드 유닛은 서로 공유하면서, 레지스터와 실행 코어를 복수화하는 방법이 사용되고 있다. 언뜻 보면 수퍼스칼라와 비슷한 구조로 보이긴 하지만 레지스터가 분리되어 있다는 점에서 서로 구분이 가능하다. 어찌 되었든 SledgeHammer는 이러한 독특한 구조로 성능의 향상을 도모하고 있다.


  




AMD 듀얼 펌프 코어의 모식도
(출처 - Chip Architect : Is SledgeHammers dual core double pumped?)


효율이 뛰어난 Itanium


이것이 아이테니엄!

Itanium은 32bit x86 명령어 집합을 그저 형식적으로 지원할 뿐이다. Itanium의 32bit 실행 능력은 동클럭의 Pentium III 혹은 Pentium IV에 미치지 못할 것이 분명하며, 이것은 Itanium이 32bit 어플리케이션의 호환성에 큰 비중을 두지 않고 있다는 것에 대한 강력한 증거이기도 하다. Itanium이 도전하는 시장은 서버와 웍스테이션 분야이며, 기존에 SUN과 DEC 등이 나눠먹기 하던 시장이다. 이 시장에서 사용되는 OS는 UNIX 계열이며, 이 때문에 굳이 바이너리 레벨의 호환성에 얽매일 필요는 없다. 게다가 SledgeHammer보다 1년 가량 먼저 출시되는 Itanium이 64bit 시장을 선점해 버리면 SledgeHammer의 입지는 줄어들 것이 분명하다.
Itanium은 RISC와 같이 복잡한 제어 로직에 다이 면적을 낭비하는 대신, 128개의 정수 레지스터, 128개의 부동 소수점 레지스터, 64개의 predication 레지스터, 8개의 분기 레지스터를 보유할 정도로 넉넉한 하드웨어 리소스를 제공한다. 이렇게 필요 이상으로 충분한 리소스는 IA-64를 미래 지향적인 프로세서 아키텍쳐로 자리매김해준다.
이상과 같이 Itanium은 호환성을 과감히 포기(?)한 대신 보다 미래 지향적인 특징을 포함함으로써 궁극적으로 64bit 프로세서가 나아갈 길을 보여준다 할 수 있다. 그러나 ‘이상’과 ‘현실’에는 늘 괴리가 존재하는 법, 아직까지도 Itanium은 800MHz에서도 안정적으로 동작하지 못하는 것으로 알려져 있다. 펜티엄IV가 1.4GHz의 클럭으로 동작될 것으로 거의 확정된 마당에 아무리 64bit 프로세서라도 800MHz는 너무 낮은 클럭이 아닐는지…


  

인텔의 서버 프로세서 로드맵


여기까지 인내심을 가지고 읽어온 독자라면 이제 Itanium과 SledgeHammer가 어떤 특징을 가지고 있는지 어느 정도 파악이 되었을 것이다. 그렇다면 단순한 아키텍쳐상의 차이만으로 두 CPU간의 우열을 판단할 수 있을까? 물론 그렇지 않다. 아키텍쳐만으로 성공을 판가름하기에는 너무나도 많은 변수가 존재하기 때문이다. 20년간의 PC의 역사를 살펴보며 유사한 사례들을 관찰해보면 승자를 유추해볼 수 있을 것이다.

386의 32bit 확장 모드는 처음부터 사용되었나?

386 프로세서가 1985년에 등장하고, 컴팩이 이듬해 최초의 386PC를 내놓았음에도 불구하고 386의 32bit 확장 모드는 유명무실한 것에 불과했다. 그 이유는 32bit 확장 모드를 지원할 운영체제가 거의 없었기 때문이다. 1989년에 486 프로세서가 등장하고도 4년이 더 흐른 1993년 윈도우 NT가 등장하고 나서야 비로소 32bit의 장점을 PC에서도 누릴 수 있게 되었다. (시장 점유율이 낮았던 OS/2, UNIX 등은 논외로 하자.) 이 때문에 1993년까지 대부분의 사용자에게 386과 486은 단지 빠른 286에 불과할 뿐이었다.
Itanium은 Xeon의 뒤를 잇는 서버급 프로세서로 기획된 만큼, 32bit 어플리케이션의 프로세싱 능력이 그다지 중요하지 않다. 그러나 이 때문에 프로세서를 구입할 수요층을 좁혀 버리는 결과를 낳을 것이다. SledgeHammer는 32bit 어플리케이션에 대해 완벽한 이진 호환성을 보장하기 때문에 가격만 떨어진다면 대중화될 수 있을 것으로 보인다. 만약 SledgeHammer의 성공으로 x86-64 아키텍쳐의 저변이 넓혀진다면 승기는 SledgeHammer 쪽으로 넘어갈 소지가 크다.

32bit 버스 시장의 교훈

독자들 중에 MCA와 EISA를 기억하는 사람이 있는지? MCA(Micro Channel Architecture)는 IBM이 호환기종에게 빼앗겨 버린 PC 시장을 되찾고자 내놓았던 PS/2(Personal System/2의 약자. 절대 Play Station 2의 약자 아님!)에 탑재되었던 32bit 버스 아키텍쳐이다. 오픈 아키텍쳐로 개방되어 있던 PC/AT의 ISA(Industrial Standard Architecture. ‘아이사’라고 읽는다.) 버스와 달리 MCA를 탑재하기 위해서는 IBM에게 라이센스를 받아야만 했다. 이에 분개한 7인의 갱(Compaq, HP, … )이 개발한 32bit 버스가 EISA(Enhanced ISA, ‘이사’라고 읽는다.)이며, 이름에서 풍기는 분위기답게 ISA와의 호환성을 유지하고 있었다. 그러나 MCA는 ISA와의 호환성 부족을 이유로, EISA는 뒤늦은 출시가 이유가 되어 시장에서 호응을 받지 못한 채 사라져 갔다. 결국 이러한 공백을 메꾼 것이 바로 여러분 PC를 뒤덮고 있는 PCI이다.
이 스토리를 보면 Itanium과 SledgeHammer의 관계와 상당히 유사하지 않은가? 32bit 호환성에 소극적인 Itanium과 32bit 호환성을 갖추고 있지만 뒤늦게 출시될 SledgeHammer… 이러한 사례로부터 우리는 차세대 아키텍쳐는 단순히 ‘성능’ 혹은 ‘호환성’ 하나 만으로 성공할 수 없음을 알 수 있다. 성능과 호환성을 모두 겸비한 제품이 승리하는 법이다. 그러나 이것도 시기를 놓친다면 의미가 없다.

흐름을 따라가는 자가 승리한다.

과거 AMD는 Nexgen이라는 CPU 제조회사를 인수한 후 그 기술을 이용한 야심작 K6를 내놓은 바 있다. K6는 인텔이 포기해버린 소켓7와의 호환성을 유지하면서도 꽤 빠른 정수 연산 속도를 보이며 유망주로 부상했지만, 결국 인텔 Celeron에게 판정패하고 말았다. 이유는 무엇이었을까? 바로 부동소수점 연산 성능이 Celeron에 비해 떨어졌기 때문이었다. 게임 시장이 부동소수점 연산 성능에 영향을 많이 받는 3D 게임 위주로 재편되었지만 AMD는 미처 그 흐름을 따라가지 못한 까닭에 3DNow! 와 같은 미봉책(?)을 선보이며, Athlon이 출시될 때까지 힘겨운 싸움을 거듭해야만 했다.
마찬가지로 인텔은 Pentium Pro에 기반을 둔 P6 아키텍쳐 후속 버전의 개발에 소홀했던 결과 현재 그 대가를 톡톡히 치르고 있다. 이미 인텔은 기가 헤르츠 프로세서 세계에서 2인자로 전락하고 만 것이 사실이다. 다음 달 말에 Pentium IV가 출시되어도 쉽게 역전될 분위기는 아닌 듯 싶다.
인텔은 64bit 프로세서에서는 일단 선수를 칠 기회를 잡았다. 64bit의 1세대 Itanium으로 1년을 보내고, SledgeHammer가 등장할 2001년 말 혹은 2002년 초 즈음에는 2세대 McKinley를 선보일 수 있다. McKinley가 어느 정도의 성능을 보일지는 짐작할 수도 없지만 확실한 것은 인텔이 절치부심(切齒腐心)하며, 모든 면에서 SledgeHammer를 압도할 수 있도록 노력하고 있을 것이라는 사실이다.

결론

역사적 사례를 통해 고찰해본 결과 독자들은 어떤 결론을 내렸는지 모르겠다. 필자가 결론을 내려보겠다. 물론 이것은 필자의 개인적인 견해이며, 독자의 의견은 충분히 다를 수도 있을 것이다. 필자는 Itanium의 장밋빛 성공에 부정적인 입장이다. 인텔이 IA-64 자체를 서버급 아키텍쳐로 정의하고 있기 때문에 개인 사용자는 구경조차 하기 힘든 프로세서가 될 것이기 때문이다. 인텔은 Itanium에 높은 마진을 붙여 서버용 CPU로 판다면 이익을 기대해볼 수는 있겠지만, IA-64의 저변을 넓히는 데에는 분명한 한계가 있다. 그 반면 AMD는 서버급 프로세서인 SledgeHammer 이후로 데스크탑용 해머인 ClawHammer를 준비하고 있다. Athlon 이후의 8세대 메인 스트림 프로세서로 64bit을 밀고 나가겠다는 전략으로 풀이할 수 있다. x86-64 아키텍쳐의 저변을 넓힌다는 것은 매우 중요하다. x86-64 아키텍쳐가 시장에 널리 보급된다면, 주요 소프트웨어 회사가 이 시장을 놓칠 리가 없고, 이렇게 해서 소프트웨어가 늘어나면 다시 하드웨어 보급이 늘어나는 선순환(善循環)이 발생한다. 필자의 예측이 그럴 듯 해 보이는지 모르겠다.
결국 승자가 누가 되는지는 2002년, 2003년이 되어야 판가름할 수 있을 것 같다. 64bit 프로세서의 주도권을 두고 벌어지는 전쟁이므로 쉽사리 끝나지는 않을 것이다. 그러나 McKinley와 ClawHammer가 출시된 후라면 어느 정도 정리가 되지 않을지… 그러나 현재 상황에서는 골리앗(인텔)이 다윗(AMD)에 의해 핀치에 몰린 것이 분명하다. 창사 이래 가장 어려운 시기를 보내고 있는 인텔과 애슬론 출시 이후 급성장하고 있는 AMD - 64bit 시대에는 두 회사의 형편이 어떻게 변할지 궁금하지 않을 수 없다.

레퍼런스

IA-64 Overview
AMD x86-64™ Technology