x64 시스템의 효과적인 활용법은?

익명 사용자의 이미지

요즈음 AMD64, EMT64 등 64bit 이 많이 나오고, 활용되고 있는듯 합니다.

그런데, 아직 안정화 단계에 들어서지 않았는지, 작은 문제들이 간혹 보이는 것 같기도 하구요.

각 배포판들이 x64 버전을 같이 발표하고 있긴 합니다만, 32버전과 혼용해서 쓰는 사람들은 불편한 점을 호소 하는 것 같습니다.

현재 쓰고 있는 분들, 혹은 쓸예정에 있는 분들은 어떻게 활용하고 계시고, 예정이신지요?

사용중에 어떠한 불편들이 있는지, 좋은 해결책을 나누었으면 합니다.

rainbird의 이미지

AMD64, EM64T는 x86_64 라고 합니다. 64bit로 동작하면서 기존 32bit application을 수행 할 수 있는 시스템을 말합니다.
아직도 커널 2.6.x대에서 계속 패치되고 있는듯 합니다. (완전한 안정은 아직 좀 먼듯합니다.)
IA-32 아키텍쳐와 다르게 IA-64아키텍쳐가 있습니다.
이 x86_64 아키텍쳐는 IA-64도 아니고 IA-32도 아닙니다.
참 애매모호한 놈입니다. :)

ps. x64라고 하는건 처음봐서 몇자 끄적였습니다 :)
ps2. 2.6.10에서 11로 패치되면서 define되어있는 address가 바뀔 정도로 아직 계속 진행중입니다 ;)

/ / / // // / /// / / / // // / // // // / / / ////// // /
/ / // // / /// / / / // // / // // // / / / /// // // / /
/ / // // / /// / / / // // / // // // / // //...rainbird

익명 사용자의 이미지

용어 선택에 착오가 있었군요. ^^

현재로서는 배포판에서 제공하는 pure 64 정도가 가장 효과적인 사용방법이 될까요?

32에서 64로 완전히 넘어가는 시점이 안정화 시점이 되려나?

상당히 오랜기간 이런상태가 지속이 될 것 같기도 하네요.

회니의 이미지

rainbird wrote:
ps. x64라고 하는건 처음봐서 몇자 끄적였습니다 :)

ms의 윈도우에선 x64라고 붙이더군요.
뭐 기존엔 Win32였으니 앞으로 나올 64비트 프로그램은 Win64라고칭하겠죠.
뭐라 부르던 별 상관없지만, 하나로 통일하는게 좋지 않을까요?

리눅스x86_64를 사용하는 입장에서 몇자적자면...
32비트나 64비트나 크게 바뀐것은 없는것 같습니다.
다만 64비트는 프로세스가 부드러워졌다는 느낌만 드네요.
그럼 큰 이슈만 나열해 보겠습니다.

1. 드라이버(64비트용)
->윈도우쪽이 심할것 같네요.

2. 웹 플러그인(자바, 플래시 모두 안됨)
-> 대책으로 32비트 브라우저를 설치해서 32비트 플러그인을 설치한다.

3. 64비트 어플리케이션 부족
-> 점점 많아지겠죠. matlab같은 유명한 프로그램은 벌써 64비트용까지 나왔습니다.

HotPotato의 이미지

pure64도 기존 데스크탑처럼 자연스럽게 쓰고 있습니다.
다만 플래시와 자바 플러그인을 못쓰고 있을 뿐.

debian pure64 port!
그리고 32비트 호환모드를 커널설정때 아예 꺼놓고 씁니다.

64비트를 사놓고 괜히 32비트용 애플리케이션을 쓸 필요는 없죠.
오피스만 똑바로 지원된다면 32비트는 필요없습니다.

--
즐 Tux~

HotPotato의 이미지

pure64 port FAQ를 읽어보면

원래 x86_64명칭을 쓰다가 amd측에서 amd64로 부르도록 명칭을 변경했다는 소리가 있습니다. 그러나 리눅스 커널에서는 x86_64로 굳어졌답니다.

