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

hwayak의 이미지

"더 큰 주소 공간을 더 효율적으로(또는 빠르게) 사용하기 위해서" 라는 것 이외에 어떤 이유들 때문에 64비트로 이주하는 것인지 궁금합니다.

물론 이 이유 하나만으로 이주의 이유는 충분하고 생각합니다만 말이죠

sisuc의 이미지

데이터 처리 속도도 빨라지기 때문이죠.

같은 시간에 헐씬 더 많은 데이터를 처리 하기 때문에 속도도 빨라 질 것입니다

가만히 생각해보면 이것들 이외의 장점은 없는듯 싶은데..

단점도 있겠죠.

어플리케이션중에는 64비트를 지원하지 않는 것도 많아서 신중하게 고민하셔야 할 것 같습니다.

위대한 한글

위대한 한글

han002의 이미지

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

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

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

..

사랑천사의 이미지


그런데 정말 64bit이 더 많은 량의 정보를 한꺼번에 처리할 수 있나요? 별로 모르겠던데요.
특히나 x86_64 같은 경우 별 차이 없다고 들었거든요. 메모리가 많으면야 좋겠지만요.
-- 사랑천사 --
LECL | Blog
yeosong@gmail.com
yeosong@gmail.com(네이트온) ysnglee2000(Skype)

사람천사

simpid의 이미지

한번에 4바이트씩 연산하는거와
한번에 8바이트씩 연산하는 차이죠.

너무 심플한 답변일지 모르지만...
사실이 그렇습니다.

64비트 이행하면 대용량 리소스가 필요한 부분에 대한 해택도 있겠지만.
제 경우는 그렇습니다.
(이미지 프로세싱 주로 하는데... 64비트 코딩시 이점이 많습니다.)

cwryu의 이미지

많이 퍼져 있는 myth인데요. x86 64비트는 생각하는 것만큼 빠르지 않고 어떤 경우는 빠르고 어떤 경우는 느리기도 합니다. 사실 "빠르다는 느낌"이나 "뭔가 다른 게 멋지다"는 느낌이 크게 작용하는데 그것도 무시할 수 없죠. :>

예전에 윈도우즈나 리눅스 벤치마크가 있었는데 찾아 보세요. CPU와 메모리를 아주 많이 사용하는 작업들은 큰 이점이 있지만 그 외의 경우 차이가 없거나 오히려 64비트 버전이 느린 경우도 있었습니다. 저는 호환성 문제를 생각하면 데스크톱 용도로는 32비트가 낫다고 생각합니다.

snowall의 이미지

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

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

피할 수 있을때 즐겨라! http://melotopia.net/b

Daiquiri의 이미지

더 많은 메모리를 사용할 수 있다는 것이 가장 큰 이유지요.

지리즈의 이미지

저사양 PC 기본메모리가 4G가 넘어가는 시점에서 거의 대부분 64bit화가 될 것으로 예상해야 할 것 같습니다.

요즘 시판중인 중사양 이상의 메이커 PC들은 64bit OS가 깔려 나오더군요.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

preisner의 이미지

64bit 환경이라는 것을 구별해서 판단해야 하겠습니다.

i386 계열에서 EM64T(X86_64) 로 넘어가는 것을 말씀 하시는 거라면 지원 메모리 크기 이슈가 제일 큽니다.
하지만 제가 알기로 EM64T 의 내부 처리 레지스터중 메모리 관련 레지스터만 64bit, 그외는 아직도 32bit 로 알고 있습니다.
다시말해 메모리 공간 외에는 어플리케이션 입장에서 별로 달라지는게 없습니다.

하지만 여전히 64bit CPU들, 예를 들면 IA64, SPARC, Power 프로세서등 의 경우 대용량 데이터 처리에 32bit 보다 많은 장점들을 가지고 있습니다.
물론 요즘 x86 계열들이 워낙에 가격대비 성능이 뛰어나 Unix 서버들의 점점 자리를 잃어 가고 있습니다만 말입니다.

어플이 64bit 환경을 고려하지 않고 만들어진 상태에서 OS와 하드웨어만 64bit 로 바뀌게 되면 별 성능 차이는 없을 것 입니다만,
시뮬레이션, 수치 연산등 엄청나게 많은 데이터를 처리해야 하는 환경에서는 64bit 환경이 아니면 안되는 어플들이 있습니다.

cwryu의 이미지

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

hiseob의 이미지

그 "64비트" 커널에 32비트 에뮬레이션 지원 옵션 없으면 32비트 바이너리 는 실행 안됩니다.

