AMD Bulldozer / Bobcat / Zambezi - Plataformas.

16MB de cache L3?! Imagine o tamanho do die.

16MB de cache L3?! Imagine o tamanho do die.

É só da L3?

Eu acho que eles se referiram ao cache total do processador, ou estou enganado?

Se for só da L3, imagina só, um proc com 20MB de cache? Jesus...

É só da L3?

Eu acho que eles se referiram ao cache total do processador, ou estou enganado?

Se for só da L3, imagina só, um proc com 20MB de cache? Jesus...

éééé, eu entendi mal mesmo

são 8MB de cache L2 (soma dos 4 cache L2 de 2MB) e 8 MB L3.

Voltando ao assunto sobre a FPU do BD, está quase confirmado que estará equipada com unidades de execução FMAC clássicas (daquelas "beberronas", mas o "power gating" embutido deve aliviar o caso), e executará um máximo de 2 uops para operações com pacotes de 128-bit de inteiros mais 2 uops para pacotes de 128-bit ponto flutuante por ciclo de relógio. Juntamente com as instruções FMA4, isto é muito bom para as operações sobre registradores XMM, entretanto, ao operar sobre os registradores YMM (AVX) o desempenho de pico para 2 núcleos do BD sem as FMA4 será a metade da capacidade para 1 núcleo do SB da Intel (você não leu isto errado).

Ou seja, a AMD preferiu economizar espaço na área do die para a FPU e investir nos demais recursos do processador. Não acho que seja uma ideia ruim caso o retorno do investimento valha a pena na prática.

Evandro, eu postei alguma explicação sobre a unidade de ponto flutuante neste tópico mas o assunto foi rolando até ela ficar muito para trás, é melhor eu postar uma nova.

O grande diferencial da FPU do BD é a capacidade de processar operações de multiplicação-e-acumulação fundida (FMAC). Isto jamais foi mantido em segredo e todos já devem saber disto.

Porém, ninguém de fora da AMD sabia como as unidades de execução individuais da FPU serão estruturadas. Foram consideradas 2 possibilidades básicas:

a) A criação de uma ponte para unificar indivíduos. Esta especulação surgiu devido a um papel que a AMD publicou sobre construção de unidades FMAC a partir de uma ponte que une multiplicadores (representados por MUL) e acumuladores (representados por ADD) equipados com suas portas individuais, utilizando a saída da unidade de adição (ADD). O consumo de energia durante operações de multiplicação ou adição individuais é baixo mas a área da FPU aumenta em mais de 40%;

Throughput de pico por ciclo de relógio (por FMAC):

1x 128-bit M + 1x 128-bit A, ou 1x 128-bit FMA (2-2 operações/ciclo);

0,5x 256-bit M + 0,5x 256-bit A, ou 0,5x 256-bit FMA (1-1 operações/ciclo);

Ilustração do exemplo (a):

(claramente feita "nas coxas" :-P)

A velha e boa FMAC clássica. Neste caso há uma penalidade no consumo de energia (nas operações de multiplicação ou adição individuais) pois tanto as operações quanto os dados dependentes têm de obrigatoriamente percorrer um caminho mais longo até a saída. A AMD ao que tudo indica preferiu este arranjo;

Throughput de pico por ciclo de relógio (por FMAC):

1x 128-bit M, ou 1x 128-bit A, ou 1x 128-bit FMA (1-1-2 operações/ciclo);

0,5x 256-bit M, ou 0,5x 256-bit A, ou 0,5x 256-bit FMA (1/2-1/2-1 operações/ciclo);

