Linux @ 64bits

[muddymind]

Uns pequenos reparos a isso tudo... Hoje em dia mts binários já são compilados usando SSE (basta ver as versões do blender optimizadas para as várias arquitecturas, por exemplo) e isso não tem a haver com o ser ou não AMD64... Aliás, SSE já existe desde os velhinhos PIII e só não é default em todos os pacotes binários por motivos de compatibilidade com hardware antigo. Isso afecta sobretudo as distros mais mainstream onde o out-of-the-box é essencial.

Agora relativamente à performance FP isso já é bastante discutível... Diz-me lá uma aplicação usada por massas que dependa pesadamente em operações FP de dupla precisão? É que essa é a única vantagem de usar registos de 64-bits porque de resto as operações são efectuadas da mesma forma e diga-se de passagem que 99% dos programas usados por praticamente todos não passam de FP32 onde as coisas ficam precisamente na mesma.

No que diz respeito ao PAE a coisa já é mais crítica pois existe efectivamente uma penalização de performance não linear que agrava quando se começa a endereçar a partir dos 3GB para cima e mesmo assim é preciso que tanto o processador como a board suportem esta extensão de endereçamento (que é feito em 36-bit).

Para finalizar gostava de adicionar aqui uma informação que ouvi hoje uns colegas de univ dizerem que não corresponde à realidade. Existe o mito de que as versões x86-64 são mais desprovidas de tralha legacy mas isso não podia estar mais longe da realidade. De facto as versões x86-64 são as mais prejudicadas pelo lixo antigo pois tem de lidar com formas de endereço misto através de uma tabela de conversão de endereços para dispositivos que não conseguem mapear endereços 64-bit. Isto podia ficar tudo muito bonito mas acontece que isso nem sempre funciona a 100% e pode provocar acessos indevidos à memória o que invalida a utilização em mts casos de hardware que se baseia nos antigos protocolos série e paralelo.

[]

 

[Bad_Cop]

O facto de teres de andar com chroots, ou com libs32, ou com nspluginwrapper e de nenhuma dessas soluções ser tão boa como usar a versão 32bits.

é por isto que ainda uso 32 bits. tenho 4gb de ram e um t8300 mas uso na mesma os 32bits porque é mais simples e, no que eu uso, só tinha a perder em optar por 64bits.

daqui para a frente logo se vê, mas para já os 32bits são o melhor para mim.

 

[bsd]

Uns pequenos reparos a isso tudo... Hoje em dia mts binários já são compilados usando SSE (basta ver as versões do blender optimizadas para as várias arquitecturas, por exemplo) e isso não tem a haver com o ser ou não AMD64... Aliás, SSE já existe desde os velhinhos PIII e só não é default em todos os pacotes binários por motivos de compatibilidade com hardware antigo. Isso afecta sobretudo as distros mais mainstream onde o out-of-the-box é essencial.

Claro, estamos completamente de acordo. Isso não afecta o pessoal do Gentoo Linux ou das outras distros inspiradas no FreeBSD que compilam tudo de source. Afecta é o pessoal das distros onde se saca packages pré-compilados. É o problema do default.

Agora, os utilizadores do blender são muito menos do que os utilizadores de visualizadores de PDF, não serão? Os utilizadores do blender sabem que o devem compilar com SSE, provavelmente. Os utilizadores de visualizadores ou criadores de PDF não sabem...

De qualquer modo, o uso de SSE não afecta os benchmarks que eu mostrei (apenas afectariam o Whetstone), quase tudo é desempenho em inteiro e em funções de SO.

Agora relativamente à performance FP isso já é bastante discutível... Diz-me lá uma aplicação usada por massas que dependa pesadamente em operações FP de dupla precisão? É que essa é a única vantagem de usar registos de 64-bits porque de resto as operações são efectuadas da mesma forma e diga-se de passagem que 99% dos programas usados por praticamente todos não passam de FP32 onde as coisas ficam precisamente na mesma.

Vejamos, há aqui alguma confusão. O tamanho dos registos de vírgula flutuante é igual em 32 ou 64 bits, isso não mudou, há os normais de 80 bits e há os XMM de 128 bits. Foi o tamanho e, mais importante, o número dos registos *inteiros* que foi alterado. O número de registos inteiros passou para o dobro (de 8, eax, ebx, ecx, edx, esi, edi, ebp e esp, para 16, + os r8-r15).

Quanto à performance em vírgula flutuante, qualquer programa vectorial (PDF, por exemplo?) usa pesadamente operações de VF. Se não for compilado em SSE, esse programa está obrigatoriamente a usar operações de VF de 80 bits, que são as únicas que existem fora do SSE.

Em relação ao PAE, não estou a ver qual é a "penalização de performance não linear" de que falas. Será alguma coisa específica do kernel do Linux de que eu não esteja a par?
Quanto às boards suportarem PAE, é lógico, mas se suportarem mais de 4GB de memória também vão suportar PAE.

