johannesrs

tradução, por favor? Ela tá falando isso só pros ultras ou pra TUDO??????

Esse era um dos resultados que eu queria. Ok, os i7 são melhores, mas... e os i5?

Eu li errado, ou o ganho foi pífio SEMPRE? Isso indicaria que pelo menos o cache não vai ser resolvido com patch de SO

Na minha opinião, e dado que ele não brincou com as flags (e o q ele trata então como padrão? colocou o -cpu=bulldozer ou seja lá o que for pelo menos?), o FX4100 ficou se comportando como um i2 à um i4. Mas não olhei o suficiente pra identificar que testes eram mais float ou mais integer, nem que testes eram mais MT ou ST... De qualquer forma, ESTE me preocupou: Tudo bem que não sabemos as flags e que tem muita gente que não gosta de openMP (eu gosto, tá?!), mas que o resultado não foi bom, não foi! Se bem que foi engraçado neste o pior i3 batendo o melhor i5... P.S.: Faltou o Thuban nos testes

EU AMO LINUX! Sério, olha só como o teste foi feito: A vida do GT ia ficar tão mais fácil assim...

O problema é COMO fazer pra segurar. Não tem fab suficiente nem pro llano quase, imagina pros 3!!

ahn... Jonny... eu tava brincando, aquilo não é sério!!!

@Nav: Deixa eu ver.... a afirmação dele gira em torno de que um processo, que vai ser composto por partes de inteiros e partes de float, é "core bound" e, portanto, a menos que o SO identifique pra onde despachar o processo exatamente, iria dar *****, é isso? Pergunta, isso já não deveria dar ***** também no HT? E o ponto mais complicado do BDZ em single não parecer ser inteiros ao invés de float??? @EduS: continua sendo 8 x 18... ou tu quer me dizer que FPU <> FPU numa mesma arquitetura? @Zie: te respondo depois.

Acho que um de nós não entendeu o outro nos números, zie. Outra coisa, em FPU: então o Thuban tem 6 núcleos * 3 FPU = 18 FPU. Enquanto que o BDZ tem 4 módulos * 2 FPU = 8 FPU?????????? No SB nem sonho em entender a conta...

"Despite the really nasty bullshit we done with FX processors, our other lines, meaning Bobcat, Llano, Opteron and GPU all showed great increment in market share and profits, so overcoming the huge rentals payed for the non-selling boxes of FX processors still parked at the harbors of all countries."

@Nav: Eu tô errado, ou isso apontaria para o front-end do bulldozer? e ele como pior, ainda que por pouco, que nos Thuban???? @Ziebert: será mesmo que não vai ter nenhum ajustezinho da arquitetura? revisão, ok, mas algo tipo os venice que incluiram até SSE3 (não que precisemos de mais instruções agora) na mesma arquitetura será que também tá fora da mesa? E Zie, tem um problema nos teus números. Se for assim, digamos um núcleo de SB com HT renderia 130% no máximo do núcleo SB sem HT. O BDZ um núcleo renderia 70%, mas o módulo todo deveria passar por quase nada com 133% (70% + 90%70%)... e não parece ser isso o que acontece...

Só uma pergunta: ok, eu entendo que o bulldozer tenha menos ALUs que os parentes e concorrentes... mas como diabos tu "reforça" uma unidade????? Edit: tô começando a me perder.... ALU e núcleos de inteiros, assim vocÊs me matam.... um "núcleo de inteiros" é composto por que unidades? E, sim, o BDZ tá um inferno de analisar e descobrir de onde vem. Nesse ponto, parece que o Charlie estaria certo, "Morte de 1000 cortes"... Quando o problema é em mais do que um ponto, é virtualmente impossível apontar exatamente quem é o culpado.

@Nav: 1 - não entendi a tua discussão em cima dos caches. Meio que enroscou no meio. Tu acha que os problemas reportados nos caches não fazem sentido em função do desempenho dos programas de compactação, é isso???? 2 - então, tu discorda do charlie e acha muito provável que seja problema no processo os problemas de clock e consumo, é isso? 3 - posso estar pirando, mas... esses escapes tentando ser reduzidos... alguém mais lembra da 4890?

bom, sem querer defender, mas quando tu diz que foi "morte por 1000 cortes" tu definitivamente não diz que é "fácil"... e ainda admito que não engulo a história de que esta arquitetura funcionaria noutro cenário como o proposto. Se eu entendi, eles supuseram um mundo baseado em cloud que só ainda não tinha esse nome ainda? Bom, então o pc do dia-a-dia deveria ser o bobcat, e o bulldozer só seria pros opteron.... só que o bobcat é recente. Agora, ele martela em dois pontos que todo mundo tá criticando: latência da L2 (se aqueles números estão certos, são de arrepiar!) e a falta de clock, excesso de consumo, etc (toda a bronca do processo). O que muda e muito no caso do Charlie é que ele começa a crítica pela L2, e não pelo clock e excesso de consumo... e adiciona, curiosamente numa crítica "sutil" demais à AMD pra passar desapercebida vinda dele, que as fontes deles dizem que o llano estaria tendo problema sde processo, mas os clocks e consumo do bulldozer tem OUTRA fonte.

Ah, mas que seria tão bom um 12-16 cores (eu tô me convencendo a chamar pelo n~ de módulos até vir performance boa... então, 6-8 módulos) pra desktop seria...

