Existe uma boa razão para executar software de 32 bits em vez de 64 bits em máquinas de 64 bits?

Benefícios do software de 32 bits em ambientes de 64 bits

• Menor consumo de memória, especialmente em aplicações pesadas com ponteiros, 64 bits versus 32 bits pode facilmente dobrar os requisitos de memória.
• Os arquivos de objetos também são menores.
• Compatibilidade com ambientes de 32 bits.
• Os vazamentos de memória têm limite máximo de 2 GB, 3 GB ou 4 GB e não sobrecarregam todo o sistema.

Desvantagens do software de 32 bits em ambientes de 64 bits

• Limite de memória de 2 GB, 3 GB ou 4 GB por processo. (Apenas por processo, em suma, vários processos de 32 bits podem usar a memória do sistema totalmente disponível).
• Não usar registros adicionais e extensões de conjunto de instruções, dependendo do x64. Isso é altamente compilador e específico da CPU.
• Pode exigir versões de 32 bits de todas (na maioria das distribuições do Linux) ou de bibliotecas e ambientes de tempo de execução incomuns (na maioria das versões do Windows). Se uma versão de 32 bits de uma biblioteca compartilhada for carregada exclusivamente para o seu aplicativo, e isso conta para o seu espaço ocupado. Nenhuma diferença se você estiver ligando estaticamente.

Outros aspectos

• Os drivers geralmente não são um problema. Apenas as bibliotecas de espaço do usuário devem diferir entre 32 bits e 64 bits, não a API dos módulos do kernel.
• Cuidado com diferentes larguras padrão para tipos de dados inteiros, testes adicionais são necessários.
• A arquitetura de CPU de 64 bits pode nem mesmo suportar 32 bits.
• Certas técnicas como ASLR e outras, dependendo de um espaço de endereçamento muito maior do que a memória física, não funcionam bem (ou a todos) em um modo de execução de 32 bits.

A menos que compare uma arquitetura de CPU, um sistema operacional e uma biblioteca de bibliotecas muito específica, não poderei entrar em mais detalhes.

A diferença entre o software de 32 bits e o software de 64 bits é o tamanho dos ponteiros e talvez o tamanho do número inteiro seja registrado. É isso.

Isso significa que todos os ponteiros no seu programa têm o dobro do tamanho. E (pelo menos em uma arquitetura ILP32 / LP64), seu long s tem o dobro do tamanho também. Isso normalmente resulta em um aumento de cerca de 30% no tamanho do código de objeto. Isso significa que…

• seu código objeto demorará ~ 30% a mais para ser carregado do disco na RAM
• seu código objeto ocupará ~ 30% a mais de espaço na memória
• você reduziu efetivamente sua largura de banda de memória (para código objeto) em ~ 20%
• você reduziu efetivamente o tamanho do cache de instruções em ~ 20%

Isso tem um efeito negativo não desprezível no desempenho.

Fazer isso só faz sentido se você puder "recomprar" esses custos de desempenho de alguma forma. Basicamente, existem duas maneiras de fazer isso: você faz um monte de matemática de 64 bits, ou você precisa de mais de 4 GiByte de memória mapeada. Se um ou ambos forem verdadeiros, faz sentido usar software de 64 bits, caso contrário não.

Observação: existem algumas arquiteturas nas quais não há variantes correspondentes de 32 ou 64 bits. Nesse caso, a questão obviamente não faz sentido. Os mais conhecidos são o IA64, que é de apenas 64 bits e não possui variante de 32 bits, e x86 / AMD64 que são, embora intimamente relacionados, arquiteturas diferentes , sendo o x86 de 32 bits, 64 apenas bit.

Na verdade, essa última afirmação não é mais 100% verdadeira. Recentemente, o Linux adicionou o x32 ABI, que permite que você execute código AMD64 com ponteiros de 32 bits, portanto, mesmo que não seja uma arquitetura de CPU "adequada", é uma maneira de usar a arquitetura AMD64 de forma que Variante de 32 bits. Isso foi feito precisamente porque a sobrecarga de desempenho que mencionei acima estava causando real problemas quantificáveis mensuráveis para usuários do mundo real que executam código do mundo real em sistemas do mundo real.

Se o software precisar interagir diretamente com sistemas legados, drivers ou bibliotecas, talvez seja necessário fornecer uma versão de 32 bits, já que o sistema operacional AFAIK em geral (definitivamente Windows e Linux AFAIK) não permite a mistura de 64 bit e código de 32 bits em um processo.

Por exemplo, se seu software precisar acessar hardware especializado, não é incomum que os clientes operem modelos mais antigos para os quais somente drivers de 32 bits estão disponíveis.

Se o seu software for uma DLL, você DEVE fornecer versões de 32 e 64 bits. Você não tem idéia se o cliente usará software de 32 bits ou 64 bits para falar com a DLL, e a DLL precisará usar o mesmo comprimento de bits do aplicativo. Isso não é negociável.

Se o seu software é um executável autônomo, é menos claro. Se você não precisa que seu software seja executado em sistemas operacionais mais antigos, talvez não seja necessário fornecer uma versão de 32 bits. Basta ficar com 64 bits, especificar que é necessário um sistema operacional de 64 bits e fazer o trabalho.

No entanto, se você precisar que seu software seja executado em sistemas operacionais mais antigos, poderá ativamente NÃO fornecer uma versão de 64 bits. Se você tem duas versões, então você tem o dobro do teste, e testar o software adequadamente em uma variedade de versões e idiomas do sistema operacional não é um processo rápido. Como o software de 32 bits é executado perfeitamente em uma plataforma de 64 bits, ainda é bastante comum que o software seja lançado apenas como 32 bits, especialmente por desenvolvedores menores.

Observe também que a maioria dos celulares é de 32 bits. Talvez alguns high-end sejam de 64 bits agora, mas há pouca razão para dar esse passo. Por isso, se estiver a desenvolver uma plataforma cruzada e pretender que o seu código seja executado também no Android, manter os 32 bits é uma opção segura.