EduardoS

O que é uma vergonha para a Intel já que: 1) A SDK da AMD não usa AVX então o SB fica na metade da capacidade; 2) A SDK da AMD já é feita nas coxas, o driver para CPU é mais para desenvolvedores etstarem aplicações do que realmente para executar código. Assim fica até parecendo que a AMD lidera um segmento que ninguém liga.

No próprio documento apresentando a RCM, mas não vou lembrar do link e nem do parágrafo, se alguém tiver fácil...

Bem... Realmente, a AMD passou essa mensagem, gostaríamos que alguém que a empresa paga para se comunicar com o público se limitasse a falar verdades não é mesmo? Mas na questão do Bulldozer não foi bem assim, quem muito falou dele foi o John Fruehe, e muito do que ele falou (inclusive contradizendo publicações técnicas da AMD para feiras de tecnologia) se provou mentira, é triste isso mas algumas coisas que você leu sobre o Bulldozer vindo dele podem não ser verdade. Falando especificamente sobre IPC existe um argumento em defesa dele, ele é o diretor de marketing da divisão de servidores, realmente, em bancos de dados o IPC raramente passa de 1 e se olhar, o desempenho do BD nesses casos não é tão ruim. E citei aquilo a título informativo, não para ofender.

O problema com AVX256? Hum... For isso não vi teste mostrando que o decoder era um fator limitante, ele é uma unidade de apoio, não executa instruções, então vamos para as ALUs: Bem... Se eles estão reduzindo de 3 para 2 eles nunca diriam que faria falta, não concorda? Do Core Duo para o Core 2 Duo a Intel aumentou as ALUs de 2 para 3, e isso que haviam unidades dedicadas a loads/stores que lidavam com algumas instruções sem precisar de ajuda das ALUs, no K-7/K-8/GH haviam 3 ALUs mas todas as instruções passavam por uma dessas ALUs, no BD em cada núcleo de inteiros só existe 2, e todas as instruções precisam passar por elas. Se realmente a duas fossem suficientes, por que todos os outros processadores tem mais? E quanto a ampliar os decoders para aumentar a utilização das ALUs, se elas executam no máximo duas instruções por clock por núcleo e o decoder decodifica 4 instruções por clock para dois núcleos... Parece suficiente, o que se ganha aumentando os decoders? No K-7/K-8/GH haviam AGUs sobrando. P) Por que preferiram deixar elas sobrando ao invés de aumentar outras partes do núcleo? R) Porque as AGUs são mais baratas que outras partes do núcleo, é preferível ter AGUs sobrando do que alguma outra parte gargalar por falta da AGU. No BD vale o mesmo princípio, o front-end é maior do que os dois núcleos de inteiros juntos, é preferível que o front-end gargale os núcleos do que deixar os núcleos gargalarem o front-end. E por fim, são médias, e médias com muitos problemas: 1) É média, quer dizer, se em um ciclo forem executadas 3 instruções e no segundo ciclo apenas 1 a média será 2 por ciclo, mas isso não siginifica que caso haja uma limitação de 2 instruções por ciclo essa média será preservada. 2) Foram obtidas a muito tempo com processadores que tinham o susbsitema de memória muito limitado e que por isso ficavam muito tempo esperando a memória sem fazer nada, o que jogava a média para baixo, para ter uma média de digamos 2 IPC nos ciclos que o processador não estivesse esperando a memória ele teria que executar muito mais instruções por clock para compensar, e o subsistema de memória evoluiu muito. 3) Testes práticos provam o contrário, um profiler do Cinebench rodando em uma thread do Sandy Bridge mostra que por diversas vezes o IPC supera 2, não é porque um estudo de 2006 com Core 2 Duo mostra que o IPC não passa de 2 que isso continua válido para o Sandy Bridge... Resonant Clock Mesh faria pouca diferença no Brazos, essa tecnologia só vai realmente valer em clocks mais altos, a 4GHz falam em 5% de ganho, mesmo o Piledriver desativa o RCM quando reduz o clock.