Tá russo, mas se pelo menos tivesse sido lançado já nesta leva... E um FX8190???

É, mas todos os patches reais devem totalizar o que? +/- 10%? E outro detalhe: com essa numeração, o máximo que teremos seria um 8190, com qto de clocks? Pouca margem pra expandir. Tô rezando pro piledriver começar com um 8210 mais forte do que o 8170, ou vai ser ****... P.S.: alguém já estimou onde o 8170 ficaria em performance se for lançado nos clocks previstos em comparação com a concorrência E a seus pais?

Parece que o patch aquele vai ser fake. Dúvida atual: Aurora 2 recebe up em dezembro pra thuban X6 (a partir de P2 710), ou seguro como tá e cresço pra Aurora 3 em julho do ano que vem, sabe-se-lá se com Ivy ou Pile? quanto à B3, não consigo levar fé o suficiente também. Se bem que, né, maldição da B2 não falha... O problema atual é que, ok, parece que em MT tá muito bom (preciso de testes compilados no linux com as flags ideais E em compilador que não seja "vendor bound" pra comparar e falar qualquer coisa de vez), não sei se o suficiente pra derrubar a intel pelo menos nessa parada, mas em ST tá indiscutivelmente ruim. A pergunta é: é "só" o maldito processo, ou tem mais alguma coisa na parada???

só uma coisa: alguém já viu um erro de registo (?????) dar um impacto tããão grande????? E concordo, em todas as discussões envolvendo o linux falou-se de uns 7% de ganho no máximo... algum teste em linux mostrando esse efeito???? P.S.: a notícia mesmo é aqui: http://quinetiam.com/?p=2356 P.S.: Pra confirmar se tem algum fundo de verdade nisso afinal: alguém procura se existiu ou não esse tipo de problema no Cortex A8? E, outra... como nem o Charlie noticiou isso ainda? E concordo: estranho isso estar no kubuntu, e não no kernel direto.

pior que quando vi os reviews, só lembrei dos comentários do cara mesmo... Bom, parece que vamos tudo pra ARM então em quanto tempo? Olhem a vantagem, sem monopólio, e vamos voltar a discutir meia dúzia de empresas (que detém patentes de processos de fabricação e portanto estão seguras, logo nunca verei uma BrIntel mesmo.... ) ao invés de uma! Add: http://www.xbitlabs.com/news/cpu/display/20111004232129_AMD_s_Next_Generation_Piledriver_Micro_Architecture_Expected_to_Offer_10_Performance_Advantage.html http://www.xbitlabs.com/news/cpu/display/20111012151052_AMD_Aims_to_Improve_Bulldozer_Performance_per_Watt_by_Up_to_50_by_2014.html

obrigado soul! Pelo menos isso explica porque que um chipset topo de linha não pode, onde um médio consegue.

@Sirro: ISSO É UMA NOTÍCIA IMPORTANTE! Se recompilação está mudando algo significativamente, em especial tanto a performance dos programas quanto o funcionamento dos Turbos, temos uma notícia muito boa nas mãos! Isso PODE (não DEVE, apenas pode) implicar que realmente a diferença de arquitetura tá sendo severa demais pros programas atualmente compilados (algo que pra mim até que afeta pouco... pena que eu acho que a intel vai largar uma flag específica pra processadores modularizados nos compiladores dela mas é NUNCA!). S.S.S. (Se e Somente Se) o clock base ficar nos níveis pretendidos já deixaria o bulldozer competitivo, as vantagens da arquitetura se mostrariam com o tempo e novas versões dos programas. Na minha leitura: parece que a arquitetura então seria promissora, mas o processo (coisa que afeta tanto clock quanto consumo) que sabemos que é problemático é que tá quebrando as pernas. Óbvio, esse é o primeiro teste do que eu quero ver, RECOMPILAÇÕES de programas PESADOS em comparação com a concorrência e a geração anterior. ISSO vai me dar as respostas que eu preciso! P.S.: olhei melhor o teste... sem graça, no primeiro ele compara com AVX e FMA, tudo bonitinho... no segundo e terceiro, blé, esquece do FMA????

importante o fato de que estamos muito abaixo do clock alvo. Alguém pode estimar o que seria o comportamento se, nos mesmos preços e consumos, tivéssemos os clocks almejados? Aqui vai dar X6 na cabeça... E vamos torcer pro tempo criar uma alternativa antes do Aurora 3 ser construído... tem tempo... X6, fonte de 1500W, algumas GPUs.... só depois disso. Mas, ***, arrancou mal o negócio!

Primeiro: Que Ferramenta? SEgundo: Cadê as Peitudas Nessa Hora? Um Peito Amigo pra Acalentar a nossa Tristeza ia bem... ou estão todas ocupadas com os acionistas????

Primeiro: mudar nomenclatura, FRESCURA e COMPLICAÇÃO Segundo: ressuscitar o FX, CAGADA FEDIDA DAS GRANDES!!! Terceiro: só estou esperando testes específicos pra multi-thread aqui, até pra decidir qualquer coisa envolvendo hardware de cluster... Mas, a menos de milagre nesse quesito fundamental pra mim, é Thuban aqui em casa, no cluster velho de POA mas sandy ou ivy no cluster novo, infelizmente. P.S.: agora, vamos convir que os resultados oscilam de um jeito tão esquisito que não tá nem dando pra entender...