32 비트 C ++ 코드를 64 비트로 포팅 - 그만한 가치가 있습니까? 왜요?

Question

X64 아키텍처 (더 높은 주소 RAM 주소 등)의 명백한 이익을 알고 있습니다.

• 내 프로그램이 기본 64 비트 모드로 실행할 필요가 없다면 어떨까요? 어쨌든 포트해야합니까?
• 32 비트 지원을 끝내기위한 예측 가능한 마감일이 있습니까?
• 내 애플리케이션이 기본 X64 코드로 더 빠르거나 더 나은 / 더 안전하게 실행됩니까?

Answer 1

X86-64는 약간의 특별한 경우입니다. 많은 아키텍처 (예 : SPARC)의 경우 64 비트 모드에 대한 애플리케이션을 컴파일하면 4GB 이상의 메모리를 수익성있게 사용할 수 없다면 어떤 혜택이 제공되지 않습니다. 바이너리의 크기를 늘리면 실제로 코드를 만들 수 있습니다. 느리게 캐시 동작에 영향을 미치는 경우.

그러나 x86-64는 단지 64 비트 주소 공간과 64 비트 정수 레지스터 이상을 제공합니다. 더블스 X86과 같은 레지스터 결핍 아키텍처에서 재 컴파일만으로도 성능이 상당히 증가 할 수있는 범용 레지스터의 수입니다.

또한 컴파일러는 SSE 및 SSE2와 같은 많은 확장이 존재한다고 가정 할 수 있으며, 이는 코드 최적화를 크게 향상시킬 수 있습니다.

또 다른 이점은 X86-64가 PC 관련 주소 지정을 추가하여 위치 독립 코드를 크게 단순화 할 수 있다는 것입니다.

그러나 앱이 성능에 민감하지 않으면이 중 어느 것도 중요하지 않습니다.

Answer 2

아직 언급하지 않은 한 가지 이점은 잠재적 인 버그를 발견 할 수 있다는 것입니다. 64 비트로 포트하면 여러 가지 변경이 이루어집니다. 일부 데이터 유형의 크기는 변경, 통화 규칙 변경, 예외 처리 메커니즘 (적어도 Windows에서)이 변경됩니다.

이 모든 것이 숨겨진 버그가 표면화 될 수 있으므로 고칠 수 있습니다.

코드가 정확하고 버그가 없다고 가정하면 64 비트로 포팅하면 이론적으로 컴파일러 스위치를 튕기는 것만 큼 간단해야합니다. 그것이 실패한다면, 그것은 당신이 언어로 보장되지 않는 것들에 의존하기 때문에, 그들은 잠재적 인 오류의 원인입니다.

Answer 3

64 비트가 당신을 위해하는 일은 다음과 같습니다.

• 64 비트를 사용하면 32 비트 앱보다 더 많은 메모리를 사용할 수 있습니다.
• 64 비트는 모든 포인터를 64 비트로 만들어 코드 발자국을 더 크게 만듭니다.
• 64 비트는 더 많은 정수 및 부동 소수점 레지스터를 제공하므로 메모리에 쏟아지는 레지스터가 덜 발생하므로 앱 속도가 약간 높아집니다.
• 64 비트는 64 비트 ALU 작업을 더 빠르게 만들 수 있습니다 (64 비트 데이터 유형을 사용하는 경우에만 도움이됩니다).
• 당신은 추가 보안을 얻지 못합니다 (또 다른 답변은 보안에 언급되어 있습니다. 그런 혜택을 알지 못합니다).
• 64 비트 운영 체제에서만 실행되는 것으로 제한됩니다.

여러 C ++ 앱을 포팅했으며 64 비트 코드 (동일한 시스템, 동일한 컴파일러, 유일한 변경 사항은 32 비트 대 64 비트 컴파일러 모드)로 약 10%의 속도를 보였지만 대부분의 앱은 대부분의 앱이었습니다. 상당한 양의 64 비트 수학을 수행합니다. ymmv.

나는 곧 32 비트 지원이 사라지는 것에 대해 걱정하지 않을 것입니다.

(주석에 메모를 포함하도록 편집 - 감사합니다!)

Answer 4

