Porque os programas não usam 100% de uma CPU multinuclear?

[engenheiro_ce]

Tópico dedicado ao debate sobre a utilização dos diversos cores pelos programas em uma CPU multinuclear.

[Visitante]

E o suposto ganho de desempenho parece não se tratar de desempenho single-threaded, já que cada núcleo é independente e a AMD está falando em maior "throughput", o que indica que para obter tais ganhos você precisa "otimizar" seu software para multi-cores e que provavelmente os programas não-otimizados (os programas single-threaded, a grande maioria) não vão se beneficiar tanto do novo design da AMD, assim como eles não se beneficiam do HT da Intel, exceto no quesito multitarefa.

[]'s

DT

[Altamir Gomes]

E o suposto ganho de desempenho parece não se tratar de desempenho single-threaded, já que cada núcleo é independente e a AMD está falando em maior "throughput", o que indica que para obter tais ganhos você precisa "otimizar" seu software para multi-cores e que provavelmente os programas não-otimizados (os programas single-threaded, a grande maioria) não vão se beneficiar tanto do novo design da AMD, assim como eles não se beneficiam do HT da Intel, exceto no quesito multitarefa.

[]'s

DT

A maioria dos programas continua monoprocessada, porém é desenvolvida em linguagens como Java, C# etc. (código gerenciado). Bastaria atualizar a máquina virtual para apresentar um ganho de desempenho ao rodar nos multi-núcleos. Algo semelhante deve ocorrer com os aplicativos DirectX: ao referenciar as funções da próxima API (versão 11) o ganho de performance com multiprocessamento será automático.

Outro fator importante é que as aquisições dos equipamentos topo de linha é feita por quem tem o costume de "marretar" tarefas na CPU, se beneficiando do multiprocessamento. Tal usuário não pode ver a máquina indo rápido-e-rasteiro que acaba acometido por um comichão e começa a instalar cada vez mais tralhas no HDD, no plano de fundo e nos serviços do Windows (risos).

Sobre a correlação entre o cluster de inteiros adicional e o uso de área, segundo a AMD, o Bulldozer usa 5% a mais no die e 12% em cada módulo. As unidades de execução sem o cluster adicional ocuparão 89% de um módulo e (provavelmente) quatro núcleos junto à ponte norte (com o cache L3) ocuparão 95% de um die. Fazendo as contas, leva-se a crer que o uncore (ponte norte mais o L3) ocupará sozinho cerca de 60% do die num Bulldozer octa-nuclear.

[Visitante]

A maioria dos programas continua monoprocessada, porém é desenvolvida em linguagens como Java, C# etc. (código gerenciado). Bastaria atualizar a máquina virtual para apresentar um ganho de desempenho ao rodar nos multi-núcleos. Algo semelhante deve ocorrer com os aplicativos DirectX: ao referenciar as funções da próxima API (versão 11) o ganho de performance com multiprocessamento será automático.

Não existe ainda um método capaz de paralelizar qualquer algoritmo caso ele seja sequencial. Se o seu problema não tem granularidade suficiente então não importa a linguagem em que ele foi descrito. Se fosse simples assim já teria sido feito a muito tempo.

Com DirectX o problema é mais simples já que o assunto em questão são gráficos.

Sobre a correlação entre o cluster de inteiros adicional e o uso de área, segundo a AMD, o Bulldozer usa 5% a mais no die e 12% em cada módulo. As unidades de execução sem o cluster adicional ocuparão 89% de um módulo e (provavelmente) quatro núcleos junto à ponte norte (com o cache L3) ocuparão 95% de um die. Fazendo as contas, leva-se a crer que o uncore (ponte norte mais o L3) ocupará sozinho cerca de 60% do die num Bulldozer octa-nuclear.

Tem um link?

[]'s

DT

[Altamir Gomes]

Não existe ainda um método capaz de paralelizar qualquer algoritmo caso ele seja sequencial. Se o seu problema não tem granularidade suficiente então não importa a linguagem em que ele foi descrito. Se fosse simples assim já teria sido feito a muito tempo.

Com DirectX o problema é mais simples já que o assunto em questão são gráficos.

Não foi feito antes por questões de investimento ($$$), ROI (Return-On-Investiment), preparação de baterias exaustivas de testes e depuração do código (tempo) e não devido a uma impossibilidade de paralelizar. De acordo com a Lei de Amdahl, a parcela intrinsecamente serial do código se torna um entrave sério contra a prática da paralelização a partir de cem núcleos de processamento conjunto, algo ainda distante da nossa realidade. A tendência atual é concentrar todos os esforços possíveis no desenvolvimento das máquinas virtuais e otimizá-las para a geração multi-núcleos — coisa cara, dispendiosa e demorada — e descarregar nelas a tarefa de adivinhar quais partes do aplicativo podem rodar em paralelo e de reordenar as seqüências de operações, livrando os programadores de aplicativos desse trabalho adicional.

A ideia é justamente jogar a bomba nas mãos dos especialistas e auxiliar aqueles cientistas da computação que são leigos nesta questão específica.

Uma camada JIT (Just-In-Time) é capaz de adaptar o código de acordo com as características do hardware onde está sendo rodado, explorando inclusive as possibilidades de multiprocessamento simétrico. Os jogos da id desde o Quake (id Tech 3) são um bom exemplo disso.

Tem um link?

[]'s

DT

No blog da AMD, entrada do John Fruehe:

The Bulldozer architecture can provide up to 80% greater expected throughput when running 2 threads simultaneously compared to a single thread running on a single integer core. Our engineers estimate that the amount of discrete circuitry that is added to each Bulldozer module in order to allow for a second integer thread to run only adds ~12% additional circuitry to each module, which translates into only ~5% of circuitry to the total Bulldozer die.

http://blogs.amd.com/work/2009/12/11/aiming-for-the-sweet-spot-in-2010-and-beyond/

[Visitante]

Não foi feito antes por questões de investimento ($$$), ROI (Return-On-Investiment), preparação de baterias exaustivas de testes e depuração do código (tempo) e não devido a uma impossibilidade de paralelizar. De acordo com a Lei de Amdahl, a parcela intrinsecamente serial do código se torna um entrave sério contra a prática da paralelização a partir de cem núcleos de processamento conjunto, algo ainda distante da nossa realidade. A tendência atual é concentrar todos os esforços possíveis no desenvolvimento das máquinas virtuais e otimizá-las para a geração multi-núcleos — coisa cara, dispendiosa e demorada — e descarregar nelas a tarefa de adivinhar quais partes do aplicativo podem rodar em paralelo e de reordenar as seqüências de operações, livrando os programadores de aplicativos desse trabalho adicional.

