Ainda assim, os únicos ambientes onde as vantagens superariam as desvantagens seriam servidores de alto desempenho ou desktops de última geração (acima de 16GB de RAM). PAE está aí desde MUITO tempo atrás (então o limite de 4GB de RAM não se aplica ao Gentoo, onde geralmente compilamos nossos próprios kernels).
O fato é que ninguém conseguiu provar sem sombra de dúvida que um Gentoo 64 é mais rápido do que um 32. Claro, em operações de decriptação por exemplo, a palavra maior ajuda bastante, mas convenhamos, hoje tem otimização AES até no processador (intel core iX por exemplo).
O código da maioria ABSOLUTA dos aplicativos não foi atualizado para tirar vantagem dos 64 bits. Talvez corrigido para compilar em ambiente 64 bits, mas não otimizado. Então, no desktop no trabalho, onde uso ~x86 e o firewall não deixa usar rsync, nem sequer git, fico com 32 bits. Se eu tivesse um servidor com 16GB ou mais de RAM servindo qualquer serviço com decriptação, encriptação (provavelmente até no próprio disco rídigo) e rodando hardened, iria de 64 bits, sem dúvida (provavelmente não esbarraria em nenhum dos principais problemas, como flash, firefox, java, etc). Mas no desktop o overhead de ter tudo duplicado (bibliotecas 32 e 64) só compensa em Windows (hehehe, lá não temos opção).
2011/3/28 Zhu Sha Zang
<zhushazang@yahoo.com.br>
Comprei um amd64 desde 2004 e desde então uso gentoo/freebsd 64-bits. Sim, tivemos muitos problemas entre 2004 e 2006 com suporte a softwares 64bits como firefox, flash, openoffice. Por isso tanto no Gentoo quanto no FreeBSD existiam os binários sem necessidade de compilação.
Para ser sincero, faz tempo que não me utilizo de 32bits, o que seria um retrocesso tecnológico pois mesmo no campo de desenvolvimento ganha-se muito com as "palavras maiores".
Não vejo qualquer tipo de instabilidade tanto em máquinas com ACCEPT_KEYWORD="~amd64" quanto em máquinas sem.
Geralmente os problemas são de compilação, raramente de execução.
Performance? Com certeza máquinas 64bits não são mais lentas que máquinas 32bits.
Att
--
Daniel da Veiga