Enviado por O Velho, seg, 30/11/2009 - 05:05
No tema:
32 ou 64 bits? O video ai em baixo, do Olhar Digital, vai ajudar você a entender e escolher o seu sistema operacional:
Fonte: Olhar Digital
- Faça login ou se registre para poder enviar comentários
Re: 32 ou 64?
Coisa semelhante ocorreu na passagem de 16 para 32 bits. Em termos de performance, seria melhor quebrar a compatibilidade. Nesse ponto, a necessidade de mercado fala mais alto.
Se fixarmos o número de ciclos por instrução, frequência e número de instruções, o ganho de performance com a mudança para 64 bits dependerá fortemente da aplicação. Há diversos casos em que o ganho será muito pequeno.
A média pode ser baixa, mas o desvio padrão é bastante elevado, isto é, mesmo o uso normal, digamos corriqueiro, apresenta picos intensos de uso da CPU.
Uma simples e intuitiva montagem com o vídeo daquela festinha de aniversário usa normalização de áudio, estabilização de vídeo e compressão, quase sem que o usuário perceba. Aquela animação em tempo-real com as fotos da festa também não é leve. A sequência de músicas que está a tocar enquanto o usuário edita seu texto pode ter sido montada por análise de afinidade melódica etc.
O usuário comum hoje não pega leve.
Não seria
sizeof(int)?Isso não acontece se for feita uma definição clara de tipos. Algo como:
// ANSI-C#define INT8 signed char#define INT16 signed short int#define INT32 signed long int#define INT64 signed long long int#define UINT8 unsigned char#define UINT16 unsigned short int#define UINT32 unsigned long int#define UINT64 unsigned long long int#define INT INT32 // <- aqui você fixa o particular de sua aplicação//#define INT int // <- ou não... =)Usa-se
intquando não se deseja fixar o tamanho via código, mas pelo contexto de compilação, ou seja, pela arquitetura (intserá a maior palavra sinalizada). Para o resto, basta deixar os inteiros fixos e as definições padronizadas.Se o código for bem escrito, ele não apresentará bugs apenas por ser recompilado. Entretanto, problemas podem surgir quanto à performance.
Lembra do endereçamento de 20 bits no x86 de 16 bits? Nunca mais!
Ou flat memory, ou nada. Se for preciso endereçar mais memória do que a maior palavra permite, a mudança de arquitetura está no todo da lista de prioridades.
Um paliativo. Imagine a festa que isso faz no pipeline do processador.
Re: 32 ou 64?
Como assim ? Se é para quebrar compatibilidade, faz um processador VLIW, como o Crusoe e Itanium. Não vejo perda de desempenho inerente por se extender o conjunto de instruções. A arquitetura x86 com suas mudanças (8 bits -> 16 bits -> 32 bits -> 64 bits) sempre conseguiu manter a curva da lei de Moore (que na verdade é sobre a densidade dos dispositivos, não velocidade).
Nada disto depende do fato de se trabalhar com 64 bits. Considerando tudo igual, a possibilidade de se operar o dobro da quantidade de dados no mesmo tempo é um ganho de 2x. Mas tens razão, só faz sentido se antes tu tinhas que ter duas instruções e pode ter agora só uma. Operar em um char continua levando o mesmo tempo.
Não, no LP64 o long passou a 64 bits e o int ficou em 32. sizeof(unsigned long int) em um Linux 64 com GCC dá 8. Já em um Linux 32 dá 4 e esta é exatamente a origem do bug.
No LLP64 e LP64 int tem 32 bits, mesmo em processadores de 64 bits.
Não é isto que eu estou dizendo, o registrador de segmento existe desde o 8086, o modo de endereçamento é indireto e pode endereçar mais que 32 bits. A arquitetura x86 pode ou não usar um modelo flat de memória, é só usar ou não o ES, DS.
Como assim ? O pipeline tem instruções e o que esvazia o pipeline é uma instrução de desvio. O cache também não é afetado, já que ele contém uma pequena amostra de uma região de memória e é problema do controlador de cache ter a região certa carregada. Novamente, como é que servidores Xeon tinham mais de 4GB de memória instalados ? É perfeitamente possível isto dentro da IA32.
Ok, mas diz isto pro pessoal da Macromedia que levou séculos para criar um flash 64 bits que funcionasse.
Re: 32 ou 64?
Pode haver perda de desempenho, pois uma extensão acrescenta complexidade desnecessária. Um conjunto de instruções o mais reduzido possível facilita o projeto de um pipeline otimizado. (O que não quer dizer que qualquer extensão seja um problema sério, caso contrário isso não seria tão comum, mas abandonar a necessidade de manter compatibilidade diminui as restrições que se impõem ao projeto.)
É por isso que, embora ambos atinjam valores abaixo de 1 hoje, processadores RISC alcançam geralmente uma menor taxa de ciclos por instrução do que os CISC. Um melhor uso do pipeline (menos stalls) tem um papel importante nisso.
Um dos maiores motivos de ainda usarmos uma CPU CISC em computadores pessoais hoje é a questão de compatibilidade (além do fato de que essa diferença arquitetônica não é tão grave a ponto de não poder ser contornada de outras formas).
Exatamente. Meu comentário foi no sentido de expor que nem sempre ocorrerá esse ganho. Primeiramente, o exemplo abaixo corrobora a existência desse ganho em um caso particular.
Considere o seguinte algoritmo ingênuo para verifica se os n primeiros naturais pares maiores do que 2 são a soma de dois primos.
Para cada número natural k, de 2 até n+1, tal que n é algum natural > 0, faça:. Achou := Não. Para cada primo p < 2k, faça:. . Para cada primo q < 2k, faça:. . . Se 2k = p + q, então. . . . Achou := Sim. . . . Interrompa este Para-faça. . . Fim Se. . Fim Para. . Se Achou, então Interrompa este Para-faça. Fim Para. Se não Achou, então. . Resultado: falha para o natural par 2k. . Fim do algoritmo. Fim SeFim ParaResultado: vale para todo natural par de 4 até 2nAgora, considere uma implementação imediata desse algoritmo ingênuo, com os seguintes detalhes:
- empregar uma cadeia de palavras (usando a maior palavra em cada contexto -- 32 e 64 bits, para os dois casos em comparação aqui) para representar um número natural qualquer;
- empregar uma lista dos primos até 2n (em que cada primo é representado por uma cadeia como no item anterior);
- somar dois números naturais nessa representação considerando cada palavra como sendo um dígito (em base 2ˆ32 ou 2ˆ64), fazendo uma soma usual dígito a dígito, passando o carry ao próximo dígito quando necessário etc.
Aqui, é fácil ver que as cadeias com palavras de 32 bits têm o dobro do tamanho daquelas com palavras de 64 bits. Como a soma de duas palavras máximas em ambos os casos ocupam, por hipótese, a mesma quantidade de ciclos, o fato de haver a metade do número de operações de soma para o caso de 64 bits implica o dobro de performance. O mesmo vale para a verificação de igualdade entre cadeias (pois a verificação também seria feita termo a termo).
Daí, segue que esse é um exemplo em que se tem praticamente o dobro de performance em 64 bits. (Curiosamente, esse exemplo também serve para mostrar que sempre há ganho real em aumentar indefinidamente essa largura.)
(Agora que escrevi tudo isso, lembrei de outro exemplo mais simples: buscar uma subcadeia em uma cadeia palavras -- comum em aplicações que envolvam sequenciamento genético.)
O ponto é que esse é um caso muito particular (escolhido a dedo, para servir de exemplo). De fato, há outros casos em que o ganho será muito pequeno.
Basta considerar aqueles que envolvam apenas operações com ponto flutuante de precisão simples (ou seja, não mais do que essa precisão), como vários tipos de redes neutrais, por exemplo. Mesmo que uma maior precisão seja usada, esse fato não tem o mesmo potencial de afetar a performance, como no exemplo anterior. (Isso pode acontecer, mas frequentemente a cognição/convergência já é aceitável para uma certa exatidão dentro da precisão simples.)
Um segundo exemplo, em meio a tantos outros de cunho bastante prático, é a execução do algoritmo A* (A star). Uma implementação desse algoritmo não se beneficiaria similarmente da mudança de 32 para 64 bits (exceto pela óbvia restrição de endereçamento, que não é a questão aqui), a depender da heurística empregada. (Um exemplo seria encontrar uma solução ótima para o cubo mágico desse modo.)
Enfim, nem sempre a performance será o dobro em 64 bits. De fato, frequentemente, ela não será muito superior apenas por causa disso.
Então, é bem provável que o respeito ao padrão seja apenas em termos de sintaxe nesse caso. De qualquer forma, é certo que os tipos definidos em
inttypes.h/stdint.h(também do padrão C99) não vão variar:int8_t,int16_t,int32_t,int64_t,uintptr_tetc.Há de se usar um padrão, senão perde-se parte da razão de ser da linguagem.
Vai depender de quão padronizado (evitando essas armadilhas) e independente (decisões de terceiros, ter de lidar com várias APIs diferentes e com suas mudanças particulares ao passar para 64 bits etc.) é o código original em 32 bits do Flash.
Re: 32 ou 64?
O Olhar Digital é um bom programa, mas de fato a limitação de tempo da televisão pra analisar coisas mais profundas como a diferença entre 32 e 64 bits complica bastante.
Não acho que a maioria (nem 10%!) dos programas tenham versões em 64 bits, você vai acabar rodando programas 32 bits que segundos testes (acho que vi no Gizmodo, não me recordo), acabam ficando mais lentos quando rodam em SO 64 bits, do que programa 32 em SO 32. A vantagem fica mesmo pra aplicações/jogos que puxam muito processamento e estão disponíveis em 64 bits.
Abraços!
Re: 32 ou 64?
Bom, dá para ver que a desinformação ainda é grande em relação à arquitetura.
Bom, então vamos ao início. No geral, é incorreto falar em "arquitetura" de 64 bits. Arquitetura de 64 bits tem o Itanium (IA64), os processadores x86 não tem um arquitetura de 64 bits, mas um conjunto de instruções que são capazes de operar com 64 bits de dados. Curiosamente, quem bolou isto foi a AMD. Claro, o processador precisa ter uma série de estruturas capazes de trabalhar com 64 bits, mas não é um arquitetura formal.
Assim, softwares "preparados" para 64 bits são softwares que fazem uso destas instruções e não há camada de abstração/adaptação/etc para "compatibilizar" nada, softwares compilados para 32 bits simplesmente não usam as instruções especiais. Notem que um software que faça uso destas instruções x64 não consegue ser executado em um processador que não suporte as instruções novas, obviamente.
Mas como usar os 64 bits ? Bom, para garantir a compatibilidade, deve-se ter tudo em 64 bits, processador, sistema operacional e aplicativos. Ok, um processador 32 bits não roda um SO de 64 bits, mas vocês pegaram a idéia. A princípio o 64 bits seria duas vezes mais rápido que os de 32 bits. Quem teve um 286 e depois trocou para um 386 deve lembrar da diferença. Só que hoje em dia, se nós olharmos o uso de CPU, para as tarefas cotidianas ela não passa de 5, 8% de uso, então com 64 bits cairia para 3, 2%, ou seja, nem dá para notar. A diferença fica evidente em aplicações que usem a CPU mesmo, como codificação de vídeo e jogos.
Notem que existem uma série de problemas relacionados a mudar de arquitetura e profissionalmente eu vou continuar a usar 32 bits por um bom tempo. Já tive problemas pelo sizeof(long) ter mudado de 4 para 8 e dado um bug muito chato de encontrar... Os softwares de 32 bits são os de sempre, vão funcionar. Já as versões de 64 bits podem não estar tão maduras e em alguns casos não é simplesmente compilar de novo.
Outra coisa que não é verdade é o limite de memória. A arquitetura x86 tem os registradores EBX, EDI, etc. Fazendo programas com vários segmentos, é possível, em teoria, fazer programas com até 2^64 endereços, ou acessar 2^64 bytes de memória. Isto acontece porque é possível usar um registrador para "janelas" de 32 bits de tamanho de endereçamento e dentro desta janela, endereçar outro espaço com 32 bits, ou seja, 64 bits no total. Na prática o processador só aceita até 48 linhas de endereço. Tá, mas e o limite de 4GB do Windows XP ? Bom, é isto mesmo, é um limite imposto pela Microsoft para evitar que o XP fosse usado em servidores e é o limite de muitos chipsets para desktops, mas não é o limite máximo que um processador pode endereçar. Se não, como é que teria Xeon em servidores com 8, 16, 32 GB de memória ? O Xeon é um IA32 como o Pentium, P II, P III, P 4, Core2, i7.
Re: 32 ou 64?
tk421, existe uma instrução chamada PAE (Physical Adress Extension) que permite que se aloque até 36 bits de memória (ou seja, quase 70 GB!) em CPUs oficialmente de 32 bits. Essa instrução (que funciona como 'janelas', igual você disse) existe já há bastante tempo e pode ser ativada nos Windows arquitetura NT (2000, XP, Vista, Seven) facilmente. Certamente por isso era possível ter servidores com tanta memória RAM mesmo antes de existirem CPUs 64 bits.
Re: 32 ou 64?
Bom saber, agora eu me preparo, ja que ano que vem tem computador novo.
Re: 32 ou 64?
Esses vídeos for dummies são fogo... Além de superficiais, ainda cometem erro. Não existe essa de programas 'preparados para 64 bits'. Tanto os Windows 64 bits quanto os processadores 64 bits possuem uma camada de compatibilidade para funciorarem no 'modo' 32 bits, portanto, um programa 32 bits nem sabe que está rodando num sistema de 64 bits; é tudo transparente. O único porém fica a cargo dos drivers, esses sim precisam ser 64 bits. Além disso, o vídeo dá a entender que tendo um sistema todo em 64 bits fará com que ele seja duas vezes mais rápido que um sistema de 32 bits, o que simplesmente não é verdade. E por fim, já há algum tempo não se vende mais processadores unicamente de 32 bits.
Re: 32 ou 64?
Concordo plenamente, fora que ate hoje o suporte 64bits e bem fraco, muitos poucos são 64bits o motivo esta ai os processadores 64bits suportam 32bits, a única grande vantagem e usar mais de 4GB de memória. Ele é melhor também com relação a vídeo e imagem mas agora que a apple esta começando a lançar por exemplo o photoshop em 64bits, vídeos já aproveitam da capacidade geral dependendo do player, no caso e necessário que o software seja 64bits para acessar o maior número de endereços.
Uma pena jogos ainda não usarem 64bits pois assim os cálculos poderia chegar a números inteiros de 64bits como teriam mais acessos a memória.
Re: 32 ou 64?
concordo com você, só duas observações: