gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
AMD vs Intel. Referee: Linux
Contribuído por vd em 16-08-04 1:01
do departamento dos-testes
Hardware 4Gr escreve "Surgiu recentemente uma discussão sobre qual a marca que detém a superioridade nos processadores, AMD ou Intel, e se a diferença na frequência do processador, vulgos Ghz, era significativa para ditar um vencedor.
A Anandtech, conhecido site da especialidade, analisou os dois processadores 64bits em causa, Opteron 150 e Xeon 3.6 em ambiente Linux, neste caso, SuSE Linux 9.1 64bits e ditam os benchmarks que, para quase todas as tarefas, o Opteron é de longe superior.

Daqui conclui-se que: a diferença na velocidade de relógio não é significativa. Em analogia, se a Intel for um Ferrari, a AMD é um TIR a andar um pouco mais lento que um Ferrari, mas a transportar bem mais mercadoria. E também se pode extrapolar que se a AMD não tem maior fatia de mercado é porque as pessoas ainda confiam, demasiado, no nome Intel. "

E para a California, OpenSource | MS SP2 vs Mozilla e Opera  >

 

gildot Login
Login:

Password:

Referências
  • Linux
  • Intel
  • Anandtech
  • analisou os dois processadores 64bits em causa
  • Mais acerca Hardware
  • Também por vd
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    Codename pouco popular (Pontos:2, Engraçado)
    por Ancestor em 16-08-04 3:45 GMT (#1)
    (Utilizador Info)

    Our preliminary look at Intel's 64-bit Xeon 3.6GHz Nocona (..)

    O CPU pode não ganhar os testes contra o AMD, mas que tem um nome engraçado, tem :D
    Re:Codename pouco popular (Pontos:2)
    por JohnnyBigodes em 16-08-04 13:48 GMT (#13)
    (Utilizador Info)
    E ainda por cima "No cona" é uma expressão/modo de vida muito popular entre os geeks...
    Re:Codename pouco popular (Pontos:2)
    por Ancestor em 16-08-04 16:17 GMT (#15)
    (Utilizador Info)
    É caso para dizer que quem tem Nocona fica na mão... Em termos de desempenho de CPU, claro.
    Re:Codename pouco popular (Pontos:2)
    por Gimp em 17-08-04 0:00 GMT (#25)
    (Utilizador Info)
    Posts assim é que dão vida a uma thread ehehehe.


    "No comments"

    Re:Codename pouco popular (Pontos:2)
    por nmarques em 16-08-04 16:58 GMT (#16)
    (Utilizador Info) http://www.the-kult.net/kampfhund/
    Sim claro... e quem foi à HAL se calhar nunca soube que a cidade Enschede significa literalmente 'na cona', sendo 'schede' vulgo calão para cona, pelo menos em Twente e Overheijel.
    --
    Nacionalista - Espirito Guerreiro
    Socialista - Orgulho Europeu!
    IPS (Pontos:3, Informativo)
    por PRE em 16-08-04 7:49 GMT (#2)
    (Utilizador Info) http://psantos.net
    Provavelmente uma melhor unidade de medida, seria instrucções por segundo, ou algo do género, em vez do clock. Pelo que me lembro das aulas de Microsprocessadores o clock é só uma pequena parte do processador, é só um componente a dar sinal periódico. Medir a qualidade de um processador só por causa dos Ghz é excluir toda a arquitectura do procesador.
    ____________________
    Pedro Santos :: psantos.net
    Re:IPS (Pontos:1)
    por knocker em 16-08-04 8:58 GMT (#3)
    (Utilizador Info)
    Completamente de acordo.
    Já estou um bocado farto da história: "quanto maior o clock, mais rápido é o processador".

    --
    Made with Debian GNU/Linux
    Re:IPS (Pontos:3, Interessante)
    por Ancestor em 16-08-04 9:33 GMT (#4)
    (Utilizador Info)
    Instruções médias por segundo. Qualquer cpu x86 moderno permite executar várias instruções por ciclo de relógio, de acordo com a possibilidade de reagrupamento destas de forma a minimizar as dependências directas. Com o aparecimento de tecnologias multicore, em versão virtual com o Hyperthread e em versão física dentro de pouco tempo, retira a estes valores muita credibilidade que teriam.

    Por si só, o MIPS (Million Instructions per Second) dá uma ideia da performance teórica, mas, em ambientes reais, existem outras limitações ao desempenho global do sistema, como por exemplo a velocidade de I/O do CPU, a velocidade I/O da memória, etc. No caso dos cpu's modernos, a velocidade de I/O é o "bottleneck" há anos.

    Re:IPS (Pontos:2, Informativo)
    por hugosantos em 16-08-04 10:18 GMT (#5)
    (Utilizador Info)
    Nao, nao seria. Numero de instrucoes processadas por segundo alem de ser bastante diferente entre arquitecturas, mesmo entre a mesma arquitectura instrucoes diferentes executam em tempos distintos (por ex XOR vs MUL, ou mesmo um NOP), nao ha tempos constantes , logo nao e' uma boa medida. Para adicionar 'a ja' complexa questao, temos tambem os tempos de acesso a memorias, tal como o bandwidth disponivel. Por isso e' que existem os benchmarks, para comparar a performance de arquitecturas nas mesmas tarefas. E o que muitas vezes se verifica e' que uns sao mais rapidos numas coisas, e outros noutras (por ex, processamento de inteiros no Opteron vs processamento de floating points em G5/Altivec).
    Re:IPS (Pontos:2, Informativo)
    por Ancestor em 16-08-04 11:18 GMT (#6)
    (Utilizador Info)

    mesmo entre a mesma arquitectura instrucoes diferentes executam em tempos distintos (por ex XOR vs MUL, ou mesmo um NOP)

    Em processadores relativamente recentes (Pentium e superior) a maioria das instruções demora no máximo 1 ciclo de relógio. Por exemplo, num 386 ou num 486, um XOR demoraria 1 ciclo, e um MUL variaria entre 3 e 27 ciclos, de acordo com o tamanho dos operandos e a complexidade da operação. Ambos os opcodes executam em 1 ciclo de relógio em CPU's modernos, e ainda podem ser emparelhados com outras instruções para execução simultânea.

    Claro que esse facto não altera minimamente a veracidade das tuas afirmações, com as quais eu concordo plenamente.


    Re:IPS (Pontos:2)
    por 4Gr em 16-08-04 13:07 GMT (#9)
    (Utilizador Info) http://www.fe.up.pt/freefeup
    Medir a qualidade de um processador só por causa dos Ghz é excluir toda a arquitectura do procesador.

    Exactamente. Era precisamente aí que queria chegar, visto que a propaganda da Intel tem-se baseado no incremento dos Ghz.

    Dominus vobiscum
    Re:IPS (Pontos:2)
    por Kmos em 16-08-04 18:40 GMT (#18)
    (Utilizador Info) http://Kmos.TondelaOnline.com
    A maior argumentação que ouço, é que o Intel não queima, mesmo sem cooler, ele desliga-se.. não faço ideia se os novos AMD fazem isso, nem faço conta de testar isso no meu Athlon, de resto tenho sempre aconselhado AMD, não só pelo preço, mas porque nunca fiquei desiludido desde que passei a comprar só AMD.

    I'm a Lost Soul in this Lost World...
    Re:IPS (Pontos:2)
    por raxx7 em 16-08-04 21:38 GMT (#21)
    (Utilizador Info)

    Os Athlon64/Opteron têm uma protecção térmica adequada. Também têm uma placa de metal que evita que se quebre o CPU ao montá-lo.
    Pequenas coisas que fazem as pessoas dormir mais descansadas.

    Mas há mais a contribuir para a imagem de menor fiabilidade dos AMD.
    Não sei se há diferenças entre a validação que Intel e a AMD faziam dos CPUs propriamente ditos (ou da que fazem, já agora), mas o facto de empresas como a HP e IBM terem sistemas baseados em Intel e não terem baseado em AMD (e portanto, de os chips da Intel terem passado pelo processo de validação destes e de os da AMD não) também contribuia para essa imagem.


    Remember to be the Killer, not the Victim! (Nuklear Girl)
    Re:IPS (Pontos:3, Informativo)
    por Ancestor em 16-08-04 19:20 GMT (#19)
    (Utilizador Info)
    Não é só propaganda. Na realidade a performance dos cpu's da linha P4 baseia-se exclusivamente na capacidade que o CPU tem em executar instruções mais rapidamente, para que os sistemas de optimização dantescos que eles têm dêm algum resultado. O redesenho do core do CPU foi feito tendo em conta velocidades até 4.5Ghz e não os iniciais 1 ou 1,2Ghz. Quem não se lembra que um P3 a 1.2Ghz dava uma tareia bestial num P4 a 1,2Ghz? Curiosamente (e digo curiosamente porque sou um assumido fã Intel) a Intel investiu rigorosamente no contrário da AMD: investiu em optimização em vez de reimplementação. O resultado são CPU's que se portam de forma excelente e meia dúzia de rotinas facilmente cacheáveis e cuja execução seja prevista pelo mecanismo de previsão de saltos, e que se portam de forma absolutamente medíocre em tudo o resto, mas cuja mediocriade tende a ser compensada por uma velocidade de processamento elevada. Exemplos? Por exemplo um radial blur.
    Re:IPS (Pontos:1)
    por BugMeNot.com em 17-08-04 13:50 GMT (#28)
    (Utilizador Info)
    ... e um pipeline que basicamente vai daqui até à lua e volta e que faz com que o CPU se comporte como uma carroça puxada a bois, apesar de ter 4 motores de aviao acoplados atrás. Não obstante, um gato que vai a correr pela berma da estrada consegue ultrapassa-la. Se a analogia não foi suficientemente clara, "carroça" = P4, "gato" = Athlon.
    Re:IPS (Pontos:1)
    por schneider em 16-08-04 19:37 GMT (#20)
    (Utilizador Info)
    ...visto que a propaganda da Intel tem-se baseado no incremento dos Ghz

    A linha intel doméstica. A linha corporativa (Itanium) trabalha a clocks muito mais baixos e tem melhor rendimento.
    Re:IPS (Pontos:1)
    por Specimen em 16-08-04 22:31 GMT (#22)
    (Utilizador Info)
    Itanium não é oposição a Pentium de uma forma domestica versus corporativa. A linha Itanium é uma linha de processadores que funcionam a 64 bits, ao contrário dos processadores baseados na arquitectura AMD64 q tb executam código IA-32 nativamente, os Itanium (agora já na segunda geração, Itanium 2) executam código IA-32 por emulação. Trata-se de uma arquitectura diferente planeada para para ser usada exclusivamente a 64 bits requerendo q o software já existente seja reescrito para poder funcionar nela. Acabou por ser relegada para um nicho corporativo muito especifíco especialmente pela jogada da AMD com o AMD64. No entanto a Intel tem Pentiums que tb poderima ser apelidados de 'corporativos' o caso da linha Pentium Xeon que se baseia na mesma arquitectura base dos Pentium 4. Em relação aos 'clocks' (frequencia) mais baixos e melhores rendimentos, isso é normal nos porcessadores 64 bits qd comparados com porcessadores 32 bits.
    Re:IPS (Pontos:1)
    por Specimen em 16-08-04 22:32 GMT (#23)
    (Utilizador Info)
    ARGh! escrever duas vezes 'porcessadores' é obra :)
    Re:IPS (Pontos:1)
    por schneider em 16-08-04 23:21 GMT (#24)
    (Utilizador Info)
    A linha Itanium é um projeto conjunto da HP e intel, que foi desenvolvido a partir do zero.

    O fato de ter melhor aproveitamento por ciclo de clock não é devido simplesmente por ter registradores de 64 bits, mas sim pela sua arquitetura diferenciada. Alguém com mais conhecimentos em microprocessadores pode explicar com mais detalhes.
    Re:IPS (Pontos:2)
    por raxx7 em 17-08-04 2:54 GMT (#26)
    (Utilizador Info)

    "registos", não "registradores".

    Um processdor tem um certo potencial para executar X instruções por ciclo. Contudo, várias razões contribuem para que, muitas vezes, ciclos de processamento sejam desperdiçados.
    * Uma operação depende do resultado de outra e vai ter de esperar pela outra.
    * Uma operação depende do um load de memória e vai ter de esperar. (No fundo, é um caso especial do anterior).
    * Um branch condicional depende de um resultado que ainda não está disponivel. O processador então tenta adivnhar. Se o previu mal, vai ter de esvaziar o pipeline, o que implica város ciclos desperdiçados. Quanto mais longo o pipeline, mais ciclos se desperdiçam.
    * O processador (devido à sua micro-arquitectura) não tem capacidade de efectuar duas determinadas instruções em paralelo e uma delas vai ter de esperar.

    Para tentar minorar isto, utilizam-se várias técnicas, tanto no hardware do CPU como na optimização de software.

    Ao nivel do hardware temos caches e prefetching de dados da memória, mecanismos sofisticados de predição de branches e reordenação de instruções (execução fora de ordem).
    Ao nivel do software, tenta-se optimizar o software de modo a minimizar a ocorrência destes problemas. Temos então vários critérios para organizar o código:
    * Se a operação B depende da operação A, vamos então tentar intercalar entre elas outras instruções úteis, de modo a que o CPU não fique parado à espera do resultado de A. O número de instruções que é necessário intercalar depende da operação.
    * Se B for um branch condicional que depende do resultado da operação A, vamos tentar fazer o mesmo que no caso anterior. O número de instruções que é necessário intercalar é tanto maior quanto maior for o pipeline.
    * Vamos tentar não emparelhar instruções que o CPU não consegue executar em paralelo.
    * Vamos maximizar o uso das caches.

    Contudo, ambas as técnicas têm limitações.
    * A quantidade de instruções que o CPU pode re-ordenar dinamiamente é finita e a reordenação não elemina todos os ciclos mortos.
    * O número de branches sobre os quais o hardware consegue manter estatisticas também. E há sempre falhas de previsão.
    * As caches são finitas e a decisão do CPU sobre o que manter em cache nem sempre é a melhor. * O hardware é custa dinheiro, consome potência e dissipa calor. * O software é estático (pelo menos geralmente). * A organização do código é limitada pelo instruction set.

    Como é que isto se relaciona com os Pentium e os Itanium?
    A ISA x86 é francamente limitativa no que diz respeito à possibilidades de organizar o código da forma mais conveniente. Poucos registos e a utilização de flags são os culpados do costume. A FPU x86 é simplesmente má e nem sempre se usa SSE/SSE2.
    A ISA IA-64 oferece muito mais possibilidades. Imensos registos, predicação e mais algumas coisas oferecem mais possibilidades de reorganização do código.
    Conta ainda com mecanismos que permitem ao software dar pistas à predição de branches e uso de caches.

    Isto significa que vale a pena construir CPUs IA-64 com capacidade para processar mais instruções por ciclo do que processadores x86 (a complexidade da descodificação de instruções x86 também tem a sua palavra a dizer neste assunto). Os Opteron processam até três instruções por ciclo. Os Pentium4 são dificeis de quantificar devido à trace-cache, mas será menos. Um Itanium2 processa até 6!
    Outros aspectos ajudam os Itanium2 a fazer boa figura.
    * Caches L1 e L2 rápidas e capacidade de fazer load/stores suficientes para sustenta as unidades de execução.
    * A cache L3 é grande. Até 6MB nos actuais, 9MB no futuro próximo. E mais no não tão próximo..
    * Simplicidade. Sem execução fora de ordem nem instruções complexas, o CPU é simples e o pipeline curto.

    Já agora, os aspectos menos bons:
    * Necessidade de optimizar agressivamente o código.
    * Nem todo o código é assim tão paralelizável. Às vezes, os GHz fazem mesmo falta.
    * Falta de rotates e apenas uma instrução shift-pair por ciclo limitam a performance nalguns algoritmos criptográficos.
    * Metade dos FLOPs de um Pentium4 em precisão simples. Curto para processamento digital de sinal (por exemplo, encoding/decoding de mp3).


    Remember to be the Killer, not the Victim! (Nuklear Girl)
    Re:IPS (Pontos:1)
    por Specimen em 17-08-04 13:07 GMT (#27)
    (Utilizador Info)
    Eu lembro-me especificamente de ter referido no meu post anterior que eram arquitecturas diferentes, portanto não entendo o comentário.
    g5 (Pontos:2)
    por TarHai em 16-08-04 11:57 GMT (#7)
    (Utilizador Info) http://www.dilbert.com
    do ponto de vista academico (fp, int e acesso a memoria) era interessante ver os 3 cpus comparados para diferentes operacoes e tamanhos de matrizes.

    Alguem sabe de uma benchmark dessas?
    ## I should be working...
    Re:g5 (Pontos:2)
    por raxx7 em 16-08-04 12:36 GMT (#8)
    (Utilizador Info)
    Podes ser mais preciso?
    Remember to be the Killer, not the Victim! (Nuklear Girl)
    Re:g5 (Pontos:2)
    por TarHai em 16-08-04 13:16 GMT (#11)
    (Utilizador Info) http://www.dilbert.com
    Eu queria um benchmark de performance em virgula flutuante vs tamanho da matriz em uso.

    Um grafico desse tipo permite ter uma ideia de como a velocidade de calculo depende da complexidade do problema a ser tratado.

    Para matrizes pequenas, a performance seria limitada pelo CPU, para as intermedias, seria limitada pela memoria cache e para as grandes pela memoria do sistema.

    Infelizmente, muitos esses sites so referem valores medios desse tipo de medidas para nao confundir os leitores.


    ## I should be working...
    Re:g5 (Pontos:2)
    por raxx7 em 16-08-04 17:37 GMT (#17)
    (Utilizador Info)
    Desconheço. O Linpack podia ser usado para isso, mas os resultados publicados só contemplam um tamanho de matriz.

    Remember to be the Killer, not the Victim! (Nuklear Girl)
    Re:g5 (Pontos:2)
    por 4Gr em 16-08-04 13:09 GMT (#10)
    (Utilizador Info) http://www.fe.up.pt/freefeup
    Os benchmarks de tratamento de imagem e rendering lidam com matrizes de grande complexidade, se bem que não apenas isso.

    Dominus vobiscum
    Re:g5 (Pontos:2)
    por fjca em 16-08-04 13:35 GMT (#12)
    (Utilizador Info)
    Podes dar uma olhadela nos testes de CPU da SPEC, que me lembre uma das aplicacoes usadas era precisamente multiplicacao de matrizes... em Fortran :)
    Re:g5 (Pontos:2)
    por JohnnyBigodes em 16-08-04 13:53 GMT (#14)
    (Utilizador Info)
    picCOLOR, usados muito habitualmente nos benchmarks do Tech Report (podes ver p. ex. aqui).

     

     

    [ Topo | FAQ | Editores | Contacto ]