cwryu의 이미지

당연한 얘기죠. 64비트 배포판으로 리눅스를 깔더라도 그 옵션은 다 켜져 있습니다. 에뮬레이션이니까 굉장히 오버헤드일 것 같이 생각하기 쉬운데 시스템콜 호출했을 때 ABI 변환하는 정도입니다.

kwon37xi의 이미지

요즘 대형 MMORPG들은 엄청난 메모리를 필요로해서 64Bit로 하면 체감상 빠른 듯 합니다.

하지만 물론 윈도우 32bit에서도 메모리 좀 크게 잡는 옵션이 있긴 하더군요.
아래 링크에서 [시스템] 부분..
http://aion.plaync.co.kr/board/update/view?articleID=68&page=&searchCondition=6&searchKeyword=%EB%A9%94%EB%AA%A8%EB%A6%AC
(Firefox에서 안보입니다.)
http://kwon37xi.egloos.com

winner의 이미지

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

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

ds5pnz의 이미지

연산이 많은 프로그램의 경우는 64비트가 훨씬 빠름을 알 수 있어요.

mycluster의 이미지

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

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

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

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

cwryu의 이미지

그 경우는 램이 많아서 빠른 거죠.

hiseob의 이미지

램이 아무리 많아도 보통 32비트 데스크탑 OS 에서는 3.xx G 까지가 끝이니까요...

cwryu의 이미지

위에도 썼듯이, 리눅스라면 32비트 배포판에서도 64비트 커널을 쓸 수 있고 32비트 커널에서도 PAE 옵션을 사용할 수 있습니다. 윈도우에서도 방법이 없나요?

mycluster의 이미지

제가 아는 한은 없습니다. 아시는 분 있나요?
그리고, OS 사면(아니면 딸려 오면) 32비트, 64비트 모두 하나의 라이선스로 쓸 수 있는데, 왜 굳이 32비트에다가... 고생을 하나요? 그냥 64비트 쓰면 되니까요. 돈 드는 것도 아닌데.

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

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

cwryu의 이미지

리눅스에서 커널 바꾸는 건 그냥 선택에서 설치하면 끝나니 고생도 아닌데, 호환성 문제로 잘못되기 시작하면 오히려 짜증나요.

winner의 이미지

http://support.microsoft.com/kb/291988/ko

http://msdn.microsoft.com/en-us/library/aa366778.aspx

http://en.wikipedia.org/wiki/Physical_Address_Extension#cite_note-11

간단하게 booting설정으로 해결됩니다.
PAE의 장점은 물론 있습니다. OS 환경에 영향을 받는 program들의 호환성이 좋아진다는 것이죠.

소타의 이미지

장비들에 메모리가 32~128GB 꼽혀 있는데 64비트 OS를 안쓰면 타워팰리스 사서 신발장만 쓰는거니까 어쩔수 없습니다..
성능은 체감상으로 차이를 잘 모르겠고 포인터 크기가 8바이트인게 안습입니다 ㅠ;

anabaral의 이미지

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

부랴부랴~~~

JuEUS-U의 이미지

기억으로는 그 때 어드레싱을 위한 추가 레지스터가 있었습니다.
거기에 page number를 저장하고 instant value로 offset을 넘겨주는 방식이였던걸로 기억합니다.

ifree의 이미지

CS 레지스터가 16개의 세그먼트를 제공했던 걸로 기억되네요.
각각 64킬로의 세그먼트 16개를 엮어서 1메가 바이트를 만들었는데 그나마 응용 프로그램에서 쓸 수 있는 메모리는 600 킬로 바이트 정도였습니다.
가용 메모리를 늘리기 위해 EMS, XMS 등의 방법이 동원되었는데, 64K 메모리 16개가 꼽혀 있던 286 보드에 16개를 더 꼽아 2메가로 만들었을 때의 감격이 생생합니다.

clique의 이미지

데스크탑 사용자는 별로 이득볼 일이 없습니다만, 4기가 보다 많은 메모리를 필요로 하는 흔한 어플리케이션(dbms 등)은 상당한 이점이 있죠.
더불어서 64비트 변수를 다룰 때 32비트로 쪼개서 처리할 필요가 없다는 점도 있고요 (이건 컴파일러가 해주지만 어쨌든 에뮬레이션이니까요)

어드레스스페이스 문제 하나 만으로도 전체적인 로직이 단순해지죠.

jeongheumjo의 이미지

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

hyper9의 이미지

Linux는 PAE를 이용해서, 4GB 보다 큰 영역을 이미 사용할 수 있었던 것 같은데요.

