AMD Barcelona

Marcos_Correia · 21 de janeiro de 2009

Éh..., mas parece que esse aí vai ficar com o preço abaixo do 7750, ele saiu a $80,00 não foi ??

Ah entendi, bem pra ficar abaixo do 7750 então não vai ser BE. Ainda assim acho desperdício...rsrsrs

Heberton(AMD) · 21 de janeiro de 2009

Mico de um site que eu considero pelo menos conhecido, eu mandei um comentário pra eles, dando uma aula sobre tudo o que eles escreveram errado!

http://www.baixaki.com.br/info/1372-processadores-amd-descubra-quais-os-modelos-vendidos-na-atualidade-e-suas-principais-aplicacoes.htm

Marcos_Correia · 22 de janeiro de 2009

Mico de um site que eu considero pelo menos conhecido, eu mandei um comentário pra eles, dando uma aula sobre tudo o que eles escreveram errado!
http://www.baixaki.com.br/info/1372-processadores-amd-descubra-quais-os-modelos-vendidos-na-atualidade-e-suas-principais-aplicacoes.htm

Vindo de onde veio não deveria-se esperar coisa melhor, quase morri de rir quando li este trecho:

"Já o “Athlon 64 FX” utiliza todo o potencial da tecnologia quad-core"

e este:

"possuindo a quantidade absurda de 6 MB de cache L2 (o maior valor encontrado atualmente no mercado)."

aluis2002 · 22 de janeiro de 2009

"possuindo a quantidade absurda de 6 MB de cache L2 (o maior valor encontrado atualmente no mercado)."

Esse foi o melhor comentário desse sitio. adorei..., a quantidade absurda de besteiras que foram ditas. hUAHuha.

--

X2 7550 à venda.

http://www.fudzilla.com/index.php?option=com_content&task=view&id=11617&Itemid=1

Edit.

onde eu vi Newegg ? valeu Xita.

johannesrs · 10 de setembro de 2009

HUAHUAHUAHUAHUA!!!!

SERÁ UM VAMPIRO???? SERÁ UM ZUMBI?????

NÃO, É UM TÓPICO VOLTANDO DA TUMBA COM NOVOS BENCHMARKS!!!!

HUAHUAHUAHUAHUA!!!!!

Ok, passando a parte da péssima introdução da qual com certeza todos vão dizer que só eu achei graça (o Xita não conta, e muito menos o meu colega de fã-clube da MSI... ). Segue neste post as imagens da dual-quad barcellona do lab, a muito prometidas. Estou postando porque no próximo post, pra evitar sobre carga de figuras num só, vou colocar os resultados de alguns benchmarks que eu efetuei aqui nesse monstrinho...

O "kit":

O "trem":

O "recheio":

johannesrs · 10 de setembro de 2009

Bom, vamos aos testes efetuados na máquina.

Inicialmente, a lista de testes incluía a seguinte série de programas:

Mopac

Firefly (vulgo PC-Gamess)

Gaussian

NWChem

Gamess

Gromacs 3.3.3 e 4.0.4

Dessa lista, o firefly foi o primeiro a ser removido da lista, ao exigir bibliotecas MPI em 32bits. Eu não ia me dar ao trabalho, literalmente removi o software da máquina.

O Mopac09 não foi testado porque ele não é, pura e simplesmente, paralelo. Ele está disponível para uso na máquina.

O Gaussian03 foi testado, mas a sua paralelização em máquinas tipo SMP sem a necessidade do Linda é uma descarada propaganda enganosa. O gaussian, pra quem não sabe, é composto de uma série de executáveis, que se chamam de acordo com as necessidades do momento. Uma minúscula parcela deles é paralelizada em SMP. Como resultado, Os testes mostraram o seguinte "escalonamento", que não será nem mostrado em figura:

1 - 1478s - 1.0
2 - 0882s - 1.7
3 - 1009s - 1.5
4 - 0775s - 1.9
5 - 0633s - 2.3
6 - 0509s - 2.9
7 - 0469s - 3.1
8 - 0465s - 3.1

Naturalmente, o Gaussian03 está disponibilizado para uso na máquina, mas restrito a um máximo de DOIS núcleos.