32 비트는 어떤 형태로든 한동안 주변에있을 것이지만, Windows Server 2008 R2는 64 비트 SKU 만 배송합니다. 더 많은 소프트웨어가 64 비트로 마이그레이션 될 때 WOW64가 Windows 8만큼 일찍 설치 옵션으로 보는 것에 놀라지 않을 것입니다. WOW64는 설치, 메모리 및 성능 오버 헤드입니다. RAM 밀도 증가와 함께 32 비트 윈도우의 3.5GB RAM 제한은 이러한 마이그레이션을 장려 할 것입니다. 차라리 CPU보다 더 많은 RAM이 있습니다 ...

64 비트를 포용하십시오! 시간을내어 32 비트 코드 64 비트를 호환 할 수 있으며, 똑똑하고 간단하지 않습니다. 정상적인 응용 프로그램의 경우 변경 사항은 코드 수정으로보다 정확하게 설명됩니다. 드라이버의 경우 선택은 다음과 같습니다. 시간이 오면 재 컴파일이있는 플랫폼에 배포 할 준비가됩니다.

IMO 현재 캐시 관련 문제는 무의미합니다. 이 영역의 실리콘 개선 및 추가 64 비트 최적화가 앞으로 나올 것입니다.

Answer 5

1. 귀하의 프로그램이 64 비트 미만으로 실행할 필요가 없다면, 왜? 메모리 바운드가 아니고 거대한 데이터 세트가 없다면 아무런 설명이 없습니다. 새로운 Miata에는 타이어가 필요하지 않기 때문에 더 큰 타이어가 없습니다.
2. 32 비트 지원 (에뮬레이션을 통해서만)은 소프트웨어가 유용 할 때 오랫동안 연장됩니다. 우리는 여전히 Atari 2600s를 모방합니다.
3. 아니요, 가능성이 높을수록 64 비트 모드에서 응용 프로그램이 느려질 것입니다. 단순히 프로세서 캐시에 적합하지 않기 때문입니다. 약간 더 안전 할 수 있지만 좋은 코더는 그 목발이 필요하지 않습니다. :)

Rico Mariani의 Microsoft에 대한 게시물 그렇지 않습니다 Visual Studio를 64 비트로 포팅하면 실제로 요약합니다 Visual Studio : 64 비트 버전이없는 이유는 무엇입니까? (아직)

Answer 6

코드가 응용 프로그램인지 재사용 가능한 라이브러리인지 여부에 따라 다릅니다. 라이브러리의 경우 해당 라이브러리의 클라이언트가 64 비트 모드로 실행해야 할 충분한 이유가 있으므로 시나리오가 작동하는지 확인해야합니다. 이것은 플러그인을 통해 확장 가능한 응용 프로그램에도 적용될 수 있습니다.

Answer 7

지금 실제로 필요하지 않은 경우 64 비트 모드에서는 포팅을하지 않아야합니다.

지금은 필요하지 않지만 언젠가는 필요할 수 있다면 (예 : 각 컴파일러 경고를 켜고 64 비트 컴파일을 시도함으로써 얼마나 많은 노력을 할 것인지 추정해야합니다). 어떤 것들은 사소하지 않기 때문에 어떤 문제가 발생할 것인지, 어떻게 고치는 데 얼마나 걸릴지 아는 것이 유용 할 것입니다.

의존성에서도 필요가 발생할 수 있습니다. 프로그램이 라이브러리 인 경우 일부 호스트 애플리케이션이 포팅되면 64 비트 모드로 포트해야 할 수도 있습니다.

예측 가능한 미래에 32 비트 응용 프로그램이 계속 지원 될 것입니다.

Answer 8

64 비트로 가야 할 사업의 이유가 없다면 64 비트를 지원할 실제 "필요"는 없습니다.

그러나 다른 사람들이 이미 언급 한 모든 사람들을 제외하고 어느 시점에서 64 비트로 가야 할 좋은 이유가 있습니다.

• 64 비트가 아닌 PC를 구매하기가 점점 어려워지고 있습니다. 32 비트 앱이 앞으로 몇 년 동안 호환 모드에서 실행될 것이지만 오늘날 또는 미래에 판매되는 새로운 PC는 64 비트 일 것입니다. 반짝이는 64 비트 운영 체제가 있다면 호환성 모드에서 "Smelly Old 32 비트 앱"을 실행하고 싶지 않습니다!

• 어떤 것들은 컴퓨터 모드에서 제대로 실행되지 않습니다. 32 비트 하드웨어에서 32 비트 OS에서 실행하는 것과 동일하지 않습니다. 호환성 모드에서 실행될 때 몇 가지 문제 (예 : 32/64 비트 레지스트리 히브에 걸쳐 레지스트리 액세스, 32/64 비트 레지스트리 히브에 걸쳐 실패하는 프로그램)가 실행될 때 실행될 때 실패합니다. 나는 항상 호환성 모드에서 내 코드를 실행하는 것에 대해 긴장감을 느낍니다. 단순히 "실제가 아님"이며 종종 보여줍니다.

• 당신이 당신의 코드를 깨끗하게 작성했다면, 당신은 그것을 64 비트 exe로 다시 컴파일하기 만하면 잘 작동 할 가능성이 높아서 시도하지 않을 이유가 없습니다.

• 일찍 네이티브 64 비트 버전을 구축할수록 새로운 기능을 추가 할 때 64 비트로 계속 작동하는 것이 더 쉬워집니다. 그것은 또 다른 'n'시대에 어두운 시대에 계속 발전하고 빛으로 뛰어 들어가는 것보다 훨씬 더 나은 계획입니다.

• 다음 면접을 받으면 64 비트 expeirence와 32-> 64 포팅 경험이 있다고 말할 수 있습니다.

Answer 9

이미 X64 장점 (가장 중요한 RAM 크기 증가)을 알고 있으며 관심이 없으며 실행 파일 (EXE)을 포트하지 마십시오. 일반적으로 X86에 대한 X64 모듈의 크기가 증가함에 따라 포트 후에 일반적으로 성능 저하가 발생합니다. 모든 포인터는 이제 이중 길이가 필요하며 코드 크기 (일부 점프, 기능 호출, VTABLE, 가상 호출, 글로벌 기호를 포함하여 모든 곳에서는이 과정이 발생합니다. 등). 상당한 분해는 아니지만 일반적으로 측정 가능합니다 (3-5% 속도 감소, 많은 요인에 따라 다름).

DLL을 소비 할 수있는 X64 앱에서 새로운 '잠재 고객'을 얻기 때문에 DLL은 포팅 할 가치가 있습니다.

Answer 10

일부 OSS 또는 구성은 32 비트 프로그램을 실행할 수 없습니다. 32 비트가없는 최소 리눅스 libc 예를 들어 설치되었습니다. 또한 IIRC 나는 보통 커널에서 32 비트 지지대를 컴파일합니다.

이러한 OSS 또는 구성이 잠재적 인 사용자 기반의 일부인 경우 그렇습니다.

더 빠른 속도가 필요한 경우, 다른 사람들이 말했듯이 X86-64에는 더 많은 레지스터와 멋진 지침이 있습니다).

또는 MMAP ()를 원하거나 큰 파일 또는 많은 메모리를 매핑하려는 경우. 그런 다음 64 비트가 도움이됩니다.

Answer 11

예를 들어 아래 편집 : 형식 코드와 같이 32 비트 코드 (GNU C/++)를 작성한 경우

struct packet {
    unsigned long name_id;
    unsigned short age;
};

네트워크 메시징의 경우 HTONL/NTOHL 등으로 인해 64 비트 시스템에서 다시 컴파일하는 동안 포트를 수행해야합니다. 네트워크 피어가 여전히 32 비트 시스템을 사용하고있는 경우 통신이 파손됩니다 (동일한 코드를 사용합니다. 당신 것); 당신은 (긴) 크기가 32에서 64로 변경 될 것임을 알고 있습니다.

32/64 포팅에 대한 자세한 내용을 참조하십시오 http://code.google.com/p/effocore/downloads/list, 문서 이름 effocoreref.pdf.

Answer 12

극단적 인 보안 조치 나 외설적 인 RAM이 필요하지 않으면 어떤 혜택을 보지 못할 것 같지 않습니다.