Alguém levantou essas idéias (na minha opinião, sem fundamento) e o site disse que no evento da AMD ela não falou se isso realmente vai existir ou não, ela também não disse se vai incluir um frigobar ou não... vr-zone é tabloid, o negócio deles é levantar rumores (a maioria falso), tem que ter muito cuidado quando ler informações por la.

Hum... Não sei se mais núcleos... Os Opterons de 20 núcleos foram cancelados...

Sobre o Steamroller? Sabemos que a AMD escreveu "10%-15%" mais performance e em baixo "greater parallelism"...

Para Opterons, não está claro o que será disponibilizado para desktops, de qualquer jeito o manual pode estar desatualizado, ele cita 10 núcleos mas oficialmente os planos de 10 núcleos foram cancelados. Todas já são suportadas, acho que você quis dizer, que poderão ser executadas ou parcialmente executadas pelas AGU Ah, no manual a descrição da XADD está errada... Na verdade nem tanto... 10% fica mais próximo da realidade, as outras 4 instruções quase nunca são usadas. A FPU já conta com uma otimização para remover MOVs desde o Barcelona, não aumentou drasticamente o desempenho mas sempre ajuda e é uma otimização simples... Agora foi a parte dos inteiros, ai provavelmente viram que dava para usar o mesmo truque para as demais e mecheram nelas. Resta saber ainda como foi feita quais as restrições, etc. A julgar pelo resultado na FPU estamos falando de algo abaixo de 1%, hoje em dia ta difícil projetar boas CPUs, precisa mexer em muita coisa para ter um ganho significativo, colocar cache é mais fácil, talvez os 8MB de L3 tragam uns 5% de ganho e ofusque as outras diferenças entre o Trinity e o Vishera, por outro lado os 8MB de L3 vai custar a AMD meio bilhão de transistores, melhorar os MOV deve ter custado só alguns milhares. EDIT: Correção.

SMT/SoMT é especulação! Talvez isso nem passe pela cabeça da AMD... 1) O resultado parece suspeito; 2) Foi só um benchmark, esse resultado não é absoluto e pode ser menor em outros casos. Sim, só com a adição do L3.

Sempre tem... A estimativa de ganho com o Steamroller é de 10%-15%, não estamos falando de muita folga, é só uma esprimidinha mesmo. Esses 100% que você fala é o tempo de CPU no Task Manager do Windows, ele não é relevante para o SMT. O tempo de CPU no Task Manager significa a porcentagem do tempo que tem uma thread atribuída para o núcleo virtual, essa trhead pode ou não usar 100% dos recursos que o processador tem, o Task Manager não tem como saber isso, essa thread pode até estar parada esperando dados da memória, se em 1 segundo essa thread ficou esperando dados por 1 segundo o Task Manager vai marcar 100%, apesar dos recursos da CPU estarem livres e possam ser usados por outra thread... É por isso que existe SMT e SoMT. Segundo o autor da ideia, não. Acho que precisaria um pouco de trabalho no prefetcher do L1 de dados e mais "ways" no L1 de instruções, de resto é suficiente*. *Claro, para que o SoMT ou SMT pudesse ser melhor utilizado no BD ele precisa de mais unidades de execução. ps: Só lembrando que tanto o SMT quanto SoMT no Steamroller são especulações (existe essa palavra no plural?) de outras pessoas, não minhas.

SoMT é, duas threads em um núcleo mas que não executam ao mesmo tempo, quando uma thread fica parada esperando a memória ou o cache L3 a outra entra. No caso do Steamroller existe a possibilidade das threads migrarem de um núcleo para outro dentro de um módulo, assim cada módulo poderia ter 4 threads com 2 ativas por vez minimizando o tempo parado. Na minha opinião sim... Mas é tudo especulação... É muito difícil aumentar esses recursos e portanto é pouco provável que aumentem, se o Steamroller tiver mais threads por módulo vai ser expremendo ainda mais os poucos recursos que tem ali.

Acho que FPUs de 256 bits. Mas já vi argumentos plausíveis para SMT e SoMT. Só esperando pra ver.

Não boto fé nesse resultado... Parece ter outra coisa influenciando ele... Não é sacanagem, é o clock que cada projeto atinge nesse processo... Os resultados não me impressionaram e não confio 100% neles, prefiro esperaar outros sites para tirar conclusões.

Eu acho que a situação é relativamente simples, a MS tentou convencer a Intel e depois a AMD e até com a VIA a desenvolver um chip de baixo consumo que pudesse ser usado em tablets e celulares, a resposta da Intel foi deixar um bando de estagiário cuidando do Atom, a resposta da AMD foi demitir todo o time do Geode e por fim a resposta da VIA foi cancelar o C7 e partir pro Nano, que era grande demais para celulares. Ai quando viram que os SmartPhones começaram a decolar (era tão imprevisível assim?) todo mundo ficou preocupado e começou a torrar bilhões para recuperar o tempo perdido (exceto a VIA que não tinha mais bilhões para torrar). Ai a MS mandou todo mundo a m#$% falou "não podemos ficar aqui esperando o mundo girar, já tivemos o NT em Alpha, PowerPC e MIPS e podemos agora coloca-lo em um ARM" e é isso ai, voltamos para a salada do século passado. Na minha opinião esse novo round vai ganhar quem deixar o software redondo, com a Apple mantendo aquela percela de glamour, nenhum dos fabricantes de hardware está tomando ações decisivas, vão todos ficar a merce da briga Google vs Microsoft.

Não, o FX-6200 tem 400MHz a mais no clock base. Porque com 2.4GHz ninguém compraria. A grande diferença é que em servidores eles podem sacrificar a performance single-thread para por mais núcleos, em desktops não, hoje a perfomance single-thread é o calcanhar de aquiles da AMD, é "só" isso que os impede de lançar processadores no mesmo nível da Intel.

Dedicar decoders para cada núcleo não vai resolver nada, existe um grande ganho em área mantendo eles compartilhados, ainda não estou convencido de que um núcleo realmente seja capaz de manter a execução de mais de 2 instruções por ciclo mesmo operando sozinho, se isso não mudar não tem porque aumentar os decoders. 1) O BD se sai melhor em testes que estressam os caches. 2) É uma arquitetura voltados a clocks altos, a latência do cache nunca chegaria perto do Sandy Bridge ou K-8. 3) A unidade de load/store foi muito melhorada no Bulldozer, parece estar a frente inclusive do Sandy Bridge, há 40 slots na fila dos loads, um para cada slot no agendador (será que são os mesmos slots?) e isso é suficiente para que alguns acessos ao L2 passe desapercebidos (ao contrário do L2 do Llano, apesar da latência desse último ser apenas 12 ciclos). Enfim, a arquitetura foi desenvolvida voltada para servidores, nesses sistemas a unidade load/store é muito importante e a AMD parece ter desenvolvido primeiro essa unidade (e muito bem por sinal) e depois feito o resto do processador em volta dela (ai nem tudo ficou muito bom...), os benchmarks mostram o resultado disso, a lógica que a maioria das pessoas parece adotar é: "é diferente da Intel? Então é ruim!", seguido por um grupo que pensa: "20 > 12, lento". 4) Essa até parece óbvio... Reduzir o tamanho do cache é muito, mas muito simples, isso permitira reduzir a latência (uns 18 ciclos se reduzisse para 1MB, talvez 16 se dedicasse 512kB para cada núcleo, mas não muito menos que isso, lembra do item 2?), mas sendo tão simples assim, se a AMD ainda não fez isso, será que podemos concluir que não aumentaria a performance? Tem tanta coisa difícil de mexer que parece insuficiente, vão botar a culpa justo no mais simples?

Já que o Sirroman pediu... A única mudança que teve no cache foi a duplicação da banda de escrita do L2, o que é muito importante em caches "write-through", não houve redução no tempo de acesso. É um ponto que quase todo mundo discorda de mim mas, na minha opinião o tempo de acesso dos caches não causa problemas e toda a estrura de caches está bem dimensionada para o núcleo do Bulldozer, sim, é diferente de todos os outros processadores, mas todos os outros processadores tem núcleos diferentes, que eu me lembre o Bulldozer é o primeiro processador nesse estilo "CMT". Que scheduling? Tirando o scheduler do Windows, que não tem nada a ver com a AMD, nenhum teste mostrou problemas no scheduler. Pessoalmente acho que o buffer deveria ser maior, mas é só um chute, não tenho informações suficientes para ter certeza disso. 6 o que? Meses? Anos? Se fosse lançado em 2006 sem dúvida seria uma grande evolução.

O documento abaixo contém uma analise mais completa e correta da arquitetura: http://www.agner.org/optimize/microarchitecture.pdf Olhando o artigo com mais calma ele concorda (comigo, porque parece que tirando o Agner, que escreveu o documento acima, todo mundo discorda de mim) no que não é o culpado pela baixa performance, alguns pontos que ele cita serem problemáticos provavelmente são uma intepretação errada dos dados publicados (e pelo que foi publicado só é possível saber que ele dividiu bananas por maçãs e chegou a uma conclusão errada porque sabemos que essa divisão não faz sentido, mas ele não cita o número de bananas e maçãs, assim leitores - nós - não saberemos se é problema ou não.) por outro lado, em um gráfico onde o BD se mostra excepcional provavelmente ele diviviu os números errados de novo. Bem... Já que eu acusei ele de dividir números errados... Vai uns exemplos: 1) Pagina 10, Instruction Cache Hit Rate: a) Esse gráfico só é relevante para o SQL Server, os outros dois tiveram números muito altos com todos os processadores, o SQL Server é realmente uma exceção, o tamanho do código é muito grande, é perigoso tirar conclusões gerais a partir dessas exceções; Ele conclui que 64kb para duas threads é muito pouco... E esqueceu que os Xeons tem 32kb para duas threads... Ainda assim o Xeon conseguiu um hit rate maior e ele não deconfiou de nada c) Esse "Instruction Cache Hit Rate" nos processadores da AMD é o número de "instruction fetches" servidos a partir do cache L1 dividido pelo total, acontece que um "instruction fetch" para a AMD são 32 bytes enquanto que para a Intel são 16 bytes (assumindo que a Intel usa a mesma nomenclatura, pode não usar), em 32 bytes cabem muitas instruções, mais especificamente 2 vezes mais que em 16 bytes, desvios vão diminuir o número de instruções efetivas nesse pacote, mesmo assim é seguro afirmar que há menos "instruction fetches" nos processadores da AMD do que nos processadores da Intel, e por fim, nesse quesito o que deixa o processador lento é o número absoluto de "instruction fetches" que não vieram do cache de instruções, se esse número tivesse sido divulgado ficaria claro que o cache de instruções não é tão pequeno assim. 2) Pagina 10, L2 Cache Hit Rate: a) Ele corretamente concluiu que algumas porcentagens são muitos baixas porque os valores do L1 são muito altos; Concluindo a porque não postou número absolutos? Agora nóes que temos que fazer as contas com os dois gráficos para chegar a números pouco precisos? c) Juntando os dois gráficos para estimar o total de loads que seriam servidos pelo L2 se o L1 não existisse, teríamos algo como 99% a 99,9% para os Xeon e antigo Opteron e 99,99% a 99,996% para o Bulldozer, ta certo que o L2 do BD é maior e ele tem um bom prefetcher mas mesmo assim a diferença é absurda, duas ordens de magnitude e o autor não desconfiou de nada... O "L2 Cache Hit Rate" é o número de requisições atendidas pelo L2 dividido pelo número total de requisições ao L2, o provável problema é que as requisições ao L2 nem sempre são de "misses" do L1, no caso dos Xeons e antigo Opteron quase todas são porque eles tem caches write-back, mas os caches do Bulldozer são write-through, quer dizer, o que é escrito no L1 também é escrito no L2 e isso provavelmente conta como acesso ao L2, mas um acesso que nunca vai gerar um miss, a slução para isso e para termos dados úteis é simples, publicar o número total de requisições que o L2 não deu conta. 3) Cade os dados do L3? 4) Pagina 7, Libquantum, sem gráfico, sem dados, vale a menção pelas conclusões, os dados que ele usou são de publicações oficiais no site spec.org e de um estudo antigo em cima do Core 2 Duo (e nenhum link), aqui ele acha que o BD foi melhor no Libquantum por causa do prefetcher... Anh... É estranho alguém publicar um artigo sobre algo que desconhce (até porque ele criticou o SPEC nesse mesmo artigo, então ele devia conhecer...), mas vou assumir que ele de fato desconhece o teste e foi um erro inocente... A questão é, o Libquantum é fácil de vetorizar e esse trabalho de vetorização é feito pelo compilador, um compilador melhor produz resultados muito melhores, no caso do BD ele possui instruções novas (XOP, e de quebra AVX) além de ter usado um compilador mais recente, o compilador e as novas instruções, e não o prefetcher, devem ter sido os responsáveis por essa melhora absurda, esse teste em especial é famoso pelo efeito dos compiladores.

Não gostei do artigo (na verdade odiei), poderia ficar a madrugada toda citando os motivos mas vou citar só os principais: 1) Usou fontes de dados externas sem citação; 2) Dados apresentados de forma incompleta, impedem o leitor de tirar conclusões; 3) Nenhuma matemática, nenhuma lógica, dados apresentados e conclusões chutadas, até passou perto dos motivos que não fazem o BD lento mas sem chegar perto do que o torna lento, que era o objetivo do artigo.

Isso se chama "dinheiro".

Digamos que para um video on board ta bom. Não que seja realmente bom, se alguém fizer gráficos foto-realistas ai vai ficar feio, mas um jogo assim nunca rodaria nesse chip mesmo...

Quem compra uma Radeon 7970 hoje vai continuar comprando o equivalente dela no futuro, esse mercado não vai diminuir, a questão são os modelos mais básicos, da 7770 para baixo que podem parar em um datacenter, seja la o que usarem na datacenter ele terá que ser capaz de fazer o que uma 7770 faz (se não o consumidor vai optar pelo hardware em mãos ao invés de cloud), o que provavelmente será uma 7970 compartilhada por diversos usuários, a prórpia 7970 hoje, muito do que existe nela não é usada pelo mercado entusiasta, foi incluindo pensando em GPGPU ou algum outro segmento do mercado profissional, ela não foi feita para o público entusiasta e suas sucessoras não serão, mas como o hardware serve para esse público é disponibilizado para ele, isso não vai mudar. Quanto ao medo de que cloud vai diminuir o mercado, esse mesmo medo existia entre alguns vendedores de servidores quando a virtualização entrou no mercado, e o mercado de servidores não diminuiu, ele cresceu, a virtualização deixou a capacidade computacional mais barata e assim vários projetos se tornaram viáveis e sairam da gaveta, o mesmo deve acontecer no mercado consumidor.

O pessoal te medo de mais dessa "cloud computing"... Seguinte, o hardware fica cada vez mais rápido, tem uma hora que sai mais em conta alugar um pedaço suficiente para atender suas necessidades do que comprar a maquina inteira. Para quem quer gastar o mínimo, ótimo o caminho é esse. Para o mercado entusiasta que sempre gastou mais do que precisa não muda nada, ainda poderão comprar seus PCs caros e barulhentos, só serão mais sub-utilizados do que hoje, essas compras são feitos pelo gosto não pela necessidade e existe mercado hoje, no futuro esse mercado ainda deve existir então ainda haverá fornecedores. E quanto ao desenvolvimento, a anos ficamos felizes usando processadores inicialmente desenvolvidos para servidores, a tal cloud precisa de muitos servidores então isso não vai mudar.

Não importa muito se tem um ponto no meio do processador a 40° ou a 100°, são 77W para dissipar, 18W a menos que o SB e suficiente para coolers mais baratos mesmo com aquele pontinho um pouco mais quente. Processadores mobile usam outro soquete, outra linha de produção e, em geral, vem sem a capinha de produção, não que a Intel se preocupe muito com a temperatura, mas não ter a capinha é mais barato e quem vai manusear geralmente são os OEM, menos risco de trincar o die. Só quem sai perdendo são os overclockers, os mais fanáticos vão pegar uma faca e arrancar a capinha.

O custo da linha de produção extra compensa? No soquete LGA2011 (ou se chamará LGA2012?) eles devem fazer isso, mas pro Ivy não existe muito interesse...