O NWChem, como todo bom software de cálculos quânticos, necessita para uma boa performance a compilação com o uso de uma boa biblioteca de BLAS. MKL, ACML e GotoBLAS foram sucessivamente testadas, com todas e nenhuma "flag" de compilação imaginável, além de todas as opções possíveis. Apesar de ser possível obter uma compilação que escale e faça uso muito eficaz dos núcleos disponíveis com o uso de MPI (tal se mostrou impossível com a opção padrão, TCGMSG), todas as compilações se mostraram absolutamente inúteis dado o simples fato de que os resultados obtidos são absolutamente irreproduzíveis entre diferente corridas E entre diferentes números de núcleos disponibilizados para o processamento. Portanto, o código está disponível para membros do grupo que quiserem tentar compilar por conta própria o código. Caso tenham sucesso, informem. Os executáveis obtidos NÃO estão disponíveis para uso pelas razões citadas acima.

Tanto o Gamess quanto ambas as versões do Gromacs testadas apresentaram resultados excelentes de performance e portanto serão apresentados na forma gráfica.

O Gamess, programa aberto de QM, foi compilado com a biblioteca MKL tanto com o compilador gnu quanto com o compilador intel. Em ambos os casos, as diferenças de tempos foram bastante reduzidas, mostrando o claro avanço do programa de desenvolvimento do GCC:

No caso do escalonamento, é importante observar que a paralelização em programas de QM exige relativamente pouca intercomunicação entre os nodos/núcleos. Mais apropriadamente falando, muitos dados são trocados, mas numa freqüência consideravelmente baixa. Como resultado, eles costumeiramente apresentam um escalonamento perfeito, conforme pode ser facilmente observado na figura abaixo:

Passando para o Gromacs: O gromacs é atualmente o pacote de dinâmica molecular, estocástica e browniana mais empregado e rápido do mundo. A grande razão disso estaria principalmente no seu núcleo de cálculo, desenvolvido principalmente em assembly, permitindo assim o uso absolutamente pŕeciso de instruções ótimas para cada arquitetura de hardware suportada. No caso de hardwares não suportados a esse nível, os núcleos de cálculo são compilador a partir de fontes em Fortran devido a maior eficácia dos compiladores no tratamento dessa linguagem na obtenção de alta performance.

A versão 3.3.3 é a última da série 3, ao passo que a versão 4.0.4 é a penúltima para a série 4 de versões. A principal diferença entre a série 3 e 4 diz respeito mais precisa e principalmente às técnicas de paralelização empregadas, de forma a mais eficientemente lidar com a divisão de trabalho entre os núcleos e assim reduzir algum "desbalanço" gerado em função da altíssima intercomunicação de dados gerada nesse tipo de cálculo quando em paralelo. A principal origem de um "desbalanço" seria o emprego das transformadas rápidas de Fourier em paralelo, as quais crescem o número de comunicações com o quadrado do número de núcleos envolvidos (por exemplo, num cálculo sendo executado com o dobro de núcleos que outro, o número de intercomunicações daquele será 4 vezes maior que este). A versão 4 permite centralizar alguns nodos/núcleos apenas para isso, resultando numa redução do número de comunicações e reduzindo essa causa de problemas de escalonamento. Tal poderá ser verificado nos resultados obtidos com emprego de PME ao invés de simples CutOff para o cálculo das interações de longa distância (eletrostáticas). Interessante ainda notar que nesse caso foram adicionados os resultados obtidos anteriormente nos mesmos testes em processadores intel Core2Qual Q6600 para comparação. Vale lembrar ainda que os processadores da máquina sendo testada são da geração "Barcelona", podendo se esperar facilmente melhoras nos resultados para a geração "Shangai" e principalmente, "Istambul". Mais ainda, os Opteron 2350 empregado neste estudo apresentam um clock de 2.1GHz, ao passo que os Core2Quad Q6600 um clock de 2.4GHz. Tal diferença é equivalente a ~15%, diferença a qual por si só não é suficiente para assegurar a superioridade do "Barcelona" frente ao "Core2" num único núcleo, mas mais do que suficiente para assegurar a vantagem em paralelo antes mesmo de empregar os 4 núcleos de um processador (superando já no emprego do 3º núcleo). Tal fato é decorrente basicamente da inferior intercomunicação entre os núcleos dos Core2 (nada pode ser aferido porém quanto aos Core i7, quando a Intel finalmente copiou a AMD nesse quesito com quase uma década de atraso). Os resultados dos benchmarks são mostrados na figura abaixo:

