Diferença entre o tamanho dos binários - x86_64 vs ARM

Question

Ao fazer uma comparação binária entre kernels Linux compilados para x86_64, a diferença de versão para versão é relativamente grande (muito mais que 25%). As diferenças de tamanho entre os arquivos de origem, de versão para versão, são menores (cerca de 8% ou menores).

A diferença no tamanho entre as imagens binárias do kernel para o ARM seria menor do que para x86_64? Eu li em algum lugar que a diferença binária entre executáveis ARM é menor do que para executáveis x86_64, uma vez que o código compilado é colocado em locais mais previsíveis, mas não me lembro onde o encontrei.

A diferença entre as versões de imagens binárias do kernel do ARM Linux é menor do que para x86_64?

    

Answer 1

Quanto ao código do kernel, além do código específico da arquitetura, que é uma parte muito pequena (1% a 5%?), todo o código-fonte do kernel é comum a todas as arquiteturas.

Sobre os binários:

Na verdade, na maioria das distribuições Linux, vmlinuz é um link simbólico que aponta para o código do kernel gzipado real; como vmlinuz-3.16.0-4-amd64 . Eu tenho certeza que o OP está falando sobre o último, no entanto mencionando o primeiro para o benefício do leitor.

link

Embora seja verdade que o código ARM é realmente menor, mesmo se os kernels não forem compactados, os códigos de kernel no ARM são geralmente customizados e têm muito menos código ativado do que nas versões de contrapartes da Intel (por exemplo, Intel um monte de placas de vídeo, mesmo que apenas os stubs de módulos, enquanto geralmente o kernel ARM personalizado só tem que lidar com o que está presente no SoC).

Além disso, comparar os blobs binários aleatórios já comprimidos talvez não produza sempre os resultados verdadeiros, pois, por alguma estranha coincidência, um binário maior pode se tornar menor devido a alguma otimização de compactação.

Portanto, na realidade, para comparar efetivamente os kernels binários, você deve compilá-los com opções idênticas e mantê-los descomprimidos (ou descompactar o arquivo vmlinuzxxx resultante).

Uma correspondência justa seria comparar outros binários não compactados, por exemplo, /bin/ls ou /usr/sbin/tcpdump e, além disso, uma arquitetura semelhante à que estamos tentando comparar (as máquinas ARM ainda são em grande parte de 32 bits. já existem alguns 64 bits)

Escusado será dizer que o mesmo código compilado no ARM será sempre (muito) menor porque o código de máquina ARM é um código de plataforma RISC. Também tem um subconjunto menor de instruções de código de máquina, que resulta em um código menor. Por outro lado, a Intel tem um conjunto maior de instruções, também devido à herança de retro-compatibilidade com várias gerações de microprocessadores.

De link

The concept of the RISC CPU is an old one, and it is also a very efficient one. In RISC CPUs you have smaller workloads being run by each instruction, these instructions are also very often split into I/O and Memory to further eliminate overhead. This makes for very efficient use of CPU and memory time, but can also require some bulky code on the software side to make everything work. When RISC first was developed, it was the way to go simply because memory and HDD access was slow. The bulky and complex instructions found in an x86 CPU were cumbersome on older CPUs and could not keep up with RISC systems.

No entanto, a conversa não é tão direta assim, já que os chips Intel são uma besta complexa hoje em dia, e no fundo da camada pseudo-CISC eles têm estratégias e projetos RISC que decodificam e emulam os opcodes da Intel como os conhecemos. p>

Os opcodes ARM também são volumosos, em comparação com o MIPS, já que o ARM é um processador barato com instruções especializadas dedicadas à decodificação de vídeo (cerca de 30% do processador é dedicado a eles).

Como um exercício curto, pegue o binário tcpdump e as quatro arquiteturas Linux que eu tenho acesso:

MIPS 32 bits - > 502,4K
ARM 32 bits - > 718K
Intel 32 bits (i386) - > 983K
Intel 64 bits (x86_64) - > 1,1 M

Voltando à sua pergunta original:

• Os kernels ARM "crescem" menos em tamanho porque a arquitetura tem menos diversidade no hardware base para uma distribuição específica.
• No entanto, e muito mais significativo, eles crescem menos em tamanho porque o código produzido é mais eficiente e compacto.

Answer 2

Os kernels "binários" ( vmlinuz ou mais) são um pequeno trecho de código que descomprime o resto do kernel comprimido. Eles têm muito em comum, pois uma grande parte do início do arquivo é a mesma (assim, ele é compactado para o mesmo).

Diferenças em tamanho dos arquivos de origem são bastante irrelevantes, a maioria das mudanças de uma versão para a próxima são linhas alteradas e novos drivers adicionados (e os drivers não aparecem no kernel binário, eles são usados apenas em algumas máquinas e, portanto, em módulos normalmente externos).