Was den Kernel-Code betrifft, so ist neben dem architekturspezifischen Code, der einen sehr kleinen Teil ausmacht (1 % bis 5 %?), der gesamte Kernel-Quellcode für alle Architekturen gleich.
Über die Binärdateien:
Tatsächlich in den meisten Linux-Distributionen vmlinuz ist ein symbolischer Link, der auf den eigentlichen Kernel-Code mit gzip zeigt; wie vmlinuz-3.16.0-4-amd64 . Ich bin sicher, dass das OP über letzteres spricht, erwähnt jedoch ersteres zum Nutzen des Lesers.
https://www.ibm.com/developerworks/community/blogs/mhhaque/entry/anatomy_of_the_initrd_and_vmlinuz
Es stimmt zwar, dass der ARM-Code tatsächlich kleiner ist, selbst wenn die Kernel nicht komprimiert wurden, aber die Kernel-Codes in ARM sind oft kundenspezifisch und haben weit weniger aktivierten Code als in den Intel-Pendant-Versionen (z. B. hat Intel viele Grafikkarten, auch wenn nur die Module Stubs sind, während sich der benutzerdefinierte ARM-Kernel normalerweise nur mit demjenigen befassen muss, der im SoC vorhanden ist).
Darüber hinaus liefert der Vergleich bereits komprimierter zufälliger binärer Blobs möglicherweise nicht immer die wahren Ergebnisse, da aufgrund eines seltsamen Zufalls eine größere Binärdatei aufgrund einer gewissen Komprimierungsoptimierung kleiner werden kann.
Um also die Binärkerne effektiv vergleichen zu können, müssen Sie sie mit identischen Optionen kompilieren und sie unkomprimiert halten (oder den resultierenden vmlinuzxxx dekomprimieren Datei).
Eine faire Übereinstimmung wäre der Vergleich anderer, nicht komprimierter Binärdateien, z. B. /bin/ls , oder /usr/sbin/tcpdump , und darüber hinaus eine ähnliche Architektur wie die, die wir zu erreichen versuchen (ARM-Maschinen sind immer noch größtenteils 32-Bit, es gibt jedoch bereits einige 64-Bit-Maschinen)
Unnötig zu sagen, dass derselbe Code, der in ARM kompiliert wird, immer (weit) kleiner sein wird, da der ARM-Maschinencode ein RISC-Plattformcode ist. Es hat auch eine kleinere Teilmenge von Maschinencode-Anweisungen, die zu einem kleineren Code führen. Andererseits hat der Intel einen größeren Befehlssatz, auch aufgrund der Retro-Kompatibilitätsvererbung mit mehreren Generationen von Mikroprozessoren.
Von http://www.decryptedtech.com/editorials/intel-vs-arm-risc-against-cisc-all-over-again
Das Konzept der RISC-CPU ist alt und zudem sehr effizient. In RISC-CPUs werden kleinere Workloads von jeder Anweisung ausgeführt. Diese Anweisungen werden auch sehr oft in E/A und Speicher aufgeteilt, um den Overhead weiter zu eliminieren. Dies sorgt für eine sehr effiziente Nutzung der CPU- und Speicherzeit, kann aber auch einiges an umfangreichem Code auf der Softwareseite erfordern, damit alles funktioniert. Als RISC zum ersten Mal entwickelt wurde, war dies der richtige Weg, einfach weil der Speicher- und Festplattenzugriff langsam war. Die umfangreichen und komplexen Anweisungen einer x86-CPU waren auf älteren CPUs umständlich und konnten mit RISC-Systemen nicht mithalten.
Trotzdem ist das Gespräch nicht so direkt genug, da Intel-Chips heutzutage ein komplexes Tier sind und tief in der Pseudo-CISC-Schicht RISC-Strategien und -Designs haben, die die Intel-Opcodes, wie wir sie kennen, dekodieren und emulieren.
Die ARM-Opcodes sind auch sperrig, verglichen mit beispielsweise einem MIPS, da der ARM ein billiger Prozessor mit spezialisierten Anweisungen für die Videodecodierung ist (ungefähr 30 % des Prozessorchips sind für sie reserviert).
Nehmen Sie als kurze Übung die tcpdump-Binärdatei und die vier Linux-Architekturen, auf die ich Zugriff habe:
MIPS 32 Bit -> 502,4 KB
ARM 32-Bit -> 718K
Intel 32 Bit (i386) -> 983 KB
Intel 64 Bit (x86_64) -> 1,1 MB
Um auf Ihre ursprüngliche Frage zurückzukommen:
- ARM-Kernel werden weniger groß, weil die Architektur weniger Unterschiede in der Basishardware für eine bestimmte Distribution aufweist.
- Allerdings, und das ist viel wichtiger, nehmen sie weniger an Größe zu, weil der erzeugte Code effizienter und kompakter ist.
Die "binären" Kernel (vmlinuz oder so) sind ein kurzer Codeabschnitt, der den Rest des eigentlichen komprimierten Kernels dekomprimiert. Sie haben so viel gemeinsam, dass ein großer Teil des Anfangs der Datei gleich ist (also auf das Gleiche komprimiert wird).
Unterschiede in der Größe der Quellarchive ist eher irrelevant, die meisten Änderungen von einer Version zur nächsten sind Zeilen geändert , und neue Treiber hinzugefügt (und Treiber tauchen nicht im binären Kernel auf, sie werden nur in einigen Maschinen verwendet und sind daher typischerweise externe Module).