É só olhar os problemas de sistemas como os da Multiflow ou mais recentemente o IPF e seus compiladores "adivinhões" ou "mágicos" para ver que isso já foi tentado antes e que falta ou retorno de investimento, "baterias exaustivas de testes" e lei de Amdahl não tem nada a ver com o caso. Décadas e muitos bilhões de dólares já foram gastos. Computação paralela não surgiu em CPUs para desktop, mas existe a muito tempo e era pesquisada por (e para) empresas e governos que nem sequer tinham que se preocupar com preços, ROI e custo dos testes.

Não foi feito antes porque ainda é impossível. É o programador que tem que analisar o algoritmo dele e achar um jeito de paralelizar (dividir o algoritmo em partes independentes e coerentes), o fato do programa estar numa máquina virtual não muda isso, e existem casos quase impossíveis de paralelizar. E quando (ou se) o programador fizer isso o algoritmo paralelo na maioria das vezes será bem diferente do sequencial, e isso é algo que programas não conseguem fazer (e muito menos fazer tão bem a ponto de sequer ser necessário citar lei de Amdahl). Programas podem ser bons para otimizar principalmente código single-threaded , como fazem compiladores ou os JITs que você mencionou (mas o risco de incompatibilidade é seu), mas para paralelizar o melhor, de longe, ainda é o cérebro do programador.

A ideia é justamente jogar a bomba nas mãos dos especialistas e auxiliar aqueles cientistas da computação que são leigos nesta questão específica.

Uma camada JIT (Just-In-Time) é capaz de adaptar o código de acordo com as características do hardware onde está sendo rodado, explorando inclusive as possibilidades de multiprocessamento simétrico. Os jogos da id desde o Quake (id Tech 3) são um bom exemplo disso.

Um JIT não é capaz de paralelizar qualquer código.

Jogos como Quake são um bom exemplo de como o programa pode usar mais de um núcleo se o programador projetou e escreveu dessa forma. E como sempre, boa parte dos jogos são gráficos, que são bem paralelizáveis (e onde VLIW e JITs fazem sentido, como nas Radeons), o que facilita a vida de programadores de jogos. Já outros programadores não têm tanta sorte.

Sistemas multiprocessados e VGAs de hoje e de ontem têm números variáveis de núcleos e pipelines, mas todas elas, independente da versão do directX, são utilizadas com boa eficiência porque o sistema de gráficos 3D usado nos jogos de hoje foi feito a décadas atrás pela SGI para ser paralelizável. Gráficos 3D convencionais são fáceis de paralelizar e por isso "não contam".

No blog da AMD, entrada do John Fruehe:

Ele só diz que para se possibilitar a execução de um segundo thread int é preciso 12% a mais de circuitaria no módulo (ou 5% considerando todo o processador).

[]'s

DT

[Altamir Gomes]

É só olhar os problemas de sistemas como os da Multiflow ou mais recentemente o IPF e seus compiladores "adivinhões" ou "mágicos" para ver que isso já foi tentado antes e que falta ou retorno de investimento, "baterias exaustivas de testes" e lei de Amdahl não tem nada a ver com o caso. Décadas e muitos bilhões de dólares já foram gastos. Computação paralela não surgiu em CPUs para desktop, mas existe a muito tempo e era pesquisada por (e para) empresas e governos que nem sequer tinham que se preocupar com preços, ROI e custo dos testes.

Não foi feito antes porque ainda é impossível. É o programador que tem que analisar o algoritmo dele e achar um jeito de paralelizar (dividir o algoritmo em partes independentes e coerentes), o fato do programa estar numa máquina virtual não muda isso, e existem casos quase impossíveis de paralelizar. E quando (ou se) o programador fizer isso o algoritmo paralelo na maioria das vezes será bem diferente do sequencial, e isso é algo que programas não conseguem fazer (e muito menos fazer tão bem a ponto de sequer ser necessário citar lei de Amdahl). Programas podem ser bons para otimizar principalmente código single-threaded , como fazem compiladores ou os JITs que você mencionou (mas o risco de incompatibilidade é seu), mas para paralelizar o melhor, de longe, ainda é o cérebro do programador.

Você está trocando as bolas. O problema da IPF com relação à performance não tem nada a ver com os compiladores para EPIC/IA64 mas origina de uma deficiência na velocidade de execução de programas x86/IA32. Em termos de performance de pico, a IPF foi líder em benchmark da indústria durante anos seguidos, portanto a sua crítica aqui não faz sentido algum.

O que está matando a performance dos multi-núcleos é que a esmagadora maioria dos cientistas e engenheiros saem da universidade não tendo sequer noção de como paralelizar um aplicativo. A partir desta questão nasceram as iniciativas OpenMP e Intel Threading Building Blocks. Todos os compiladores de ponta da indústria, como o Open64, PGI, ICC, Sun Studio etc. já têm implementados flags de paralelização automática do código. Paralelização automática significa, com toda a certeza, que não é impossível transferir todo o trabalho de paralelização do programador humano para a máquina.

Um JIT não é capaz de paralelizar qualquer código.

Jogos como Quake são um bom exemplo de como o programa pode usar mais de um núcleo se o programador projetou e escreveu dessa forma. E como sempre, boa parte dos jogos são gráficos, que são bem paralelizáveis (e onde VLIW e JITs fazem sentido, como nas Radeons), o que facilita a vida de programadores de jogos. Já outros programadores não têm tanta sorte.

Sistemas multiprocessados e VGAs de hoje e de ontem têm números variáveis de núcleos e pipelines, mas todas elas, independente da versão do directX, são utilizadas com boa eficiência porque o sistema de gráficos 3D usado nos jogos de hoje foi feito a décadas atrás pela SGI para ser paralelizável. Gráficos 3D convencionais são fáceis de paralelizar e por isso "não contam".

JIT melhora a performance na medida do possível. A intenção não é a de fazer milagres, tal diz o adágio: melhor um pássaro na mão...

A implementação do multiprocessamento nos binários executáveis dos jogos para PC tem mais a ver com coisas do gênero de processamento de física e colisões, inteligência artificial e suporte a multiplayer online massivo. Os drivers de vídeo com suporte a 3D desde sempre paralelizaram usando JIT numa camada abstraída do programa principal que comanda cada jogo. Ainda, as GPUs retiram a carga de processamento gráfico de cima do processador central, o que significa obviamente que este fica livre para realizar outras tarefas não-relacionadas ao processamento gráfico. O DirectX 10 descentraliza ainda mais o processamento. E o caminho daqui para frente é esse aí mesmo, não há volta.

Ele só diz que para se possibilitar a execução de um segundo thread int é preciso 12% a mais de circuitaria no módulo (ou 5% considerando todo o processador).

[]'s

DT

Correto. O resto foi extraído aplicando-se matemática elementar.

[johannesrs]

