제가 사용하는 컴퓨터가 다들 좀 년식이 있는 것들입니다.

집에서 사용하는 데스크탑 PC (2007년 구입)

AMD Athlon 64 X2 4200+ 코드네임은 오래되어서 기억이 안나는군요.

노트북 (2006년산)

Intel Core Duo Yonah 2.00GHz

성능 자체는 AMD쪽이 좋은데, 사실 이놈을 오랫동안 써 오면서 항상 문제가 됐던게

'버스속도가 제대로 나오지 않음', 'IDE/SATA 컨트롤러 성능이 거지같음', 'USB 컨트롤러 호환성이 나쁨'

'버스에 로드가 걸리면 시스템 전체가 불안정해짐' 'ACPI 지원이 불안정함' 등등..

기저대역에서 불안한 모습을 자주 목격하고 있습니다.

물론 이놈과 함께 한 시간이 2007년부터 한세월이라, 특성은 잘 파악하고 있어서 잘 쓰고 있긴 합니다.

노트북은 2006년산인데, Intel Core Duo 코드네임 Yonah입니다. 나름 듀얼코어인데,

이놈이 펜티엄3의 모바일판인 베니아스 코어 -> 공정개선한 도선코어 -> 도선을 두개 붙인 요나(Yonah) 코어 요렇게 발전해 왔습니다.

쉽게 말해서 '공정이 개선된 펜티엄3 듀얼코어'입니다.

성능은 제가 쓰기에 무리가 없습니다.

가끔 컴파일 할 때 답답하고, 논문작성시 수식입력이 심하게 느리다는 것을 제외하면 쓰는데 지장은 없습니다.

물론 롤이 안되는 것은 지극히 심각한 단점이나, 업무효율의 극단적 향상을 가져다 주므로 꼭 나쁘기만 한 것은 아닙니다. (?)

아무튼 이놈은 년식이 오래됐는데도 불편함 없이 쓰는 이유가

기저대역 안정성이 AMD와 비교할 수 없을 정도로 탄탄하기 때문입니다.

부하를 아무리 걸어도 절대 시스템이 불안정해지지 않습니다.

뭐 사실 AMD가 그래서 싼 것이고, Intel이 그래서 비싼 것이지만요.

AMD는 제가 유치원 다닐 때도 불안정하다고 소문이 났는데,

이제 슬슬 늙어가는 처지인데도 여전히 불안정한 것을 보면 이놈들은 당최 고칠 생각이 없는 모양입니다.

아무튼 AMD가 역사상 단 한 차례 빛을 본 적이 있었는데,

바로 478소켓 말년과 775소켓 초기의 프레스핫 프레슬러 시절이었습니다. 아주 프렛셔가 팍팍 느껴지지 않습니까?

온갖 집에 보일러를 하나씩 놔 두고, 쓸데없이 파워의 전력량을 400W 이상씩 올려버린 주범이었습니다.

인텔이 넷버스트 아키텍쳐로 한참 삽을 퍼던 시절에

AMD는 어떻게든 시장을 뒤엎어 보고자 노력을 하는데요,

그중 하나가 x86-64 또는 AMD64라 불리우는 64-bit 아키텍처의 도입이었습니다.

아키텍처라는게 하루이틀만에 나올 수도 없는 것이고

더군다나 x86의 다큐멘테이션만 A4용지의 '높이'로 50cm은 될 정도로 아주 복잡할 뿐더러

별 희안한 사이드이펙트까지 다 있습니다.

가령 ZF는 Zero Flag를 의미하는데, Result가 Zero라면 Flag가 Enable됨을 의미합니다.

그런데 Bit Shift Zero의 Result가 Zero라면 Zero Flag는 False입니다. 별 희안한 사이드이펙트가 다 있죠.

상황이 이렇다보니 AMD64에 대응할 수 있는 인텔 고유의 x86-64 아키텍처를 '빠른 시간 내에' 만들 수 없게 되고

여론이 어떻게 불리해 지다 보니 인텔은 어쩔 수 없이 AMD가 만든 AMD64를 채택하게 됩니다.

여기까진 있을법한 이야기인데,

상황이 이렇게 돌아가다보니 재미있는 현상이 나타납니다.

여기저기서 32-bit 프로세서는 4GB이상의 메모리를 사용할 수 없다는 괴소문이 떠돌고

지금도 여기저기서, 소위 자칭 컴퓨터의 신 파코즈에서도 그런 괴소문이 떠돌아다닙니다.

32-bit 프로세서는 사실 1개의 프로세스가 4GB이상의 메모리를 점유할 수 없을 뿐,

시스템 전체가 인식할 수 있는 메모리의 용량은 MMU(Memory Management Unit)에 달려있는데 말이죠.

