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 비트 프로그램은이를 적절히 활용하도록 작성하면 더 빠를 수 있습니다.