Ilustração do exemplo (:

Como o BD possui 2 FMACs, ele será capaz de processar 1 instrução FMA (2 operações) de 256-bit por ciclo de relógio. Sans FMA, o desempenho continuará limitado a 1 instrução que é capaz de executar apenas 1 operação, ou seja, metade do desempenho possível com o FMA.

A título de comparação, o throughput de pico por ciclo de relógio do SB é:

1x 128-bit M + 1x 128-bit A (2 operações/ciclo)

1x 256-bit M + 1x 256-bit A (2 operações/ciclo)

Agora simplificando, o desempenho em ponto flutuante nos programas antigos e atuais não otimizados para o BD seria melhor no caso (a) e pior no caso (, enquanto que nos programas otimizados para o BD (suporte a FMA4) o desempenho em ambos casos seria similar. O SB notoriamente também não se sairia excepcionalmente bem na execução de programas não-otimizados para AVX.

Absolutamente. O diferencial é que o conjunto de instruções AVX que é suportado pelo SB não é o mesmo suportado pelo BD.

Aplicativos otimizados para o BD precisam das instruções FMA4/XOP mais as PREFETCH/PREFETCHW (oriundas do 3dnow) para alimentar a unidade de ponto flutuante com velocidade máxima. As diferenças entre o SB e o BD neste caso são dramáticas, mas não se trata de uma solução ter superioridade definitiva sobre a outra.

WAT? Oracle comprando AMD?

Não sou expert nisso, mas acho bem improvável não?

http://www.xbitlabs.com/news/other/display/20100924041856_Oracle_to_Acquire_Semiconductor_Software_Companies.html

Oracle está de olho em empresas de Software e de Semicondutores, AMD, IBM (divisão de chips) e NVIDIA apontadas como alvos em potencial..

WTFH? Não sei por que, mas acho que a IBM não vai vender sua divisão de chips para uma das mais perigosas concorrentes. A nVidia é uma empresa de GPUs, até existem aplicações disso em computação empresarial mas são bem restritas, a Oracle não vai pagar caro para tirar tudo. AMD tudo bem, essa sim dá para imaginar algo do tipo... mas acho bem difícil.

Absolutamente. O diferencial é que o conjunto de instruções AVX que é suportado pelo SB não é o mesmo suportado pelo BD.

Aplicativos otimizados para o BD precisam das instruções FMA4/XOP mais as PREFETCH/PREFETCHW (oriundas do 3dnow) para alimentar a unidade de ponto flutuante com velocidade máxima. As diferenças entre o SB e o BD neste caso são dramáticas, mas não se trata de uma solução ter superioridade definitiva sobre a outra.

então nesse caso fica difícil dizer quem é superior ao outro. Mas como a Intel sempre consegue que tudo funcione sobre o umbigo dela veremos programas aprimorado para eles.

Eles querem aumentar os tentáculos deles.. achei que só o Google queria dominar o mundo.

O Mundo quer dominar o Mundo.

Pessoal, alguém me explica isso aqui:

BTW, I now turned skeptical too concerning Bobcat for servers except for rooters or something alike just because it would not make any sense. For example, even if 10 Bobcats match the TDP of an Interlagos they would never match its performance because of the losses in the interconnects and the design would become much more complex. So there would be only a few applications if any. Maybe the same might be told about Llano Fusions. I would think thats much more effective to combine BDs with Streaming GPUs if necessary. This is also the reason why I would not be too afraid of ARM or other potential competitors in the Server realms. There is no alternative to a really powerful server-processor combined with a really high throughput interconnect such as Hypertransport. Anything else I can only imagine in terms of controllers for special devices such as rooters or for some very dedicated tasks. Now I could go on to answer the question of Dale concerning the client chipsets but I abstain from it because it is out of topic here.

Yes, this is the real problem. There is price, power, performance and system count. Bobcat would do well in power and price at a chip level, but when you get into designing a large cluster you have a performance target and a system count (think devices to manage) that come into play.

If you needed one really low power server with low utilization, you might be able to overlook the missing “server” features, but when you are building out a cloud data center, it just doesn’t make sense.

Não é bem que o JF tenha viajado na maionese. A resposta dele foi intencionalmente pouco compreensiva e bem por cima mesmo (para evitar a divulgação acidental de segredos industriais? "Missing "server" features" do BC pode significar corte nos barramento HT3.1, IOMMU, protocolo MOESI, "snoop filter", cachê L3 etc.).

Ele deu a entender que esse corte não fará grande diferença em servidores de pouca utilização (digamos, armazenamento em rede caseiro, um banco de dados ou servidor de mídia pessoal, ou "website server"), o que já não será mais verdade nos datacenter de alta utilização.

De qualquer jeito, onde pegou os quotes?

Comentários daqui: http://blogs.amd.com/work/2010/09/20/cores-–-more-is-better/

Agora tem mais respostas(ainda nem li, mas já tô pondo aqui para não ficar no meio a discussão). Se puderem comentar mais uma vez, acho que todo mundo agradece ^^:

But what if we consider Bobcat as mulicore CPU like Cell, Niagara or even Larrabee? Isnt Intel testing such a 48-core device? Of course this would be something totally different and a new product and I dont know how well this would do in the server space. I do not hear too much about Cell, Niagara and its peers. But its nice to know that AMD could do that with Bobcat if necessary. I heard that the core itself is very small and most of the die is dedicated to graphics and cache. Therefore a CPU with 48 or even more Bobcat-cores wouldnt be out of range. However, the market is just not existing yet.

Funny that intel is knocking my current 12-core processor by saying no applications really scale that well, while simultaneously discusing a 48-core future technology.

I can’t speak to any bobcat plans at this point. However, the first thing that you have to do is size the market for such a solution and determine whether or not there is actually a market for that. There is a big need for 48 core platforms today, but they also require massive amounts of memory throughput, which is why a 4 socket system is a better choice for that at this point.

In fact Niagra is reported to have its strengsths (SQL) but also its weaknesses while IBM is reassessing the cell chip too. Intels 48-cpu is still a prototype and no product. They just presented it to the software guys and told them: Here! Isnt this nice? Just play around with it and try to develop some nice software with it. Maybe it will have a future. Perhaps Intel can do that because they have abundant resources and they are capable of tackling still developing markets too. Of course AMD cant do this because they have to be careful with their money and in fact it is really amazing what you are doing: X86-64, integrated memory controller, Hypertransport, NUMA-architecture and now the Fusion processors. Intel is more or less copying all this from AMD and spent so much money on projects that never really worked: Timmna and Netburst with their crippling Rambus-memory-controllers, Prescott, Itanium, Larrabee. Interestingly all these products had been very academic in terms of theory with catch-words such as Super high frequencies (Netburst), super parallelism (Itaniums VLIW-achitecture) and revolutionary approaches (Larrabee) as if there had never been an experienced industry in a degeloped market with guy who knew very well what they were doing. I was really astonished by all the Larrabee-Hype because I could not imagine that the guys from Nvidia and ATI could have been so stupid by ignoring the fact that everything is so much easier by simply using some outranged X86-cores. But it seems that some Intel-leaders were the ones who did not understand that it takes a little bit more in order to compete in the graphic market. According to some rumours I received from Taiwan the graphic card industry did not even consider it to produce cards with the first Larrabee-chips. In fact all these super-duper architectures from Intel have in common that there power/performance ratio is so lousy that they couldnt compete.

Na verdade o que ambos falaram foi que a Intel, justifica que não está fazendo proc. de 12 cores ainda pois não há mercado para tal, e ao mesmo tempo desenvolve e testa um de 48 e joga nas mãos do pessoal que produz software para eles desenvolverem algo que use, ou pelo menos seja uma máscara justificando o tal.

E no fim citam o desempenho gráfico dos núcleos que a Intel está desenvolvendo e cita que produtores de chips gráficos de Taiwan nem deram bola para tal, pois o desempenho é muito fraco mesmo.

Resumo da conversa

TGB: Multicore is sweet. BC might do well if AMDers get more like Intel and pour some into extraneous and expensive R&D.

JF: We rule with that (multicore, not R&D) but our competitor wouldn't admit it. Thinking massive multicore right now, problem is, we're still working out bugs in our 2-core BC prototypes.

TGB: Yeah, and KISS rules too.

Que viagem...

Please God, NOT Oracle!

Esse caras são uma desgraça, eles basicamente são a nvidia turbinada: Compraram a SUN e terminaram com ela de vez só pra ter a licença do java e incomodar todo mundo, inclusive android! Eles literalmente são uma desgraça, não sabem investir em pesquisa e desenvolvimento de hardware!

http://www.xbitlabs.com/news/mainboards/display/20100924152855_AMD_to_Introduce_Bulldozer_Compatible_Core_Logic_Sets_in_Q2_2011.html

Novos chipsets em Q2 de 2011, 3 versões para a "série 9", dois SBs diferentes, aparentemente nenhum chip gráfico onboard.

É o seguinte:

1. Fusion Llano no mercado: IGP (ou GPU) ondie.

2. Fusion bobcat no mercado: IGP (ou GPU) ondie.

3. AM3 no mercado (família 800).

4. Bulldozer no mercado (provavelmente um IGP novo, baseado no que estão utilizando no bobcat).

Apesar de que muito poucos usuários do Bulldozer Orochi usarão video onboard em seus PC's.