Raspbian이 64 비트 모드로 이동

에서 이 페이지 , 공식 RPi3 발표 상태 :

다운로드 페이지에서 최근 NOOBS 또는 Raspbian 이미지가 필요합니다. 시작시 다른 Raspberry Pi 장치에서 사용하는 것과 동일한 32 비트 Raspbian 사용자 영역을 사용하고 있습니다. 향후 몇 개월 동안 64 비트 모드로 전환 할 가치가 있는지 조사 할 것입니다.

내 질문은 프로세서가 64 비트 라는 점에서 OS를 64 비트로 실행하는 것이 모든면에서 더 낫다는 것이 분명 하지 않습니까? 내가 무엇을 놓치고 있습니까?

프로세서가 64 비트 인 경우, 64 비트로 OS를 실행하는 것이 모든면에서 더 나을 것이라는 것이 분명하지 않습니까?

실제로는 그렇지 않습니다. 어떤 식 으로든 64 비트 운영 체제를 실행 하면 Raspberry Pi의 성능 이 저하 될 수 있습니다.

64 비트의 장점 :

64 비트 프로세서 / 운영 체제를 사용하면 얻을 수있는 두 가지 주요 이점은 장치가 4GB 이상의 RAM을 처리 할 수 ​​있으며 기본적으로 큰 2^32라이브러리가 필요하지 않은 것보다 큰 정수를 처리 할 수 있다는 것입니다.

라즈베리 파이에는 4GB 이상의 RAM이 없습니다. 1GB의 RAM에서 두 가지 주요 이점 중 첫 번째 이점을 완전히 상실했습니다. 두 번째 혜택은 재단이 전체 운영 체제를 지원하는 데 충분한 수의 사람들을 실제로 사용하고있는 비율은 몇 퍼센트입니까? RPi는 소프트웨어 방법을 통해 많은 수를 사용할 수 있지만, 그 영역에서 일관되게 유지하려면 더 나은 하드웨어를 사용해야 할 것 같습니다.

64 비트 문제 :

더 큰 숫자를 저장하는 기능은 마법에 의해 부여되지 않습니다. 오히려 메모리 객체의 크기를 늘려야합니다. C (및 C ++)에서는를로 변경하는 것을 의미 int합니다 int64_t. 이것은 자동으로 수행되지 않으므로 재단에 대한 의견은 두 가지를 유지하고 싶지 않습니다.

또한 많은 응용 프로그램은 64 비트 모드에서 실행될 때 (대부분의 사용자에게) 이점을 제공하지 않습니다. 대부분의 웹 브라우저, MS Office 및 기타 널리 사용되는 소프트웨어는 모두 32 비트 방식으로 배송 및 유지 관리됩니다. 물론 64 비트 MS Office 릴리스를 사용할 수 있지만 거의 사용되지 않습니다.

응용 프로그램 / 운영 체제가 64 비트 아키텍처를 활용하도록 작성된 경우 변수와 포인터가 더 많은 공간을 차지하기 때문에 응용 프로그램에서 더 많은 메모리를 사용하게됩니다. 일반적으로 이는 특전의 혜택을받는 기계에 대한 상대적으로 작은 거래입니다. 우리의 경우에는 특권이 거의없고 RAM도 거의 없습니다.

참고 사항 :

64 비트 컴퓨터에서 실행한다고해서 응용 프로그램이 32 비트로 실행되고 있지는 않습니다. 윈도우는 두 개의 서로 다른 설치 경로를함으로써이 아주 명확하게, C:\Program Files그리고 C:\Program Files (x86).

그렇다면 재단은 64 비트 지원을 제공 할 가능성이 있습니까? :

"어떤 사람들은 혜택을 볼 수 있지만 대부분은 그렇지 않을 것입니다."와 같은 시점으로 돌아 왔습니다. 확실히 64 비트 빌드를 제공하는 다른 프로젝트를 보게 될 것입니다. 그러나 기초가 과도하게 많은 (imo) 플랙을 얻지 않는 한 아마도 그렇지 않을 것입니다 (imo). 별도의 64 비트 브랜치를 만들고 유지 관리하는 것은 작은 노력이 아니며 솔직히 가치가없는 것 같습니다.

ARM 및 Intel / AMD의 상황이 다르다는 점에 주목할 가치가 있습니다. 이는 x86_64 로의 전환이 기본적으로 8 개의 범용 레지스터만으로 무너지고 64 비트 모드에서 두 배가 된 고난도 아키텍처를 업데이트 할 수있는 기회로 사용 되었기 때문입니다. 따라서 인텔 / AMD 시스템을 64 비트 모드로 전환하면 성능에 큰 차이를 일으키는 실제 기능을 사용할 수 있습니다.

