| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | | 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
|
| |
| |
| | E ainda por cima "No cona" é uma expressão/modo de vida muito popular entre os geeks...
|
| |
| | É caso para dizer que quem tem Nocona fica na mão... Em termos de desempenho de CPU, claro.
|
| |
| | Posts assim é que dão vida a uma thread ehehehe.
"No comments"
|
| |
| | 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) |
| | 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 |
| |
| |
| | 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) |
| | | 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) |
| | 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) |
| | | 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.
|
| |
| | 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 |
| |
| | 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... |
| |
| | | 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) |
| | 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.
|
| |
| | ... 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.
|
| |
| | ...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.
|
| |
| | 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.
|
| |
| | ARGh! escrever duas vezes 'porcessadores' é obra :)
|
| |
| | 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.
|
| |
| | | "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) |
| |
| | Eu lembro-me especificamente de ter referido no meu post anterior que eram arquitecturas diferentes, portanto não entendo o comentário.
|
| |
| | 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... |
| |
| |
| | Podes ser mais preciso?
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| | 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... |
| |
| | 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) |
| |
| | Os benchmarks de tratamento de imagem e rendering lidam com matrizes de grande complexidade, se bem que não apenas isso.
Dominus vobiscum |
| |
| | Podes dar uma olhadela nos testes de CPU da SPEC, que me lembre uma das aplicacoes usadas era precisamente multiplicacao de matrizes... em Fortran :)
|
| |
|
