64 비트 프로그램이 32 비트 버전보다 크고 빠릅니까?

x86에 초점을 맞추고 있다고 생각하지만 일반적으로 32 비트에서 64 비트로 이동하는 데 관심이 있습니다.

논리적으로, 어떤 경우에는 상수와 포인터가 더 커져 프로그램이 더 커질 수 있음을 알 수 있습니다. 효율성을 위해 단어 경계에 메모리를 할당하려는 욕구는 할당 사이에 더 많은 공백을 의미합니다.

또한 x86의 32 비트 모드는 중첩되는 4G 주소 공간으로 인해 컨텍스트 전환시 캐시를 플러시해야한다고 들었습니다.

그렇다면 64 비트의 실제 이점은 무엇입니까?

그리고 보충 질문으로 128 비트가 더 좋을까요?

편집하다:

방금 첫 32/64 비트 프로그램을 작성했습니다. 16 바이트 (32b 버전) 또는 32 바이트 (64b 버전) 개체의 연결 목록 / 트리를 만들고 stderr에 많은 인쇄를 수행합니다. 정말 유용한 프로그램은 아니지만 일반적인 것은 아니지만 첫 번째 작업입니다.

크기 : 81128 (32b) v 83672 (64b)-큰 차이가 없습니다.

속도 : 17s (32b) v 24s (64b)-32 비트 OS (OS-X 10.5.8)에서 실행

최신 정보:

64b이지만 32b 포인터를 사용하는 새로운 하이브리드 x32 ABI (Application Binary Interface)가 개발 중이라는 점에 주목합니다. 일부 테스트의 경우 32b 또는 64b보다 코드가 작고 실행 속도가 빠릅니다.

https://sites.google.com/site/x32abi/

32b 주소 지정이 허용하는 것보다 더 많은 메모리에 액세스해야하는 경우가 아니면 이점이 적습니다.

64b CPU에서 실행하는 경우 32b 또는 64b 코드를 실행하더라도 동일한 메모리 인터페이스를 얻게됩니다 (동일한 캐시와 동일한 BUS를 사용하고 있음).

x64 아키텍처에는 더 쉽게 최적화 할 수있는 레지스터가 몇 개 더 있지만 이는 포인터가 이제 더 커지고 포인터가있는 구조를 사용하면 메모리 트래픽이 증가한다는 사실에 의해 종종 해결됩니다. 32b 응용 프로그램에 비해 64b 응용 프로그램의 전체 메모리 사용량이 15-30 % 정도 증가 할 것으로 예상합니다.

일반적으로 x86에 비해 x86-64에서 컴퓨팅 집약적 인 코드의 속도가 30 % 향상됩니다. 이는 8 x 32 비트 범용 레지스터와 8 x SSE 레지스터 대신 16 x 64 비트 범용 레지스터와 16 x SSE 레지스터가 있다는 사실 때문일 가능성이 큽니다. 이것은 x86-64 Linux의 인텔 ICC 컴파일러 (11.1)를 사용하는 것입니다. 물론 다른 컴파일러 (예 : gcc) 또는 다른 운영 체제 (예 : Windows)의 결과는 다를 수 있습니다.

이점에 관계없이 라이브러리를 32 비트 바이너리로 컴파일하고 64 비트에서 제공하는 경우 항상 시스템의 기본 단어 크기 (32 비트 또는 64 비트)에 맞게 프로그램을 컴파일하는 것이 좋습니다. 64 비트 버전이 사용 가능한 기본값 인 경우 라이브러리와 링크하려는 모든 사용자가 라이브러리 (및 기타 라이브러리 종속성)를 32 비트 바이너리로 제공하도록 강제합니다. 이것은 모두에게 상당히 성가신 일이 될 수 있습니다. 확실하지 않은 경우 라이브러리의 두 버전을 모두 제공하십시오.

64 비트의 실질적인 이점에 관해서는 ... 가장 분명한 것은 더 큰 주소 공간을 확보한다는 것입니다. 따라서 파일을 mmap하면 한 번에 더 많은 주소를 지정할 수 있습니다 (더 큰 파일을 메모리에로드). 또 다른 이점은 컴파일러가 최적화 작업을 잘 수행한다고 가정하면 많은 산술 연산을 병렬화 할 수 있다는 것입니다 (예 : 두 쌍의 32 비트 숫자 쌍을 두 개의 레지스터에 배치하고 단일 추가 작업에서 두 ​​개의 추가 수행). 숫자 계산이 더 빨리 실행됩니다. 즉, 전체 64 비트 대 32 비트는 점근 적 복잡성에 전혀 도움이되지 않으므로 코드를 최적화하려는 경우 이와 같은 상수 요소보다는 알고리즘을 살펴 봐야 할 것입니다.