(사실 이 부분은 '학부수준'의 운영체제론을 들으면 곧바로 알 수 있는 부분인데 소위 인터넷, 특히 파코즈의 '자칭' 전문가들이 저런 소리를 하고 다니는 것을 보면 그들이 얼마나 입만 살아있는지 알 수 있습니다.)

당시에는 MMU가 인식할 수 있는 용량조차 2GB 또는 4GB가 맥시멈이긴 했습니다만,

지금처럼 CPU에 MMU가 내장된게 아니라 그냥 메인보드만 바꿔주면 끝이었습니다.

x86에서 64비트를 네이티브로 지원할 수 있게 되자

MS는 32비트 커널에서 4GB이상을 사용할 수 없도록 제한을 겁니다. (개인사용자용에 한하여, 기업용은 32-bit 커널도 4GB를 초과하는 시스템 메모리를 인식할 수 있음)

소프트웨어 회사에서는 '리거시를 떨쳐내는 것'이 큰 도움이 되기에 MS로선 좋은 기회였죠.

x86-64는 이처럼, 필요에 의해 도입된게 아니라 다분히 AMD의 작업(?)에 의해 도입되었습니다.

문제는 이 AMD64가 아키텍처상으로 별볼일 없는 수준이었다는 점입니다.

레지스터 크기가 32비트에서 64비트로 늘어나면 참 좋은데.. 실제로는 이 장점을 제대로 활용하지 못합니다.

AMD64라는건 인텔을 까기 위해 나온거니까요. 어디서나 그렇지만, 까기 위해 나온 것 중에선 제대로 된게 없습니다.

AMD64는 그저 레지스터 크기가 두 배로 증가했을 뿐, 여기서 얻는 어드벤티지는 없습니다.

더군다나 대부분의 64비트 커널에서는 Integer값은 사실 8-byte(64-bit)가 되어야 하지만

소프트웨어의 호환성을 위해 32비트, 즉 4-byte(32-bit)로 동일하게 정의하고 있습니다.

뿐만 아니라 64비트 프로세서가 32비트 프로세서를 돌리는 일이 비일비재 하기 때문에

레지스터의 크기가 64비트로 증가했다고 해서 항상 그 64비트를 다 쓰는건 아닙니다.

많은 경우엔 32비트 프로세스가 돌아가므로 32비트만 필요할 뿐입니다.

이처럼 64비트 프로세서가 32비트로 동작할 경우 인텔의 64비트 아키텍처인 IA-64는 64비트 레지스터에 32비트 Integer를 담고, 다른 32비트에는 또 다른 값을 담아서 1사이클에 2개의 연산을 할 수 있는 구조를 채택하고 있습니다. 물론 그 효율성은 매우 처참해서, 인텔도 버린 것이 IA-64이긴 합니다.

큰 레지스터 크기를 활용하는 스케줄링이 AMD64에는 없습니다.

64비트 프로세서에서 32비트 어플리케이션을 사용할 때, IA-64에서 사용한 스케줄링 기법을 도입하면 소프트웨어의 변화 없이 성능을 약 1.2배 -_-; 향상시킬 수 있으나, AMD64는 이런게 전혀 없습니다.

결국 사이드이펙트만 수십만가지인 복잡하디 복잡하고 레지스터의 수도 8개로 극도로 제한적인 비효율적인 CPU 아키텍처의 대명사 x86은, 그 오명을 조금이라도 씻을 수 있는 64비트로의 전환에서도 AMD의 작업으로 인해 개판이 되고야 맙니다.

사실 64비트 프로세서는 이제야 조금 필요할 뿐입니다. 아니, 보수적으로 보면 지금도 별 필요 없습니다.

32비트 프로세서도 16GB, 64GB의 램을 인식할 수 있고 모두 사용할 수 있습니다.

다만 1개의 프로세스가 이론상 최대 4GB, 윈도우와 리눅스에서는 최대 3GB까지만 사용할 수 있을 뿐입니다.

그보다 더 많은 메모리를 사용하려면 프로세스를 여러개 만들면 되는 것이고요.

특수한 용도, 이미지 처리나 각종 연구용으로는 따로 64비트 프로세서를 쓰면 됩니다.

아니면 프로세스당 3GB의 메모리를 쓸 수 있으니, 여러 개의 프로세스를 띄우는 방식으로 구현했으면 됐습니다.

어차피 그런 쪽의 수요는 전체에 비하면 매우 적으니 크게 문제가 될 사안도 아니라고 보고요.

오랜 기간동안 64비트로의 이행을 준비해 오고, CPU아키텍처도 더 잘 설계했다면 프로세서의 효율이 높아졌을텐데..

역시 세상 일은 깔끔하게 돌아가는게 몇 없나봅니다.

ps. 지금의 64비트 프로세서도 MMU의 한계로 2^64만큼의 메모리를 다 인식하지는 못합니다.

MMU가 40-bit정도의 어드레스 스페이스를 인식할 수 있다고 하네요.