Pequeno detalhe: todo e qq curso das próprias desenvolvedoras dos compiladores, ou se tu falar com os próprios desenvolvedores dos mesmos, eles vão te dizer o adágio óbvio: "funciona, mas não é tão bom quanto o que tu pode obter a mão".

Ou seja:

Paralelização automática significa, com toda a certeza, que não é impossível transferir todo o trabalho de paralelização do programador humano para a máquina.

Errado. Na verdade, isso significa que "não é impossível transferir PARTE pelo menos do trabalho"! O todo exigira um domínio extremo de inteligência artificial.

Um programa feito da forma mais serial possível, sem o mínimo de atenção à paralelização, dificilmente vai ter na sua cadeia "hot spots" que o compilador possa reconhecer e dizer "aqui dá pra paralelizar alguma coisa". E um programa feito com a intenção de ser paralelizável, nem que seja para ser reconhecido como paralelizável por um compilador automatizado pra isso, exige que o programador pense de uma forma diferente. Logo, aqui não é "deus ex machina", a máquina ajuda, mas os neurônios ainda somos nós quem queimamos.

E, como o Thiago bem lembrou: tu acha que se houvesse outra forma, tão óbvia, já não teria sido inventada? Tipo, tu acha que quem fica nos laboratórios da Sandia, simulando funcionamento de disco-voador e bomba atômica, não tem GRANA pra ficar testando isso? Acredite, infelizmente, eles TEM.

[Altamir Gomes]

Pequeno detalhe: todo e qq curso das próprias desenvolvedoras dos compiladores, ou se tu falar com os próprios desenvolvedores dos mesmos, eles vão te dizer o adágio óbvio: "funciona, mas não é tão bom quanto o que tu pode obter a mão".

Ou seja:

Errado. Na verdade, isso significa que "não é impossível transferir PARTE pelo menos do trabalho"! O todo exigira um domínio extremo de inteligência artificial.

Um programa feito da forma mais serial possível, sem o mínimo de atenção à paralelização, dificilmente vai ter na sua cadeia "hot spots" que o compilador possa reconhecer e dizer "aqui dá pra paralelizar alguma coisa". E um programa feito com a intenção de ser paralelizável, nem que seja para ser reconhecido como paralelizável por um compilador automatizado pra isso, exige que o programador pense de uma forma diferente. Logo, aqui não é "deus ex machina", a máquina ajuda, mas os neurônios ainda somos nós quem queimamos.

E, como o Thiago bem lembrou: tu acha que se houvesse outra forma, tão óbvia, já não teria sido inventada? Tipo, tu acha que quem fica nos laboratórios da Sandia, simulando funcionamento de disco-voador e bomba atômica, não tem GRANA pra ficar testando isso? Acredite, infelizmente, eles TEM.

Depende da filosofia de trabalho do programador. A maioria prefere deixar todo o trabalho de otimização para o compilador ou interpretador for just enough results. Por outro lado, alguns — de fato, bem poucos — se dão o trabalho de otimizar o código "no braço" até extrair a última gota de desempenho. O que eu descrevi aplica-se perfeitamente à maioria.

Como já disse, as iniciativas de paralelização automática estão aí para quem quiser conferir. Se esta é a melhor alternativa trata-se d'outra questão.

[Visitante]

Você está trocando as bolas. O problema da IPF com relação à performance não tem nada a ver com os compiladores para EPIC/IA64 mas origina de uma deficiência na velocidade de execução de programas x86/IA32. Em termos de performance de pico, a IPF foi líder em benchmark da indústria durante anos seguidos, portanto a sua crítica aqui não faz sentido algum.

Você diz que a deficiência de desempenho do IPF no lado IA64 tem a ver a deficiência na execução x86, o que já é contraditório, mas logo em seguida diz que IPF foi líder em benchmarks, o que contradiz a contradição anterior. E o líder de "benchmarks" e no "mundo real" foi o POWER da IBM.

Mas meu ponto ao citar IPF e Multiflow foi para mostrar que a "busca por paralelismo via software" já foi tentada antes de várias formas, já que é a base de ambas essas arquiteturas, que eram ótimas no papel (e nos "benchmarks") mas falharam no mundo real onde os aplicativos não têm paralelismo sobrando, os compiladores não são videntes ou mágicos e o software não chega nem perto de ter as "otimizações" extremas que são permitidas e feitas em benchmarks.

O que está matando a performance dos multi-núcleos é que a esmagadora maioria dos cientistas e engenheiros saem da universidade não tendo sequer noção de como paralelizar um aplicativo. A partir desta questão nasceram as iniciativas OpenMP e Intel Threading Building Blocks. Todos os compiladores de ponta da indústria, como o Open64, PGI, ICC, Sun Studio etc. já têm implementados flags de paralelização automática do código. Paralelização automática significa, com toda a certeza, que não é impossível transferir todo o trabalho de paralelização do programador humano para a máquina.

Difícil ensinar na faculdade se os professores não sabem resolver o problema. Ainda mais difícil é um compilador paralelizar um problema sequencial apenas por causa de uma flag na hora da compilação. Compilar o Visicalc ou uma versão antiga do Photoshop em um compilador moderno não vai fazer as partes do programa rodarem em paralelo já que o programa não foi projetado para isso. Uma flag no compilador não muda nada. Programação paralela até o momento (e sem previsão de mudança) é muito mais uma questão algorítmica do que uma questão de otimização bruta via software, e só o programador consegue entender o algoritmo.

A implementação do multiprocessamento nos binários executáveis dos jogos para PC tem mais a ver com coisas do gênero de processamento de física e colisões, inteligência artificial e suporte a multiplayer online massivo. Os drivers de vídeo com suporte a 3D desde sempre paralelizaram usando JIT numa camada abstraída do programa principal que comanda cada jogo. Ainda, as GPUs retiram a carga de processamento gráfico de cima do processador central, o que significa obviamente que este fica livre para realizar outras tarefas não-relacionadas ao processamento gráfico. O DirectX 10 descentraliza ainda mais o processamento. E o caminho daqui para frente é esse aí mesmo, não há volta.

E ainda assim tudo o que você descreveu, principalmente a parte não-gráfica, precisa ser feita pelo programador, já que os compiladores são muito primitivos para tal. E é por isso que a grande maioria dos jogos ainda é single-threaded.

[]'s

DT

[Altamir Gomes]

Você diz que a deficiência de desempenho do IPF no lado IA64 tem a ver a deficiência na execução x86, o que já é contraditório, mas logo em seguida diz que IPF foi líder em benchmarks, o que contradiz a contradição anterior. E o líder de "benchmarks" e no "mundo real" foi o POWER da IBM.

Eu não me contradisse em absolutamente nada do que você aponta. Percebo que a cada postagem você se enrola por si só mais e mais e então tenta transferir a sua própria confusão de idéias sobre mim como se fosse eu e não você mesmo o real culpado por estas. Eu no seu lugar procuraria a documentação das ferramentas citadas anteriormente para uma leitura cuidadosa ao invés de ficar refutando e refutando a esmo ad infinitum. Mas pois bem, vamos lá.

O Power da IBM possui ótimo desempenho de multiprocessamento simétrico, o que porém não desqualifica os méritos da IPF. Ambas são plataformas do mais alto desempenho. O problema principal com a IPF é basicamente a falta de base instalada. A primeira razão para isto é que a Intel comparada à IBM é uma novata no setor de servidores de míssão crítica e computação de alta performance e a segunda é que a IPF é uma plataforma RISC que requer a reescrita de toda uma biblioteca de código para atingir seu desempenho ótimo.

Servindo à Intel como alternativa para inserção de sua plataforma no mercado, há uma base instalada de aplicativos x86/IA-32 abrangente. Ficou decidido então que a IPF seria compatível com x86 pelo menos até o momento derradeiro quando a transição para o EPIC/IA-64 completasse. O único entrave aí é o baixo desempenho com aplicativos x86, os quais não tem absolutamente nada a ver com a questão da extração de paralelismo uma vez que estes não haviam sido escritos com isso em mente. É absolutamente impróprio tentar fazer uma comparação do Power rodando código do mais alto desempenho com a IPF rodando x86 e mais ainda usando-os como referencial a fim de dizer-me que não dá para se extrair paralelismo automaticamente. Entendeu agora porque creio que você se confunde tanto?

Não responderei a todo o restante que você escreveu sobre JIT e autoparalelização porque garanto que caso você se der o trabalho de baixar as ferramentas para teste e documentação relacionada já citadas neste tópico e testá-las por si mesmo, chegará por conta própria à conclusão natural que a suposta impossibilidade de se automatizar a paralelização de aplicativos é uma falácia das grandes.

Mas meu ponto ao citar IPF e Multiflow foi para mostrar que a "busca por paralelismo via software" já foi tentada antes de várias formas, já que é a base de ambas essas arquiteturas, que eram ótimas no papel (e nos "benchmarks") mas falharam no mundo real onde os aplicativos não têm paralelismo sobrando, os compiladores não são videntes ou mágicos e o software não chega nem perto de ter as "otimizações" extremas que são permitidas e feitas em benchmarks.

Difícil ensinar na faculdade se os professores não sabem resolver o problema. Ainda mais difícil é um compilador paralelizar um problema sequencial apenas por causa de uma flag na hora da compilação. Compilar o Visicalc ou uma versão antiga do Photoshop em um compilador moderno não vai fazer as partes do programa rodarem em paralelo já que o programa não foi projetado para isso. Uma flag no compilador não muda nada. Programação paralela até o momento (e sem previsão de mudança) é muito mais uma questão algorítmica do que uma questão de otimização bruta via software, e só o programador consegue entender o algoritmo.

E ainda assim tudo o que você descreveu, principalmente a parte não-gráfica, precisa ser feita pelo programador, já que os compiladores são muito primitivos para tal. E é por isso que a grande maioria dos jogos ainda é single-threaded.

[]'s

DT

[johannesrs]

Altamir, tu me desculpa, mas tu no mínimo tá se expressando mal.

Olha só, duas frases retiradas diretamente de posts anteriores:

"O único entrave aí é o baixo desempenho com aplicativos x86, os quais não tem absolutamente nada a ver com a questão da extração de paralelismo uma vez que estes não haviam sido escritos com isso em mente."

"Depende da filosofia de trabalho do programador. A maioria prefere deixar todo o trabalho de otimização para o compilador ou interpretador for just enough results. Por outro lado, alguns — de fato, bem poucos — se dão o trabalho de otimizar o código "no braço" até extrair a última gota de desempenho. O que eu descrevi aplica-se perfeitamente à maioria.

Como já disse, as iniciativas de paralelização automática estão aí para quem quiser conferir. Se esta é a melhor alternativa trata-se d'outra questão."

O fato de ser pra x86, power, ia64, etc, envolve mais questões de ter sido compilado naquela plataforma ou não, e umas coisinhas aqui e ali. Não vou entrar nesse mérito.

Tu percebe que na primeira frase citada, tu diz com todas as letras que "esses programas não foram pensados com paralelização em mente", enquanto que o grosso da tua posição é que "auto-paralelização consegue resultados ótimos, não sendo necessário que o programador programe já pensando em paralelização"?

Na minha língua, as duas frases são contraditórias: ou os autoparalelizadores não conseguem paralelizar sozinhos um código que não foi minimamente pensado em paralelização, porque os seus algorítmos usados pra localizar "hot spots" passíveis de paralelização não vão conseguir mudar o algorítimo a esse ponto mantendo resultado (caso de inteligência artificial avançada estilo terminators e nós *******... ), ou eles conseguem e o programador não precisa ficar nem pensando nisso!

Cara, ou é branco ou é preto ou é cinza. Ou os autoparalelizadores fazem tudo sozinhos em qualquer situação (branco), ou não fazem praticamente nada e o programador tem que fazer tudo a mão (preto), ou, dado que o programador já tenha programado pensando em paralelização, ainda que não tenha colocado os "pragmas" ou as chamadas pras interfaces mpi, ele crie "hot-spots" conscientemente que o compilador consegue usar pra cirar o código paralelo (cinza).

[Altamir Gomes]

Altamir, tu me desculpa, mas tu no mínimo tá se expressando mal.

Olha só, duas frases retiradas diretamente de posts anteriores:

"O único entrave aí é o baixo desempenho com aplicativos x86, os quais não tem absolutamente nada a ver com a questão da extração de paralelismo uma vez que estes não haviam sido escritos com isso em mente."

"Depende da filosofia de trabalho do programador. A maioria prefere deixar todo o trabalho de otimização para o compilador ou interpretador for just enough results. Por outro lado, alguns — de fato, bem poucos — se dão o trabalho de otimizar o código "no braço" até extrair a última gota de desempenho. O que eu descrevi aplica-se perfeitamente à maioria.

Como já disse, as iniciativas de paralelização automática estão aí para quem quiser conferir. Se esta é a melhor alternativa trata-se d'outra questão."

O fato de ser pra x86, power, ia64, etc, envolve mais questões de ter sido compilado naquela plataforma ou não, e umas coisinhas aqui e ali. Não vou entrar nesse mérito.

Tu percebe que na primeira frase citada, tu diz com todas as letras que "esses programas não foram pensados com paralelização em mente", enquanto que o grosso da tua posição é que "auto-paralelização consegue resultados ótimos, não sendo necessário que o programador programe já pensando em paralelização"?

Na minha língua, as duas frases são contraditórias: ou os autoparalelizadores não conseguem paralelizar sozinhos um código que não foi minimamente pensado em paralelização, porque os seus algorítmos usados pra localizar "hot spots" passíveis de paralelização não vão conseguir mudar o algorítimo a esse ponto mantendo resultado (caso de inteligência artificial avançada estilo terminators e nós *******... ), ou eles conseguem e o programador não precisa ficar nem pensando nisso!

Cara, ou é branco ou é preto ou é cinza. Ou os autoparalelizadores fazem tudo sozinhos em qualquer situação (branco), ou não fazem praticamente nada e o programador tem que fazer tudo a mão (preto), ou, dado que o programador já tenha programado pensando em paralelização, ainda que não tenha colocado os "pragmas" ou as chamadas pras interfaces mpi, ele crie "hot-spots" conscientemente que o compilador consegue usar pra cirar o código paralelo (cinza).

Não precisaria nem dizer que esta se trata novamente de uma deficiência na leitura do que eu escrevi, desta vez misturando um parágrafo que pertence ao tempo pretérito (os aplicativos x86 já escritos) com outro que trata do tempo presente e futuro (as iniciativas atuais com olhos para os multi-núcleos).

[johannesrs]

não, Altamir, tu me desculpe novamente, mas não é essa a deficiência aqui.

Olha o meu primeiro post nessa conversa: eu disse que se o programador fizer o trabalho sem nem um MÍNIMO de consideração por paralelização, o compilador não vai conseguir paralelizar. Isso não é meramente o cenário dessas aplicações x86 já compiladas... É o cenário se eu pegar os códigos dessas aplicações x86 do tempo do "êpa" e que realmente foram programadas sem uma linha de pensamento em paralelização, e recompilá-las agora, na bucha, usando todas as flags de auto-paralelização. E te digo que não vai paralelizar nada. Eu não falei de usar os binários, e isso é absolutamente óbvio!

Tu diz o contrário, diz que o progrmador NÃO pŕecisa se preocupar nem o mínimo com programação, que o compilador consegue autoparalelizar sozinho. O que o Dick e eu dissemos (o Dick talvez seja um pouco mais firme e concorde menos ainda com qualquer possibilidade nesse sentido) é que se eu programar com a paralelização em mente, AINDA QUE NÃO A EXPLICITE no programa, um compilador com flags de auto-paralelização ativadas NESTE CASO *PODE* encontrar hot-spots de paralelização e te devolver um código paralelo. Mas, sejamos bem claros: SE o programador fizer o seu trabalho SEM COGITAR PARALELIZAÇÃO POR UM MOMENTO QUE SEJA, o algorítmo será programado de uma forma que NÃO criará "hot spots" pro compilador encontrar e tentar paralelizar, e NÃO vai ser paralelo. Em suma, mesmo pra auto-paralelização obter alguma coisa, o programador tem que ter feito a sua parte. É essa a tecla que eu bato.

Tu agora escolhe: OU o programador TEM que pensar em paralelização, o que tu meio que disfarçou numa "programação em tempo presente futuro", OU o programador NÃO PRECISA pensar nisso DE JEITO NENHUM, e nesse caso não interessa se o código foi escrito pra um eniac, o que seria o cúmulo do "tempo passado", que a auto-paralelização do compilador vai dar conta do recado.

Desculpem se tiver me exaltado, não era a intenção.

[Visitante]

Eu não me contradisse em absolutamente nada do que você aponta. Percebo que a cada postagem você se enrola por si só mais e mais e então tenta transferir a sua própria confusão de idéias sobre mim como se fosse eu e não você mesmo o real culpado por estas.

Eu eu percebo que a cada postagem você tenta desviar o assunto do ponto em questão para coisas como o lado x86 do Itanium, desempenho dos POWER, entre outras coisas que não só não tem nada a ver com o que estava sendo discutido como são simplesmente erradas, como chamar IPF de RISC em vez de VLIW, achar que eu me referia ao lado x86 do Itanium quando era óbvio que eu me referia a paralelização do lado IA64, entre várias outras coisas que mostram que você é mais um gerador de termos aleatórios de informática que não entende o significado dos próprios termos. Se você quer continuar a discussão e insiste para eu olhar a "documentação das ferramentas citadas anteriormente", convém a você mostrar o local exato na "documentação das ferramentas" onde é dito que o compilador paraleliza qualquer código sequencial single-threaded, senão, acho que vou parar de responder a seus posts.

Mas o pior é a frase em negrito que na verdade é uma admissão de que para extrair paralelismo o programa tem que ser feito com isso em mente pelo programador, que mostra que você já cedeu o ponto e não consegue refutar o que foi dito pelo johannesrs e eu, mas ainda assim prefere ficar insistindo em vez de deixar quieto. Mais um motivo para não responder mais a seus posts.

[]'s

DT

[Altamir Gomes]

Pessoal, a coisa está desandando, mas é que isto aqui está virando uma competição ***** por não-sei-o-quê sem consideração alguma pela reflexão tranqüila e concentrada. Lamento o inconveniente.

Se eu continuar a responder tudo o que estão jogando aqui, arrumarão um jeito de discordar para dizer que não era bem aquilo, que escrevi algo contraditório; reclamação a qual não passará de uma distorção intencional ou ignorante resultante de uma comichão de discordar, que não resistiria a um auto-questionamento de cinco minutos. Da minha parte concordo em fazer o seguinte daqui para frente, responder às discordâncias com um mínimo crivo de legitimidade e bom-senso, ignorando as outras em definitivo.

não, Altamir, tu me desculpe novamente, mas não é essa a deficiência aqui.

Trata-de disso sim senhor. Caso você tivesse separado os dois argumentos que citou pelo tempo verbal de cada um a aquela discordância sua estaria agora morta e enterrada.

Olha o meu primeiro post nessa conversa: eu disse que se o programador fizer o trabalho sem nem um MÍNIMO de consideração por paralelização, o compilador não vai conseguir paralelizar. Isso não é meramente o cenário dessas aplicações x86 já compiladas... É o cenário se eu pegar os códigos dessas aplicações x86 do tempo do "êpa" e que realmente foram programadas sem uma linha de pensamento em paralelização, e recompilá-las agora, na bucha, usando todas as flags de auto-paralelização. E te digo que não vai paralelizar nada. Eu não falei de usar os binários, e isso é absolutamente óbvio!

Tu diz o contrário, diz que o progrmador NÃO precisa se preocupar nem o mínimo com programação, que o compilador consegue autoparalelizar sozinho. O que o Dick e eu dissemos (o Dick talvez seja um pouco mais firme e concorde menos ainda com qualquer possibilidade nesse sentido) é que se eu programar com a paralelização em mente, AINDA QUE NÃO A EXPLICITE no programa, um compilador com flags de auto-paralelização ativadas NESTE CASO *PODE* encontrar hot-spots de paralelização e te devolver um código paralelo. Mas, sejamos bem claros: SE o programador fizer o seu trabalho SEM COGITAR PARALELIZAÇÃO POR UM MOMENTO QUE SEJA, o algorítmo será programado de uma forma que NÃO criará "hot spots" pro compilador encontrar e tentar paralelizar, e NÃO vai ser paralelo. Em suma, mesmo pra auto-paralelização obter alguma coisa, o programador tem que ter feito a sua parte. É essa a tecla que eu bato.

Tu agora escolhe: OU o programador TEM que pensar em paralelização, o que tu meio que disfarçou numa "programação em tempo presente futuro", OU o programador NÃO PRECISA pensar nisso DE JEITO NENHUM, e nesse caso não interessa se o código foi escrito pra um eniac, o que seria o cúmulo do "tempo passado", que a auto-paralelização do compilador vai dar conta do recado.

Desculpem se tiver me exaltado, não era a intenção.

A resposta é muito simples, nestes casos específicos pode se tratar de um algoritmo não-paralelizável ou extremamente difícil de se paralelizar. Talvez não valha a pena nem perder tempo e esforços para paralelizar mesmo à mão código dessa natureza.

Eu eu percebo que a cada postagem você tenta desviar o assunto do ponto em questão para coisas como o lado x86 do Itanium, desempenho dos POWER, entre outras coisas que não só não tem nada a ver com o que estava sendo discutido como são simplesmente erradas, como chamar IPF de RISC em vez de VLIW, achar que eu me referia ao lado x86 do Itanium quando era óbvio que eu me referia a paralelização do lado IA64, entre várias outras coisas que mostram que você é mais um gerador de termos aleatórios de informática que não entende o significado dos próprios termos. Se você quer continuar a discussão e insiste para eu olhar a "documentação das ferramentas citadas anteriormente", convém a você mostrar o local exato na "documentação das ferramentas" onde é dito que o compilador paraleliza qualquer código sequencial single-threaded, senão, acho que vou parar de responder a seus posts.

O que você escreveu lá não estava óbvio de maneira alguma porque eu tive o trabalho de completar o seu raciocínio manco e ainda por cima me acusa de distorcer o que você escreveu. Onde, logo atrás, você especificou estar mencionando código x86 ou EPIC? Também não especifica quais aplicações do "mundo real" não ganham desempenho sob IPF quando otimizadas especificamente para essa arquitetura.

Outra coisa, não está errado dizer que IPF é RISC e nem está errado dizer que é VLIW porque o EPIC/IA-64 é uma síntese de ambas filosofias. Aconselho a leitura deste artigo do prof. Sérgio Bampi.

http://www.ee.furg.br/~silviacb/arquitetura2/ia64P.html

Mas o pior é a frase em negrito que na verdade é uma admissão de que para extrair paralelismo o programa tem que ser feito com isso em mente pelo programador, que mostra que você já cedeu o ponto e não consegue refutar o que foi dito pelo johannesrs e eu, mas ainda assim prefere ficar insistindo em vez de deixar quieto. Mais um motivo para não responder mais a seus posts.

[]'s

DT

Análise completamente eqüivocada e desprovida de racionalidade. O próprio ato de se adicionar uma flag de autoparalelização à linha de comando do compilador implica numa preocupação da parte do programador com a extração de paralelismo. Só falta você refutar até mesmo esta demonstração trivial de lógica. Se você estiver com tal ideia absurda em mente peço encarecidamente que não me responda e guarde-a para si mesmo, livrando assim os leitores dessa importunação.

[Visitante]

Onde, logo atrás, você especificou estar mencionando código x86 ou EPIC? Também não especifica quais aplicações do "mundo real" não ganham desempenho sob IPF quando otimizadas especificamente para essa arquitetura.

Amigo, quem em sã consciência se importa com desempenho x86 do Itanium, que nem sequer tem mais a unidade de execução x86 a algumas gerações? Quem é ***** a ponto de comprar um servidor IPF para rodar programas x86?

Se eu citei Multiflow então é mais que óbvio que eu me refiro a ISA IA64 do Itanium, já que paralelismo ajudado via software é a base de ambas essas arquiteturas. Se eu estivesse falando em x86 eu obviamente citaria um Nehalem ou Phenom. O fato de algo tão evidente ter passado desapercebido é incrível para dizer o mínimo. O meu ponto, que você insiste em desviar ou ignorar, é que essas arquiteturas já tentaram expor paralelismo via software e falharam (o que não é mencionado no seu link já que ele foi escrito a dez anos atrás), porque paralelização ainda vem do programador e é difícil.

E por mundo real eu obviamente me refiro a qualquer software comercial que não é um benchmark, já que a maioria dos benchmarks é ultra-otimizada pelos compiladores usando técnicas que não são usadas em software comercial por causa de estabilidade e facilidade de debug. E como "otimização" via software é a base do IPF atual, ele tem uma perda maior de desempenho entre benchmarks ultra-otimizados e software comercial do que os CPUs concorrentes.

Análise completamente eqüivocada e desprovida de racionalidade. O próprio ato de se adicionar uma flag de autoparalelização à linha de comando do compilador implica numa preocupação da parte do programador com a extração de paralelismo. Só falta você refutar até mesmo esta demonstração trivial de lógica. Se você estiver com tal ideia absurda em mente peço encarecidamente que não me responda e guarde-a para si mesmo, livrando assim os leitores dessa importunação.

Como já foi dito antes, o programador pode ser super-preocupado com paralelismo, mas se tudo o que ele fez foi adicionar uma flag na hora da compilação do problema serial dele o problema vai continuar sendo serial.

[]'s

DT

[Dragum]

vocês são advogados que treinam no forum? hehe... cada um com seu PONTO DE VISTA e a história mostrará quem está certo: MT será geral ou só com ajuda -talvez muita- do programador?

na minha humilde opinião, vamos ter uma nova forma de escrever algoritmos complexos que tornará o MT muito mais comum... é a tendência: expansão paralela, pois a barreira do silício ta cada vez mais na ponta do nariz.

[Visitante]

trabanom - proprietário do tópico.

Nossa, quem sou eu para discutir com o "proprietário do tópico".

Vou fundar o MST então, o Movimento dos Sem Tópicos.

na minha humilde opinião, vamos ter uma nova forma de escrever algoritmos complexos que tornará o MT muito mais comum... é a tendência: expansão paralela, pois a barreira do silício ta cada vez mais na ponta do nariz.

A questão é quanto tempo ainda vai levar para isso acontecer.

[]'s

DT

[johannesrs]

Altamir, discordo. Não vou mais discutir, porque pra mim tu tá em contradição clara. Novamente, retorna-se ao ponto em que o programador teve que ter pelo menos em parte paralelização em mente pra autoparalelização funcionar, que é o que eu disse desde o começo, é o oposto do que tu disse no princípio, e principalmente tu agora repete na penúltima frase do teu último post na página anterior.

Ademais: esse DBST deve equilibrar muito as coisas! Mas ficou meio que não-entendido no texto se ele viria pros X4... O texto diz q não viriam (já que ele defende que só com 6 cores isso se tornaria possível?), mas eu acho que pelos novos X4 serem "T" também eles virão com!

P.S.: concordo que o assunto já deu o q tinha que dar, mas gostaria de fazer uma ressalva aqui: existem opiniões, e existem fatos. Os fatos são inquebráveis (podem no máximo serem completados). No caso o fato é "no momento, uma programação feita com a mente focada em serial resulta num algoritimo suficientemente diferente do algoritmo para a mesma tarefa em paralelo que os programas de compilação não conseguem encontrar 'hot spots' de paralelização para explorar e tornar o programa paralelo". A minha opinião é "e isso vai continuar sendo assim, só podendo se extrair alguma paralelização do código com uma programação pelo menos em parte voltada para a paralelização, pelo menos até a Inteligência Artificial avançar horrores ao ponto de colocar a nossa sobrevivência em sério risco". Pegar um fato, usar muito latim e fazer parecer outra coisa, é mania de filósofo. Eu sou um cientista, se quer derrubar a minha hipótese/teoria que é baseada num grupo de fatos, venha com novos fatos que contradigam a minha hipótese/teoria, e que possam ser amplamente replicados.

[Altamir Gomes]

Parece mesmo que adivinhei na mosca o que os dois rapazes fariam: não compreenderam absolutamente nada do que eu disse deixando à mostra a parcela de inépcia de cada um. As informações nas últimas postagens de johannesrs e Dick Trace estão realmente imprecisas, bagunçadas e conflitivas.

Dick Trace estica meus argumentos, balança de um lado ao outro impingindo sentidos e significados os quais jamais intencionei, tal como imputar a mim o mérito de dizer que a paralelização automática resolveria todos os problemas e, como se já não bastasse, metralha a todo momento que estou equivocado em alguma coisa mas limita-se ao achismo e não apresenta uma página sequer que o corrobore e tampouco manifesta qualquer intenção empírica de acessar o material que lhe recomendei. johannesrs tem uma certa dificuldade de leitura e acabou embaralhando todas as respostas as quais se compreendidas responderiam de imediato a todos os questionamentos que ele levantou.

Foram eles mesmos que criaram sozinhos toda a confusão em torno de algo que na minha opinião e de outros que conversaram comigo sem criar tantos problemas está suficientemente claro e em bom Português.

Concordo com o trabanom que esta discussão já passou dos limites e tornou-se uma rinha infantil e chata. Para piorar tudo o par simplesmente não aceita ser contrariado e tornou-se cego ao mais banal dos esclarecimentos, como se a cada resposta dada eu retirasse o doce de suas bocas e o choro os impedisse de entender as coisas com clareza.

Para os dois, caso ainda queiram que eu responda às suas questões ao invés de ficarem aprontando bagunça, que larguem esse espontaneísmo infantilizado e façam um tópico analisado com serenidade, bem-estruturado, limpo, compreensível, e detalhem ponto-a-ponto onde exatamente estou errado. Por enquanto, passar bem.

[engenheiro_ce]

Tópico dedicado para o debate aberto.

[ThiagoLCK]

A maioria dos programas continua monoprocessada, porém é desenvolvida em linguagens como Java, C# etc. (código gerenciado). Bastaria atualizar a máquina virtual para apresentar um ganho de desempenho ao rodar nos multi-núcleos.

O ICC gasta uma porrada de tempo e processamento fazendo auto-paralelização, que mesmo assim é utilizada com sucesso em poucas situações. Aliás, só sei de uso similar no Spec.

Algo semelhante deve ocorrer com os aplicativos DirectX: ao referenciar as funções da próxima API (versão 11) o ganho de performance com multiprocessamento será automático.

Isso se as funções forem otimizadas para multiprocessamento e rodarem no processador. De qualquer modo, duvido que o ganho seja relevante.

Você está trocando as bolas. O problema da IPF com relação à performance não tem nada a ver com os compiladores para EPIC/IA64 mas origina de uma deficiência na velocidade de execução de programas x86/IA32.

Besteira. O Itanium Merced sempre foi lento em qualquer porcaria exceto alguns código de ponto flutuante, em que ele liderou durante pouco tempo. O McKinley não conta, porque os mais rápidos sofreram recall, mas de qualquer modo ele e o Madison foram os únicos Itaniums a apresentar boa performance por algum tempo significativo. Montecito e Montvale foram decepcionantes. Tudo isso trata de performance IA64. Não falo da performance da unidade de compatibilidade IA32 porque não consigo parar de rir cada vez que a vejo.

Em termos de performance de pico, a IPF foi líder em benchmark da indústria durante anos seguidos, portanto a sua crítica aqui não faz sentido algum.

Parabéns pela vagueza cuidadosa, é a única forma de conseguir fazer a IPF parecer boa!

Todos os compiladores de ponta da indústria, como o Open64, PGI, ICC, Sun Studio etc. já têm implementados flags de paralelização automática do código.

Compiladores pouco usados fora de áreas específicas de computação facilmente paralelizável com flags pouquíssimo usadas na prática...

Paralelização automática significa, com toda a certeza, que não é impossível transferir todo o trabalho de paralelização do programador humano para a máquina.

Sim, e essa função é muito usada no Spec. O trabalho para usá-la em outros casos não compensa seus benefícios. É melhor ter trabalho para paralelizar.

A primeira razão para isto é que a Intel comparada à IBM é uma novata no setor de servidores de míssão crítica e computação de alta performance

A HP também, imagino...

e a segunda é que a IPF é uma plataforma RISC que requer a reescrita de toda uma biblioteca de código para atingir seu desempenho ótimo.

A POWER, a x86 e todas as outras arquiteturas, CISC, RISC ou VLIW não, imagino...

É absolutamente impróprio tentar fazer uma comparação do Power rodando código do mais alto desempenho com a IPF rodando x86 e mais ainda usando-os como referencial a fim de dizer-me que não dá para se extrair paralelismo automaticamente.

Vejo que você sabe falar muita coisa, mas na verdade não tem a mínima ideia do que está dizendo. Todas as comparações de desempenho entre POWER e IPF foram feitas com código nativo. E a unidade de compatibilidade x86 por hardware da IPF foi abandonada há muito tempo.

Não responderei a todo o restante que você escreveu sobre JIT e autoparalelização porque garanto que caso você se der o trabalho de baixar as ferramentas para teste e documentação relacionada já citadas neste tópico e testá-las por si mesmo, chegará por conta própria à conclusão natural que a suposta impossibilidade de se automatizar a paralelização de aplicativos é uma falácia das grandes.