Os teus comentários relativos a dispositivos que não podem ser mapeados acima dos 4GB ou que não conseguem eles endereçar acima disso por DMA, são pertinentes. Infelizmente, não são os dispositivos série ou paralelos que são afectados, não se usa DMA aí nem memory-mapped IO.

Agora, quanto a isto sou neutro: pode-se opinar o que se quiser, mas eu não inventei o resultado daqueles benchmarks, também não o posso contornar. E olha que aquele benchmark é muito abrangente, demora mais de meia hora, testa a velocidade de compilação do compilador de C, montes de coisas típicas de UNIX.

 

[CR_]

O facto de teres de andar com chroots, ou com libs32, ou com nspluginwrapper e de nenhuma dessas soluções ser tão boa como usar a versão 32bits.

Para o utilizador comum isso não é problema: no caso do flash até instalas normalmente tal como o fazes em 32bit (pelo sistema de pacotes) tal com os codecs. Não tive mais nenhuma dor de cabeça por ser EMT64 a não ser o flash não ser tão estável obviamente.

 

[esquiso]

Para o utilizador comum isso não é problema: no caso do flash até instalas normalmente tal como o fazes em 32bit (pelo sistema de pacotes) tal com os codecs. Não tive mais nenhuma dor de cabeça por ser EMT64 a não ser o flash não ser tão estável obviamente.

Eu não disse que o problema era sempre o mesmo. Enquanto que uma solução prima por ser fácil e rápida - a do nspluginwraper -, pecando por ser instável, outras - como o recurso a chroot - têm o efeito contrário. Mas isso pensei que era óbvio

 

[CR_]

Nunca tive de usar o chroot ou libs32 manualmente. Se usei foi tudo feito pelo package-manager. Portanto o que eu quero contradizer é que a afirmação que não se deve usar amd64 porque trás "dores de cabeça".

 

[petersaints]

Nunca tive de usar o chroot ou libs32 manualmente. Se usei foi tudo feito pelo package-manager. Portanto o que eu quero contradizer é que a afirmação que não se deve usar amd64 porque trás "dores de cabeça".

A única dor de cabeça em Ubuntu 64-bit, em outras distros user-friendly é exactamente a mesma coisa, é o Flash, que apesar de funcionar crasha muito mais, e o Java dentro do Browser, que apesar de se usar o IcedTea não é compativel com muitos sites (felizmente raramente uso sites com Java mas o Flash é realmente um grande problema para mim).

 

[APLinhares]

Mais uma vez, existem distribuições que não necessitam de chroot's, e usam apenas as lib32, sem problemas, como no caso do .rpm, que permite usar aplicativos 32 ou 64bits sem problemas. Por exemplo, usar o firefox na sua versão de 32bits, e flash.
Infelizmente .deb não suporta desta forma tão clara, usando apenas as lib32

 

[petersaints]

Mais uma vez, existem distribuições que não necessitam de chroot's, e usam apenas as lib32, sem problemas, como no caso do .rpm, que permite usar aplicativos 32 ou 64bits sem problemas. Por exemplo, usar o firefox na sua versão de 32bits, e flash.
Infelizmente .deb não suporta desta forma tão clara, usando apenas as lib32

Por RPM queres dizer Fedora e openSUSE, por exemplo?

 

[Fork]

Melhores Distros 64 bits

Boas pessoal,

Quais as melhores distros 64 bits?

Eu queria uma com KDE e que desse pouco trabalho a configurar.

Assim estou a pensar em Fedora 10, Kubuntu 8.10 e Linux Mint 6 64 bit edition.

Alguém me pode aconselhar sobre quais destas (ou outras) deva escolher.

Obrigado.

 

[petersaints]

Boas pessoal,

Quais as melhores distros 64 bits?

Eu queria uma com KDE e que desse pouco trabalho a configurar.

Assim estou a pensar em Fedora 10, Kubuntu 8.10 e Linux Mint 6 64 bit edition.

Alguém me pode aconselhar sobre quais destas (ou outras) deva escolher.

Obrigado.

Penso que para KDE, independentemente de ser 32 ou 64-bit, apostaria em openSUSE

 

[APLinhares]

KDE + 64bits, openSuSE é das melhores apostas, na minha opinião.
Ve tb Fedora que está a apostar no KDE4.

 

[Fork]

Obrigado pelas dicas, vou experimentar essas duas assim que o desktop novo chegue.

Aliás vou experimentar 3. O chakra (criei um tópico, está mais abaixo), o fedora e o OpenSuse. Das 3 fico com a que gostar mais.

 

[Nomearod]

Fedora 10 está excelente. Não tive um único problema usando a versão 64 bits com o KDE 4. Aliás, diria que KDE 4 consegue estar melhor no Fedora do que no Open Suse.

 

[Abd67]

