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

 
Compra de equipamento
Contribuído por scorpio em 11-10-00 11:02
do departamento GHz-mania
perguntas antraz escreve "Com os preços de um processador xeon 700 a irem desde 150 a 1200 (valores aproximados) para a mesma velocidade de relógio, onde o que varia é o tamanho da cache, qual serão os vossos critérios para a melhor escolha ? Acredito que quem faz compras deste tipo de processador não costume olhar muito ao preço, porque geralmente o dinheiro não é dele, mas do ponto de vista técnico quais os critérios ? "

tutoriais linux??? | Frigoríficos IBM com RedHat :)  >

 

gildot Login
Login:

Password:

Referências
  • Mais acerca perguntas
  • Também por scorpio
  • Perguntas
  • Como se pode ter o seu próprio host ?
  • Linux preparado para 'enterprise'?
  • Produtividade: linha de comando vs IDE
  • Sistemas operativos: O que são?
  • linux distribuído nas revistas, sim ou não ?
  • Pergunte ao Gildot: qual o melhor codificador de mp3?
  • staroffice
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    Depende... (Pontos:1)
    por fjca em 11-10-00 12:39 GMT (#1)
    (Utilizador Info)
    Depende do numero de CPU's na maquina e nas aplicacoes. As maquinas SMP ( mais precisamente os chipset BX, GX e os ServerWorks ) usam a cache para a comunicacao entre CPU's, logo uma das coisas mais importantes e' ter uma cache com um tamanho decente. Ora agora a Intel anda a vender CPU's com 256 Kb de cache, e tem outros com 2 Mb... ainda por cima as versoes cache >= 1 Mb estagnaram nos 700 Mhz... Basicamente eu diria que para um a dois CPU's ( e mais uma vez depende das aplicacoes ) podemos ter caches mais pequenas, mas para mais de dois CPU's e' melhor comprar com 1 Mb ou mais... Entao se for para 4 ou mais, 2 Mb de certeza. E' claro que um Xeon com 2 Mb custa... muito...
    Re:Depende... (Pontos:0)
    por Anonimo Cobarde em 13-10-00 9:59 GMT (#7)
    se forem 4 ou mais processadores 2M de certeza ? bem, 5000 contos em processadores é um bocado, certo ? a questão é mesmo essa.
      já estive a procurar resultados de benchmark mas nunca vi nenhum que se preocupasse desta questão. apenas a questão do tamanho da cache. não há por ai nenhum arquitecto de computadores que possa elucidar os curiosos como eu ?
    não me leves a mal, mas eu duvido que esses 2M valham a pena, penso que isso é para o pessoal que apenas diz:'quero o melhor que tiver.'
    a resposta simples seria 'então compra com 1M', mas a questão técnica ficaria sem resposta, e nós não queremos isso, pois não ?

    antraz
    Re:Depende... (Pontos:1)
    por fjca em 14-10-00 19:13 GMT (#8)
    (Utilizador Info)
    Nao, nao queremos isso...

      O que se passa e' de que numa arquictetura SMP Intel x86 o bus de memoria e' partilhado por todos os CPU's do sistema. Ora o acesso a' memoria principal do sistema e' controlado pela cache de cada processador, usando um protocolo de coerencia de cache, que evita que as caches dos varios CPU's tenham dados invalidos.
     
    Numa maquina single CPU, cada so' existe uma cache, e todas as operacoes entre esta e a memoria principal sao directas. No caso de varios CPU's, isso nao acontece, pq um processador pode ter uns dados na cache enquanto outro processador ja' escreveu na memoria principal dados diferentes. E' para isso que serve o protocolo de coerencia de cache, mas a sua operacao tem uma latencia inerente, devido ao facto de algumas operacoes serem extensiveis a todas as caches, e a existir contencao no acesso a memoria. E quanto mais CPU's, pior...

      Devido a isso, ha' que minimizar ao maximo os acessos 'a memoria principal, e isso so' se consegue mantendo o codigo a executar dentro da cache local. Ou se minimiza o codigo, ou se aumenta o tamanho da cache.
     
      Mais uma vez, depende das aplicacoes que vao correr na maquina. Uma comparacao entre varios CPU's da mesma aplicacao ( que eu achei numa pesquisa super-rapida ), neste caso o cliente SETI, pode ser lida aqui:

    http://www.hardwarecentral.com/hardwarecentral/print/2075/

      Atencao que alem disso, nem todos os Xeon sao iguais. Por exemplo os novos P III Xeon com bus de 133 MHz so' funcionam em configuracoes SMP. Para mais CPU's a velocidade do bus desce para 100 MHz. E eles falam em 4-way apenas.
      Alias, se bem me lembro os Xeon mais antigos vinham certificados consoante o tamanho da cache, tipo os de 512 Kb so para 2-way, enquanto que os de 1 Mb para 2-4 CPU's e os de 2 Mb para mais de 4 CPU's... mas tb posso estar enganado...
       
    Re:Depende... (Pontos:0)
    por Anonimo Cobarde em 16-10-00 9:35 GMT (#9)
    artigo porreiro.
    obrigado!
    antraz
    nao depende assim tanto (Pontos:1)
    por z0mbi3 em 11-10-00 13:36 GMT (#2)
    (Utilizador Info) http://z0mbi3.sempre.nu
    Um processador com mais cache equivale (quase sempre) a um melhor desempenho !
    Pelo menos nao tou a ver nenhum caso em que isso nao aconteca...a cache é das coisas que limita (ou afecta) muito a serio a performance do CPU. Veja-se por exemplo aquela cena do RC5 que havia uns Celerons mais antigos que tinham uma cache maior que uns pII ou pIII (ja nao me lembro quais) que crunchavam blocos mais rapidamente precisamente porque conseguiam ter o cliente em cache...por isso este e um caso tipico em que quanto mais melhor...
    noutras palavras, se $$$ -> +oo logo cache tb deve tender para +oo :)

    Em principio nao é o mais importante. (Pontos:1)
    por mduarte em 11-10-00 14:05 GMT (#3)
    (Utilizador Info)
    Hint 1 - Muita RAM (Toda a que poderes comprar) Hint 2 - Controladora/Discos SCSI (Caro mas rende) Processador é apenas moderadamente importante. A não ser que queiras fazer calculo pesado...
    save the wales, feed the poor, free the mallocs
    Re:Em principio nao é o mais importante. (Pontos:0)
    por Anonimo Cobarde em 12-10-00 12:48 GMT (#4)
    E' obvio que nunca viste uma maquina a funcionar sem cache.
    Faz um 486DX2-66 mais lento do que um 386SX-16.
    E' verdade que so' velocidade de relogio nao serve de nada se o resto do sistema nao tiver capacidade para responder.
    Mais RAM so' e' precisa se a que tens nao chega. E investir em SCSI so' e' util se as tuas aplicacoes usarem muito o disco.
    Mas muito importante e muitas vezes desprezado e' a velocidade com que o CPU consegue aceder as instrucoes/dados, que e' o que ele faz continuamente.
    Uma vez que as memorias dinamicas (DRAM, EDORAM, SDRAM) sao muito mais lentas que o CPU, a cache desempenha um papel fulcral, evitando que o CPU passe longos periodos a' espera de acesso a RAM
    Re:Em principio nao é o mais importante. (Pontos:1)
    por mduarte em 13-10-00 7:27 GMT (#5)
    (Utilizador Info)
    És demasiado rapido a tirar conclusões :-].
    Obviamente que sem cache a máquina fica MUITO LENTA.
    Mas o que está em discussão não é o cache / vs sem cache.
    É X Kbytes de cache vs Y Kbytes de cache. O preço que tu pagas as mais para teres um Xeon com 2 Megas de cache vs um com 1 Mb de cache vs um vulgar PIII com 512 Kb de cache não é minimamente correspondido em desempenho, isto porque o acrescimo marginal de desenpenho por cada Kbyte de cache adicionado é cada vez menor. Quanto ao SCSI :
    A não ser que vás usar o teu Xeon de centenas de contos (hint hint) para crackar o RC5 ou para o SETI, é muito provavel que vás precisar de vários discos rápidos para fazer o que quer que seja.
    Mesmo com UDMA -X quando estás a usar o disco intensivamente o uso do CPU deve de estar sempre acima dos 30% só para I/O (com SCSI E o dinheiro que pagaste pela cache adicional a ser desperdiçado :-)
    save the wales, feed the poor, free the mallocs
    Re:Em principio nao é o mais importante. (Pontos:1)
    por mduarte em 13-10-00 7:30 GMT (#6)
    (Utilizador Info)
    O post ficou acidentalmente cortado. Com SCSI o uso de CPU (com uma controladora/Sistema operativo decente) fica abaixo dos 5%
    save the wales, feed the poor, free the mallocs

     

     

    [ Topo | Sugerir artigo | Artigos anteriores | Sondagens passadas | FAQ | Editores | Preferências | Contacto ]