Eu quase poderia acreditar que você se beneficiaria mais de um kernel de 64 bits e de um espaço de usuário de 32 bits do que perderia tempo discutindo isso. O que pode, claro, algumas vezes ser verdade (eu faço isso para um servidor redis).
Mas se você quiser começar a mixar binários de 64 e 32 bits, como você mencionou em um comentário, você está realmente procurando por problemas. Isso significaria que muitas bibliotecas seriam mapeadas duas vezes na memória, o que seria bastante ineficiente. Nenhuma distribuição oferece isso (mesmo o projeto Debian multiarch
não cobre binários).
Você se refere a binários como "cat", "dd", "bash", até mesmo "gcc" como não precisando de 64 bits, mas esses são exemplos típicos de programas em que usar ponteiros de 32 bits em vez de 64 bits não salve "nada". Você já perdeu mais tempo digitando cat
em sua mensagem do que poderia salvar executando uma versão de 32 bits em vez de 64 bits.
Sem mencionar que x86_64
não tem apenas ponteiros maiores, também tem o dobro de registros genéricos e os compiladores podem fazer tantas suposições sobre as extensões disponíveis quanto com i686
(que é mais que i586
, por sua vez, mais de i486
, por sua vez, mais de i386
). O desempenho pode acabar sendo melhor.
Se você quiser usar binários de 64 bits e 32 bits, minha recomendação pessoal seria executar os (provavelmente poucos) aplicativos intensivos de ponteiro que precisem de menos de 4 GB RAM e para o qual você realmente se importa com o desempenho em um chroot
(ou qualquer outro contêiner) de 32 bits. A menos que eles estejam executando em uma pilha Java, nesse caso, você provavelmente ficará melhor em um espaço de usuário de 64 bits e usar uma JVM híbrida (com ponteiros compactados).
Se você realmente deseja um kernel de 64 bits e um espaço de usuário de 32 bits, e não apenas porque leu em algum lugar que ele teria um desempenho melhor, você sempre pode obter o kernel dos pacotes de 64 bits de sua distribuição. e aperte-o em uma instalação de 32 bits.