Por mim estou bastante satisfeito com o ubuntu 64 bits. Realemente, como escrito mais acima, o problema é mesmo com o flash e java. Mas fora isso estou satisfeito e noto melhoria de performance da versão 32 para 64.

 

[petersaints]

Mais uma vez, existem distribuições que não necessitam de chroot's, e usam apenas as lib32, sem problemas, como no caso do .rpm, que permite usar aplicativos 32 ou 64bits sem problemas. Por exemplo, usar o firefox na sua versão de 32bits, e flash.
Infelizmente .deb não suporta desta forma tão clara, usando apenas as lib32

Vim desenterrar isto um pouco... mas andava aqui a ver tópicos e vi este post do AndreAPL e surgiu-me uma dúvida que gostaria de ver respondida por ele ou quem saiba.

Claramente distribuição que usem .deb e APT, este último (o APT) não suportam arquitecturas múltiplas. Ou seja apesar de porder forçar o dpkg a instalar um pacote 32-bit em 64-bit não há resolução de depêndecias... ou seja que das duas uma:

1. As libs de 32-bit (no caso do Ubuntu ia32-libs e outras lib32*) default disponíveis na distribuição chegam para correr o programa após o install forçado.
2. As libs de 32-bit não chegam e obrigam-me a andar a sacar pacotes de 32-bit e a colocar em /usr/lib32 o seu conteúdo, isto se eu souber exactamente o que falta, se não estou agarrado, e ao fim de um tempo de uso tenho montes de libs de 32-bit que entretanto posso até já não precisar e que só andando com muito cuidado a remover manualmente.
(Nota: Também posso usar o getlib com o mesmo efeito que faz a detecção das libs necessárias e sua colocação no sítio correcto mas não é 100% fiável e não tem a opção de desinstalar as libs também).

Com isto tudo quero perguntar se quando o AndreAPL diz "usam apenas as lib32, sem problemas, como no caso do .rpm, que permite usar aplicativos 32 ou 64bits sem problemas. Por exemplo, usar o firefox na sua versão de 32bits, e flash.
Infelizmente .deb não suporta desta forma tão clara, usando apenas as lib32 " quer dizer que posso escolher instalar pacotes de uma arquitectura ou de outra com resolução de dependências? Posso usar de forma transparente ambas as arquitecturas se necessário? É que se há coisa que adoro em Windows é a implementação de 64-bit ser praticamente transparente!!

 

[APLinhares]

Duma maneira rápida, .rpm permite ter um programa em 32 num sistema 64bits, não misturando os ficheiros, usando um sistema de forma transparente (e com respectivas dependências).
O exemplo mais notório era mesmo o firefox, onde usando sistema 64bits usava firefox + plugins a 32bits sem sobrepor nada.
Claro que tb é possivel, para nao descarregar todos os pacotes de 32bits, para usar bibliotecas de compatibilidade
exemplo

Claro que isto exige manutenção de pacotes, daí a comunidade debian nunca ter suscitado interesse em soluções do genero, dispondo apenas as libs de 32bits genéricas (ou entao o chroot em casos extremos), e não criando como aqui, pacotes "transitórios".

Mas actualmente os 64bits estão a virar um standard, e as soluções já existem em larga escala, sendo cada vez menos necessária/notória esta separação.

 

[nuno_nunes]

Pois o meu dá para por o sistema em 64 Bits e eu estou a optar pelo 32 Bits...

Pois tambem não tenho 4 Gb de RAM...

 

[petersaints]

Duma maneira rápida, .rpm permite ter um programa em 32 num sistema 64bits, não misturando os ficheiros, usando um sistema de forma transparente (e com respectivas dependências).
O exemplo mais notório era mesmo o firefox, onde usando sistema 64bits usava firefox + plugins a 32bits sem sobrepor nada.
Claro que tb é possivel, para nao descarregar todos os pacotes de 32bits, para usar bibliotecas de compatibilidade
exemplo

Claro que isto exige manutenção de pacotes, daí a comunidade debian nunca ter suscitado interesse em soluções do genero, dispondo apenas as libs de 32bits genéricas (ou entao o chroot em casos extremos), e não criando como aqui, pacotes "transitórios".

Mas actualmente os 64bits estão a virar um standard, e as soluções já existem em larga escala, sendo cada vez menos necessária/notória esta separação.

É interessante... já tinha estado ontem a testar em VM no Fedora. É pá claro que cada vez menos se necessita de sistemas hibridos mas dá sempre jeito. Agora tenho que testar Fedora 10 vs openSUSE 11.1! Não sei porquê gosto mais de Fedora... parece-me mais minimalista.

 

[APLinhares]

Fedora é uma distro mais cuidada, organizada e tem um artwork fabuloso. E felizmente tb já começaram a apostar em KDE 4. Se tivessem apostado tão intensivamente bem antes ... era a distro que usaria