Pergunta

Suponho que estou focando no x86, mas geralmente estou interessado na mudança de 32 para 64 bits.

Logicamente, posso ver que constantes e ponteiros, em alguns casos, serão maiores, então os programas provavelmente serão maiores.E o desejo de alocar memória nos limites das palavras para maior eficiência significaria mais espaço em branco entre as alocações.

Também ouvi dizer que o modo de 32 bits no x86 precisa liberar seu cache durante a troca de contexto devido a possíveis espaços de endereço 4G sobrepostos.

Então, quais são os reais benefícios de 64 bits?

E como pergunta complementar, 128 bits seria ainda melhor?

Editar:

Acabei de escrever meu primeiro programa de 32/64 bits.Ele cria listas/árvores vinculadas de objetos de 16 bytes (versão 32b) ou 32 bytes (versão 64b) e imprime bastante em stderr - não é um programa realmente útil e não é algo típico, mas é o meu primeiro.

Tamanho:81128(32b) v 83672(64b) - então não há muita diferença

Velocidade:17s(32b) v 24s(64b) - rodando em sistema operacional de 32 bits (OS-X 10.5.8)

Atualizar:

Observo que uma nova ABI (Application Binary Interface) híbrida x32 está sendo desenvolvida com 64b, mas usa ponteiros de 32b.Para alguns testes, resulta em código menor e execução mais rápida do que 32b ou 64b.

https://sites.google.com/site/x32abi/

Foi útil?

Solução

A menos que você precise acessar mais memória que o endereço 32B permitirá, os benefícios serão pequenos, se houver.

Ao executar na CPU 64B, você obtém a mesma interface de memória, não importa se estiver executando o código 32B ou 64B (você está usando o mesmo cache e o mesmo barramento).

Embora a arquitetura X64 tenha mais alguns registros que permitem otimizações mais fáceis, isso geralmente é neutralizado pelo fato de os ponteiros agora são maiores e o uso de qualquer estrutura com ponteiros resulta em um tráfego de memória mais alto. Eu estimaria o aumento do uso geral da memória para uma aplicação de 64b em comparação com um 32B em cerca de 15 a 30 %.

Outras dicas

Normalmente, vejo uma melhoria de velocidade de 30% para código intensivo em computação em x86-64 em comparação com x86. Isso provavelmente é devido ao fato de termos registros de propósito geral de 16 x 64 bits e registros SSE de 16 x em vez de registros de propósito geral de 8 x 32 bits e registros SSE 8 x. Isso é com o Intel ICC Compiler (11.1) em um Linux X86-64 - resulta com outros compiladores (por exemplo, GCC) ou com outros sistemas operacionais (por exemplo, Windows), pode ser diferente, é claro.

Independentemente dos benefícios, eu sugiro que você sempre compile seu programa para o tamanho de palavra padrão do sistema (32 bits ou 64 bits), pois se você compilar uma biblioteca como um binário de 32 bits e fornecê-la em um formato de 64 bits sistema, você forçará qualquer pessoa que queira se vincular à sua biblioteca a fornecer sua biblioteca (e quaisquer outras dependências da biblioteca) como um binário de 32 bits, quando a versão de 64 bits for o padrão disponível.Isso pode ser um grande incômodo para todos.Em caso de dúvida, forneça as duas versões da sua biblioteca.

Quanto aos benefícios práticos do 64 bits...o mais óbvio é que você obtém um espaço de endereço maior; portanto, se mapear um arquivo, você poderá endereçar mais dele de uma vez (e carregar arquivos maiores na memória).Outro benefício é que, supondo que o compilador faça um bom trabalho de otimização, muitas de suas operações aritméticas podem ser paralelizadas (por exemplo, colocar dois pares de números de 32 bits em dois registradores e realizar duas adições em uma operação de adição única), e grandes os cálculos numéricos serão executados mais rapidamente.Dito isso, toda a coisa de 64 bits versus 32 bits não o ajudará em nada com a complexidade assintótica; portanto, se você deseja otimizar seu código, provavelmente deveria observar os algoritmos em vez de fatores constantes como este.

