| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | Olha para um processador com hyper-threading e ve^ a dobrar :-)
Ou seja, o SO vê (e comporta-se como se tivesse) 2 processadores. Um dual-P4 comporta-se como se tivesse 4 processadores, um quad comporta-se como se tivesse 8.
|
| |
| |
| | Sim, mas numa maquina com mais que um processador e' preciso ter cuidado com a versao de linux utilizada. Se for 2.4.x, o kernel nao distingue os processadores virtuais dos reais, o que facilmente causara' ter um processador ocupado com dois processos e o(s) outro(s) processador(es) a fazer nada...
hugs
Strange |
| |
| | Verdade. Mas a minha experiência é que não há diferença notável de performance entre ter 2 processos no mesmo processador real (2 virtuais diferentes), ou um processo em cada processador (real).
Um bom teste (embora pouco científico) é correr clientes de seti@home e comparar o workrate ;-)
|
| |
| | | Mas a minha experiência é que não há diferença notável de performance entre ter 2 processos no mesmo processador real (2 virtuais diferentes), ou um processo em cada processador (real). I somehow can't believe that... ;-) O hyperthreading apenas permite "desmultiplicar" o CPU quando este esta' 'a espera de eventos externos (memoria, interrupts, etc.) -- pelo que se tiveres processos que nao passam uma parte significativa do tempo bloqueados nao vez grande diferenca de performance. No teu exemplo do seti@home duvido que vejas grande diferenca de performance. Regards,
"Monogamy is for guys that can't get pussy." --Steve-O.
|
| |
| | eh, acabaste de descrever pipelining, técnica que é empregue em processadores RISC, e que, pensava eu, era usada pelo menos parcialmente em Intel.
Ou seja, essa história de 2 processadores parece um hack horrivel para ter uma funcionalidade aka-RISC com compatibilidade com um instruction-set não optimizado (CISC), e passar a responsabilidade de aproveitar ou não os ciclos livres de que o processador dispõe.
Logicamente, como qq pessoa com 2 palmos de testa vê, independemente do que a Intel disser, isto nunca vai ter o rendimento de dois processadores.
-- |
| |
| | "independemente do que a Intel disser, isto nunca vai ter o rendimento de dois processadores. "
Não é para ter rendimento de dois processadores, é só para aumentar a performance de Um. É claro que a Intel faz demasiado markting com isso.
Pedro Esteves |
| |
| | eh, obviamente quando estou a falar de passar a responsabilidade, estou a falar de passa-la para o software/developers.
Rui
-- |
| |
| | I somehow can't believe that... ;-)
Ei... eu disse a minha experiência :-) Eu estou mesmo a usar processadores com hyperthreading com serviços que ficam com o I/O preso durante algum tempo, enquanto recebem ou enviam dados para sockets (o que se pode dizer da maior parte dos serviços de rede :-) ).
Para "grandes processos monolíticos" (leia-se inetd ou sendmail, por exemplo), o hyperthreading não ajuda grande coisa.
Por acaso não sei de certeza o que acontece aos serviços que fazem pre-fork (tipo apache), mas a sensação que tenho é que os processos ficam no processador para onde foram spawned no arranque.
|
| |
| | Penso que não há muito problema nisso, à parte claro de não se conseguir obter o máximo de performance do sistema. Penso que a distinção entre processadores virtuais e reais está a ser tratada no 2.5.x não sei se está planeado algum backport para o 2.4.x.
-- Carlos Rodrigues
|
| |
| | Já existem patches para fazer a distinção entre cpu's virtuais e cpu's reais...
url: http://www.aceshardware.com/#60000456
e quanto à tecnologia hyper-threading.. não é assim tão boa quanto a estão a pintar.. um p4 com hyper-threading enabled não me parece que tenha a mesma performance de um dual p4 com hyper-threading desactivado.
url: http://www.aceshardware.com/read.jsp?id=50000319
Afinal de contas SMT != SMP, e ter parece-me demasiado bom para ser verdade, gastar dinheiro num MB SMP e num segundo CPU para um sistema com a mesma performance que um cpu com hyper-threading enabled.. económicamente não faz sentido.
Miguel F. M. de Sousa Filipe
handle: m3thos
email: mmsf@rnl.ist.utl.pt
More Human than Human.
|
| |
| | Já existem patches para fazer a distinção entre cpu's virtuais e cpu's reais...
url: http://www.aceshardware.com/#60000456
e quanto à tecnologia hyper-threading.. não é assim tão boa quanto a estão a pintar.. um p4 com hyper-threading enabled não me parece que tenha a mesma performance de um dual p4 com hyper-threading desactivado.
url: http://www.aceshardware.com/read.jsp?id=50000319
Afinal de contas SMT != SMP, e ter parece-me demasiado bom para ser verdade, gastar dinheiro num MB SMP e num segundo CPU para um sistema com a mesma performance que um cpu com hyper-threading enabled.. económicamente não faz sentido.
Miguel F. M. de Sousa Filipe
handle: m3thos
email: mmsf@rnl.ist.utl.pt
More Human than Human.
|
| |
| | | um p4 com hyper-threading enabled não me parece que tenha a mesma performance de um dual p4 com hyper-threading desactivado Claro que não, e não é esse o objectivo. O objectivo é dar trabalho aos vários componentes do processador que não estão a ser utilizados pelo processo actual. E como não é possível em alguns casos compilar os programas para tirar partido de todas as potencialidades do P4 isso permite uma melhoria ligeira na performance.
hugs
Strange |
| |
| | Por esta ima gem parece que o 2.4.x já suporta.
|
| |
| | Bem Já que tamos numa de processadores e Comdex.
A AMD já tem lá um dos seus novos processadores Hammer a 1.4 Ghz.
Em termos de performance é equivalente a um P4 2200 ou um Athlon xp 2200+, isto nos testes do 3DMark, que não usa os 64 bits do processador.
A velocidade de estreia deve ser proximo dos 2 Ghz.
fonte: http://www.anandtech.com/showdoc.html?i=1752&p=3
Pedro Esteves |
| |
| *cof* (Pontos:3, Esclarecedor) |
| | | Esse Thomas Pabst não é o tal que é um pouco assim a fugir pró Intel-biased? :) O homem já perdeu credibilidade por causa as opiniões (criativas) acerca da Intel.
A minha anterior assinatura era ainda pior que esta. |
| |
| |
| | Epá! Tiraste-me as palavras da boca!! É isso mesmo ó provinciano! Mto bem dito!!! Pa. eu compreendo-te perfeitamente! a mim estas cenas tambem me revoltam bues!
|
| |
| | | LOL. O outro post não estava em russo, mas sim em esloveno. E já agora, não se diz "Ti znaiesh pa partugalheitz", mas sim "Ti gavariet pa partugalhietz", ou então "Ti znaiesh partugalhietz eezuk?" (O "ya" na primeira silaba passa sempre para "ee"). Da, ya gavariu pa russkiy ;-)
|
| |
|
| | The problem:
x86 é uma ISA de merda :-)
Um Athlon ou um Pentium Pro/II/III são capazes de descodificar até 3 instruções x86 por ciclo. Os K6 até eram capazes de descodificar 4. O Pentium4 usa um descodificar simples e a trace cache, pelo que as contas não são muito lineares.
Em qualquer caso, são uns belos brinquedos, ou pelo menos parecem.
A triste verdade: um PentiumIII a correr código _optimizado_ para ele executa em média cerca de 1,5 instruções x86 por ciclo.
x86 simplesmente não deixa muito espaço para paralelismo entre as instruções e a execução fora de ordem só pode ajudar até certo ponto.
SMT (ou Hyperthreading) permite utilizar melhor o CPU, executando no mesmo CPU duas streams de instruções em paralelo. Um pouco mais de performance -- dependendo da aplicação -- por um custo baixo.
Outra solução é a da Transmeta: utilizar software para converter dinâmicamente para uma ISA mais eficiente. A utilização de software permite ter janelas de instruções muito maiores do que o habitual OoO dos CPUs.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| |
| |
| | anandtech fala sobre isso:
http://www.anandtech.com/cpu/showdoc.html?i=1546&p=5
--- "Esta voz!?!..." Cpt Francis Blake -- S.O.S. Meteoros |
| |
|