em64t는 amd64에 호환되게 메모리를 늘렸다고 들었던 것 같습니다.

--
즐 Tux~

hiseob의 이미지

EM64T 의 정체는

AMD의 AMD64 와 같은걸로 압니다.

INTEL 이 AMD 가 어려울떄 크로스 라이선싱을 했죠.

(그래서 요즘 새로나오는 애슬론 64 나 옵테론에 SSE3 가 들어가 있죠.)

익명 사용자의 이미지

제조업 회사에 근무하면서 비주얼베이직(예전)이나 C#(현재)으로 DB프로그램 만들어주는 사람입니다.
DB로는 MySQL을 씁니다.

2년 전에 썼던 DB서버 메모리가 1GB이었고, DB캐쉬로 700MB를 썼는 데, 자료가 쌓이면서 DB파일 크기가 1GB를 넘어갔습니다.
이제 좀 있으면 메모리가 부족해져서 하드디스크 액세스가 많아질 것 같더군요.

중국에 새롭게 건설한 공장에는 메모리 한계를 의식해서 EM64T서버를 구입하고 4GB를 달았습니다. (OS는 리눅스입니다.)
향후 램 추가할 수 잇는 소켓이 4개 더 있으니, 8GB로 만들 수 잇겠지요.

중국 공장의 경우 데이터가 많이 쌓여도 데이터가 (대부분의 경우) 메모리에서만 놀지 않을까 싶습니다.

지금까지 불편한 점은 모르겠습니다.
MySQL은 X86_64에 대해서도 바이너리가 제공됩니다. (RPM은 없었던 것 같습니다만.)
mono가 X86_64를 지원하기 때문에 C#으로 서버 관리용 프로그램을 짜서 cron으로 돌립니다.
(저는 쉘 스크립트나 Perl등 리눅스에서 널리 쓰이는 언어를 전혀 모릅니다.)

X86_64에 대한 프로그램적 지원은 리눅스의 경우 상당히 좋다고 생각합니다.

저는 메모리 용량 한계 때문에 서버에는 X86_64를 선택했습니다만, 일반 사무용 컴퓨터에는 기존의 32비트로도 당분간은 별 문제 없을 것 같습니다.

coyday의 이미지

뭐.. 개인 사용자에겐 당분간은 크게 달라질 것 같진 않은데 아무래도 서버 시장에서는 순수하게 서버 용도로 64비트로의 이행이 가속될 것 같습니다. 성능은 당연히 좋아질 테고...

북한산(X) 삼각산(O) 백운대(X) 백운봉(O)

ssggkim의 이미지

주제와 상관없는 내용이지만 궁금해서 질문드립니다. 부디 이해해주시길 :wink:

anonymous10 wrote:
mono가 X86_64를 지원하기 때문에 C#으로 서버 관리용 프로그램을 짜서 cron으로 돌립니다.
(저는 쉘 스크립트나 Perl등 리눅스에서 널리 쓰이는 언어를 전혀 모릅니다.)

Windows에서도 C#의 경험이 당연히 있으실듯 한데, mono의 C# 구현은 windows에서와 비교해서 어느정도 인지 평을 좀 해주실 수 있으련지요.

익명 사용자의 이미지

좋은 점..

비주얼 스튜디오 2003에서 컴파일해서 모노에서 바로 돌릴 수 있습니다.

안 좋은 점.

자잘한 버그가 많습니다.
String.Compare메소드 결과과 윈도우와 다르더군요.
테이블의 필드들을 소트할 때 썼는 데 불편하더군요.

또, 파일에 UniCode로 저장한 내용이 윈도우에서 보면 깨집니다.

그냥 간단한 스크립트 짜는 데에는 문제가 없지만, 본격적으로 쓰기에는 아직 좀 더 있어야 되겠더라구요.
저는 윈폼을 주로 쓰는 데 윈폼은 가장 약한 부분이죠.

어쨋거나 리눅스에서 돌리는 프로그램을 비주얼 스튜디오에서 컴파일한다는 게 가장 좋았습니다.