バイナリファイルサイズの違い - x86_64とARM

Question 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コアは、特定のリリースの基本ハードウェアでアーキテクチャの多様性が少ないため、サイズが小さくなります。
しかし、もっと重要なのは、生成されたコードがより効率的でコンパクトであるため、サイズが小さくなることです。

Answer