x86_64 컴파일된 Linux 커널의 바이너리 비교를 수행할 때 버전 간의 차이는 상대적으로 큽니다(25% 이상). 소스 아카이브의 다양한 버전 간의 크기 차이는 작습니다(약 8% 이하).
바이너리 커널 이미지 간의 크기 차이가 x86_64보다 ARM에서 더 작습니까? 컴파일된 코드가 더 예측 가능한 위치에 배치되기 때문에 ARM 실행 파일 간의 바이너리 차이가 x86_64 실행 파일보다 작다는 것을 어딘가에서 읽었지만 어디서 찾았는지 기억이 나지 않습니다.
바이너리 ARM Linux 커널 이미지 버전 간의 차이가 x86_64 버전 간의 차이보다 작습니까?
답변1
커널 코드의 경우, 아키텍처별 코드의 아주 작은 부분(1%~5%?)을 제외하고 모든 커널 소스 코드는 모든 아키텍처에 공통됩니다.
바이너리 관련:
실제로 대부분의 Linux 배포판 에서는 vmlinuz. vmlinuz-3.16.0-4-amd64나는 OP가 후자에 대해 이야기하고 있다고 확신하지만 독자의 이익을 위해 전자를 언급합니다.
https://www.ibm.com/developerworks/community/blogs/mhhaque/entry/anatomy_of_the_initrd_and_vmlinuz
ARM 코드가 더 작은 것은 사실이지만 커널이 압축되지 않은 경우에도 ARM의 커널 코드는 일반적으로 사용자 정의되어 있으며 Intel의 커널 코드보다 훨씬 덜 활성 코드입니다(예: Intel에는 모듈 스텁만 포함하여 많은 비디오 카드가 있지만 일반적으로 맞춤형 ARM 코어는 SoC에 존재하는 부분만 처리하면 됩니다.
또한 압축된 임의의 바이너리 블롭을 비교하면 항상 현실적인 결과를 얻을 수는 없습니다. 왜냐하면 이상한 우연의 일치로 일부 압축 최적화로 인해 더 큰 바이너리가 더 작아질 수 있기 때문입니다.
따라서 실제로 바이너리 커널을 효과적으로 비교하려면 동일한 옵션으로 커널을 컴파일하고 압축되지 않은 상태로 유지해야 합니다(또는 결과 vmlinuzxxx파일의 압축을 풀어야 함).
/bin/ls공정한 일치는 , 또는 와 같은 다른 비압축 바이너리를 /usr/sbin/tcpdump우리가 일치시키려는 아키텍처와 유사한 아키텍처와 비교하는 것입니다(ARM 시스템은 여전히 대부분 32비트이지만 이미 일부 64비트 시스템이 있습니다).
말할 필요도 없이 ARM 기계어 코드는 RISC 플랫폼 코드이기 때문에 ARM에서 컴파일된 동일한 코드는 항상 (훨씬) 더 작습니다. 또한 기계어 코드 명령어의 하위 집합이 더 적으므로 코드도 더 작아집니다. 반면에 Intel은 여러 세대의 마이크로프로세서와의 하위 호환성 상속으로 인해 더 큰 명령어 세트를 가지고 있습니다.
~에서http://www.decryptedtech.com/editorials/intel-vs-arm-risc-against-cisc-all-over-again
RISC CPU의 개념은 오래된 것이며 매우 효율적인 개념이기도 합니다. RISC CPU에서 각 명령은 더 작은 작업 부하를 실행하며 이러한 명령은 일반적으로 오버헤드를 추가로 제거하기 위해 I/O와 메모리로 분할됩니다. 이는 CPU와 메모리 시간을 매우 효율적으로 사용할 수 있지만 모든 것이 제대로 작동하려면 소프트웨어 측면에서 엄청난 양의 코드가 필요할 수도 있습니다. RISC가 처음 개발되었을 때는 메모리와 HDD 액세스 속도가 느렸기 때문에 이것이 가능한 접근 방식이었습니다. x86 CPU의 크고 복잡한 명령은 구형 CPU에서는 번거롭고 RISC 시스템을 따라잡을 수 없습니다.
그러나 Intel 칩은 이제 복잡한 짐승이고 의사 CISC 계층 내부 깊숙한 곳에 우리가 알고 있는 Intel opcode를 디코딩하고 에뮬레이트할 수 있는 RISC 전략과 설계가 있기 때문에 대화가 충분히 간단하지 않습니다.
ARM opcode는 MIPS에 비해 크기도 합니다. 왜냐하면 ARM은 비디오 디코딩 전용 명령어가 포함된 저렴한 프로세서이기 때문입니다(프로세서 칩의 약 30%가 이러한 명령어 전용임).
간단한 연습으로 tcpdump 바이너리와 내가 액세스할 수 있는 4가지 Linux 아키텍처를 사용합니다.
MIPS 32비트 -> 502.4K
ARM 32비트 -> 718K
Intel 32비트(i386) -> 983K
Intel 64비트(x86_64) -> 1.1M
그럼 원래 질문으로 돌아가서:
- ARM 코어는 특정 릴리스의 기본 하드웨어에서 아키텍처의 다양성이 적기 때문에 크기가 더 작아집니다.
- 그러나 더 중요한 것은 생성된 코드가 더 효율적이고 컴팩트하기 때문에 크기가 더 작아진다는 것입니다.
답변2
"바이너리" 커널( vmlinuz또는 유사)은 압축된 커널의 나머지 부분을 풀어주는 작은 코드 조각입니다. 파일 시작 부분의 상당 부분이 동일하기 때문에 공통점이 많습니다(따라서 동일하게 압축합니다).
차이점크기소스 아카이브의 내용은 상당히 중요하지 않습니다. 한 버전에서 다음 버전으로의 대부분의 변경 사항은 라인입니다.변경됨그리고 새 드라이버다음에 추가(드라이버는 바이너리 커널에 나타나지 않으며 일부 시스템에서만 사용되므로 일반적으로 외부 모듈입니다.)