32비트에서 64비트로 넘어가는 이유가 무엇인가요?

메모리가 6기가라서요...

업무용 PC를 올해 초부터 윈도7 64bit를 쓰는데 일부 소프트웨어 빼고(최근에 다시 확인보니 윈도7 64bit에서도 잘 돌아가도록 새버전 나옴) 업무에 지장이 없음.
집에서도 작년부터 64bit쓰는데 32bit시스템과 별 불편함을 못 느끼고 있어요.

자신이 쓰는 소프트웨어만 잘 돌아간다면 64bit 추천.

저는 윈7을 좀 빨라지는걸 기대하고 64bit로 쓰긴 하는데 메모리 4GB를 남김없이 쓸 수 있다는 걸 제외하면 체감 속도는 별로 빠르진 않네요...-_-

--------------------------
피할 수 있을때 즐겨라!
http://snowall.tistory.com

리눅스에서는 메모리 제한은 별 문제가 안 됩니다. 32비트 리눅스를 쓰면 시스템 메모리가 3.xG가 최대 메모리로 제한되긴 하지만, 간단히 커널만 64비트로 바꿔도 되고요. PAE 옵션 들어 있는 32비트 커널 써도 되죠. 여기서 나오는 퍼포먼스 손해는 그 "빠르다는 느낌" 문제만 아니라면 무시할 만한 수준입니다.

물론 CPU level에서 이해해야 하기에 문헌이 있어도 이해하기가 만만하지는 않을 것 가기는 합니다.

제가 알기로는 64bit에서는 명령어 길이가 길어지기 때문에(다른 부분이 안 길어진다고 하더라고 operand가 memory 주소인 경우만 생각해도 길어지겠죠.) loading 시간은 당연히 더 걸릴 것 같네요. 그런데 32bit program과 64bit program을 비교해보면 가끔은 64bit가 더 작더군요. 64bit 이상인 경우를 많이 다루는 application인 것인지...???

64비트로 가면 메모리를 많이 쓸 수 있다는 것 뿐만 아니라, 체감 속도도 빨라지죠...
단, 그 체감속도라는 것이 단일한 어플리케이션이 빨라진다는 것이 아니라, 메모리를 500메가를 먹는 프로그램을 동시에 여러개를 띄웠는데, 32비트면 끽해야 3~4개 띄우고 그 다음부터는 스와핑 들어가서 엄청 느려지는 것처럼 보이지만...
64비트로 메모리 왕창 꼽고 돌리면 돌리는 족족 스와핑 안하고 돌아가니 각각의 어플이 굉장히(?) 빨라진 것 처럼 체감되죠.

2차선 도로 4차선으로 넓힌다고 내차 속도가 100키로에서 200키로로 빨라지지는 않겠지만, 적어도 막히지는 않으니 빨리 달린다고 느끼는거랑 같겠지요.

--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러

16비트 시절에는 한 번에 읽을 수 있는 메모리 단위가 64K 였을텐데..
그런데 실제로는 더 쓰는 방법이 있었잖아요.
32비트에서는 그런 방법을 제공하지 않아서 4G 제약이 있는 건가요?

강점이 최대로 부각될 듯 합니다.
제가 여러 가상머신을 돌려봤는데 컴퓨터의 여러 리소스들을 여러 가상머신이 나누어 사용하는데 절대적으로 부족한게 메모리였어요.
CPU는 요즘 멀티코어가 나오니까 문제없고 하드디스크도 워낙 값이 싸졌으니까 문제없는데 메모리는 32비트 머신에서는 3기가 + a 로 제한이 있다는 것이 문제였습니다.
가상머신을 4개쯤 이상 동시에 쓰려면 64비트 머신에서 대용량 메모리를 탑재한 컴에서 써야...

두가지 측면의 성능 향상이 있습니다.

우선 32bit Application과 64bit Application에 모두 해당되는 성능 향상은 OS의 성능 향상입니다.
대부분의 경우 32bit 단위의 접근이 많지만 파일 시스템의 경우 그 이상인 경우가 대부분입니다.