편집 :
병렬 추가에 대한 내 진술을 무시하십시오. 이것은 일반적인 add 문에 의해 수행되지 않습니다. 일부 벡터화 / SSE 명령과 혼동했습니다. 더 큰 주소 공간을 제외하고 더 정확한 이점은 더 많은 범용 레지스터가 있다는 것입니다. 즉, CPU 레지스터 파일에서 더 많은 로컬 변수를 유지할 수 있으며, 이는 변수를 프로그램 스택 (일반적으로 L1 캐시로 나가는 것을 의미 함).

더 많은 레지스터를 갖는 것 외에도 64 비트에는 기본적으로 SSE2가 있습니다. 이것은 실제로 일부 계산을 병렬로 수행 할 수 있음을 의미합니다. SSE 확장에는 다른 장점도있었습니다. 그러나 주요 이점은 확장 기능이 있는지 확인할 필요가 없다는 것입니다. x64 인 경우 SSE2를 사용할 수 있습니다. ... 내 기억이 올바르게 봉사한다면.

저는 foolsmate 라는 체스 엔진을 코딩하고 있습니다. 최소값 기반 트리 검색을 사용하여 깊이 9 (특정 위치에서)로 이동하는 가장 좋은 방법은 다음과 같습니다.

에 Win32구성 : ~ 17.0s;

x64구성으로 전환 한 후 : ~ 10.3s;

이것은 가속의 41 % 입니다!

애플리케이션을 64 비트로 이동하는 이유는 애플리케이션이 더 나은 성능을 위해 캐시 할 때 2GB 제한이 상당히 빠르게 초과되는 동시 사용자가 100 명 이상인 대규모 데이터베이스 또는 ERP 애플리케이션과 같은 애플리케이션에서 더 많은 메모리가 필요하다는 것입니다. 이것은 특히 integer 및 long이 여전히 32 비트 인 Windows OS의 경우입니다 (새 변수 _int64가 있습니다. 포인터 만 64 비트입니다. 실제로 WOW64는 Windows x64에서 고도로 최적화되어 32 비트 응용 프로그램이 64 비트 Windows에서 낮은 패널티로 실행됩니다. OS. Windows x64에서의 경험은 32 비트 응용 프로그램 버전이 64 비트보다 10-15 % 더 빠르게 실행됩니다. 이전의 경우 적어도 독점 메모리 데이터베이스의 경우 b- 트리 (데이터베이스 시스템의 프로세서 집약적 인 부분)를 유지하기 위해 포인터 산술을 사용할 수 있기 때문입니다. . 32-64 비트 운영 체제에서 두 배로 감당할 수없는 최고의 정확도를 위해 큰 십진수가 필요한 계산 집약적 인 응용 프로그램입니다. 이러한 응용 프로그램은 소프트웨어 에뮬레이션 대신 기본적으로 _int64를 사용할 수 있습니다. 물론 대용량 디스크 기반 데이터베이스는 쿼리 계획을 캐싱하는 데 대용량 메모리를 사용할 수 있기 때문에 32 비트 이상의 개선을 보여줄 것입니다.

각 메모리 페치 (32 비트 대신 64 비트)에 대해 CPU와 RAM간에 더 많은 데이터가 전송되므로 64 비트 프로그램은이를 적절히 활용하도록 작성하면 더 빠를 수 있습니다.

x68에서 x68_64까지의 특정 경우에 64 비트 프로그램은 크기가 약간 더 작지는 않지만 약간 더 많은 메모리를 사용하고 더 빠르게 실행됩니다. 대부분 이것은 x86_64에 64 비트 레지스터가있을뿐만 아니라 두 배나 많기 때문입니다. x86에는 컴파일 된 언어를 가능한 한 효율적으로 만들기에 충분한 레지스터가 없으므로 x86 코드는 레지스터와 메모리간에 데이터를 앞뒤로 이동하는 데 많은 명령과 메모리 대역폭을 소비합니다. x86_64는 그보다 훨씬 적기 때문에 약간의 공간을 차지하고 더 빠르게 실행됩니다. 부동 소수점 및 비트 트위들 링 벡터 명령어도 x86_64에서 훨씬 더 효율적입니다.

그러나 일반적으로 64 비트 코드는 런타임에 코드 및 메모리 사용량 모두에서 반드시 더 빠르지는 않으며 일반적으로 더 큽니다.

오디오이든 시각적이든 관계없이 트랜스 코딩, 디스플레이 성능 및 미디어 렌더링과 같은 CPU 사용이 필요한 모든 응용 프로그램은 (이 시점에서) 분명히 필요하며 CPU의 순전 한 처리 능력으로 인해 32 비트 대비 64 비트를 사용하는 이점이 있습니다. 그것에 던져지는 데이터의 양. 데이터가 처리되는 방식이기 때문에 주소 공간의 문제가 아닙니다. 64 비트 코드가 제공되는 64 비트 프로세서는 특히 트랜스 코딩 및 VoIP 데이터와 같이 수학적으로 어려운 작업에서 더 나은 성능을 발휘할 것입니다. 실제로 모든 종류의 '수학'애플리케이션은 64 비트 CPU 및 운영 체제를 사용하여 이점을 얻을 수 있습니다. 내가 틀렸다는 것을 증명 해봐.