Qual JIT comercial Java ou .NET tem autoparalelização? Uma coisa é fazer isso com ICC no Spec, outra bem diferente é fazer com uma JVM rodando uma aplicação real em condições normais.

Outra coisa, não está errado dizer que IPF é RISC e nem está errado dizer que é VLIW porque o EPIC/IA-64 é uma síntese de ambas filosofias. Aconselho a leitura deste artigo do prof. Sérgio Bampi.

A IPF é uma arquitetura em que o local das instruções não define completamente o agendamento. Isso a desqualifica como um VLIW segundo algumas definições. Ela é normalmente classificada como RISC, ou VLIW de comprimento variável, ou coisa do tipo. EPIC seria um nome não tão ruim para ambos, VLIWs comuns e IPF, mas a Intel tomou conta do termo.

Análise completamente eqüivocada e desprovida de racionalidade. O próprio ato de se adicionar uma flag de autoparalelização à linha de comando do compilador implica numa preocupação da parte do programador com a extração de paralelismo. Só falta você refutar até mesmo esta demonstração trivial de lógica. Se você estiver com tal ideia absurda em mente peço encarecidamente que não me responda e guarde-a para si mesmo, livrando assim os leitores dessa importunação.

Imagino que para você o cara que compila o programa deva ser exatamente o mesmo que o programou. E imagino também que pra você pessoas não mudem de opinião. E imagino também que na sua visão de mundo ninguém tente usar AutoPar em aplicativos desenvolvidos sem atenção a paralelização.

Espero que ninguém se incomode de eu ressuscitar tal tópico. De qualquer modo, devo esclarecer ao Dick Tracy que o IA64 busca muitas vezes paralelismo de forma mais granulada que um sistema de AutoPar. O que não elimina o argumento de que confiar em compiladores não é muito sábio.

Resumindo:

1- AutoPar existe, não é muito usado fora do Spec, requer bastante tempo e processamento.

2- JITs comerciais de Java e .NET, ao que eu saiba, não usam AutoPar. Aliás, mesmo os compiladores da MS e o GCC não usam.

3- AutoPar não faz milagres, o ganho é imenso em algumas aplicações do Spec, ridículo em outras. E isso depois de anos de trabalho específico em cima dessas aplicações...

[Altamir Gomes]

Complementação dos pontos discutidos aqui dedicada ao Thiago:

Todos os compiladores os quais mencionei são muito utilizados no mercado que requer alta performance, onde o flag-mining e o multiprocessamento são palavras de ordem, apesar de realmente não se tratarem de produtos mainstream. A paralelização automática pelo compilador conforme dito anteriormente não é impossível mas requer um trabalho de pesquisa e desenvolvimento complicado, arriscado, trabalhoso, demorado e amplamente experimental.

Se é melhor ter trabalho para paralelizar código à mão: com certeza não é melhor para os muitos engenheiros e cientistas de software os quais não têm a mínima ideia de como paralelizar um único bloco de código chegando ao ponto de achar que OpenMP é marca de sabão em pó ou coisa similar quando perguntados.

Sobre JIT, Java, .NET e camadas virtuais. Em teoria, é menos complicado implementar paralelização automática numa máquina virtual .NET ou Java uma vez que estas foram feitas com escalonamento para multiprocessadores em mente e com os devidos detalhamentos e padronizações para multi-threading nas suas respectivas especificações.

As seguintes entradas de blog mencionam um futuro sistema operacional Windows multiprocessado super-escalar, o qual será possível graças ao JIT e código gerenciado além da retrocompatibilidade proporcionada pelas máquinas virtuais a la Hyper-V. A Sun está totalmente entregue à era do multi-threading e portanto uma máquina virtual Java com autopar não deve demorar a sair (um papel em 2003 descrevendo como isto poderá ser realizado encontra-se em http://citeseer.ist.psu.edu/664621).

http://www.windowsvienna.com/windows-7-takes-more-advantage-of-multi-core-cpus-a24.html

http://blogs.zdnet.com/microsoft/?p=1477

Quanto ao cerne desta discussão e o desempenho da IPF. Em primeiro lugar o meu foco desde o início não centraliza no desempenho do hardware per se mas na capacidade de um compilador suficientemente treinado e otimizado de extrair paralelismo do código-fonte. Na minha opinião o SPEC serve melhor como um medidor de desempenho do compilador do que da unidade de processamento central, daí meu foco persistente na tecnologia de transformação do código e não nos demais parâmetros.

Supondo que alguém me responda "ah, mas esses caras não jogam limpo, otimizam SPEC até níveis inimagináveis para as outras aplicações". Mesmo assim o SPECCPU é constituído de código real, retirado de aplicações reais, e portanto funciona muito bem para aferição da performance e potencial do compilador mantendo a premissa inabalada. Da parte dos Itanium McKinley defeituosos não os desconsiderarei já que o elementar ao caso que é o paralelismo ao nível das instruções (ILP) não muda com a velocidade de relógio da unidade de processamento central, salvo pequenas diferenças ocasionadas pela latência de memória e dos dispositivos de entrada-saída.

A experiência da HP com desenvolvimento de unidades de processamento central vai até o PA-RISC e a IPF veio depois pelas mãos da Intel. Esta última passou o projeto Merced para suas equipes de engenheiros novatos (e que segundo relatos dos veteranos da empresa tratavam-se mesmo de novatos, daqueles engenheiros que acabaram de sair frescos da universidade). O relacionamento entre as duas empresas neste espectro limita-se ao backing da HP para a produção de servidores Itanium e em troca a Intel desenvolve a IPF para consumo pela clientela PA-RISC da HP. A experiência da HP se aplica aos chipsets e circuitos de apoio enquanto que toda responsabilidade relacionada com a lógica interna das unidades centrais de missão crítica encontra-se nas costas da Intel.

A Intel possui dez anos de experiência nessa área enquanto que a IBM, descontada a época da computação de ponta baseada nas válvulas elétricas possui mais de cinqüenta. Não acredito que a mera presença aliviante da HP pese para a Intel tanto quanto quarenta anos de experiência pesaram para a Big Blue.

A importância de uma biblioteca de código de propósito geral compatível, extensa, acessível ao consumidor e otimizada em tempo hábil é impar além de ser um objetivo muito difícil e tortuoso, por isso há tantas desenvolvedoras de microprocessadores falidas devido à extrema popularização da arquitetura x86. Neste tocante as arquiteturas (e até as microarquiteturas) de propósito geral mais antigas e populares têm o tempo a seu favor. Refutar diametralmente esta afirmação eqüivale a negar toda compreensão da cronologia.

[Alrai]

bom galera li bastante coisa, mais quer dizer que meu Folding@Home , em -smp não esta utilizando 100% de todos meus cores do meu Xeon??