Linux @ 64bits

[||Red_Evil||]

uso 64bts, devido a ter 4gb ram, até agora não notei assim grandes problemas.

 

[hellaxe]

Uso no portátil porque é 64bits e tenho 4 gigas de ram.
Falta essa opção na poll

 

[esquiso]

Não. Porque acho que i686 chega perfeitamente para o que eu quero - algo rápido e livre do "lixo" que a i386 têm.

 

[muddymind]

Aqui fico-me mesmo pelo x86 pois como apenas tenho 3GB de RAM não compensa a posterior dor de cabeça com flash e JAVA Já experimentei x86-64 mas não vi nenhuma melhoria (como seria de esperar)...

 

[JPgod]

O laptop só tem 2 gb de ram e o próprio chipset nao suporta mais que 3 gb e tal. Daí fico pelo 32 bits.

 

[souto]

Uso ambas, dependendo do computador.
It's all the same crªp

 

[DJS]

Aqui fico-me mesmo pelo x86 pois como apenas tenho 3GB de RAM não compensa a posterior dor de cabeça com flash e JAVA Já experimentei x86-64 mas não vi nenhuma melhoria (como seria de esperar)...

Que dor de cabeça??????

Eu uso x64 tanto no fixo como no portatil e não volto para o x86. A única razão de queixa que tenho até hoje do x64 é mesmo os gajos da pinnacle não terem feito drivers para a minha placa de tv porque de resto isto voa.

 

[esquiso]

Que dor de cabeça??????

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.

 

[Evil_Tidus]

no portatil tenho 4Gb de ram logo utilizo a versão x64 sem problemas

 

[dElpH!]

Versão x64 portatil com 4gb de ram , até agora estou bastante contente

 

[hasta.g5]

Uso i686. Só tenho 2GB de RAM e x86_64 tem menos suporte, incluindo programas diariamente utilizados.

 

[muddymind]

Que dor de cabeça??????

Eu uso x64 tanto no fixo como no portatil e não volto para o x86. A única razão de queixa que tenho até hoje do x64 é mesmo os gajos da pinnacle não terem feito drivers para a minha placa de tv porque de resto isto voa.

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.

Nem mais... e já agora, se tivesses 3GB de RAM achas que a x86-64 voava mais que a x86? so why even bother? [EDIT: placebo effect doesn't count ]

 

[SWEDISH]

64bits nas duas máquinas uma com 4GB ram outra com 2GB

 

[[knap]]

X86-64 no portátil com 3GiB de ram.
i686 no desktop com 1.25GiB de ram e cpu apenas 32 bits.

 

[skinnie]

X86-64 no portátil com 2Gb de ram.
i686 no desktop com 1Gb de ram e cpu 32 bits.

Experimentei o X86-64 e achei-o um pouquinho mais rápido/fluido,fiquei com ele...não vejo o porquê de não aproveitar a tecnologia 64Bits..
Mas o uso que faço também basico..

 

[gatohumano]

Eu uso 64bits com 1gb de ram,acho bem mais fluido que os 32bits,não tenho grandes problemas.
Atenção que isso de dizerem que so se tira bom proveito dos 64bits se tiverem mais de 4gb de ram é mentira.

 

[muddymind]

X86-64 no portátil com 2Gb de ram.
i686 no desktop com 1Gb de ram e cpu 32 bits.

Experimentei o X86-64 e achei-o um pouquinho mais rápido/fluido,fiquei com ele...não vejo o porquê de não aproveitar a tecnologia 64Bits..
Mas o uso que faço também basico..

Eu uso 64bits com 1gb de ram,acho bem mais fluido que os 32bits,não tenho grandes problemas.
Atenção que isso de dizerem que so se tira bom proveito dos 64bits se tiverem mais de 4gb de ram é mentira.

O efeito placebo é tão giro peguem no phoronix test suite e façam uns quantos benches e depois digam-me se têm resultados melhores no x86-64 que no x86

 

[bsd]

O efeito placebo é tão giro

Não é efeito placebo.

Eu uso a versão AMD64 do FreeBSD no meu portátil (Mobile Athlon 64) há mais de 3 anos. Como programador com alguma ligação ao "baixo nível" era interessante. Logo na altura fiz benchmarks e vi que o Athlon 64 é significativamente mais rápido a correr código de 64 bits (gerado pelo GCC, para ser completo na descrição).

Tenho em casa o resultado dos BYTE UNIX benchmarks feitos num outro desktop com a versão de 32 bits e com a versão de 64 bits, depois posso postar. O que é engraçado é ver que o Athlon é mais rápido mesmo nalguns testes em que seria de esperar que ganhasse a versão de 32 bits.

Outra coisa, é que o GCC ao gerar código de 64 bits automaticamente activa a geração de código SSE, quando em 32 bits teríamos de explicitamente dizer -mfpmath=sse. Isto é outra razão para que certos packages (muito particularmente tudo o que tem gráficos vectoriais, como o cairo, o evince, etc) fiquem automaticamente muitíssimo mais rápidos.

Também tenho visto os resultados para o portátil que estou a pensar comprar, o ThinkPad W500, e até o WEI dá melhores valores na versão de 64 bits.

 

[bsd]

Ora vejamos: isto são os resultados dos BYTE UNIX benchmarks (em single-user mode). Já pouco se usam, porque a revista BYTE já não existe há quase 10 anos. Isto serve para testar as funções tradicionais num sistema UNIX. O baseline é um Pentium a 90MHz.

  BYTE UNIX Benchmarks (Version 4.1.0)
  System -- satan.anjos.strangled.net
  Start Benchmark Run: Mon Aug 11 21:49:42 WEST 2008
   0 interactive users.
   9:49PM  up 25 mins, 0 users, load averages: 0.01, 0.08, 0.14
  -r-xr-xr-x  1 root  wheel  112036 Jul 27 21:38 /bin/sh
  /bin/sh: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.0 (700109), dynamically linked (uses shared libs), FreeBSD-style, stripped

[...]
                     INDEX VALUES            
TEST                                        BASELINE     RESULT      INDEX

Dhrystone 2 using register variables        116700.0  7666547.1      656.9
Double-Precision Whetstone                      55.0     1871.2      340.2
Execl Throughput                                43.0     2257.3      525.0
File Copy 1024 bufsize 2000 maxblocks         3960.0   115434.0      291.5
File Copy 256 bufsize 500 maxblocks           1655.0    69255.0      418.5
File Copy 4096 bufsize 8000 maxblocks         5800.0   106507.0      183.6
Pipe Throughput                              12440.0  1006848.4      809.4
Pipe-based Context Switching                  4000.0   135339.0      338.3
Process Creation                               126.0     5818.9      461.8
Shell Scripts (8 concurrent)                     6.0      965.3     1608.8
System Call Overhead                         15000.0   817122.0      544.7
                                                                 =========
     FINAL SCORE                                                     477.1

  BYTE UNIX Benchmarks (Version 4.1.0)
  System -- satan.anjos.strangled.net
  Start Benchmark Run: Mon Aug 18 19:28:58 WEST 2008
   0 interactive users.
   7:28PM  up  1:17, 0 users, load averages: 0.99, 0.94, 0.76
  -r-xr-xr-x  1 root  wheel  131600 Aug 12 21:43 /bin/sh
  /bin/sh: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), for FreeBSD 7.0 (700110), dynamically linked (uses shared libs), FreeBSD-style, stripped

