| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Pessoalmente aplaudo o melhorado suporte SMP, espero que esteja ao nível do SMP no kernel Linux.
Smith: "Why, Mr. Anderson, why do you persist?" - Neo: "Because I choose to." |
| | | | | | bom, eu espero que não. o smp em linux é asqueroso...
|
| | | | (bom, eu espero que não. o smp em linux é asqueroso...) - Nao estaras a falar de HT q para bulir tem q ser com o smp enable. Uma coisa e HT com smp outra coisa e smp purinho. Smp em linux e do melhor que existe.
" Os loucos só são loucos porque são uma minoria " |
| | | | viste-me falar em intel ? quanto mais HT?
do melhor que existe? bom...se tivesse a falar de SunOS, ainda compreendia...mas la esta, 'opiniões'...
|
| | | | Nem isso. O HT é suportado apenas com um kernel SMP, mas isso não quer dizer que o kernel seja estúpido e não saiba que está perante CPUs virtuais. Na realidade esta distinção está presente e afecta a politica de escalonamento e a afinidade de processos a cada CPU.
A razão porque o HT não é suportado no kernel UP, é porque este existe propositadamente para evitar ter de lidar com múltiplos CPUs, virtuais ou não.
O que acontece, é que em outros sistemas o kernel é sempre SMP, porque as máquinas a que se destinam dificilmente terão apenas um CPU.
O caso do Windows XP é mais ou menos equivalente ao do Linux. O Home é UP-only e o Professional escolhe uma HAL SMP para suportar HT (se nãoe stou em erro).
--
Carlos Rodrigues
|
| | | | A IBM diz que há uma melhoria de 30% em aplicações que utilizem multithreading quando é utilizado o Hyperthreading em Linux (num kernel 2.4, em kernels mais recentes as melhorias são mais substanciais). http://www-106.ibm.com/developerworks/linux/library/l-htl/ O que se passa é que no Linux um processador "Hyper-threaded" é tratado como se fossem dois processadores reais, daí a necessidade de utilizar um kernel SMP para retirar todos os benefícios. Não vejo o problema nisto.
Smith: "Why, Mr. Anderson, why do you persist?" - Neo: "Because I choose to." |
| | | | | O grande problema é que o HT não é implementado em dual-core, mas apenas num só processador. Isso acarreta alguns problemas em termos de atribuição de threads a cada cpu, e até muitas vezes, a uma discrepância na distribuição de carga entre o cpu real e o virtual. Isto, claro, para não falar no acesso concorrente a dispositivos de hardware/memória, que poderá dar origens a stalls. Eu pessoalmente sou bastante céptico em relação ao HT, e apesar de ser um recurso engenhoso, não me parece a melhor forma de resolver o problema. Por acaso tenho um servidor xeon com HT activo a correr FreeBSD 9.0 e com monitorização snmp da carga dos cpu's, e a distribuição de carga é hilariante. Eu sei que o suporte smp do FBSD 9 não ajuda, e o trabalho típico do servidor não é thread-based, mas o resultado afigura-se muito mais uma manobra de marketing que propriamente a um aumento justificável de performance.
|
| | | | Dual-Core (CMP) e Hyperthreading (SMT) são coisas ortogonais. Os processadores POWER5 da IBM utlizam ambas as técnicas.
O SMT não é uma solução para "o problema", seja qual for o problema que estás a pensar. É uma forma de aproveitar melhor os recursos do CPU, sem grandes custos (a Intel afirma que o Hyperthreading era responsável por 5% da área dos Pentium 4),
E é sabido que por vezes faz mais mal que bem.
|
| | | | No caso da Intel, o HT é uma bela maneira de evitarem ter que redesenhar o core do CPU - tendo em conta todo o tipo de penalizações de execução que o cpu possui. Em vez de terem um muito mau, têm dois muito maus. No meu caso prático, não pretendi aproveitar o SMP do HT, até porque a máquina suporta 2º processador, apenas me limitei a não desactivar o HT, até por curiosidade de funcionamento da "coisa". Por outro lado, se existe necessidade de utilizar o cpu, não vejo grande vantagem de em vez de um, ter dois pipelines de execução que competem entre si por ciclos de relógio, visto que o core é o mesmo. A Intel diz que tem vantagem, eu continuo céptico - mesmo nas máquinas P4 não encontrei diferenças assinaláveis.
|
| | | | | O suporte para HT está em todos os Pentium4, embora em muitos dos primeiros modelos esteja desactivado. Não foi um acrescento. Não há "dois pipelines de execução que competem entre si por ciclos de relógio". Só há um pipeline de execução e algumas estruturas de estado duplicadas. O front-end do pipeline limita-se a fazer o fetch de instruções da trace cache de cada uma das duas threads alternadamente, que depois são misturadas no pipeline e separadas de novo na fase de retirement. O interesse disto está em que o core tem uma certa capacidade de execução, mas nem todo o software tem o paralelismo ao nivel de instruções (ILP) necessário para o aproveitar ao máximo. Na verdade, muito pouco o faz. O SMT dos P4 e POWER5 introduz duas streams de instruções completamente independentes, permitindo aproveitar melhor a capacidade do core. O facto de detectares ou não diferença depende do que fazes com a máquina. Nem todas as tarefas são CPU bound e nem todas as que são beneficiam de SMT. More about SMT
|
| | | | Se estás por dentro da tecnologia do cpu, percebeste perfeitamente a analogia dos "dois pipelines" (um p4 não tem dois pipelines de execução, mas seis, salvo erro). E realmente se estás a executar código com 2 estruturas de estado no mesmo core, esse código está a competir por ciclos de relógio, precisamente porque o "pipeline" de execução é o mesmo. Quanto ao facto de o HT estar disponível em todos os p4, não acredito muito nisso. De facto, só os processadores mais recentes possuem tecnologia de fabrico que lhes permitem esse grau de integração, visto que o tamanho do core é mantido.
|
| | | | | O Pentium4 tem um pipeline, com 7 unidades de execução. Boneco. De facto, as instruções das duas threads competem por recursos. E como já escrevi aqui, nem sempre o SMT se revela benéfico.
Contudo, se queres por isso em termos de competir por "ciclos de relógio", o que tens que perceber é que a maioria do software não aproveita ao máximo todos os "ciclos de relógio". Quanto ao que tu acreditas e deixas de acreditar, pouco me interessa. O facto é que está lá, mas desactivado. Por isso é que a área do chip não varia entre os que tinham e os que não tinha. SMT não adiciona muita complexidade para um CPU com execução fora de ordem, mas também não é algo que se adicione facilmente a uma concepção já existente.
|
| | | | | Por isso é que a área do chip não varia entre os que tinham e os que não tinha. Caso não tenhas reparado, a tecnologia de fabrico dos P4 com HT já não é de 0.18y, mas sim de 0.13y e de 90nm. Eu até acreditaria se os modelos mais recentes sem HT (fabricados já com 0.13micron) possuissem a tecnologia no core, mas desactivada. A utilização de tecnologia de fabrico 0.13y permite não só aumentar a escala de integração mas também reduzir o consumo e a dissipação. Ora, se o grau de integração é maior, sobra espaço para mais umas coisas, como o HT e a memória extra dos prescott e dos celeron D.
|
| | | | Reparei, mas é sabido que o Pentium4C (130 nm) é um shrink do Pentium4A (180 nm) com mais cache L2. A Intel afirmou-o, não tem razões para mentir nisso e o comportamento do chip é consistente com isso. Também não há a menor informação de que a Intel tenha procedido ao redesenho substancial necessário para acomodar SMT durante a transição de 180 para 130 nm.
E no caso do Pentium4E (90 nm) notou-se a diferença. É um desenho novo, nota-se isso na performance de algum código e já se sabia antes da introdução que não seria apenas um shrink do Pentium4C.
|
| | | | Pá é o que da! tens o freebsd 9.0 e nem sequer me dizes nada, ando eu aqui a refilar contra parede e o 5.3 e tu ai com essa bomba nas mãos... es o gajo lixado de sempre ;).
Ao Orgulho segue-se a ruína, e a arrogância vem antes da queda (Prov. 16:18) |
| | | | É realmente asqueroso, tão asqueroso que até nem corre nestas máquinas: O que vale é que cagar postas de pescada é fácil. Justificar afirmações escabrosas com factos é que é complicado.
--
Carlos Rodrigues
|
| | | | Em relação aos Altix, bem, é interessante ver aplicações SMP massivas baseadas em tecnologia Intel. O linux corre nisso sem patches? Se sacar um vanilla kernel aquilo funciona?
Em relação aos servers IBM, penso que o linux não funciona como host SO, apenas como imagem de execução - corrijam-me se estiver errado.
|
| | | | O linux corre nisso sem patches? Se sacar um vanilla kernel aquilo funciona?
Quase nada funciona com apenas o kernel vanilla, porque os patches que não sejam claramente benéficos para toda a gente precisam primeiro de ser justificados no mundo real antes de o Linus os aprovar. O próprio Linus já está farto de insistir que o kernel dele é apenas uma referência e não deve ser encarado como um substituto dos vendor kernels.
No entanto, parece que o kernel do Fedora (e o resto da distribuição), pelo menos, corre .
Mas sejam quais forem os patches necessários, não serão de certeza patches muito intrusivos, já que o kernel vanilla tem praticamente tudo aquilo que é necessário (a começar pelo suporte NUMA).
Nos mainframes da IBM penso que só corre mesmo como imagem de execução sim, mas o AIX é a mesma coisa, segundo sei. E isso não quer dizer que não tenha de suportar SMP na mesma.
Mas isto é completamente lateral, pois o que interessa é que o Linux está a correr nestas máquinas, e os utilizadores (administradores) não precisam andar a aplicar patches obscuros para o fazer. O Altix vem com uma versão, modificada pela SGI, do RedHat Linux AS (se não me engano) e os mainframes da IBM são suportados com RHEL ou SLES (a FCT até acabou de comprar um zSeries com SLES8).
Mais, a minha (limitada) experiência confirma o que digo, uma vez que até conseguimos espremer alguma performance extra de um Alpha ES40 com 4 CPUs simplesmente mudando-o de Tru64 para Linux.
Portanto, a malta que vem para aqui atirar poias para o ar, criticando aquilo que está farto de demonstrar a sua qualidade em situações reais, tem de se esforçar bastante para arranjar argumentos que apoiem as suas afirmações.
--
Carlos Rodrigues
|
| | | | Notas várias:
A SGI suporta uma versão de RH modificada ou SUSE normal para IA-64. Eles aplicam alguns patches, mas não muitos. Pelo que sei, a maioria são backports de coisas já existentes nos 2.6.x (e eles parecem ansiosos que o 2.6 esteja num ponto que o possam mandar aos clientes).
Nos zSeries, o Linux corre tanto em LPARs como em VM, mas VM é a forma preferida. E o AIX não corre em zSeries. Devem estar a confundir com os iSeries.
|
| | | | *cof*
Nativo, LPAR, VM e "Virtual Image Facility", seja lá o que isso for.
|
| | | | E o AIX não corre em zSeries. Devem estar a confundir com os iSeries.
Oops. Tens razão.
--
Carlos Rodrigues
|
| | | | "Se sacar um vanilla kernel aquilo funciona? " Se não funcionar, recompila-se o kernel. O kernel é feito de propósito para ser compilado, recompilado e voltado a compilar. Se instalares uma máquina Linux e nunca lhe recompilares o kernel, a máquina fica triste.
Venho portanto lançar uma campanha para "kernel-recompilation-awareness". Não é difícil (embora demore um bocado em CPUs de galinheira), e o sistema fica feliz da vida.
Smith: "Why, Mr. Anderson, why do you persist?" - Neo: "Because I choose to." |
| | | | Vou tentar te explicar... é que parte da malta que aqui frequenta o burgo esperam que aquilo em que confiam como seus instrumentos de trabalho funcione logo a partida sem ter que andar a dar marteladas a torto e a direito...
Mas prontos é uma mania que essa gente tem de usar coisas que funcionam sem precisar de agua benta em cima e com a percentagem de sorte, ousadia natural...
Enfim não percebo.
Ao Orgulho segue-se a ruína, e a arrogância vem antes da queda (Prov. 16:18) |
| | | | estava eu aki a passear e eis que deparo com uma situação... Vocês axam, que um final user como eu quer saber de compilações????????
Para isso, uso, por exemplo gentoo, não).
Axam que devo andar a compilar kerneis à bruta e não usar os debian kerneis, com tudo em modulos, que detectam todo o hardware, ou cada vez que mudo de hardware tenho k recompilar o kernel?
Cumps-
Gass |
| | | | É uma questão de gosto pessoal, eu pessoalmente acho que é mais macho recompilar o kernel, o sistema fica um verdadeiro sistema com tomates em vez de um sistema José Castelo Branco ai-não-me-recompiles-que-me-desafinas.
Não estou a dizer que recompilar o kernel é absolutamente necessário, é realmente uma questão de gosto.
Smith: "Why, Mr. Anderson, why do you persist?" - Neo: "Because I choose to." |
| | | | A questão é... ~em sequer precisar dos pozinhos mágicos.. get it?
Out of box ready for work. É isso que a malta do mac donalds gosta e eu tb.
Não se poem aqui em causa a habilidade pessoal e masoquista de ninguem.
Ao Orgulho segue-se a ruína, e a arrogância vem antes da queda (Prov. 16:18) |
| | | | uh? deves estar a confundir expressões tu... kernel vanilla -> kernel do kernel.org, sem patches...
duh, se nao recompilas o kernel és urso porque provavelmente não tens la merdas que precisas (tipo suporte pra raids da serverworks por exemplo) ou tens lixo que nunca mais usar na vida...
e falam-me a mim de postas de pescada...
|
| | | | la la la la só vi a resposta agora, se calhar já nem vais ler isto, mas como o Ancestor disse, vanilla kernel?
pois, patches há muitos, mas estava a falar de linux, tás a ver? tipo aquele que se saca em kernel.org? tás a ver?
e sim, eu sei bem que no top500 uma grande percentagem das maquinas corre linux...quer dizer, linux? não, correm versões adulteradas... e refiro-me a patches mesmo ao proprio code de SMP... blah! fuck that, BSD nao precisa disso...
postas de pescada? pah, com a tua resposta, meu deus... dou graças à circunstancia por não me ter proporcionado ler a resposta antes, assim só desperdiço uma gargalhada com ela...
|
| |
|