Os resultados de tempos obtidos acima mostram:

1 - a velocidade do Core2Quad Q6600 é superior à do Opteron 2352 em todos os diferentes graus de uso dos núcleos, se tornando absolutamente irrisória a partir de 4 núcleos.

2 - A vantagem do C2Q com CutOff foi em termos dos tempos de execução no Opteron 2352 de 35% em 1 núcleo, 17% em 2 núcleos, 17% em 3 núcleos e 11% em 4 núcleos. Já com PME, a vantagem foi de 32% em 1 núcleo, 20% em 2 núcleos, 13% em 3 núcleos e míseros 9% em 4 núcleos.

3 - Caso se efetue a correção necessária para que o opteron tenha o mesmo clock do core2quad (no caso, simulando um Opteron 2354?), as vantagens do Core2 com CutOff serão de 23% em 1 núcleo, 2% em 2 núcleos, 2% em 3 núcleos e -5% em 4 núcleos, e com PME de 20% em 1 núcleo, 6% em 2 núcleos, -2% em 3 núcleos e -7% em 4 núcleos.

4- a intercomunicação superior e o "quad core nativo" característicos do Barcelona claramente favorecem o Opteron em paralelo, uma vez que a vantagem do Q6600 em paralelo se desfaz por completo a partir do 3º núcleo utilizado quando descontamos a diferença de clock.

5 - O Gromacs 4.0.4 claramente tem uma vantagem de performance quando comparado com a versão 3.3.3.

Já os resultados de benchmarks obtidos acima mostram:

1 - Em todos os casos observa-se um escalonamento superior do Gromacs 4.0.4 frente ao Gromacs 3.3.3, tanto empregando CutOff quanto PME.

2- O escalonamento dos Core2 é absolutamente pobre, e naturalmente mais sofrido no emprego do PME, novamente devido à tecnologia de intercomunicação inferior.

3 - O Gromacs 4.0.4 passa muito mais perto do escalonamento perfeito com PME que a versão 3.3.3.

4 - É claramente observada uma "mágica" existência de "superscalling" no caso de uso de Cutoff.

Em função do ítem 4 acima, mais uma figura foi criada, na qual para todos os testes no Opteron o tempo de execução em serial foi renormalizado frente ao tempo de execução em paralelo com apenas dois núcleos. Os resultados são mostrados a seguir:

Os benchmarks obtidos acima, com o tempo de execução em um núcleo normalizado artificialmente para levar o dobro do tempo do com dois núcleos, mostram claramente a manutenção do fenômeno de superscalling no caso de uso de CutOff. Na prática, realmente uma pena que tal método não tem relevância prática para a maioria dos sistemas de interesse químico estudáveis.

DreamWalker · 10 de setembro de 2009

Não da pra ver as imagens aqui (maldito Firewall) hauiehoaehaei então so amanhã mais tarde. PS.: Tu dormiu rapá? hauieoaheuaiehaeihioaheae

Diego Paladin · 10 de setembro de 2009

@johannes

RODA CRAISIS?

:D:D

Evandro · 10 de setembro de 2009

Belo trabalho !

Tu vai rodar o autodock nela ?

jefferson.igorbr · 10 de setembro de 2009

Bota pra foldar !

Que bela máquina.

johannesrs · 10 de setembro de 2009

pra q mais de 20 giga pra docking?

EduardoS · 10 de setembro de 2009

mostrando o claro avanço do programa de desenvolvimento do GCC:

Se bem que nesse caso quem fez todo o trabalho foi a MKL...

De qualquer jeito ai vai três dicas:

Open64 - Meio Open e meio AMD herdando do PathScale esse compilador é quase 100% compatível com o gcc e a portação de códigos (se seu código compila com gcc e ICC o trabalho de portação deve ser zero) é simples, tem um conjunto simples de flags recomendadas e uma longa biblioteca para quem tem muito tempo livre...

Sun Studio - Pacote free feito pela Sun, simples de usar, nem tão simples de fazer funcionar e se destaca em alguns aspectos, da para brincar com auto-paralelização dele que é melhor que a do ICC.

http://developer.amd.com/gpu/acmlgpu/Pages/default.aspx

Vai ter upgrade pra Istanbul?