SSE registers
SSE is a SIMD instruction set that works only on floating point values, like 3DNow!. However unlike 3DNow! it has no connection with the FPU stack. It has larger registers than 3DNow! and can pack twice the number of single precision floats. The original SSE was designed for handling single precision only, but then the SSE2 was introduced for double precision numbers, which the 3DNow! could not handle as a double precision number is 64 bit in size which would be the full size of a single 3DNow! MMn register. At 128 bit the SSE2 can pack two double precision floats into one register. Thus SSE2 is much more suitable for scientific calculations than either SSE1 or 3DNow!.
-- 자료출처 : 리눅스클러스터 사이트
AMD가 x86 ISA를 64비트로 확장시키겠다는 소식을 접했을 때, 필자는 AMD가 무리한 계획을 세웠다고 생각했다. x86이 세계에서 제일 성공을 거둔 ISA이기는 하지만, 세계에서 제일 평판이 형편 없는 ISA이기도 하기 때문이다. 프로그래머들과 분석가들, 아키텍쳐 전문가들 모두 x86을 선원들이 모두들 언젠가는 조용히 바다속으로 미끌어 떨어지기를 바라는, 전체 컴퓨터 산업의 시시한 알바트로스로 여기고있다. 하지만 그런 바램이 있다 하더라도 실상은 다르다. 사실 필자는 x86이 조만간 사라지지 않는다고 주장해왔으며, 퍼포먼스를 따지면서 걱정할 이유도 없다. 다시 따지지도 않겠지만, 우선 간단하게 알려주겠다.
아마 대부분은 다음 주장에 동의하리라. "주류 사업의 거대한 세계 시장과 소비자용 소프트웨어, 대다수의 소프트웨어가 x86 ISA용으로 일어난다." 맞지 않은가? 그런데 소프트웨어 산업에서의 x86의 위치 날조는 중요한 점을 놓치고 있다. 필자의 기사, "The Future of x86 and the Concept of the ISA"는 소프트웨어 산업의 진짜 상황이 다음과 같음을 전하고 있다. "시장은 x86 software 소비자와 주류 사업의 거대한 전세계 시장과 여타 ISA용 소프트웨어를 위한 작은 시장으로 나뉘어져있다." 데스크탑의 측면에서 여러 ISA에 포팅된 오퍼레이팅 시스템(즉 리눅스), 혹은 오픈 소스 시장의 측면에서 본 거대한 잠재 가능성이 있다고는 하지만, 현실적인 상황은 여전하며, 기존의 IT와 소비자용 소프트웨어의 상황은 변함이 없다.
만약 전세계 상용 소프트웨어 대부분을 단순히 추상적인 의미의 "소프트웨어"가 아니라, x86 바이너리 코드로 본다면, x86 ISA의 향상은 x86 소프트웨어 시장의 진보와 확장에 실질적으로 득이면 득이지 해가 아니다. 실제로 인텔의 끊임없는 x86 ISA에 대한 추가나 확장은 이렇게 보아야 설명이 가능하다. 16비트에서 32비트로의 움직임이나 x87 플로팅-포인트 인스트럭션의 추가, 플로팅-포인트 SIMD나 인티거의 추가 등, x86에 대한 모든 수정은 그만큼의 새 애플리케이션, 새 시장과 함께 PC의 새로운 가능성을 열어주고 있다. 따라서, x86 ISA에 대한 지속적인 새 기술의 접목은 "정보 혁명"의 지난 20여년간의 주연격 조연이나 다름없다.
다음의 기사는 AMD가 x86 진화의 다음 단계인, x86-64를 어떻게 바라보고 있는가를 다룬다. 보다시피, x86-64는 32비트 x86 ISA에 64비트 익스텐션의 추가 이상이다. 새로운 기능은 물론 한물 간 기능의 제거도 들어가있다.
이 기사는 x86-64 ISA만 다루기 때문에, 해머(Hammer), 옵테론(Opteron) 등의 특별한 사례를 다룬다. 또한 본 기사가 64 비트 컴퓨팅에 대한 일반론도 다루기 때문에 처음 절반은 단순히, x86-64를 위한 기사가 아니다. 따라서, PPC970으로 애플이 어떻게 64비트 플랫폼으로 이주할 지에 대해 알고 싶은 독자들에게도 처음 절반이 매우 유용하리라고 본다.
Why 64 bits?
왜 64비트 컴퓨팅이 필요한 지에 대한 대답은 별로 만족스럽지가 못하다. AMD의 차세대 해머 프로세서에 대한 질문이 계속 등장하는 걸 보면 알 수 있다. 당연히 이유가 있다. "64비트 질문"에 대해 잘 알려지지 않은 측면이 있는데, 두 가지 질문으로 나뉘어져있다. 첫 번째는 기존의 64비트 서버와 웍스테이션 시장이 어떻게 장사를 했느냐이며, 두 번째는 소비자 시장에서 64비트 컴퓨팅에서 뭘 바랄 수 있느냐이다. 보통 64비트에 대한 질문은 두 번째 질문의 대답을 얻기 위해서 첫 번째 질문을 하는 식이다. 따라서 우리도 일단 첫 번째 질문에 답해본 다음에 두 번째 질문에 답해보겠다.
What is 64-bit computing?
마이크로프로세서 기술의 기본 개념에 대한 필자의 소개 기사, "Understanding the Microprocessor"를 읽으면, 코드/데이터의 관계와 의미에 대해 친숙할 것이다. (아직 읽지 않았다면, 적어도 기사에 나온 표 정도는 다시 보는 편이 좋다) 단순히 말하면, 16비트이니 32비트이니 64비트는 마이크로프로세서의 데이터 스트림을 일컫는다. 64비트 코드라는 말을 들어본 적이 있을테지만, 이 말은 64 비트 데이터를 움직이는 코드를 말한다.
좀더 전문적인 말로 들어가면 각종 비트는 각 프로세서의 general-purpose registers(GPRs)가 다룰 수 있는 비트 수치를 의미한다. 따라서 64 비트 프로세서라는 마은 "64비트를 저장하는 GPR이 프로세서에 있다"를 뜻한다. 같은 맥락에서, "64비트 인스트럭션"은 그 64비트를 다루는 인스트럭션을 말한다.
위의 표에서, 필자는 예전 표를 최선을 다해 변경시켰다. 원래의 표를 기억하지 못하는 독자를 위해 다시 말하면, 검은 상자가 코드이며, 하얀 상자는 데이터이다. 회색 상자는 그 결과이며, 인스트럭션이나 코드의 "사이즈"에 집착하지 말기 바란다. 32비트에서 64비트에 이르는 프로세서의 "너비 확장"에 대한 느낌을 전달할 뿐이기 때문이다.
메모리나 캐시, 레지스터에 있는 모든 데이터가 64비트 데이터는 아님도 알아야한다. 이들 데이터 크기는 혼합되어있으며 64비트가 제일 넓은 범위의 데이터이다. 이것이 무엇이고, 무엇을 뜻하는 지는 잠시 뒤에 알아본다. (64비트 프로세서 상에서 흘러가는 데이터 스트림이 64비트와 32비트 데이터 혼합이라는 사실을 미리 언급할 수도 있었지만, 그런 가정을 감안할 경우 위의 모든 상자를 바꿔야한다. 대신 크기 조정 함수를 사용해서 남겨두었다)
위의 64-비트 CPU 그림에서, 코드 스트림의 너비가 바뀌지 않았음도 염두에 두어야한다. 같은-크기의 opcode는 이론상 기본 데이터 크기가 무엇이냐에 따라서, 32비트나 64비트를 작동하는 인스트럭션을 뜻할 수 있다. (opcode에 대해서는 이 기사를 보기 바란다. x86-64 opcode에 대해서는 다음 장에서 다룬다) 다른 말로 하면, 데이터 스트림의 너비를 두 배로 넓힐 수 있다. 더 넓은 데이터 스트림으로 올리려면, 프로세서 레지스터의 크기와 그런 레지스터를 채워주는 내부 데이터 경로 크기 역시 더 넓혀야한다.
이제, 32비트 프로세서와 64비트 프로세서의 두 가지 프로그래밍 모델을 보겠다.
위 그림에 나오는 64 비트 CPU 레지스터는 32비트 CPU의 두 배 너비이지만 막상 인스트럭션을 실행하는 인스트럭션 레지스터(IR)의 크기는 두 프로세서가 모두 같다. 다시 말해서, 데이터 스트림이 크기상 두 배로 올라갔지만, 인스트럭션 스트림은 그대로 남아있다. 프로그램 카운터(PC)도 두 배인데, 여기에 대해서는 나중에 간단하게 이유를 말하겠다.
지금까지 여러분에게 말한 바가 바로 그 질문에 대한 단순한 대답이랄 수 있다. 도대체 64비트 컴퓨팅이란 무엇인가? 데이터스트림이 다중 타입으로 구성되어있다는 사실을 염두에(첫 번째 비교 그림에서 나온 힌트를 생각하라) 둘 때, 답변은 약간 더 복잡해진다.
위 그림의 단순한 프로세서에서 두 가지 종류의 데이터는 인티거 데이터와 어드레스 데이터이다. 궁극적으로 어드레스는 메모리 공간을 구성하는 인티거일 뿐이기 때문에, 어드레스 데이터도 결국에는 특정한 종류의 인티거 데이터라고 할 수 있다. 따라서 두 데이터 타입은 모두 GPR에 저장되며, 인티거와 어드레스 계산은 ALU가 행한다.
현재의 프로세서들은 플로팅-포인트 데이터와 벡터 데이터라는 두 가지 추가적인 데이터 타입을 지원한다. 각 데이터 타입은 자기 자신의 레지스터와 실행 유닛 조합을 가지고 있으며, 다음의 표는 32비트와 64비트 프로세서의 네 가지 데이터타입에 대해 나타내고있다.
***** align="center">
Data Type Register Type Execution Unit x86 Width x86-64 Width
Integer GPR ALU 32 64
Address GPR ALU or AGU 32 64
Floating-point*
FPR FPU 64 64
Vector VR VPU 128 128
*******>
*x87은 플로팅-포인트double-precision을 하기 위해 80비트 레지스터를 사용한다. 플로트 자신은 64비트이지만, 연산의 정밀성을 높이기 위해 프로세서가 내부적으로 80비트 포맷으로 바꾼다.
위 표에서 인티거와 어드레스 하드웨어 안에서 64비트가 만드는 차이점을 볼 수 있다. 플로팅-포인트와 벡터 하드웨어도 같다.
Current 64-bit applications
이제 64비트 컴퓨팅에 대해서 알았으니, 인티거와 데이터 크기가 커지면 무엇이 좋은 지 알아보도록하자.
Dynamic range
더 넓어진 인티거는 더욱 늘어난 다이나믹 레인지(dynamic range)를 동반한다. "다이나믹 레인지"가 무엇인 지를 논하기에 앞서, 다이나믹 레인지가 어떤 식으로 돌아가는 지를 보여주겠다.
모두들 알다시피, 기본 십진수로 열 개의 숫자(0~9)로 모든 수를 나타낼 수 있다. 기본 열 개는 각기 다른 상징을 가지며, 그 자체가 수를 나타낸다. 열 개의 인티거보다 더 많은 수를 나타내려면 하나의 기호가 더 필요하지만, 0~9 사이의 기호를 조합하여 더 큰 수를 나타낼 수 있다.(물론 00~99까지의 백 개의 인티거로도 가능하다) 이 숫자를 가지고 할 수 있는 일반식(다이나믹 레인지는 일반적으로 DR이라고 한다)으로 여러분은 10진수를 n-개로 나타낼 수 있다.
DR = 10 n
따라서 한 자리 숫자는 10 1= 10개로 나타낼 수 있으며, 두 자리 숫자는 10 2= 100개, 세 자리 숫자는 10 3= 1000로 나타낼 수 있다.
두 가지 숫자, 0과 1로만 표현하는 2진법은 2비트이기 때문에, 다음과 같은 식으로 숫자를 표현한다.
00 = 0?
01 = 1?
10 = 2?
11 = 3
비슷하게 3비트 바이너리 숫자는 여덟 가지의 조합을 주며, 각기 다른 여덟 개의 인티거를 가지고 사용할 수 있다. 비트 수를 늘릴 수록, 표현할 수 있는 인티거 숫자도 늘어난다. 일반적으로 n비트는 2 n 개의 인티거를 나타낸다. 따라서 4 비트 바이너리는 2 4,혹은 16 개의 인티거. 8비트는 2 8=256 개의 인티거이다.
따라서, 32비트 GPR에서 64비트 GPR로의 이주는 프로세서가 다룰 수 있는 인티거의 범위를 2 32 = 4.3e9에서 2 64 = 1.8e19로 늘려준다. 따라서 DR은 43억 개의 인수로 늘어난다. 실로 64비트는 32비트 인티거보다 훨씬 넓은 범위를 다룰 수 있다.
The benefits of increased dynamic range, or, how the existing 64-bit computing market uses 64-bit integers
어드레스도 결국은 특별한 목적을 갖는 인티거이기 때문에, 좀더 많은 인티거 값을 다룰 수 있는 ALU와 레지스터의 조합은 좀더 많은 어드레스 또한 다룰 수 있다. 최근 64비트 아키텍쳐를 다룬 언론들은 32비트 프로세서가 최대한 4GB의 메모리 어드레스만을 다룰 시 있음을 알려주고 있다. 2 32 = 4.3e9이 바로 4GB이다. 64비트 아키텍쳐는 이론적으로 1800만 테라바이트의 어드레스를 다룰 수 있다.
물론 64비트 공간값이 다룰 수 있는 이론상의 크기와 실제상의 지원 크기는 매우 다르다. x86-64의 경우, 가상 주소 공간은 48비트이며, 282 테라 바이트의 주소 공간을 만든다. (예전 필자의 기사, "IA-64 preview article"에서 빌리자면, 빌 게이츠가 예전 DOS 시절에 640K를 말하던 때와 같다. 282 테라바이트라면 충분하리라는 말이다. 퀘이크 16이 3~4백만 테라바이트의 하드 디스크 공간을 차지하는 때에 필자를 인용하진 말기 바란다.) x86-64의 물리적인 공간은 40비트이며, 물리적으로 1테라바이트의 메모리를 지원할 수 있다.
그렇다면 4GB의 메모리로는 무엇을 할 수 있을까? 물론 대규모의 데이터베이스가 첫 사례이다. 초대규모의 데이터베이스용 백-엔드 서버는 오래 전부터 64비트가 필수 사항이었기 때문에 다가오는 64비트는 데이터베이스 플랫폼을 데스크탑으로 가져온다는 뜻이다.
미디어와 미디어 제조 면에서,매우 거대 용량의 2D 이미지 파일을 다루는 전문가들도 훨씬 방대해진 RAM을 환영할 것이다. 대용량의 메모리가 가능해진다면 시뮬레이션이나 모델링에서 훨씬 섹시해진 애플리케이션이 나올 수 있다. 여러가지 날씨나 과학 연구 시뮬레이션은 물론 CAD 툴과 3D 렌더링 프로그램도 마찬가지이다. 심지어는 이미 농담처럼 언급한 바 있는 실시간 3D 게임도 그 수혜를 받을 수 있다. 현재 형태의 3D 게임은 4GB의 램보다 훨씬 많은 RAM으로부터 별다른 장점을 얻을 수 없지만, 앞으로 5년 내에 4GB 램보다 더 많은 램덕분에 나오는 게임을 볼 수 있을 것이다. 하지만 본 기사는 소비자 측면에서의 64비트의 잠재성을 다루도록 한다. 미리 앞서가지는 말도록 하자.
64비트 어드레싱이 제공하는 메모리 공간때문에 발생하는 단점도 있다. 메모리 공간값(혹은 프로그래머 용어로 포인터(pointers)라고 한다)이 두 배로 넓어지기 때문에 캐시 공간도 두 배로 잡아먹는다. 보통 포인터는 캐시상의 모든 데이터의 한 부분만을 차지하지만, 그 부분이 두 배로 넓어지면, 캐시에서 다른 유용한 데이터도 손댈 수 있다. 즉 미소하게나마 퍼포먼스를 떨어뜨릴 수 있다.
위의 논의를 읽은 독자들은 제온(Xeon) 시스템이 4GB 이상의 램도 탑재할 수 있다고 반박할 것이다. 더구나 인텔은 32비트 시스템이 512GB의 메모리를 탑재할 수록 조작을 가하였다. 더구나 제일 확실한 4GB 한계의 메모리마저 아직은 벅찬 포인터이다.
대부분 과학(MATLAB, Mathematica, MAPLE 등)이나 시뮬레이션의 영역이지만 어떤 애플리케이션들은 32비트의 다이나믹 레인지를 벗어나는 연산 때문에 64비트 인티거를 요구하기도한다. 가능한 DR을 넘기게 되면, 오버플로우(overflow)나 언더플로우(underflow) 현상이 발생한다. (오버플로우는 인티거의 최대 수치를 넘었을 때 일어나며, 언더플로우는 최소 수치보다 낮을 때 발생한다) 이런 현상이 일어나면, 레지스터에서 나온 값이 올바르지 못할 수 있다. x86 프로세서의 상태에 대해서는 이 기사를 읽기 바란다. 이경우 인티거가 프로세서의 DR을 넘었는 지 알아봐야한다. 그런 상황은 인티거 애플리케이션에서는 매우, 매우 드물다. 엔지니어링을 배울 때, 필자는 플로팅-포인트의 라운드-오프 에러와 관련된 문제가 발생했을 때조차 이 문제에 닥친 적이 전혀 없었다.
32비트 플랫폼 상에서 인티거 오버플로우나 언더플로우 문제가 생겼을 때, 프로그래머들은 C와 같은 고급 수준의 언어로 제공된 64비트 인티거 옵션을 사용해야한다. 그런 경우, 인티거당 두 개의 레지스터를 사용하는 컴파일러는 32비트 하드웨어에서 64비트 연산을 인티거의 절반씩 계산함으로써 해결한다. 당연히 퍼포먼스가 상당히 떨어진다. 진정한 64비트 인티거 구현보다 훨씬 바람직스럽지 못하다.
마지막으로, 64 비트 인티거가 실제로 이득을 줄 수 있는 또다른 분야가 있으니 바로 암호해독이다. 대부분의 유명 암호 스킴은 매우 거대한 인티거의 다중화와 더 거대한 수의 인티거를 이용한 보안에 의존한다. 마지막 장에서 다루겠지만, AMD는 주류 사업이나 소비자들에게 보안이 좀더 수요가 커지기를 희망하고 있다. 저렴한 64-bit, x86-호환 프로세서가 매우 매력적으로 탈바꿈하기 때문이다.
이와 같은 관점에서,결론 부분에서 다시 언급하겠지만, 필자는 위에서 다이나믹 레인지가 더 넓어진다고 해서 퍼포먼스도 더 높아진다고 언급한 적이 없다. 이전에 주장했다시피, 64비트 인티거 코드는 32비트 머신에서 매우 느리게 돌아간다. 64 비트 연산은 32비트 연산 두 개를 나누어서 별도로 계산을 하기 때문이다. 따라서 64비트 인티거를 32비트 머신에서 돌릴 때에는 퍼포먼스라는 대가가 따르며, 이 대가는 64비트 머신으로 이주할 경우 상쇄된다. 더이상 두 개로 나눌 필요가 없어지기 때문이다. 주안점은 64비트 인티거를 사용하고 또 필요로하는 애플리케이션만이 64비트 하드웨어에서 퍼포먼스가 늘어난다. 64비트 프로세서의 더 넓어진 레지스터와 DR때문이다. 즉 64비트에서 32비트 사이에는 마술과 같은 퍼포먼스 증대가 절대로 없다. 보통 저널리스트들은 "64비트 컴퓨터가 32비트보다 컬럭 사이클당 데이터를 두 배 더 처리할 수 있다"고 말하기 때문에 현혹되기 쉽다. 기술적으로는 맞는 말이지만 오해받기 십상이다. 이렇게 말해야 옳다. "64비트 컴퓨터는 32비트 컴퓨터가 처리할 수 있는 공간보다 43억 배가 더 큰 공간을 처리할 수 있다." 이렇게 쓰면 적어도 64비트가 컴퓨터를 두 배 더 빠르게 하잖을까라는 오해를 줄일 수 있다. 훨씬 더 섹시하지 않은가?
AMD's 64-bit alternative: x86-64
AMD가 x86 ISA를 64비트 컴퓨팅으로 이끌려 한다는 소식은, AMD가 단순히 GPR을 바꾼다는 의미는 물론 x86 자체를 향상시키겠다는 의지이기도 하다. 여기에 대해서 알아보겠다.
Extended registers
인텔의 하드웨어가 4비트에서 8비트로, 16비트에서 32비트로 변해갔다는 식으로 현대 x86 ISA를 역사적으로 설명하지는 않겠다. 그런 정보는 관심만 있다면 쉽게 찾을 수 있으며, 필자는 단지 우리가 "x86 ISA"라고 알고 있는 것은 1978년에 나온 8086을 가리킨다는 사실만 짚고 넘어가겠다. 8086은 GPR로 사용할 수 있는 메모리 공간을 갖기 위해서 네 개의 16비트 GPR과 네 개의 16비트 레지스터를 갖고 있었다. (하지만 네 개의 GPR은 16비트 어드레싱 모드에서는 메모리 공간을 저장하는 데에 사용할 수 없었다)
386이 나오면서 인텔은 16비트 레지스터를 여덟 개로 늘리면서 x86 ISA가 32비트릴 지원할 수 있도록 확장시켰다. 늘어난 레지스터에 접근하기 위해, 어셈블리 프로그래머들은 각기 다른 레지스터 니모닉(mnemonic) 셋트를 사용하였다. (니모닉과 바이너리 opcode의 관계에 대해서는 이 기사를 참조하기 바란다)
여덟 개로 GPR을 늘리고 새로운 니모닉을 레지스터에 지정하면서 인텔이 16비트에서 32비트 이전을 한 일과 AMD가 노리는 x86-64로의 이전은 매우 비슷하다. 그러나 AMD는 인텔처럼 현재 여덟 개인 GPR을 늘리는 일만 하지 않았다.
More registers
x86에서 제일 오래되고 구태의연한 부분 중에 하나가 x86 프로그래밍 모델이 단지 여덟 개의 GPR과 여덟 개의 FPR, 여덟 개의 SIMD 레지스터만을 갖는다는 사실이다. 완전히 새로운 RISC ISA는 구조적으로 훨씬 많은 레지스터를 지원한다. 가령, PowerPC ISA는 각기 다른 종류의 레지스터를 32개씩 지원한다. 다루는 레지스터가 많아지면, 프로세서는 각 실행 유닛이 순간적으로 실행시킬 수 있는 데이터를 그만큼 많이 처리할 수 있다. 즉, 다루는 레지스터가 늘어나면, LOAD와 STORE를 줄일 수 있으며, 잇따라 하부시스템 체증 현상을 줄이고, 읽어야할 데이터도 줄인다. 또한 레지스터가 늘어나면, 컴파일러나 프로그래머는 인스트럭션을 훨씬 융통성있게 처리해서 파이프라인 거품 현상이나 의존성(dependencies)을 최소한으로 줄일 수 있다. (파이프라인 거품 현상과 의존성에 대해서는 이 기사, 혹은 이 기사를 읽기 바란다)
현재 x86 CPU는 이런 제한을 레지스터 리네이밍(register renaming)이라는 트릭으로 해결한다. 여기에 대해서는 자세히 설명하지 않겠지만, 이 트릭은 별도의 "숨겨진" 내부 레지스터나 머신 전용 레지스터를 다이나믹하게 프로그래머에게 보이는 레지스터로 매핑시킨다. 가령 P4에는 이런 마이크로아키텍쳐럴 리네임 레지스터가 128개 있으며, 더 많은 데이터를 저장해서 ALU로 보내거나 의존성을 줄인다. 주안점은 P4가 갖는 128개의 GPR 중에서 원래 프로그래머나 컴파일러에게 보이는 레지스터는 여덟 개에 불과하다. 나머지 120개는 P4의 내부 레지트서 리네임 로직에게만 보이기 때문에, 런타임 시에 어떻게 최적으로 사용할 지는 P4의 하드웨어에 달려있다.
레지스터 리네이밍보다는 x86 ISA를 통해서 프로그래머에게 더 많은 레지스터를 직접 접근할 수 있도록 하는 편이 더 나을 수 있다. 이경우 컴파일러나 어셈블리 언어 프로그래머들은 좀더 융통성을 갖고 코드 최적화를 통솔할 수 있으며, 메모리 접근 인스트럭션(LOAD와 STORE)도 줄일 수 있다. 따라서 AMD는 x86을 64비트로 확장시키기에 GPR 늘리기는 물론 방편으로 x86-64 ISA를 통한 SIMD 레지스터도 늘렸다.
64비트 모드로 돌아갈 때, x86-64 프로그래머들은 여덟 개의 추가적인 GPR에 접근할 수 있기 때문에, 전체 GPR은 16 개가 된다. 더해서, 여덟 개의 새로운 SIMD 레지스터는 SSE/SSE2 코드에 사용할 수 있기 때문에 프로그래머가 접근 가능한 GPR와 SIMD 레지스터 수는 각기 여덟 개에서 열 여섯 개씩으로 늘어난다. AMD가 제시한 표는 새로운 프로그래밍 모델을 보여주고있다.
AMD가 x87 플로팅-포인트 스택을 별도로 남겨두었음을 주목해야한다. 인텔이나 AMD나 프로그래머들이 공히 x87 대신 SSE/SSE2를 플로팅-포인트 코드로 사용하기를 독려하고 있기 때문인데, 여기에 대해서는 이전에 다룬 적이 있어서 다시 설명하지는 않겠다. 마지막으로, 프로그램 카운터(PC)를 늘렸는데, 이는 다음 인스트럭션 어드레스를 PC가 다루는데, 어드레스가 이제 64비트이므로 PC가 다루는 공간도 그만큼 늘어났다는 의미이다.
Switching modes
기존의 x86 코드와의 완전한 바이너리 호환(32비트와 이전의 16비트도 포함한다)은 x86-64의 최대 강점 중에 하나이다. x86-64는 호환을 각종 하부 "모드(mode)"로 처리하는데, 첫 번째 모드는(별로 흥미롭지도 않은 모드이다) 리가시(legacy)모드이다. 이 모드에서 프로세서는 정확히 표준 x86 CPU처럼 움직인다. 32비트 OS와 32비트 코드도 마찬가지이지만 x86-64에서 추가된 기능은 꺼져있다.
간단하게 말하자면, 리가시 모드에서의 해머 칩은 또다른 애슬론(Athlon)일 뿐이다.
64비트는 롱 모드(long mode)인데(정말 흥미로운 모드이다!), 이 모드에서 애플리케이션 소프트웨어를 돌리려면 64 비트 OS를 갖춰야한다. 롱 모드는 두 가지 하부 모드, 64비트 모드와 호환성 모드(compatibility mode)를 제공하는데, 이 모드에서 OS는 순수 x86 코드와 x86-64 코드 양자를 모두 돌릴 수 있다. 다음의 표가 그 과정을 시각적으로 보여준다.
(위 표에서, "x86 Apps"는 32비트와 16비트 x86 애플리케이션을 모두 포함한다)
따라서, 리가시 x86 코드(32비트와 16비트)는 64비트 OS에서 호환성 모드로 돌리며, x86-64 코드는 64비트 OS의 64비트 모드에서 돌릴 수 있다. 이 중 롱 모드의 64비트 하부 모드에서 돌아가는 코드만이 x86-64의 새로운 기능을 구사할 수 있다. 롱 모드의 호환성 모드에서 돌리는 리가시 x86 코드는 그런 확장된 레지스터와 같은 별도의 레지스터를 사용할 수 없으며 메모리 데역폭도 4GB로 제한된다.
이 모드들은 세그먼트별로 code segment descriptor로 2비트씩나뉜, 코드 세그먼트의 집합이기도하다. 칩은 각 2비트를 조사해서 특정 코드를 32비트로 다룰 지, 혹은 64비트로 다룰 지를 결정한다. AMD의 본 차트가 각종 모드의 관련 기능을 보여준다.
이제, 64비트 모드의 기본 인티거 크기가 32비트로 되어있음을 볼 수 있다. 설명하자면 이러하다.
우리는 이미 인티거와 어드레스가 64비트로 옮겨갈 때 어떤 영향을 받는 지를 논하였기 때문에, 그에 해당되는 인스트럭션만 영향을 받는다고 알고 있다. 모든 어드레스가 64비트라면 기본 포인터 공간에서 어드레스 공간을 바꿀 이유가 없다. 32비트 리가시 모드 상의 한 LOAD가 32비트 어드레스 포인터를 취한다면, 64비트 모드의 LOAD는 64비트 어드레스 포인터를 취하는 식이다.
달리 말해서, 인티거 인스트럭션은 또다르다. 64비트 인티거가 항상 필요하지도 않으며, 32나 16비트를 요구하는 애플리케이션의 경우 64비트 광대역 메모리와 캐시 공간도 필요 없다는 의미이다. 따라서, 기본 인티거 크기가 64 비트이어야 한다는 것이 프로그래머의 관심이 아니다. 인티거 인스트럭션의 기본 데이터 크기는 32비트이며, 더 크거나 더 작은 인티거를 원한다면 기본 크기를 넘어날 인스트럭션에 옵션을 추가(prefix)시켜야한다. 이러한 추가를 AMD는 REX(Register EXtension)라고 부른다. 렉스는 1 바이트의 길이를 가지며, 64 비트 인스트럭션은 따라서 1 바이트의 크기를 갖는다. 즉, 코드 크기 증가는 경미한 수준이다.
코드 크기 증가가 안좋은 이유는 코드가 커질 수록 좀더 많은 광대역과 캐시가 필요하기 때문이다. 하지만, 위의 렉스와 같은 스킴은 프로그램의 인스트럭션 혼합에서의 64 비트 인티거 인스트럭션 수에 따라 달라질 수 있도록 해준다. AMD는 x86 코드를 동일한 x86-64 코드로 늘리는 평균 퍼센테이지를 10% 이하로 보고 있다. 렉스 덕분이다.
리가시나 호환성 모드가 롱 모드에 비해 퍼포먼스 저하가 없다는 AMD의 x86-64 계획에 렉스는 실로 중요한 존재이다. 그렇다고 호환성 모드가 x86-64(특히 더 많은 레지스터)의 장점을 위해 퍼포먼스를 변하시키지도 않으며, 오버헤드 현상도 없다. 이전의 32비트 프로그램은 x86-64의 신기능을 의도적으로 무시하기 때문에 여러모로 영향을 끼치지 않는다. AMD는 x86-64가 x86으로부터 바로 업그레이드할 수 있기를 원하며, 64 비트 지원과 함께 최고의 32비트 퍼포먼스도 노리고 있다.
Out with the old
레지스터의 수나 크기를 늘리면서 x86 ISA를 유지하기 위해 x86-64는 하방 호환성 때문에 계속 존재하던, 잘 사용하지 않는 오래된 기능 일부를 줄이기도 하였다.
AMD 엔지니어들이 이전 x86 기능들 중에 퇴출시킬 것을 알아보기 시작했을 때, 제일 첫 번째 퇴출자는 분할 메모리 모델(segmented memory model)이었다. x86-64 ISA로 작성한 프로그램은 평평한 64 비트 가상 주소 공간을 사용한다. 또한 롱 모드의 호환성 모드에서 돌리는 이전의 x86 애플리케이션을 돌리려면 보호가 필요하다. 실제 모드와 가상 8086 모드 지원은 롱 모드에 없으며 리가시 모드에서만 지원한다. 사실 그렇게 중요하다고 보기는 힘들다. 현대의 x86 애플리케이션들은 보호 모드를 이용하며, 몇 개의 정말 옛날 애플리케이션만 제외하기 때문이다.
Whither x86-64?
DR이 늘어나면 무엇이 좋은 지에 대한 이전 논의를 돌이켜보면, 보안/암호 해독 이외에 소비자 수준의 애플리케이션 중에 64비트 공간을 제대로 활용할 애플리케이션이 전혀 없다는 사실을 알 수 있다. 오히려 퇴보랄까, 64비트 소비자 애플리케이션 시장은 전혀 존재하지 않는다. 이유는 매우 확실하다. 실질적으로 소비자용 애플리케이션 소프트웨어들이 x86 소프트웨어 시장이며, x86은 32비트이기 때문이다. 64비트가 필요한 애플리케이션들은 MIPS나 SPARC, Power4, Alpha 등의 하드웨어용이며, 64비트 애플리케이션을 돌리기 원하는 소비자들은 그런 특화된 하드웨어를 구입한다.
x86-64는 닭이 먼저냐 달걀이 먼저냐의 문제라고 말할 지도 모르겠다. 사실 소비자 수준의 64비트 애플리케이션이 없는 이유는 소비자 수준의 64 비트 하드웨어가 없기 때문이며, 달리 말해서 소비자 수준의 64 비트 하드웨어가 없는 이유는 소비자 수준의 64비트 애플리케이션이 없기 때문이다. AMD이건, AMD 비판가들의 말을 듣건 간에 위 두 이유 중에 하나는 반드시 언급된다. AMD는 전자 때문이기를 바란다. AMD가 호환성을 갖춘 x86-64 프로세서 하드웨어를 괜찮은 값으로 내놓는다면 애플리케이션이 뒤따라 나오리라는 이유때문이다. 하지만 이 시점에서 64비트 데스크탑이 나온다고 딱히 애플리케이션들이 잇따라 나오리라고 장담할 수 없으며, 하드웨어 공급이 그 해결책일 수도 없다.
어떻게 보면, 두 이유가 나온 이유는 각자의 사고 방식 때문이랄 수도 있다. AMD가 소비자 수준의 64비트 하드웨어를 적절한 가격/퍼포먼스로 내놓는다면 코더들이 미처 소비자용 애플리케이션으로 생각 못했던 기능들을 추가시킬 수 있다. 분명 더 나은 하드웨어로 혁신을 이룰 수 있다. 소비자용 3D 그래픽 칩셋 산업이 갑자기 급성할 수도 있고, 늘어난 DRAM과 대용량 저장장치 덕분에 전에 없던 완전히 새로운 애플리케이션이 나올 수도 있다. AMD는 의심의 여지 없이 그런 일이 x86-64에서 일어나기 바라고있다.
하지만 "먼저 만들면 그들이 따라온다" 계획은 아직 그리 구체적이지 못하다. 소비자 시장을 목적으로 하는 고도의 퍼포먼스 CPU(AMD와 인텔) 경쟁은 이미 벌어지고 있기 때문이다. 현재 CPU의 퍼포먼스와 관련된 모든 부분은 심각한 마케팅 문제를 야기하고 있으며, 인텔은 P4 2.8GHz와 같은 칩이 필요로할 애플리케이션의 대규모 시장 개척을 위해 년당 수천만 달러를 퍼붓고 있다. 이전까지의 전례를 감안하자면, x86 ISA의 기능을 확장시키는 것도 AMD에게는 좋은 전략이다. 새로운 틈새 시장으로 시장을 확장시킬 수 있기 때문이다.
어떻게 보던지 간에 x86-64는 이미 시장으로 들어서고 있는 중이며, 새로운 PC 기술, 그중에서도 컴퓨터 게임 분야에 상당한 영향을 끼칠 것으로 보인다.소비자들에게 10년 내에는 64비트가 필요하지 않으리라는 인텔의 주장을 두고 슬래쉬돗(Slashdot)에 최근 올라간 글에서, Epic Games사의 언리얼(Unreal) 엔진 전문가인 팀 스위니(Tim Sweeny)는 다음과 같은 발언을 하였다. 전부 인용할만 하다.
본사의 차세대 게임 개발과 사전 프로세싱 툴의 측면에서, 본사는 매일같이 윈도우즈의 2GB 한계에 부닺히고 있습니다.
비용-효율적으로 보자면, 64비트 CPU의 하방-호환성은 당장도 가능하며, 본사가 바로 그 기술을 오늘 매입했습니다. 당장 필요하기 때문이죠. 아마 4월 정도면 활용하리라 봅니다.
"4GB면 충분해"라는 말이나 그와 비슷한 주장, 윈도윙 익스텐션이면 된다는 주장은 모두 앞을 모르는 소리입니다. 프로그래머들이 1990년의 뱅크-교환 기술(bank-swapping technology)을 다시 채택할 거라고 봅니까?
앞으로 나올 옵테론 마더보드 중에 16 개의 DIMM 슬롯을 갖고 있는 마더보드가 많아요. 당장 pricewatch.com에서 찾아보면 800 달러로 8GB의 램을 채울 수 있습니다. 웍스테이션급 애플리케이션을 돌려야하는 사람들에게는 정말 신의 선물입니다. 이 마더보드는 다른 64 비트 웍스테이션 플랫폼(SPARC/PA-RISC/Itanium)을 가격으로나 퍼포먼스로나 네 배 이상 초월합니다. 4천 달러짜리 웍스테이션이나 서버급 CPU의 시대는 이제 끝났어요. 천 달러 짜리 CPU면 됩니다.
"아직 멀었다"는 애플리케이션 호환성을 봅시다. 세 달동안 해머 칩에 64-bit SuSE Linux를 설치해서 돌렸죠. 64비트 버전의 UT2003은 소비자형 Athlon64가 나오기 전에 출하됩니다. 차세대 엔진은 64비트를 지원할 뿐만 아니라뭔가 만들려면 64 비트를 기본적으로 요구합니다.
인텔에 말 안한줄 아십니까? 비용-효율적인 64비트 데스크탑 솔루션좀 만들어달라고 항상 애원해왔어요. 인텔은 소비자들의 목소리를 듣고 64비트 데스크톱으로의 전환에 주도적인 역할을 해야합니다. 언론한테 "10년 내에는"이라는 이상한 변명이나 하지 말고요.
인텔이 왜 그런 말을 했을까요? 곧 있으면 시장에 대규모로 들이닥칠 저렴한 64비트 데스크톱으로부터, 존재하지도 않는 4천 달러짜리 아이태니엄(Itaniums) 시장을 막기 위해서라면 분명, 인텔은 실패합니다.
-Tim Sweeney, Epic Games
무료로 콘텐츠를 만들어서 뿌리던 게임 커뮤니티가 그동안 아마추어라고 생각했었다. 하지만 이들이야말로 차세대 게임의 콘텐츠를 만들기 위해 64비트 머신을 원한다는 사실은 64비트에게 상당한 잠재성을 두고 있기에 팀 스위니의 글을 인용하였다. mod 커뮤니티가 x86-64의 성공을 바라는 소비자 시장으로 충분하다는 주장을 하려함이 아니다. 필자는 하드코어 게이밍이나 얼리어돕터 커뮤니티들은 나머지 소비자 시장에 영향을 줄 수 있다는 사실을 말하고 싶다. 다시 말하건데 소비자용 3D 그래픽 시장의 성장은 오로지 GLQuake가 뿌린 씨앗이었다.
Counter-Strike 서버 소프트웨어의 새로운 x86-64 포트 출하와도 관련이 깊다. 카운터-스트라이크(혹은 보통 CS라고 부른다)는 최근 가장 성공적인 온라인 스타로서, CS 팀의 주장에 따르면 x86-64 포팅에 최적화가 없었는데도 퍼포먼스가 30% 올라갔다고 전한다. 아마도 x86-64의 레지스터 증가와 관련이 있는 듯 하다. 나머지는 옵테론의 DDR 컨트롤러와 거대해진 L2 캐시, 마이크로아키텍쳐의 향상덕분이다.
3D 그래픽 산업의 성공은 게이머들이 매우 고가의 특별한 하드웨어라도 게임을 위해서라면 구입하리라는 사실을 시사해준다. AMD가 x86-64를 적정가에 적절한 퍼포먼스로 제공한다면, 유명 게임 몇 개의 퍼포먼스 증가(최고 인기의 게임 하나라도 족하다)가 x86-64의 시장 채택을 앞당길 수 있다.
A few final words about performance
x86-64로 포팅한 CS의 퍼포먼스 증가가 레지스터의 너비 증가 때문이 아니라 레지스터 자체의 수가 늘어났기 때문이라는 필자의 인용을 보기 바란다. 대규모 인티거(게임을 포함해 대부분의 애플리케이션들이 포함된다)가 제공하는 DR의 확장을 요구하지 않는 애플리케이션 상에서 64 비트 포팅으로 일어나는 퍼포먼스 증가는 좀더 많은 메모리로 얻을 수 있는 퍼포먼스 증가와 같다. 앞서 언급한 바와같이 64비트는 그 자체가 퍼포먼스 향상을 의미하지는 않지만 64비트 인티거 애플리케이션의 경우에는 다르다. x86-64의 경우에서 추가된 레지스터와 다른 변화는 게임과 같은 일상적인 애플리케이션의 퍼포먼스에 실제로 영향을 끼친다.
애플이 32비트 PPC에서 64비트 PPC로 옮기면, 맥 사용자들도 x86-64와 같은 퍼포먼스 증가를 기대할 수 있을까? 아니다. 맥 사용자들에게 있어서 64비트 PPC는 더 많은 인티거와 메모리 뿐이다. 레지스터가 늘어난다는 말이 아니며, 어드레싱 스킴을 쇄신하지도 않기 때문이다.
Conclusions
다음 기사에서는 옵테론에서의 x86-64 ISA 구현이 어떻게 이뤄졌는 지를 알아보겠다. 옵테론과 애슬론의 차이점과 x86-64 지원이 옵테론의 마이크로아키텍쳐에 어떤 영향을 끼쳤는 지도 설명하겠다.
Bibliography and Suggested Further Reading
AMD, x86-64 Technology White Paper.
Paul DeMone, The Battle in 64-bit Land, 2003 and Beyond.
Dave Mulvihill, The Myths and Realities of 64-bit Computing.
Jon Stokes, Understanding the Microprocessor.
Jon Stokes, Inside the PowerPC 970.
SSE is a SIMD instruction set that works only on floating point values, like 3DNow!. However unlike 3DNow! it has no connection with the FPU stack. It has larger registers than 3DNow! and can pack twice the number of single precision floats. The original SSE was designed for handling single precision only, but then the SSE2 was introduced for double precision numbers, which the 3DNow! could not handle as a double precision number is 64 bit in size which would be the full size of a single 3DNow! MMn register. At 128 bit the SSE2 can pack two double precision floats into one register. Thus SSE2 is much more suitable for scientific calculations than either SSE1 or 3DNow!.
-- 자료출처 : 리눅스클러스터 사이트
AMD가 x86 ISA를 64비트로 확장시키겠다는 소식을 접했을 때, 필자는 AMD가 무리한 계획을 세웠다고 생각했다. x86이 세계에서 제일 성공을 거둔 ISA이기는 하지만, 세계에서 제일 평판이 형편 없는 ISA이기도 하기 때문이다. 프로그래머들과 분석가들, 아키텍쳐 전문가들 모두 x86을 선원들이 모두들 언젠가는 조용히 바다속으로 미끌어 떨어지기를 바라는, 전체 컴퓨터 산업의 시시한 알바트로스로 여기고있다. 하지만 그런 바램이 있다 하더라도 실상은 다르다. 사실 필자는 x86이 조만간 사라지지 않는다고 주장해왔으며, 퍼포먼스를 따지면서 걱정할 이유도 없다. 다시 따지지도 않겠지만, 우선 간단하게 알려주겠다.
아마 대부분은 다음 주장에 동의하리라. "주류 사업의 거대한 세계 시장과 소비자용 소프트웨어, 대다수의 소프트웨어가 x86 ISA용으로 일어난다." 맞지 않은가? 그런데 소프트웨어 산업에서의 x86의 위치 날조는 중요한 점을 놓치고 있다. 필자의 기사, "The Future of x86 and the Concept of the ISA"는 소프트웨어 산업의 진짜 상황이 다음과 같음을 전하고 있다. "시장은 x86 software 소비자와 주류 사업의 거대한 전세계 시장과 여타 ISA용 소프트웨어를 위한 작은 시장으로 나뉘어져있다." 데스크탑의 측면에서 여러 ISA에 포팅된 오퍼레이팅 시스템(즉 리눅스), 혹은 오픈 소스 시장의 측면에서 본 거대한 잠재 가능성이 있다고는 하지만, 현실적인 상황은 여전하며, 기존의 IT와 소비자용 소프트웨어의 상황은 변함이 없다.
만약 전세계 상용 소프트웨어 대부분을 단순히 추상적인 의미의 "소프트웨어"가 아니라, x86 바이너리 코드로 본다면, x86 ISA의 향상은 x86 소프트웨어 시장의 진보와 확장에 실질적으로 득이면 득이지 해가 아니다. 실제로 인텔의 끊임없는 x86 ISA에 대한 추가나 확장은 이렇게 보아야 설명이 가능하다. 16비트에서 32비트로의 움직임이나 x87 플로팅-포인트 인스트럭션의 추가, 플로팅-포인트 SIMD나 인티거의 추가 등, x86에 대한 모든 수정은 그만큼의 새 애플리케이션, 새 시장과 함께 PC의 새로운 가능성을 열어주고 있다. 따라서, x86 ISA에 대한 지속적인 새 기술의 접목은 "정보 혁명"의 지난 20여년간의 주연격 조연이나 다름없다.
다음의 기사는 AMD가 x86 진화의 다음 단계인, x86-64를 어떻게 바라보고 있는가를 다룬다. 보다시피, x86-64는 32비트 x86 ISA에 64비트 익스텐션의 추가 이상이다. 새로운 기능은 물론 한물 간 기능의 제거도 들어가있다.
이 기사는 x86-64 ISA만 다루기 때문에, 해머(Hammer), 옵테론(Opteron) 등의 특별한 사례를 다룬다. 또한 본 기사가 64 비트 컴퓨팅에 대한 일반론도 다루기 때문에 처음 절반은 단순히, x86-64를 위한 기사가 아니다. 따라서, PPC970으로 애플이 어떻게 64비트 플랫폼으로 이주할 지에 대해 알고 싶은 독자들에게도 처음 절반이 매우 유용하리라고 본다.
Why 64 bits?
왜 64비트 컴퓨팅이 필요한 지에 대한 대답은 별로 만족스럽지가 못하다. AMD의 차세대 해머 프로세서에 대한 질문이 계속 등장하는 걸 보면 알 수 있다. 당연히 이유가 있다. "64비트 질문"에 대해 잘 알려지지 않은 측면이 있는데, 두 가지 질문으로 나뉘어져있다. 첫 번째는 기존의 64비트 서버와 웍스테이션 시장이 어떻게 장사를 했느냐이며, 두 번째는 소비자 시장에서 64비트 컴퓨팅에서 뭘 바랄 수 있느냐이다. 보통 64비트에 대한 질문은 두 번째 질문의 대답을 얻기 위해서 첫 번째 질문을 하는 식이다. 따라서 우리도 일단 첫 번째 질문에 답해본 다음에 두 번째 질문에 답해보겠다.
What is 64-bit computing?
마이크로프로세서 기술의 기본 개념에 대한 필자의 소개 기사, "Understanding the Microprocessor"를 읽으면, 코드/데이터의 관계와 의미에 대해 친숙할 것이다. (아직 읽지 않았다면, 적어도 기사에 나온 표 정도는 다시 보는 편이 좋다) 단순히 말하면, 16비트이니 32비트이니 64비트는 마이크로프로세서의 데이터 스트림을 일컫는다. 64비트 코드라는 말을 들어본 적이 있을테지만, 이 말은 64 비트 데이터를 움직이는 코드를 말한다.
좀더 전문적인 말로 들어가면 각종 비트는 각 프로세서의 general-purpose registers(GPRs)가 다룰 수 있는 비트 수치를 의미한다. 따라서 64 비트 프로세서라는 마은 "64비트를 저장하는 GPR이 프로세서에 있다"를 뜻한다. 같은 맥락에서, "64비트 인스트럭션"은 그 64비트를 다루는 인스트럭션을 말한다.
위의 표에서, 필자는 예전 표를 최선을 다해 변경시켰다. 원래의 표를 기억하지 못하는 독자를 위해 다시 말하면, 검은 상자가 코드이며, 하얀 상자는 데이터이다. 회색 상자는 그 결과이며, 인스트럭션이나 코드의 "사이즈"에 집착하지 말기 바란다. 32비트에서 64비트에 이르는 프로세서의 "너비 확장"에 대한 느낌을 전달할 뿐이기 때문이다.
메모리나 캐시, 레지스터에 있는 모든 데이터가 64비트 데이터는 아님도 알아야한다. 이들 데이터 크기는 혼합되어있으며 64비트가 제일 넓은 범위의 데이터이다. 이것이 무엇이고, 무엇을 뜻하는 지는 잠시 뒤에 알아본다. (64비트 프로세서 상에서 흘러가는 데이터 스트림이 64비트와 32비트 데이터 혼합이라는 사실을 미리 언급할 수도 있었지만, 그런 가정을 감안할 경우 위의 모든 상자를 바꿔야한다. 대신 크기 조정 함수를 사용해서 남겨두었다)
위의 64-비트 CPU 그림에서, 코드 스트림의 너비가 바뀌지 않았음도 염두에 두어야한다. 같은-크기의 opcode는 이론상 기본 데이터 크기가 무엇이냐에 따라서, 32비트나 64비트를 작동하는 인스트럭션을 뜻할 수 있다. (opcode에 대해서는 이 기사를 보기 바란다. x86-64 opcode에 대해서는 다음 장에서 다룬다) 다른 말로 하면, 데이터 스트림의 너비를 두 배로 넓힐 수 있다. 더 넓은 데이터 스트림으로 올리려면, 프로세서 레지스터의 크기와 그런 레지스터를 채워주는 내부 데이터 경로 크기 역시 더 넓혀야한다.
이제, 32비트 프로세서와 64비트 프로세서의 두 가지 프로그래밍 모델을 보겠다.
위 그림에 나오는 64 비트 CPU 레지스터는 32비트 CPU의 두 배 너비이지만 막상 인스트럭션을 실행하는 인스트럭션 레지스터(IR)의 크기는 두 프로세서가 모두 같다. 다시 말해서, 데이터 스트림이 크기상 두 배로 올라갔지만, 인스트럭션 스트림은 그대로 남아있다. 프로그램 카운터(PC)도 두 배인데, 여기에 대해서는 나중에 간단하게 이유를 말하겠다.
지금까지 여러분에게 말한 바가 바로 그 질문에 대한 단순한 대답이랄 수 있다. 도대체 64비트 컴퓨팅이란 무엇인가? 데이터스트림이 다중 타입으로 구성되어있다는 사실을 염두에(첫 번째 비교 그림에서 나온 힌트를 생각하라) 둘 때, 답변은 약간 더 복잡해진다.
위 그림의 단순한 프로세서에서 두 가지 종류의 데이터는 인티거 데이터와 어드레스 데이터이다. 궁극적으로 어드레스는 메모리 공간을 구성하는 인티거일 뿐이기 때문에, 어드레스 데이터도 결국에는 특정한 종류의 인티거 데이터라고 할 수 있다. 따라서 두 데이터 타입은 모두 GPR에 저장되며, 인티거와 어드레스 계산은 ALU가 행한다.
현재의 프로세서들은 플로팅-포인트 데이터와 벡터 데이터라는 두 가지 추가적인 데이터 타입을 지원한다. 각 데이터 타입은 자기 자신의 레지스터와 실행 유닛 조합을 가지고 있으며, 다음의 표는 32비트와 64비트 프로세서의 네 가지 데이터타입에 대해 나타내고있다.
***** align="center">
Data Type Register Type Execution Unit x86 Width x86-64 Width
Integer GPR ALU 32 64
Address GPR ALU or AGU 32 64
Floating-point*
FPR FPU 64 64
Vector VR VPU 128 128
*******>
*x87은 플로팅-포인트double-precision을 하기 위해 80비트 레지스터를 사용한다. 플로트 자신은 64비트이지만, 연산의 정밀성을 높이기 위해 프로세서가 내부적으로 80비트 포맷으로 바꾼다.
위 표에서 인티거와 어드레스 하드웨어 안에서 64비트가 만드는 차이점을 볼 수 있다. 플로팅-포인트와 벡터 하드웨어도 같다.
Current 64-bit applications
이제 64비트 컴퓨팅에 대해서 알았으니, 인티거와 데이터 크기가 커지면 무엇이 좋은 지 알아보도록하자.
Dynamic range
더 넓어진 인티거는 더욱 늘어난 다이나믹 레인지(dynamic range)를 동반한다. "다이나믹 레인지"가 무엇인 지를 논하기에 앞서, 다이나믹 레인지가 어떤 식으로 돌아가는 지를 보여주겠다.
모두들 알다시피, 기본 십진수로 열 개의 숫자(0~9)로 모든 수를 나타낼 수 있다. 기본 열 개는 각기 다른 상징을 가지며, 그 자체가 수를 나타낸다. 열 개의 인티거보다 더 많은 수를 나타내려면 하나의 기호가 더 필요하지만, 0~9 사이의 기호를 조합하여 더 큰 수를 나타낼 수 있다.(물론 00~99까지의 백 개의 인티거로도 가능하다) 이 숫자를 가지고 할 수 있는 일반식(다이나믹 레인지는 일반적으로 DR이라고 한다)으로 여러분은 10진수를 n-개로 나타낼 수 있다.
DR = 10 n
따라서 한 자리 숫자는 10 1= 10개로 나타낼 수 있으며, 두 자리 숫자는 10 2= 100개, 세 자리 숫자는 10 3= 1000로 나타낼 수 있다.
두 가지 숫자, 0과 1로만 표현하는 2진법은 2비트이기 때문에, 다음과 같은 식으로 숫자를 표현한다.
00 = 0?
01 = 1?
10 = 2?
11 = 3
비슷하게 3비트 바이너리 숫자는 여덟 가지의 조합을 주며, 각기 다른 여덟 개의 인티거를 가지고 사용할 수 있다. 비트 수를 늘릴 수록, 표현할 수 있는 인티거 숫자도 늘어난다. 일반적으로 n비트는 2 n 개의 인티거를 나타낸다. 따라서 4 비트 바이너리는 2 4,혹은 16 개의 인티거. 8비트는 2 8=256 개의 인티거이다.
따라서, 32비트 GPR에서 64비트 GPR로의 이주는 프로세서가 다룰 수 있는 인티거의 범위를 2 32 = 4.3e9에서 2 64 = 1.8e19로 늘려준다. 따라서 DR은 43억 개의 인수로 늘어난다. 실로 64비트는 32비트 인티거보다 훨씬 넓은 범위를 다룰 수 있다.
The benefits of increased dynamic range, or, how the existing 64-bit computing market uses 64-bit integers
어드레스도 결국은 특별한 목적을 갖는 인티거이기 때문에, 좀더 많은 인티거 값을 다룰 수 있는 ALU와 레지스터의 조합은 좀더 많은 어드레스 또한 다룰 수 있다. 최근 64비트 아키텍쳐를 다룬 언론들은 32비트 프로세서가 최대한 4GB의 메모리 어드레스만을 다룰 시 있음을 알려주고 있다. 2 32 = 4.3e9이 바로 4GB이다. 64비트 아키텍쳐는 이론적으로 1800만 테라바이트의 어드레스를 다룰 수 있다.
물론 64비트 공간값이 다룰 수 있는 이론상의 크기와 실제상의 지원 크기는 매우 다르다. x86-64의 경우, 가상 주소 공간은 48비트이며, 282 테라 바이트의 주소 공간을 만든다. (예전 필자의 기사, "IA-64 preview article"에서 빌리자면, 빌 게이츠가 예전 DOS 시절에 640K를 말하던 때와 같다. 282 테라바이트라면 충분하리라는 말이다. 퀘이크 16이 3~4백만 테라바이트의 하드 디스크 공간을 차지하는 때에 필자를 인용하진 말기 바란다.) x86-64의 물리적인 공간은 40비트이며, 물리적으로 1테라바이트의 메모리를 지원할 수 있다.
그렇다면 4GB의 메모리로는 무엇을 할 수 있을까? 물론 대규모의 데이터베이스가 첫 사례이다. 초대규모의 데이터베이스용 백-엔드 서버는 오래 전부터 64비트가 필수 사항이었기 때문에 다가오는 64비트는 데이터베이스 플랫폼을 데스크탑으로 가져온다는 뜻이다.
미디어와 미디어 제조 면에서,매우 거대 용량의 2D 이미지 파일을 다루는 전문가들도 훨씬 방대해진 RAM을 환영할 것이다. 대용량의 메모리가 가능해진다면 시뮬레이션이나 모델링에서 훨씬 섹시해진 애플리케이션이 나올 수 있다. 여러가지 날씨나 과학 연구 시뮬레이션은 물론 CAD 툴과 3D 렌더링 프로그램도 마찬가지이다. 심지어는 이미 농담처럼 언급한 바 있는 실시간 3D 게임도 그 수혜를 받을 수 있다. 현재 형태의 3D 게임은 4GB의 램보다 훨씬 많은 RAM으로부터 별다른 장점을 얻을 수 없지만, 앞으로 5년 내에 4GB 램보다 더 많은 램덕분에 나오는 게임을 볼 수 있을 것이다. 하지만 본 기사는 소비자 측면에서의 64비트의 잠재성을 다루도록 한다. 미리 앞서가지는 말도록 하자.
64비트 어드레싱이 제공하는 메모리 공간때문에 발생하는 단점도 있다. 메모리 공간값(혹은 프로그래머 용어로 포인터(pointers)라고 한다)이 두 배로 넓어지기 때문에 캐시 공간도 두 배로 잡아먹는다. 보통 포인터는 캐시상의 모든 데이터의 한 부분만을 차지하지만, 그 부분이 두 배로 넓어지면, 캐시에서 다른 유용한 데이터도 손댈 수 있다. 즉 미소하게나마 퍼포먼스를 떨어뜨릴 수 있다.
위의 논의를 읽은 독자들은 제온(Xeon) 시스템이 4GB 이상의 램도 탑재할 수 있다고 반박할 것이다. 더구나 인텔은 32비트 시스템이 512GB의 메모리를 탑재할 수록 조작을 가하였다. 더구나 제일 확실한 4GB 한계의 메모리마저 아직은 벅찬 포인터이다.
대부분 과학(MATLAB, Mathematica, MAPLE 등)이나 시뮬레이션의 영역이지만 어떤 애플리케이션들은 32비트의 다이나믹 레인지를 벗어나는 연산 때문에 64비트 인티거를 요구하기도한다. 가능한 DR을 넘기게 되면, 오버플로우(overflow)나 언더플로우(underflow) 현상이 발생한다. (오버플로우는 인티거의 최대 수치를 넘었을 때 일어나며, 언더플로우는 최소 수치보다 낮을 때 발생한다) 이런 현상이 일어나면, 레지스터에서 나온 값이 올바르지 못할 수 있다. x86 프로세서의 상태에 대해서는 이 기사를 읽기 바란다. 이경우 인티거가 프로세서의 DR을 넘었는 지 알아봐야한다. 그런 상황은 인티거 애플리케이션에서는 매우, 매우 드물다. 엔지니어링을 배울 때, 필자는 플로팅-포인트의 라운드-오프 에러와 관련된 문제가 발생했을 때조차 이 문제에 닥친 적이 전혀 없었다.
32비트 플랫폼 상에서 인티거 오버플로우나 언더플로우 문제가 생겼을 때, 프로그래머들은 C와 같은 고급 수준의 언어로 제공된 64비트 인티거 옵션을 사용해야한다. 그런 경우, 인티거당 두 개의 레지스터를 사용하는 컴파일러는 32비트 하드웨어에서 64비트 연산을 인티거의 절반씩 계산함으로써 해결한다. 당연히 퍼포먼스가 상당히 떨어진다. 진정한 64비트 인티거 구현보다 훨씬 바람직스럽지 못하다.
마지막으로, 64 비트 인티거가 실제로 이득을 줄 수 있는 또다른 분야가 있으니 바로 암호해독이다. 대부분의 유명 암호 스킴은 매우 거대한 인티거의 다중화와 더 거대한 수의 인티거를 이용한 보안에 의존한다. 마지막 장에서 다루겠지만, AMD는 주류 사업이나 소비자들에게 보안이 좀더 수요가 커지기를 희망하고 있다. 저렴한 64-bit, x86-호환 프로세서가 매우 매력적으로 탈바꿈하기 때문이다.
이와 같은 관점에서,결론 부분에서 다시 언급하겠지만, 필자는 위에서 다이나믹 레인지가 더 넓어진다고 해서 퍼포먼스도 더 높아진다고 언급한 적이 없다. 이전에 주장했다시피, 64비트 인티거 코드는 32비트 머신에서 매우 느리게 돌아간다. 64 비트 연산은 32비트 연산 두 개를 나누어서 별도로 계산을 하기 때문이다. 따라서 64비트 인티거를 32비트 머신에서 돌릴 때에는 퍼포먼스라는 대가가 따르며, 이 대가는 64비트 머신으로 이주할 경우 상쇄된다. 더이상 두 개로 나눌 필요가 없어지기 때문이다. 주안점은 64비트 인티거를 사용하고 또 필요로하는 애플리케이션만이 64비트 하드웨어에서 퍼포먼스가 늘어난다. 64비트 프로세서의 더 넓어진 레지스터와 DR때문이다. 즉 64비트에서 32비트 사이에는 마술과 같은 퍼포먼스 증대가 절대로 없다. 보통 저널리스트들은 "64비트 컴퓨터가 32비트보다 컬럭 사이클당 데이터를 두 배 더 처리할 수 있다"고 말하기 때문에 현혹되기 쉽다. 기술적으로는 맞는 말이지만 오해받기 십상이다. 이렇게 말해야 옳다. "64비트 컴퓨터는 32비트 컴퓨터가 처리할 수 있는 공간보다 43억 배가 더 큰 공간을 처리할 수 있다." 이렇게 쓰면 적어도 64비트가 컴퓨터를 두 배 더 빠르게 하잖을까라는 오해를 줄일 수 있다. 훨씬 더 섹시하지 않은가?
AMD's 64-bit alternative: x86-64
AMD가 x86 ISA를 64비트 컴퓨팅으로 이끌려 한다는 소식은, AMD가 단순히 GPR을 바꾼다는 의미는 물론 x86 자체를 향상시키겠다는 의지이기도 하다. 여기에 대해서 알아보겠다.
Extended registers
인텔의 하드웨어가 4비트에서 8비트로, 16비트에서 32비트로 변해갔다는 식으로 현대 x86 ISA를 역사적으로 설명하지는 않겠다. 그런 정보는 관심만 있다면 쉽게 찾을 수 있으며, 필자는 단지 우리가 "x86 ISA"라고 알고 있는 것은 1978년에 나온 8086을 가리킨다는 사실만 짚고 넘어가겠다. 8086은 GPR로 사용할 수 있는 메모리 공간을 갖기 위해서 네 개의 16비트 GPR과 네 개의 16비트 레지스터를 갖고 있었다. (하지만 네 개의 GPR은 16비트 어드레싱 모드에서는 메모리 공간을 저장하는 데에 사용할 수 없었다)
386이 나오면서 인텔은 16비트 레지스터를 여덟 개로 늘리면서 x86 ISA가 32비트릴 지원할 수 있도록 확장시켰다. 늘어난 레지스터에 접근하기 위해, 어셈블리 프로그래머들은 각기 다른 레지스터 니모닉(mnemonic) 셋트를 사용하였다. (니모닉과 바이너리 opcode의 관계에 대해서는 이 기사를 참조하기 바란다)
여덟 개로 GPR을 늘리고 새로운 니모닉을 레지스터에 지정하면서 인텔이 16비트에서 32비트 이전을 한 일과 AMD가 노리는 x86-64로의 이전은 매우 비슷하다. 그러나 AMD는 인텔처럼 현재 여덟 개인 GPR을 늘리는 일만 하지 않았다.
More registers
x86에서 제일 오래되고 구태의연한 부분 중에 하나가 x86 프로그래밍 모델이 단지 여덟 개의 GPR과 여덟 개의 FPR, 여덟 개의 SIMD 레지스터만을 갖는다는 사실이다. 완전히 새로운 RISC ISA는 구조적으로 훨씬 많은 레지스터를 지원한다. 가령, PowerPC ISA는 각기 다른 종류의 레지스터를 32개씩 지원한다. 다루는 레지스터가 많아지면, 프로세서는 각 실행 유닛이 순간적으로 실행시킬 수 있는 데이터를 그만큼 많이 처리할 수 있다. 즉, 다루는 레지스터가 늘어나면, LOAD와 STORE를 줄일 수 있으며, 잇따라 하부시스템 체증 현상을 줄이고, 읽어야할 데이터도 줄인다. 또한 레지스터가 늘어나면, 컴파일러나 프로그래머는 인스트럭션을 훨씬 융통성있게 처리해서 파이프라인 거품 현상이나 의존성(dependencies)을 최소한으로 줄일 수 있다. (파이프라인 거품 현상과 의존성에 대해서는 이 기사, 혹은 이 기사를 읽기 바란다)
현재 x86 CPU는 이런 제한을 레지스터 리네이밍(register renaming)이라는 트릭으로 해결한다. 여기에 대해서는 자세히 설명하지 않겠지만, 이 트릭은 별도의 "숨겨진" 내부 레지스터나 머신 전용 레지스터를 다이나믹하게 프로그래머에게 보이는 레지스터로 매핑시킨다. 가령 P4에는 이런 마이크로아키텍쳐럴 리네임 레지스터가 128개 있으며, 더 많은 데이터를 저장해서 ALU로 보내거나 의존성을 줄인다. 주안점은 P4가 갖는 128개의 GPR 중에서 원래 프로그래머나 컴파일러에게 보이는 레지스터는 여덟 개에 불과하다. 나머지 120개는 P4의 내부 레지트서 리네임 로직에게만 보이기 때문에, 런타임 시에 어떻게 최적으로 사용할 지는 P4의 하드웨어에 달려있다.
레지스터 리네이밍보다는 x86 ISA를 통해서 프로그래머에게 더 많은 레지스터를 직접 접근할 수 있도록 하는 편이 더 나을 수 있다. 이경우 컴파일러나 어셈블리 언어 프로그래머들은 좀더 융통성을 갖고 코드 최적화를 통솔할 수 있으며, 메모리 접근 인스트럭션(LOAD와 STORE)도 줄일 수 있다. 따라서 AMD는 x86을 64비트로 확장시키기에 GPR 늘리기는 물론 방편으로 x86-64 ISA를 통한 SIMD 레지스터도 늘렸다.
64비트 모드로 돌아갈 때, x86-64 프로그래머들은 여덟 개의 추가적인 GPR에 접근할 수 있기 때문에, 전체 GPR은 16 개가 된다. 더해서, 여덟 개의 새로운 SIMD 레지스터는 SSE/SSE2 코드에 사용할 수 있기 때문에 프로그래머가 접근 가능한 GPR와 SIMD 레지스터 수는 각기 여덟 개에서 열 여섯 개씩으로 늘어난다. AMD가 제시한 표는 새로운 프로그래밍 모델을 보여주고있다.
AMD가 x87 플로팅-포인트 스택을 별도로 남겨두었음을 주목해야한다. 인텔이나 AMD나 프로그래머들이 공히 x87 대신 SSE/SSE2를 플로팅-포인트 코드로 사용하기를 독려하고 있기 때문인데, 여기에 대해서는 이전에 다룬 적이 있어서 다시 설명하지는 않겠다. 마지막으로, 프로그램 카운터(PC)를 늘렸는데, 이는 다음 인스트럭션 어드레스를 PC가 다루는데, 어드레스가 이제 64비트이므로 PC가 다루는 공간도 그만큼 늘어났다는 의미이다.
Switching modes
기존의 x86 코드와의 완전한 바이너리 호환(32비트와 이전의 16비트도 포함한다)은 x86-64의 최대 강점 중에 하나이다. x86-64는 호환을 각종 하부 "모드(mode)"로 처리하는데, 첫 번째 모드는(별로 흥미롭지도 않은 모드이다) 리가시(legacy)모드이다. 이 모드에서 프로세서는 정확히 표준 x86 CPU처럼 움직인다. 32비트 OS와 32비트 코드도 마찬가지이지만 x86-64에서 추가된 기능은 꺼져있다.
간단하게 말하자면, 리가시 모드에서의 해머 칩은 또다른 애슬론(Athlon)일 뿐이다.
64비트는 롱 모드(long mode)인데(정말 흥미로운 모드이다!), 이 모드에서 애플리케이션 소프트웨어를 돌리려면 64 비트 OS를 갖춰야한다. 롱 모드는 두 가지 하부 모드, 64비트 모드와 호환성 모드(compatibility mode)를 제공하는데, 이 모드에서 OS는 순수 x86 코드와 x86-64 코드 양자를 모두 돌릴 수 있다. 다음의 표가 그 과정을 시각적으로 보여준다.
(위 표에서, "x86 Apps"는 32비트와 16비트 x86 애플리케이션을 모두 포함한다)
따라서, 리가시 x86 코드(32비트와 16비트)는 64비트 OS에서 호환성 모드로 돌리며, x86-64 코드는 64비트 OS의 64비트 모드에서 돌릴 수 있다. 이 중 롱 모드의 64비트 하부 모드에서 돌아가는 코드만이 x86-64의 새로운 기능을 구사할 수 있다. 롱 모드의 호환성 모드에서 돌리는 리가시 x86 코드는 그런 확장된 레지스터와 같은 별도의 레지스터를 사용할 수 없으며 메모리 데역폭도 4GB로 제한된다.
이 모드들은 세그먼트별로 code segment descriptor로 2비트씩나뉜, 코드 세그먼트의 집합이기도하다. 칩은 각 2비트를 조사해서 특정 코드를 32비트로 다룰 지, 혹은 64비트로 다룰 지를 결정한다. AMD의 본 차트가 각종 모드의 관련 기능을 보여준다.
이제, 64비트 모드의 기본 인티거 크기가 32비트로 되어있음을 볼 수 있다. 설명하자면 이러하다.
우리는 이미 인티거와 어드레스가 64비트로 옮겨갈 때 어떤 영향을 받는 지를 논하였기 때문에, 그에 해당되는 인스트럭션만 영향을 받는다고 알고 있다. 모든 어드레스가 64비트라면 기본 포인터 공간에서 어드레스 공간을 바꿀 이유가 없다. 32비트 리가시 모드 상의 한 LOAD가 32비트 어드레스 포인터를 취한다면, 64비트 모드의 LOAD는 64비트 어드레스 포인터를 취하는 식이다.
달리 말해서, 인티거 인스트럭션은 또다르다. 64비트 인티거가 항상 필요하지도 않으며, 32나 16비트를 요구하는 애플리케이션의 경우 64비트 광대역 메모리와 캐시 공간도 필요 없다는 의미이다. 따라서, 기본 인티거 크기가 64 비트이어야 한다는 것이 프로그래머의 관심이 아니다. 인티거 인스트럭션의 기본 데이터 크기는 32비트이며, 더 크거나 더 작은 인티거를 원한다면 기본 크기를 넘어날 인스트럭션에 옵션을 추가(prefix)시켜야한다. 이러한 추가를 AMD는 REX(Register EXtension)라고 부른다. 렉스는 1 바이트의 길이를 가지며, 64 비트 인스트럭션은 따라서 1 바이트의 크기를 갖는다. 즉, 코드 크기 증가는 경미한 수준이다.
코드 크기 증가가 안좋은 이유는 코드가 커질 수록 좀더 많은 광대역과 캐시가 필요하기 때문이다. 하지만, 위의 렉스와 같은 스킴은 프로그램의 인스트럭션 혼합에서의 64 비트 인티거 인스트럭션 수에 따라 달라질 수 있도록 해준다. AMD는 x86 코드를 동일한 x86-64 코드로 늘리는 평균 퍼센테이지를 10% 이하로 보고 있다. 렉스 덕분이다.
리가시나 호환성 모드가 롱 모드에 비해 퍼포먼스 저하가 없다는 AMD의 x86-64 계획에 렉스는 실로 중요한 존재이다. 그렇다고 호환성 모드가 x86-64(특히 더 많은 레지스터)의 장점을 위해 퍼포먼스를 변하시키지도 않으며, 오버헤드 현상도 없다. 이전의 32비트 프로그램은 x86-64의 신기능을 의도적으로 무시하기 때문에 여러모로 영향을 끼치지 않는다. AMD는 x86-64가 x86으로부터 바로 업그레이드할 수 있기를 원하며, 64 비트 지원과 함께 최고의 32비트 퍼포먼스도 노리고 있다.
Out with the old
레지스터의 수나 크기를 늘리면서 x86 ISA를 유지하기 위해 x86-64는 하방 호환성 때문에 계속 존재하던, 잘 사용하지 않는 오래된 기능 일부를 줄이기도 하였다.
AMD 엔지니어들이 이전 x86 기능들 중에 퇴출시킬 것을 알아보기 시작했을 때, 제일 첫 번째 퇴출자는 분할 메모리 모델(segmented memory model)이었다. x86-64 ISA로 작성한 프로그램은 평평한 64 비트 가상 주소 공간을 사용한다. 또한 롱 모드의 호환성 모드에서 돌리는 이전의 x86 애플리케이션을 돌리려면 보호가 필요하다. 실제 모드와 가상 8086 모드 지원은 롱 모드에 없으며 리가시 모드에서만 지원한다. 사실 그렇게 중요하다고 보기는 힘들다. 현대의 x86 애플리케이션들은 보호 모드를 이용하며, 몇 개의 정말 옛날 애플리케이션만 제외하기 때문이다.
Whither x86-64?
DR이 늘어나면 무엇이 좋은 지에 대한 이전 논의를 돌이켜보면, 보안/암호 해독 이외에 소비자 수준의 애플리케이션 중에 64비트 공간을 제대로 활용할 애플리케이션이 전혀 없다는 사실을 알 수 있다. 오히려 퇴보랄까, 64비트 소비자 애플리케이션 시장은 전혀 존재하지 않는다. 이유는 매우 확실하다. 실질적으로 소비자용 애플리케이션 소프트웨어들이 x86 소프트웨어 시장이며, x86은 32비트이기 때문이다. 64비트가 필요한 애플리케이션들은 MIPS나 SPARC, Power4, Alpha 등의 하드웨어용이며, 64비트 애플리케이션을 돌리기 원하는 소비자들은 그런 특화된 하드웨어를 구입한다.
x86-64는 닭이 먼저냐 달걀이 먼저냐의 문제라고 말할 지도 모르겠다. 사실 소비자 수준의 64비트 애플리케이션이 없는 이유는 소비자 수준의 64 비트 하드웨어가 없기 때문이며, 달리 말해서 소비자 수준의 64 비트 하드웨어가 없는 이유는 소비자 수준의 64비트 애플리케이션이 없기 때문이다. AMD이건, AMD 비판가들의 말을 듣건 간에 위 두 이유 중에 하나는 반드시 언급된다. AMD는 전자 때문이기를 바란다. AMD가 호환성을 갖춘 x86-64 프로세서 하드웨어를 괜찮은 값으로 내놓는다면 애플리케이션이 뒤따라 나오리라는 이유때문이다. 하지만 이 시점에서 64비트 데스크탑이 나온다고 딱히 애플리케이션들이 잇따라 나오리라고 장담할 수 없으며, 하드웨어 공급이 그 해결책일 수도 없다.
어떻게 보면, 두 이유가 나온 이유는 각자의 사고 방식 때문이랄 수도 있다. AMD가 소비자 수준의 64비트 하드웨어를 적절한 가격/퍼포먼스로 내놓는다면 코더들이 미처 소비자용 애플리케이션으로 생각 못했던 기능들을 추가시킬 수 있다. 분명 더 나은 하드웨어로 혁신을 이룰 수 있다. 소비자용 3D 그래픽 칩셋 산업이 갑자기 급성할 수도 있고, 늘어난 DRAM과 대용량 저장장치 덕분에 전에 없던 완전히 새로운 애플리케이션이 나올 수도 있다. AMD는 의심의 여지 없이 그런 일이 x86-64에서 일어나기 바라고있다.
하지만 "먼저 만들면 그들이 따라온다" 계획은 아직 그리 구체적이지 못하다. 소비자 시장을 목적으로 하는 고도의 퍼포먼스 CPU(AMD와 인텔) 경쟁은 이미 벌어지고 있기 때문이다. 현재 CPU의 퍼포먼스와 관련된 모든 부분은 심각한 마케팅 문제를 야기하고 있으며, 인텔은 P4 2.8GHz와 같은 칩이 필요로할 애플리케이션의 대규모 시장 개척을 위해 년당 수천만 달러를 퍼붓고 있다. 이전까지의 전례를 감안하자면, x86 ISA의 기능을 확장시키는 것도 AMD에게는 좋은 전략이다. 새로운 틈새 시장으로 시장을 확장시킬 수 있기 때문이다.
어떻게 보던지 간에 x86-64는 이미 시장으로 들어서고 있는 중이며, 새로운 PC 기술, 그중에서도 컴퓨터 게임 분야에 상당한 영향을 끼칠 것으로 보인다.소비자들에게 10년 내에는 64비트가 필요하지 않으리라는 인텔의 주장을 두고 슬래쉬돗(Slashdot)에 최근 올라간 글에서, Epic Games사의 언리얼(Unreal) 엔진 전문가인 팀 스위니(Tim Sweeny)는 다음과 같은 발언을 하였다. 전부 인용할만 하다.
본사의 차세대 게임 개발과 사전 프로세싱 툴의 측면에서, 본사는 매일같이 윈도우즈의 2GB 한계에 부닺히고 있습니다.
비용-효율적으로 보자면, 64비트 CPU의 하방-호환성은 당장도 가능하며, 본사가 바로 그 기술을 오늘 매입했습니다. 당장 필요하기 때문이죠. 아마 4월 정도면 활용하리라 봅니다.
"4GB면 충분해"라는 말이나 그와 비슷한 주장, 윈도윙 익스텐션이면 된다는 주장은 모두 앞을 모르는 소리입니다. 프로그래머들이 1990년의 뱅크-교환 기술(bank-swapping technology)을 다시 채택할 거라고 봅니까?
앞으로 나올 옵테론 마더보드 중에 16 개의 DIMM 슬롯을 갖고 있는 마더보드가 많아요. 당장 pricewatch.com에서 찾아보면 800 달러로 8GB의 램을 채울 수 있습니다. 웍스테이션급 애플리케이션을 돌려야하는 사람들에게는 정말 신의 선물입니다. 이 마더보드는 다른 64 비트 웍스테이션 플랫폼(SPARC/PA-RISC/Itanium)을 가격으로나 퍼포먼스로나 네 배 이상 초월합니다. 4천 달러짜리 웍스테이션이나 서버급 CPU의 시대는 이제 끝났어요. 천 달러 짜리 CPU면 됩니다.
"아직 멀었다"는 애플리케이션 호환성을 봅시다. 세 달동안 해머 칩에 64-bit SuSE Linux를 설치해서 돌렸죠. 64비트 버전의 UT2003은 소비자형 Athlon64가 나오기 전에 출하됩니다. 차세대 엔진은 64비트를 지원할 뿐만 아니라뭔가 만들려면 64 비트를 기본적으로 요구합니다.
인텔에 말 안한줄 아십니까? 비용-효율적인 64비트 데스크탑 솔루션좀 만들어달라고 항상 애원해왔어요. 인텔은 소비자들의 목소리를 듣고 64비트 데스크톱으로의 전환에 주도적인 역할을 해야합니다. 언론한테 "10년 내에는"이라는 이상한 변명이나 하지 말고요.
인텔이 왜 그런 말을 했을까요? 곧 있으면 시장에 대규모로 들이닥칠 저렴한 64비트 데스크톱으로부터, 존재하지도 않는 4천 달러짜리 아이태니엄(Itaniums) 시장을 막기 위해서라면 분명, 인텔은 실패합니다.
-Tim Sweeney, Epic Games
무료로 콘텐츠를 만들어서 뿌리던 게임 커뮤니티가 그동안 아마추어라고 생각했었다. 하지만 이들이야말로 차세대 게임의 콘텐츠를 만들기 위해 64비트 머신을 원한다는 사실은 64비트에게 상당한 잠재성을 두고 있기에 팀 스위니의 글을 인용하였다. mod 커뮤니티가 x86-64의 성공을 바라는 소비자 시장으로 충분하다는 주장을 하려함이 아니다. 필자는 하드코어 게이밍이나 얼리어돕터 커뮤니티들은 나머지 소비자 시장에 영향을 줄 수 있다는 사실을 말하고 싶다. 다시 말하건데 소비자용 3D 그래픽 시장의 성장은 오로지 GLQuake가 뿌린 씨앗이었다.
Counter-Strike 서버 소프트웨어의 새로운 x86-64 포트 출하와도 관련이 깊다. 카운터-스트라이크(혹은 보통 CS라고 부른다)는 최근 가장 성공적인 온라인 스타로서, CS 팀의 주장에 따르면 x86-64 포팅에 최적화가 없었는데도 퍼포먼스가 30% 올라갔다고 전한다. 아마도 x86-64의 레지스터 증가와 관련이 있는 듯 하다. 나머지는 옵테론의 DDR 컨트롤러와 거대해진 L2 캐시, 마이크로아키텍쳐의 향상덕분이다.
3D 그래픽 산업의 성공은 게이머들이 매우 고가의 특별한 하드웨어라도 게임을 위해서라면 구입하리라는 사실을 시사해준다. AMD가 x86-64를 적정가에 적절한 퍼포먼스로 제공한다면, 유명 게임 몇 개의 퍼포먼스 증가(최고 인기의 게임 하나라도 족하다)가 x86-64의 시장 채택을 앞당길 수 있다.
A few final words about performance
x86-64로 포팅한 CS의 퍼포먼스 증가가 레지스터의 너비 증가 때문이 아니라 레지스터 자체의 수가 늘어났기 때문이라는 필자의 인용을 보기 바란다. 대규모 인티거(게임을 포함해 대부분의 애플리케이션들이 포함된다)가 제공하는 DR의 확장을 요구하지 않는 애플리케이션 상에서 64 비트 포팅으로 일어나는 퍼포먼스 증가는 좀더 많은 메모리로 얻을 수 있는 퍼포먼스 증가와 같다. 앞서 언급한 바와같이 64비트는 그 자체가 퍼포먼스 향상을 의미하지는 않지만 64비트 인티거 애플리케이션의 경우에는 다르다. x86-64의 경우에서 추가된 레지스터와 다른 변화는 게임과 같은 일상적인 애플리케이션의 퍼포먼스에 실제로 영향을 끼친다.
애플이 32비트 PPC에서 64비트 PPC로 옮기면, 맥 사용자들도 x86-64와 같은 퍼포먼스 증가를 기대할 수 있을까? 아니다. 맥 사용자들에게 있어서 64비트 PPC는 더 많은 인티거와 메모리 뿐이다. 레지스터가 늘어난다는 말이 아니며, 어드레싱 스킴을 쇄신하지도 않기 때문이다.
Conclusions
다음 기사에서는 옵테론에서의 x86-64 ISA 구현이 어떻게 이뤄졌는 지를 알아보겠다. 옵테론과 애슬론의 차이점과 x86-64 지원이 옵테론의 마이크로아키텍쳐에 어떤 영향을 끼쳤는 지도 설명하겠다.
Bibliography and Suggested Further Reading
AMD, x86-64 Technology White Paper.
Paul DeMone, The Battle in 64-bit Land, 2003 and Beyond.
Dave Mulvihill, The Myths and Realities of 64-bit Computing.
Jon Stokes, Understanding the Microprocessor.
Jon Stokes, Inside the PowerPC 970.
댓글 2
.
target=_blank>http://linuxcluster.com/
http://arstechnica.com/