ARM은이 문제가 처음부터 시작되지는 않았지만 (AArch64는 레지스터를 추가하지만 32 비트 아키텍처는 굶주 리지 않았습니다) 이점은 기본적으로 직접 주소 지정이 가능한 메모리와 기본 큰 정수 지원입니다. 거래 및 아마도 단점 (모든 것에 사용되는 더 많은 메모리)에 의해 반박 될 것입니다.

(이와 같은 이유로, 인텔 / AMD Linux 용 "x32"abi를 작성 하여 CPU 향상을 유지하면서 32 비트 포인터를 사용 하는 작업이 일부있었습니다 .)

Pi 3에 이미 Debian Aarch64 (ARMv8)를 실행중인 사람들이 있다고 확신합니다. 대부분의 사용자에게는 아마 약간의 스트레치 이지만 많은 사람들에게는 그렇게 어렵지 않을 것입니다 ( 여기에 대한 힌트는 여기 를 참조하십시오 ). ¹

그러나 Raspbian 및 / 또는 Foundation에 64 비트 버전이 제공되지 않는 경우 블로그 등을 운영하는 사람들이 블로그를 운영하는 방법을 설명하고 여전히 필요한 제품을 얻는 방법을 점점 더 많이 보게 될 것입니다.

이제 Pi 3 용 Fedora aarch64 릴리스 가 있습니다.

^{1. 32 비트에 약간의 문제가있을 수 있습니다 /opt/vc. x86-64 용 32 비트 compat 라이브러리가 있었지만 Aarch64 ...는 아닐 수도 있습니다.}

출시 홍보의 일환으로 두 가지 별도의 코드 기반 (32 및 64 비트)을 유지하기위한 노력이 한 가지 문제라고 언급했습니다. Adafruit PI3 Launch 비디오는 64 비트 프로세서로의 이동이 64 비트 모드를 사용하는 것보다 새로운 칩을 제공하는 클럭 속도 증가에 관한 것이라고 언급했습니다.

64 비트 주소 지정은 1GB 이상의 메모리가없는 경우에도 유용 할 수 있습니다.

대용량 파일을 메모리에 매핑 할 수 있으므로 포인터가 있고 OS에서 I / O를 투명하게 수행 할 수 있습니다. I / O를 수행하는 또 다른 방법입니다. 큰 파일에서이 작업을 수행하려면 64 비트 주소 지정이 필요합니다.

내가 유용 할 수있는 또 다른 예는 프로세스가 스왑 공간을 사용하여 2GB 이상의 주소 공간을 가질 수있게하는 것입니다. 최근에 스토리지가 많고 파일 시스템이 손상된 32 비트 NAS에 문제가있었습니다. 캐싱 옵션이 켜져 있어도 fsck 프로세스에 메모리가 부족합니다. 스왑 공간을 추가하면 문제를 해결할 수 없었습니다. 32 비트 주소 공간이 그 한계였습니다. 따라서 32 비트 바이너리를 사용하여이 손상된 파일 시스템에서 fsck를 실행할 방법이 없었습니다. 64 비트 바이너리와 일부 스왑 공간이 있으면 실행되었을 것입니다.

64 비트 기본 프로그램이 더 크고 (데이터 및 포인터를위한 더 많은 메모리), 4GB 미만의 RAM을 가진 ARMv8의 64 대 32 비트 OS에는 눈에 띄는 이점이 없다고 주장하면서 몇 가지를 높이고 싶습니다. 포인트들.

ARMv7 실행을보다 효율적으로 만드는 ARMv7 (및 이전) 및 ARMv8에서 아키텍처가 수행되는 방식에는 몇 가지 중요한 차이점이 있습니다. 이 중 일부는 더 넓은 내부 데이터 경로에서 비롯된 것이며, 일부는 특수한 경우를 제거하고 훨씬 더 깊은 파이프 라인입니다. 이와 동일한 변경으로 ARMv7 (32 비트) 코드를 실행할 때 ARMv8이 향상되었습니다.

기본 64 비트 응용 프로그램은 64 비트 포인터를 사용하고 'size_t'는 64 비트이므로이를 사용하는 요소가 더 커집니다. 나머지 데이터는 같은 크기를 유지하는 경향이 있습니다. 그러나 이것의 중요성은 실행 가능한 이미지의 크기에 미미합니다.

64 비트 네이티브가 실제로 빛나는 곳 (큰 정수 및 부동 소수점 항목에 신경 쓰지 않는 경우)의 가상 주소 공간이 더 큽니다.

• OS는 가상 주소 공간을 점점 더 큰 섹션으로 나눌 수 있으므로 공유 리소스를보다 쉽게 ​​관리하고 다양한 수준의 권한간에보다 간소화 된 컨텍스트 전환 등을 수행 할 수 있습니다.
• 스와핑을 활성화 한 경우 실제 메모리 제한을 초과하여 더 많은 프로세스를 실행할 수 있습니다 (이는 실제로 32 비트에서도 마찬가지이지만 64 비트에서는 덜 제한적 임)