[...]
                     INDEX VALUES            
TEST                                        BASELINE     RESULT      INDEX

Dhrystone 2 using register variables        116700.0 10518432.0      901.3
Double-Precision Whetstone                      55.0     2446.9      444.9
Execl Throughput                                43.0     1670.8      388.6
File Copy 1024 bufsize 2000 maxblocks         3960.0   112226.0      283.4
File Copy 256 bufsize 500 maxblocks           1655.0    67834.0      409.9
File Copy 4096 bufsize 8000 maxblocks         5800.0    97799.0      168.6
Pipe Throughput                              12440.0  1338846.0     1076.2
Pipe-based Context Switching                  4000.0   166373.1      415.9
Process Creation                               126.0     3760.8      298.5
Shell Scripts (8 concurrent)                     6.0      785.7     1309.5
System Call Overhead                         15000.0   989785.4      659.9
                                                                 =========
     FINAL SCORE                                                     485.4

Observações:

• Dhrystone 2 (a medida "tradicional" de desempenho em inteiro), 901 contra 657, provavalmente pelo facto da arquitectura AMD64 ter o dobro dos registos que tem a IA-32 (tem mais 8 registos além dos EAX, etc, e são todos de 64 bits). Dantes era normal os RISC ganharem neste benchmark precisamente por causa disto.
• Whetstone, desempenho em vírgula flutuante, aqui não entram SSE e mesmo assim 445 contra 340.
• Na cópia de ficheiros, os valores são semelhantes, porque o disco e o sistema de ficheiros são os mesmos.
• Criação de processos, ganha o IA-32, muito possivelmente porque os contextos são mais pequenos, claro.
• Consequentemente, o IA-32 ganha na interpretação de scrips shell.

Eu fiz mais testes que estes. A diferença mais importante de desempenho é que no AMD64 TODOS os packages estão compilados com SSE, o que é uma diferença brutal.

Claro que o verdadeiro motivo para o AMD64 é o espaço de endereçamento em cada processo, mesmo que a memória não seja mais que 2GB, até porque a versão de 32-bits pode endereçar até 36-bits de memória física com PAE.

A questão é, experimentem no Windows, com DLLs e stacks de threads espalhados pelo espaço de endereçamento todo, ver quanto é que vocês conseguem obter de memória CONTÍGUA. 500MB? 1GB? Nem tanto. No Linux não é tão grave, mas mesmo assim... Ou seja, programar em 64 bits é um modelo de programação diferente (ainda me lembro de dizer isto dos 32 bits, eu sou desse tempo).

 

[bsd]

Tenho que acrescentar uma coisa, na votação não devia estar referido 4GB de memória. Esta limitação (dos 3GB) é só do Windows Vista.

Vejam no kernel do Linux quantas opções têm, em 32 bits, para lidar com o espaço de endereçamento físico (são 3: uma permite lidar com 2GB de memória, outra com 4GB e outra, com PAE, permite lidar com 64GB de memória física).

Também o Windows 2000 e o Windows Server permitem lidar com mais do que 4GB de memória na versão de 32 bits. Se eles puseram esta limitação no Vista foi se calhar para empurrar o pessoal para os 64 bits (manter as duas versões tem custos elevados para muita gente).

Ou seja: se é só por terem 4GB ou 8GB de memória, podem bem continuar com a versão de 32 bits. A grande diferença está no espaço de endereçamento para cada processo e para programas que sozinhos usem uma catrefada de memória.