기본적으로 코드가 64 비트 포팅의 좋은 후보라면 직관적으로 알고있을 것입니다.

Answer 13

마감일에 대해. 나는 걱정하지 않을 것입니다. 32 비트와 같은 것들은 기본적으로 그리고 다른 형태의 예측 가능한 미래를 위해 좋은 일을 할 것입니다.

Answer 14

이 질문에 대한 나의 대답을 참조하십시오 여기. 나는 64 비트 컴퓨터가 32 비트 컴퓨터보다 훨씬 더 많은 정보를 저장하고 검색 할 수 있다고 말하는 게시물을 닫았습니다. 대부분의 사용자에게는 웹을 탐색하고 이메일을 확인하고 Solitaire를 재생하는 것과 같은 것이 32 비트 주소 지정 내에서 편안하게 작동하기 때문에 실제로 많은 것을 의미하지는 않습니다. 64 비트 혜택이 실제로 빛날 곳은 컴퓨터가 휘젓어야하는 많은 데이터가있는 영역에 있습니다. 디지털 신호 처리, 기가 픽셀 사진 및 고급 3D 게임은 대량의 데이터 처리가 64 비트 환경에서 크게 향상 될 수있는 영역입니다.

코드가 더 빠르거나 더 나은 코드에 대해서는 전적으로 코드와 그에 따른 요구 사항에 달려 있습니다.

Answer 15

성능 문제에 관해서는 실제로 프로그램에 따라 다릅니다. 프로그램이 포인터 집약적 인 경우 64 비트로 포팅하면 성능 다운 그레이드가 발생할 수 있습니다. 동일한 크기의 CPU 캐시, 각 64 비트 포인터는 캐시에서 더 많은 공간을 차지하고 가상-물리적 매핑도 더 많은 TLB 공간을 차지합니다. . 그렇지 않으면 프로그램이 포인터 집약적이지 않으면 성능은 x64의 혜택을받습니다.

물론 성능이 포팅의 유일한 이유는 아닙니다. 포팅 노력, 시간 예약과 같은 다른 문제도 고려해야합니다.

Answer 16

나는 당신이 "기본"을 실행할 수 있도록 64 비트로 포팅하는 것이 좋습니다 (또한 OpenBSD를 사용합니다. AMD64 포트에서는 32 비트 에뮬레이션 지원을 제공하지 않으므로 모든 것이 64 비트 여야합니다).

또한, stdint.h 당신의 가장 친한 친구입니다! 애플리케이션을 포팅하면 코드를 포괄적으로 코딩하는 방법을 배워야합니다. 128 개의 비트 프로세서가있을 때 코드가 작동하게 할 것입니다 (수십 년 동안 희망적으로)

나는 2 ~ 3 가지를 64 비트로 포팅했으며 이제는 이제 둘 다 (stdint.h를 사용하는 경우 매우 쉽습니다)와 첫 번째 프로젝트에서 2 ~ 3 개의 버그와 같은 64 비트로 포팅되었지만 나타났습니다. 그것. 대부분은 간단한 재 컴파일이었고 이제 새 코드를 만들 때 32와 64 비트의 차이에 대해 걱정하지 않습니다. (intptr_t 및 size_t 사용)

Answer 17

64 비트 프로세스에서 DLL이 호출되는 경우 DLL도 64 비트 여야합니다. 그렇다면 그만한 가치가 있는지 여부는 중요하지 않습니다. 선택의 여지가 없습니다.

Answer 18

명심해야 할 한 가지 문제는 사용 가능한 소프트웨어 라이브러리입니다. 예를 들어, 회사는 여러 개의 OpenGL 라이브러리를 사용하는 응용 프로그램을 개발하고 OpenSuse OS에서 그렇게합니다. 이전 버전의 OS에서는 X86_64 아키텍처에서 이러한 라이브러리의 32 개 비트 버전을 다운로드 할 수 있습니다. 그러나 최신 버전에는 이것을 가지고 있지 않습니다. 64 비트 모드로 컴파일하기가 더 쉬워졌습니다.

Answer 19

64 비트 컴파일러가 성숙 해지면 64 비트가 훨씬 빠르게 실행되지만 발생하면 알 수 없습니다.