Existe uma melhoria da largura de banda de instalar um sistema operacional de 32 bits em uma máquina de 64 bits?

Question

recentemente opôs para sistemas de 64 bits, dizendo que, para programas que se encaixam em 4 GB de memória, "eles efetivamente jogar fora metade do cache" porque os ponteiros são duas vezes tão grande como em um sistema de 32 bits.

A minha pergunta é: esse problema pode ser evitado através da instalação de um sistema operacional de 32 bits em uma máquina de 64 bits? E existem benchmarks de largura de banda que demonstram a vantagem neste caso?

Answer 1

A resposta é: sim, pode, até certo ponto, embora a diferença de desempenho é improvável que seja grande

.

Qualquer referência para testar esta terá que fazer um monte de resolução ponteiro, que será difícil separar do barulho. Projetando uma referência que não vai otimizar distância é difícil. Este artigo sobre falhas benchmarks java foi publicado por alguém em resposta a outra questão, mas muitos dos princípios descritos na aplicará a esta.

Answer 2

A largura de banda não é realmente o termo correto aqui. O que Knuth estava realmente falando era densidade de dados, que se refere a pegada de cache. Imagine que você tem um cache de dados 16KB L1: Se você está armazenando puramente ponteiros, você pode armazenar 2 ^ 14/2 ^ 2 = 2 ^ 12 = 4096 ponteiros de 32 bits, mas apenas 2.048 ponteiros de 64 bits. Se o desempenho de sua aplicação depende de ser capaz de manter o controle de mais de 2K buffers diferentes, você pode ver um benefício de desempenho real a partir de um espaço de endereçamento de 32 bits. No entanto, o código mais real não é assim, e benefícios de desempenho real a partir de um sistema de cache muitas vezes vêm de ser capaz de armazenar em cache inteiro comum e estruturas de dados de ponto flutuante, não enormes quantidades de ponteiros. Se o seu conjunto de trabalho não é ponteiro-pesado, a desvantagem de 64-bit torna-se insignificante, ea cabeça se torna muito mais evidente se você está realizando uma série de 64-bit inteiro aritmética.

Answer 3

Eu não acho que Knuth opôs a sistemas de 64 bits. Ele apenas disse que o uso de ponteiros de 64 bits em um sistema que tem menos de 4 GB de RAM é idiota (pelo menos se você tiver lotes de ponteiros como os de uma lista duplamente ligada). Eu não posso dizer que concordo com ele, aqui estão 3 maneiras diferentes que podem ser tomadas. Vamos supor que você tem uma CPU capaz de 64 bits que também pode ser executado em modo de 32 bits como um Intel Core Duo.

1 - Tudo é de 32 bits, o sistema operacional, o appz, todos eles. Então você tem ponteiros de 32 bits, mas você não pode usar os registros extra / instruções que estão disponíveis no modo de 64 bits.

2 - Tudo é de 64 bits, o sistema operacional, o appz, todos eles. Então você tem ponteiros de 64 bits e você pode usar os registros extra / instruções que estão disponíveis no modo de 64 bits. Mas como você tem menos de 4 GB de RAM, usando ponteiros de 64 bits parece idiota. Mas, não é?

3 - OS é 64 bits e OS curiosamente garante que todos os ponteiros do código / dados estão no 0x00000000 - gama 0xFFFFFFFF (Memória Virtual !!!). A ABI é executado de uma forma muito estranho que todos os ponteiros código / dados mantidos na memória / arquivos são de 32 bits de largura, mas eles são carregados em registradores de 64 bits como estendido zero. Se houver um local de código para saltar, compilador / ABI faz os fix-ups necessárias e faz o salto de 64 bits real. Desta forma, os ponteiros são 32 bits, mas appz pode ser de 64 bits que significa que eles podem fazer uso dos registros de 64 bits e instruções. Este processo é algo como thunking, acho ;-P

A minha conclusão é ::

A terceira opção parecia factível para mim, mas não é um problema fácil. Em teoria, pode funcionar, mas eu não acho que isso é viável. E eu também acho que a sua citação "Quando tais valores ponteiro aparecer dentro de uma estrutura, não só perder a metade da memória, eles efetivamente jogar fora metade do cache." é exagerado ...

Answer 4

eu vi em algum lugar que o melhor mix (em x86 CPUs) é usar um sistema operacional de 64 bits e aplicações de 32 bits.

com um SO de 64 bits você tem:

• capacidade de lidar com mais de 4 GB de espaço de endereço
• mais, maiores registros para ajudar na dados de cópia de operações

com um aplicativo de 32 bits que você tem:

• ponteiros menores
• menos, registros menores para economizar em mudanças de contexto

contras:

• todas as bibliotecas devem ser duplicadas. minúscula para os padrões de espaço no HD.
• todas as bibliotecas carregadas são duplicados na RAM. não tão pequena ...

surpreendentemente, parece não haver nenhuma sobrecarga ao alternar os modos. Eu acho que a quebra de espaço do usuário para o kernel custa o mesmo, não importa o número de bits do espaço do usuário.

é claro, existem algumas aplicações que se beneficiam de espaço de endereço grande. mas para tudo o resto, você pode obter um desempenho extra de 5%, ficando no 32-bit.

e não, eu não se preocupam com este pequeno aumento de velocidade. mas isso não acontece "ofender" me para executar 32-bit FireFox em uma máquina KUbuntu 64 bits (como eu vi em alguns fóruns)