1990년대 후반 PC를 만졌던 사람이라면 'Intel Inside Pentium with MMX' 스티커를 기억할 것이다. MMX는 강력한 마케팅 문구였지만, 동시에 SIMD(Single Instruction, Multiple Data) 명령어를 주류 데스크톱 CPU에 처음으로 본격 도입하려 한 인텔의 진지한 시도이기도 했다. 오늘날 우리는 AVX-512, ARM의 NEON과 SVE, 그리고 수천 개 코어를 가진 GPU를 당연하게 쓰지만, 이 모든 것은 수십 년에 걸친 탐색과 시장 압력, 그리고 하위 호환이라는 잡음이 쌓인 결과다. 그 출발점 중 하나를 이해하려면 기술이 막 시작되던 시점으로 돌아가 보는 편이 낫다.
MMX가 실제로 한 일
MMX(MultiMedia eXtensions)는 1997년 펜티엄 MMX 프로세서와 함께 등장했고, 그래픽·디지털 신호 처리·오디오·모뎀 소프트웨어 등 멀티미디어 성능 개선을 목표로 한 57개의 추가 명령어 집합이었다. 핵심 아이디어는 단순하다. 정수를 하나씩 처리하는 대신, 64비트 레지스터 하나에 여러 정수를 채워 넣고 동시에 연산한다는 것이다. 예를 들어 8개의 바이트를 하나하나 더하는 대신, MMX는 단 하나의 명령어로 여덟 번의 덧셈을 처리한다. 이것이 병렬성이고, SIMD의 본질이다. 같은 64비트 레지스터가 명령어에 따라 8바이트, 4워드 등 서로 다른 레이아웃으로 해석될 수 있었다는 점도 특징이다.
MMX가 SIMD의 시초는 아니다. 하나의 명령이 여러 데이터를 다룬다는 발상은 펜티엄보다 수십 년 앞선다. 대표적으로 1960년대 ILLIAC IV 프로젝트는 최초의 대규모 병렬 컴퓨터로, 원래 256개의 64비트 부동소수점 유닛과 4개의 CPU로 초당 10억 연산을 목표했다. 다만 벡터 프로세싱과 SIMD를 같은 것으로 묶으면 곤란하다. 1976년 크레이-1은 64개 원소를 담는 벡터 레지스터 여덟 개를 갖췄고, VL(벡터 길이) 레지스터로 처리할 원소 개수를 지정해 여러 사이클에 걸쳐 순차 처리했다. 반면 SIMD는 고정된 레지스터 폭에 묶여 있다는 점이 근본적인 차이다. MMX가 마주한 제약도 결국 이 '고정 폭'과 하드웨어 재사용 결정에서 비롯됐다.
실무적으로 흥미로운 설계 결정
인텔의 영리한 선택 하나는 새 레지스터 파일을 추가하지 않고 x87 부동소수점 스택 레지스터를 재활용한 것이다. MMX 레지스터는 64비트 폭이지만 내부적으로는 80비트짜리 부동소수점 레지스터의 하위 64비트에 별칭으로 얹혀 있었다. 이 결정은 실리콘을 아꼈지만 중대한 부작용을 낳았다. MMX 모드와 부동소수점 연산이 물리적으로 같은 레지스터를 공유하므로, MMX 사용을 끝낸 뒤에는 반드시 EMMS 명령으로 상태를 정리해 x87 연산이 정상 동작하게 해야 했다. 이를 빼먹으면 한참 뒤에 엉뚱한 부동소수점 버그가 튀어나왔고, MMX 프로그래머라면 누구나 언젠가 이 교훈을 몸으로 배웠다.
그래픽 실무에서 특히 유용했던 기능은 포화(saturating) 연산이다. 일반 정수 덧셈은 255를 넘기면 되돌아가 버려서, 픽셀 밝기를 더하다 보면 최대 밝기가 갑자기 어두운 값으로 뒤집히는 문제가 생긴다. MMX는 결과를 255로 붙잡아 두는 무부호 포화 연산을 제공해 밝기 조정과 블렌딩을 훨씬 단순하게 만들었다. 이 밖에 특정 값보다 큰 화소를 흰색으로 바꾸는 마스크 생성, 패킹된 값들의 동시 비트 시프트, 16비트 정수 쌍의 독립적 곱셈도 지원해 임계값 필터, 스프라이트 투명 처리, 고정소수점 곱셈 같은 루틴에 쓰였다. 다만 MMX는 부동소수점 SIMD가 없었다는 한계가 뚜렷했다. 실수 SIMD는 몇 년 뒤 펜티엄 III의 SSE에 이르러서야 x86에 도착했고, 그전까지 MMX 프로그램은 고정소수점 산술에 크게 의존했다.
시대의 타이밍과 채택의 현실
MMX가 실제로 얼마나 쓰였느냐고 묻는다면, 생각보다 많지 않았다는 것이 솔직한 답이다. 기능적 한계도 있었지만 더 큰 이유는 타이밍이었다. MMX가 등장할 무렵 S3 ViRGE, ATI 3D Rage, 3dfx Voodoo 같은 3D 가속 카드가 PC 시장에 진입하면서, CPU 측 최적화가 노리던 작업을 전용 하드웨어가 가져가기 시작했다. 물론 DOS 말기와 윈도우 95 초기, 비가속 게임에서는 여전히 CPU가 병목이었다. 노바로직 코만치 3의 주 프로그래머 카일 프리먼은 이 게임이 오디오와 그래픽 모두에 MMX를 적극 활용했다고 자주 언급했고, Eraser Turnabout, POD, Extreme Assault 같은 게임의 소프트웨어 렌더러도 MMX의 덕을 봤다. 반면 흔히 예로 드는 퀘이크는 오해다. 원작 퀘이크는 1996년작으로 MMX 도입 이전이며, 그 유명한 렌더러 성능은 레지스터 할당, 루프 최적화, 룩업 테이블, 손으로 짠 x86 어셈블리에서 나온 것이다.
MMX를 쓴 애플리케이션들은 대개 CPUID 명령으로 지원 여부를 확인한 뒤, 지원되면 MMX 경로를, 아니면 스칼라 경로를 타는 선택적 코드 패스를 함께 실었다. 수백만 명이 여전히 구형 펜티엄을 쓰고 있었기 때문에 비MMX 버전 유지는 필수였다. CPUID가 반환하는 EDX 레지스터의 23번 비트가 MMX 지원을 알려 주며, 다른 비트들은 또 다른 기술 지원 여부를 담았다. 훗날 AMD는 K6-2(1998)와 함께 3DNow!를 내놓아 64비트 MMX 레지스터에 부동소수점 SIMD 명령을 더했고, 퀘이크 II도 이를 지원했다. 다만 3DNow! 코드는 1999년 GPL로 공개된 퀘이크 II 3.19 소스에는 포함되지 않았고, 별도의 3DNow! 최적화 v3.20 바이너리로만 배포됐다.
결국 3DNow!는 MMX만큼 널리 퍼지지 못했다. 인텔이 1997년 1월 MMX로 먼저 출발한 반면 3DNow!는 1998년에 나왔고, 무엇보다 인텔의 x86 시장 점유율이 압도적이었다. MMX를 선택한다는 것은 더 많은 PC 게이머를 지원할 수 있다는 뜻이었던 반면 3DNow!는 AMD 전용 확장에 머물렀다. 오늘의 관점에서 MMX 이야기가 주는 교훈은 명확하다. 하드웨어 재사용으로 얻은 비용 절감이 EMMS 같은 상태 관리 부담과 부동소수점 SIMD의 부재라는 대가를 남겼고, 아무리 잘 설계된 명령어 집합이라도 전용 가속 하드웨어의 부상과 시장 지배력이라는 외부 변수 앞에서는 채택의 향방이 갈린다는 점이다. 새로운 SIMD 확장을 다룰 때 하위 호환 경로와 런타임 기능 감지를 반드시 챙겨야 하는 관행 역시 바로 이 시기에 뿌리를 두고 있다.