OS가 현재이 기능을 활용하는지 여부에 관계없이 주류가 32 비트에서 멀어짐에 따라 차이가 생길 것입니다.

나는 기본 64 비트 AArch64 커널로 이동하는 가장 좋은 주장은 이식성이라고 생각합니다. 주류 데스크탑은 대부분 64 비트 프로세서로 이동했으며 64 비트를 가정하는 더 많은 패키지를보고 있으며 그러한 코드를 32 비트로 다시 포팅하는 것이 더 어렵습니다 32에서 64 비트로 포팅하는 것보다 사용자 공간에서는 다중 아치 라이브러리를 설치했다고 가정하면 32 비트 응용 프로그램과 64 비트 응용 프로그램을 나란히 실행할 수 있으므로 32 비트에서 64 비트가 아닌 경우 32 비트 응용 프로그램을 포트 할 필요가 없습니다. 문제. 64 비트 OS는 단순히 더 많은 소프트웨어를 제공 할 것입니다.

Raspberry PI 3에 64 비트 커널을 생성하는 것이 쉽다는 것은 아닙니다. 낮은 수준에서 변경해야하는 중요한 차이점이 있지만 모든 장치 드라이버가 64 비트로 깨끗하지는 않습니다 (특히 ARM 전용 GPU 용 드라이버). Raspberian은 32 비트 OS로 남아있을 수도 있지만 장거리에서는 근시안적이라고 생각합니다.

단일 부트 미디어 (예 : SD 카드)에는 64 비트와 32 비트 버전의 OS가 포함될 수 있으며 보조 부트 소프트웨어 (u-boot, arm-boot 등)는로드 할 미디어를 결정할 수 있습니다. 더 어려운 부분은 사용자 영역입니다. 파일 시스템은 64 비트가 쓸모없는 32 비트 시스템에서도 멀티 아치이어야합니다. 32 비트 전용 시스템에서 불필요한 라이브러리 및 프로그램 실행 파일을 제거하기 위해 초기 부팅 후 실행할 수있는 스크립트 또는 유틸리티를 사용하여이 문제를 해결합니다.

기존 답변은 64 비트 아치의 문제를 잘 다루지 만 업그레이드의 많은 장점을 보지 못했습니다. 그래서 최근에 내가 발견 한 두 가지가 있습니다.

• PHP가 Unix 타임 스탬프를 처리 할 때 32 비트 아치의 정수 크기는 날짜의 상한을 설정하여 2038 년의 특정 날짜를 초과 할 수 없습니다 . 타임 스탬프를 처리하는 모든 언어에서 이것이 문제라고 생각합니다. (PHP의 DateTime과 같이 유닉스 타임 스탬프를 사용하지 않는 대부분의 날짜 처리 서브 시스템은 특히 구형 CPU에서도이 문제에 의해 제한되지 않도록 설계되었습니다).

• Mongo는이 아치에서 크기가 2G 미만인 데이터베이스로 제한되며 곧 32 비트 빌드는 더 이상 사용되지 않습니다. 에서 수동 :

  MongoDB 3.2부터는 32 비트 바이너리가 더 이상 사용되지 않으며 향후 릴리스에서 사용할 수 없게됩니다.

  32 비트 빌드는 Linux 및 Windows 용으로 존재하지만 프로덕션 배포에는 적합하지 않습니다. 32 비트 빌드는 WiredTiger 스토리지 엔진도 지원하지 않습니다.

이것에 대한 내 생각 : ARM 프로세서가 메모리를 어떻게 처리하는지 정확히 알지 못하지만 공유 메모리 및 주소 지정을 사용할 때 내가 프로그래밍 한 이전의 여러 CPU 아키텍처 (SPARC / Alpha / i386 / AMD64 / X86_64)에서이를 알 수 있습니다 "실제"가상 주소 포인터에 의해 64 비트로의 이동은 사소한 것이 아닙니다. memcpy가 수행해야하는 작업을 수행하지만 64 비트에서 데이터가 다음과 같이 저장된다는 점을 고려해야합니다.

HGFEDCBA
HGFEDCBA
HGFEDCBA

그러나 32 비트에서는 다음과 같습니다.

ABCD
ABCD
ABCD

따라서 jpeg를 RAM에 저장하면 32 비트에서 바이트 단위로 바이트 단위로 이동하여 선형 방식으로 문제없이 헤더 바이트를 읽거나 에지 감지를 수행 할 수 있습니다. 그러나 64 비트 아키텍처에서는 다음이 변경됩니다.

32 비트 :

for (i=0; i< img_length/4; i++) 
{ 
    address=shm_start+i; 
    for (c=0; c< 4; c++) 
    { 
        byte=((*address >> c) & 15) 
    } 
}

64 비트 :

for (i=-; i< img_length/8; i++) 
{ 
    address=shm_start+i; 
    for (c=7; c>=0; c--) 
    { 
        byte=((*address >> c) & 15) 
    } 
}