EDITAR:
Por favor, desconsidere minha declaração sobre a adição paralelizada.Isso não é executado por uma instrução add comum...Eu estava confundindo isso com algumas das instruções vetorizadas/SSE.Um benefício mais preciso, além do maior espaço de endereço, é que há mais registros de uso geral, o que significa que mais variáveis ​​locais podem ser mantidas no arquivo de registro da CPU, que é muito mais rápido de acessar, do que se você colocar as variáveis ​​no arquivo de registro da CPU. pilha de programas (o que geralmente significa ir para o cache L1).

Além de ter mais registros, 64 bits tem SSE2 por padrão. Isso significa que você pode realmente executar alguns cálculos em paralelo. As extensões SSE também tinham outras guloseimas. Mas acho que o principal benefício é não ter que verificar a presença das extensões. Se for x64, ele tem SSE2 disponível. ... se minha memória me serve corretamente.

Somente a justificativa para mover seu aplicativo para 64 bits é a necessidade de mais memória em aplicativos, como bancos de dados grandes ou aplicativos de ERP com pelo menos 100s de usuários simultâneos, onde o limite de 2 GB será excedido rapidamente quando os aplicativos cache para melhor desempenho. Este é um caso especialmente no sistema operacional Windows, onde o número inteiro e o longo ainda tem 32 bits (eles têm nova variável _int64. Somente os ponteiros são de 64 bits. Na verdade OS. Minha experiência no Windows X64 é a versão de aplicativo de 32 bits, executa 10-15% mais rápido que 64 bits, pois, no caso anterior, pelo menos para bancos de dados de memória proprietários, você pode usar a aritmática do ponteiro para manter a árvore B (a maioria dos processadores intensivos dos sistemas de banco de dados) . Aplicações intensivas de compuação que requerem grandes decimais para maior precisão não proporcionada pelo dobro do sistema operacional de 32-64 bits. Esses aplicativos podem usar _int64 em nativamente em vez de emulação de software. É claro que grandes bancos de dados baseados em disco para a capacidade de usar a memória grande para os planos de consulta em cache e assim por diante.

Mais dados são transferidos entre a CPU e a RAM para cada busca de memória (64 bits em vez de 32), para que os programas de 64 bits possam ser mais rápidos, desde que sejam escritos para que eles aproveitem corretamente isso.

No caso específico de x68 a x68_64, o programa de 64 bits terá o mesmo tamanho, se não um pouco menor, use um pouco mais de memória e será mais rápido. Principalmente isso ocorre porque o x86_64 não tem apenas registros de 64 bits, ele também possui o dobro. O X86 não possui registros suficientes para tornar os idiomas compilados o mais eficientes que poderiam ser, portanto o código X86 gasta muitas instruções e a largura de banda de memória mudando os dados entre registros e memória. x86_64 tem muito menos disso, e assim ocupa um pouco menos de espaço e funciona mais rápido. O ponto flutuante e as instruções de vetor de lança de bits também são muito mais eficientes em x86_64.

Em geral, porém, o código de 64 bits não é necessariamente mais rápido e geralmente é maior, tanto para uso de código quanto de memória em tempo de execução.

Quaisquer aplicativos que exijam uso de CPU, como transcodificação, exibição de desempenho e renderização de mídia, seja em áudio ou visual, certamente exigirão (neste momento) e se beneficiarão do uso de 64 bits versus 32 bits devido à capacidade da CPU de lidar com o puro quantidade de dados sendo lançados nele. Não é tanto uma questão de espaço de endereço, mas é a maneira como os dados estão sendo tratados. Um processador de 64 bits, com código de 64 bits, terá um desempenho melhor, especialmente com coisas matematicamente difíceis, como transcodificação e dados de VoIP - de fato, qualquer tipo de aplicativos de 'matemática' deve se beneficiar pelo uso de CPUs e sistemas operacionais de 64 bits. Prove -me errado.

Estou codificando um motor de xadrez. A melhor extração de movimentos usando uma pesquisa de árvore baseada em minimax para a profundidade 9 (de uma determinada posição) levou ~ 17.0s na configuração do Win32 e, depois de alternar para X64, agora leva ~ 10,3s. Isso é 41% da aceleração!

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top