preisner의 이미지

Windows 도 이미 Windows 2000 server 부터 PAE를 지원해서 4G 이상 사용 할 수 있습니다.

PAE 와 x86_64 와의 차이에 대해 혼동하시는 분들이 있는 것 같군요.
PAE는 OS 에서 4G 이상의 메모리를 지원 한다고 해도, 어플리케이션 입장에서는 4G 이상의 메모리를 어드레싱 할 수 없습니다.
x86_64 환경에서는 OS와 어플리케이션이 64bit 를 지원한다면 하나의 어플리케이션이 4G 이상의 메모리를 사용 할 수 가 있습니다.

jeongheumjo의 이미지

그냥 궁금해졌어요...
저는 그런거 몰랐거든요. 32비트 XP는 당연히 4기가까지 지원 안될꺼라고 생각했었는데요...
64기가까지 지원되도록 한다면 성능상으로도 64비트 머신에서 64기가 메모리 사용하는 것과 동일한가요?
PAE를 써도 가상주소는 여전히 4기가까지인거죠?

mac040의 이미지

단일 어플리케이션에서는 아마도 4기가까지 할당이 가능할 겁니다(보통 OS 상의 제약으로 인해 이 이하인 겨웅가 많습니다.)

실제로 PAE를 32bit OS에서 지원하는 경우는 거의 없습니다.

이유인즉 Device Driver들이 가운데 주소를 고정으로 떡하니 잡고 있는 경우가 많아서 입니다..

윈도우 7 32bit의 경우 PAE를 사용하지 않고.. (32bit 윈도우 7을 깔면 3.몇 기가로 잡히는 이유)
윈도우 서버 32bit 제품군의 경우 PAE를 사용합니다..
이유인즉 윈도우 서버용 드라이버는 주소할당등의 룰을 따르지 않을 경우 마이크로 소프트에서 인증을 해주지 않고 이러한 드라이버는 윈도우 서버 버전에 인스톨이 되지 않게끔해서 해결한 것으로 알고 있습니다.

또 PAE를 사용할 경우 물리적인 메모리 엑세스는 32비트 단위이고, CPU에서 PAE를 별도로 세팅하는 것이기 떄문에(사실 이렇게 이해는 하고 있으나 PAE 메뉴얼은 복적이 없습니다.. 없어질 기술 같아서) 네이티브 64비트 보다는 느립니다.

JuEUS-U의 이미지

으으음... 뭐 설명을 하려해도, OS virtual memory에 대한 기본적인 이해 없이는 설명이 좀 난해합니다만....

PAE가 활성화된 상태의 32 bit 커널은 addressing에 64 bit 값을 사용합니다.
분명히 해야할 것은 어디까지나 '커널 내부'에서나 그렇게 된다는 겁니다. (다른 모든 조건은 기존 32 bit 환경하고 동일합니다.)
따라서 각 process의 virtual memory space는 여전히 4 GB(32 bit로 표현할 수 있는 최대 크기)로 한정되며
OS가 이 32 bit virtual address를 64 bit physical address로 translate하는 방식으로 4 GB 이상의 physical RAM을 전부 활용할 수 있는겁니다.

여기서 각 프로세스의 page directory/table entry는 전부 64 bit 값으로 구성됩니다.

mac040의 이미지

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

우선 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 깔고 보자"입니다.

사랑천사의 이미지

설마 그래서 AMD64 인건가요... 헉...
-- 사랑천사 --
LECL | Blog
yeosong@gmail.com
yeosong@gmail.com(네이트온) ysnglee2000(Skype)

사람천사

김동수의 이미지

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

김동수 - Prototype for Evolution

preisner의 이미지

좋은 글 잘 읽었습니다.
이건 모.. 리눅스 사이트에서 웬만한 윈도 사이트에서도 볼 수 없는 글을 보는군요. :)

감사합니다.

김동수의 이미지

관련 내용은 제대로 정리 해서 제 블로그에 올리도록 하겠습니다.

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

김동수 - Prototype for Evolution

bushi의 이미지

죄라고 할 것 까진 없지만,
같은 드라이버를 사용할 수 있는 동종 제품군에서도 제품의 가격에 따라 달라지는 것은 사실입니다.
http://www.microsoft.com/whdc/system/platform/server/pae/paedrv.mspx

OTL

litdream의 이미지

어쩌다가 이 글을 접했는데요, 결국 PC 는 64비트 세상이 와버렸네요. 이글을 왜 못봤을까 싶네요. 재밌는 내용도 많았는데..

삽질의 대마왕...