벤치 마킹 결과를 보면 파일 시스템 상에서 10~20%까지의 성능 향상도 나타납니다.
그런데 파일 시스템은 대부분의 Application에서 사용 하므로..32bit Application한테도 득이 되겠죠.

두번째로는 64bit Application의 성능 향상입니다.
망할 32bit X86 아키텍쳐는 모든 지역변수를 스택에 담아 연산하도록 되어 있어 스택 잡았다 놓는데 상당한 시간을 소비합니다.
(이건 순전히 X86 아키텍쳐가 그지 같기 때문입니다. 이러한 문제들의 극복을 위해 X86들은 끔찍하게 캐쉬를 늘려왔습니다.)
반면 요즘 잘나가는 ARM이나 Power PC, MIPS등은 지역변수들중 상당부분을 레지스터에 잡아서 사용합니다.
AMD 64(인텔은 AMD로부터 64 아키텍쳐를 역 라이센스 받았습니다.. 그리고 지들이 이름을 새로 붙였죠)에서는 이런 진보된 아키텍쳐를 흉내내어 지역변수중 상당 부분 연산을 레지스터 상에서 끝냅니다..

이러한 이득은 64bit OS상에서도 적용되어 32bit Application에도 득이 될 수 있습니다.(OS속도가 빨라지므로 시스템 콜도 빨라지겠죠)

제 결론은.." 32bit Application이 대부분이더라도 OS는 64bit 깔고 보자"입니다.

PAE 이야기가 나와서 아는것만 읊어봅니다.

PAE는 기본적으로 32bit 의 메모리 물리 어드레싱 한계인 2^32(4G) 를 확장하여 2^36(64GB)로 만들어줍니다.
PAE 자체가 Physical Address Extension 의 약자입니다. 물리 주소 확장...

물론 물리 메모리가 4GB를 넘어가고 PAE커널이 올라갔다고 해도, 장치 드라이버중 PAE지원 사양을 만족시키지 못하는것이 하나라도 있다면 드라이버 호환 문제가 발생 하기 때문에 3.x GB 로 메모리 제한을 해 버립니다.

물론, 윈도우에서는 xp sp2 이상부터는 기본값으로 PAE가 enabled 되어 있지만, 드라이버 문제 때문에 메모리 제한이 걸려버리는 미묘한 상황에 처하게 됩니다. (당연한 소리지만 OS는 아무런 죄가 없습니다... 당연하지만, 리눅스도 해당되는 이야기 입니다..)

PAE가 정상적으로 standby 되면, 실제 사용 가능한 물리 메모리 양이 늘어나 표시되게 됩니다...

하지만, 이는 하나의 프로세스가 할당받는 메모리 영역의 4GB제한하고는 또 다른 이야기인데, 이 4GB 제한은 당연히 32bit 구조(2^32) 때문에 발생 하는 것이며, 그나마도 4GB를 반으로 쪼개서 유저와 시스템 영역으로 나누어 사용합니다. (0x00000000~0x7FFFFFFF 까지가 유저 메모리 구간, 0x80000000~ 0xFFFFFFFF 까지가 시스템 영역)

윈도우에서는 32bit 에서의 유저 영역 제한인 2GB의 딜레마를 해결하기 위해서 AWE 라는 api 를 제공합니다. 이 api 를 사용하면 2GB가 넘어가는 크기의 메모리 영역을 제한적으로 사용 가능하게 됩니다.
AWE 가 MSSQL의 기능이라고 알고 있는 분도 계시는데 틀립니다.. AWE 는 그냥 api 입니다. 물론 AWE는 PAE가 standby 상태가 아니면 못씁니다.

여기서 잠깐.
PAE와 AWE 를 사용하는 시스템은 당연히 native 64bit 시스템보다 동급에서 성능이 구릴수밖에 없습니다. 당연한 소리지만 불가능을 가능하게 만들수는 있지만, 일종의 트릭을 사용하는데에서 발생하는 오버헤드를 피해갈 수 있는 방법은 없습니다.

-------------------------------------
김동수 - Prototype for Evolution