A arquitetura de computação CDNA 3 da AMD
(chipsandcheese.com)- A AMD CDNA 3 é uma arquitetura de GPU de computação que busca corrigir os pontos em que a CDNA 2 teve bons resultados em supercomputação FP64, mas ficou atrás da H100 em desempenho de IA e escala de GPU integrada
- A MI300X expõe um total de 304 Compute Units em 8 XCDs como se fosse uma única GPU, reduzindo a carga de ter que dividir o trabalho entre duas GPUs e pools de memória separados, como ocorria na MI250X
- A hierarquia de memória foi reorganizada com 256 MB de Infinity Cache, 4 MB de L2 por XCD e 32 KB de L1 perto de cada CU, oferecendo teoricamente 17,2 TB/s de largura de banda de cache, embora em uma configuração de memória unificada os links die-to-die possam se tornar um gargalo
- As unidades de execução adotam uma estrutura próxima de dual issue para aumentar o aproveitamento de FP32 e ampliam o número de threads rastreáveis por SIMD, enquanto a vazão de operações matriciais também dobra por CU em relação à geração anterior da CDNA
- A principal mudança da CDNA 3 está na hierarquia de memória e no empacotamento, e a MI300X foi projetada para fazer vários chiplets parecerem um único grande acelerador graças à largura de banda muito maior do Infinity Fabric
A lacuna que a CDNA 3 mira
- A AMD vem evoluindo sua arquitetura para alcançar a Nvidia no mercado de computação com GPU, passando por Terascale 3, GCN e a separação entre CDNA/RDNA
- A MI250X e a MI210, baseadas em CDNA 2, conquistaram vários contratos de supercomputadores, incluindo o Frontier da ORNL, que ocupou o 1º lugar no TOP500 em novembro de 2023
- A CDNA 2 entregou desempenho sólido e com boa relação custo-benefício em computação FP64, mas a H100 oferece melhor desempenho de IA e uma GPU integrada maior
- A CDNA 3 foi projetada para reduzir essa diferença ao combinar o empacotamento avançado da AMD, Infinity Fabric, o Infinity Cache da linha RDNA e Compute Units aprimoradas
Layout de GPU da MI300X
- A MI300X usa uma estrutura de chiplets que separa a computação em Accelerator Complex Die (XCD)
- O XCD cumpre um papel semelhante ao Graphics Compute Die (GCD) da CDNA 2/RDNA 3 e ao Core Complex Die (CCD) do Ryzen
- Como os produtos CDNA não têm hardware gráfico dedicado da linha RDNA, a AMD aparentemente mudou a nomenclatura
- Cada XCD tem fisicamente 40 Compute Units CDNA 3, com 38 ativadas por XCD na MI300X
- Um XCD tem 4 MB de cache L2, usados por todas as CUs daquele die
- A MI300X oferece 304 Compute Units no total com 8 XCDs
- É um aumento significativo em relação às 220 CUs da MI250X, e a MI300X pode expor essas CUs como uma única GPU
- Na MI250X, cada GPU tinha seu próprio pool de memória, então os programadores precisavam dividir manualmente o trabalho entre as duas GPUs
- A Nvidia H100 expõe 132 Streaming Multiprocessors (SM) como uma única GPU integrada, mas usa a abordagem tradicional de implementar a computação em um grande die monolítico
- A H100 divide o L2 em duas instâncias; um único SM pode usar os 50 MB completos de L2, mas há penalidade de desempenho para acessos acima de 25 MB
- O XCD da MI300X não usa a capacidade de L2 de outros XCDs para cache, então, em termos de aproveitamento da capacidade de cache, a abordagem da Nvidia é mais eficiente
Comparação estrutural com o Ponte Vecchio
- O Ponte Vecchio (PVC) da Intel usa o Compute Tile como bloco básico de computação, algo aproximadamente correspondente ao XCD da CDNA 3
- O Base Tile do PVC inclui um grande cache de último nível e controladores de memória HBM, de forma semelhante ao die de IO da CDNA 3
- Assim como a MI300X, a placa com PVC também pode ser exposta como uma única GPU com pool de memória unificado
- As diferenças entre as duas estruturas aparecem no tamanho dos chiplets, na disposição do cache e nos links entre dies
- O Compute Tile do PVC é composto por 8 Xe Cores, sendo menor que um XCD da CDNA 3 com 38 CUs
- Em vez de um cache grande para todo o Compute Tile, a Intel reduz a necessidade de tráfego cross-die com um cache L1 maior
- Ao usar um Ponte Vecchio de 2 stacks como GPU integrada, a ponte EMIB fornece apenas 230 GB/s, o que dificulta aproveitar totalmente a largura de banda da HBM ao distribuir o acesso entre todos os controladores de memória
- A Intel fornece APIs para tratar a GPU em configuração NUMA
- Na configuração física, a CDNA 3 exige alta largura de banda entre os dies de IO, enquanto o PVC se sustenta com links EMIB de menor largura de banda, mas tem um projeto mais complexo por causa de quatro tipos de die e do uso de processos e foundries diferentes
- A MI300X usa apenas dois tipos de die, e tanto o processo de 6 nm quanto o de 5 nm são da TSMC
Infinity Cache e gargalos de memória
- O desempenho de computação cresceu mais rápido que a memória ao longo de décadas, e as GPUs, assim como as CPUs, vêm respondendo com estratégias de cache mais sofisticadas
- A CDNA 2 usava uma hierarquia tradicional de cache em dois níveis, apoiada em 8 MB de L2 e HBM2e, mas a MI250X sofria mais com falta de largura de banda do que a Nvidia H100
- A CDNA 3 adiciona o Infinity Cache vindo da RDNA 2
- No MI300, o Infinity Cache é um cache no lado da memória que a documentação técnica chama de Memory Attached Last Level (MALL)
- Ele fica mais distante do Compute Unit do que L1 e L2, estando ligado aos controladores de memória
- Todo o tráfego de memória passa pelo Infinity Cache, e o tráfego de IO e a comunicação com GPUs pares também podem se beneficiar da largura de banda do Infinity Cache
- Como ele sempre vê o estado mais atualizado do conteúdo da DRAM, não precisa lidar com tarefas de manutenção de cache como snoop
- Como caches no lado da memória geralmente têm latência maior, a AMD protege os Compute Units com um cache L2 de vários MB tanto na CDNA 3 quanto na RDNA 2
Capacidade do Infinity Cache e largura de banda teórica
- O Infinity Cache da CDNA 3 usa uma estrutura 16-way set associative, como na RDNA 2
- A implementação da CDNA 3 é mais otimizada para largura de banda do que para capacidade
- É composta por 128 slices
- Cada slice tem capacidade de 2 MB e largura de banda de leitura de 64 bytes por ciclo
- No total, os slices fornecem 8192 bytes por ciclo, o que equivale a 17,2 TB/s a 2,1 GHz
- O Infinity Cache de 128 MB da RDNA 2 oferece 1024 bytes por ciclo considerando todos os slices, ou teoricamente 2,5 TB/s a 2,5 GHz
- Com base nos die shots, os slices de Infinity Cache da RDNA 2 parecem oferecer 4 MB de capacidade e 32 bytes por ciclo
- A MI300X pode entregar bom desempenho mesmo em cargas de trabalho com baixa densidade de computação, desde que obtenha taxa de acerto suficiente no Infinity Cache
- Ao montar um modelo roofline com a largura de banda teórica do Infinity Cache, a MI300X pode atingir seu throughput FP64 total com 4,75 FLOPs por byte carregado
- Usando apenas DRAM, seriam necessários 14,6 a 15 FLOPs por byte carregado
Limitações da largura de banda cross-die
- O Infinity Fabric da MI300X se estende por 4 dies de IO, e cada die de IO está conectado a 2 stacks de HBM e às partições de cache correspondentes
- Quando a MI300X opera como uma única GPU lógica com pool de memória unificado, a largura de banda das conexões die-to-die pode limitar o alcance da largura de banda teórica total do Infinity Cache
- O gargalo aparece nos cálculos de largura de banda considerando uma única partição de die de IO
- Ela tem 2,7 TB/s de largura de banda de entrada nas duas bordas que fazem contato com dies de IO adjacentes
- Os 2 XCDs conectados a esse die de IO podem obter 4,2 TB/s de largura de banda do Infinity Cache
- Se as requisições com miss em L2 forem distribuídas uniformemente por todo o die, 3/4, ou 3,15 TB/s, terão de vir de dies pares
- Como 3,15 TB/s é maior que 2,7 TB/s, a largura de banda cross-die limita a largura de banda do cache
- Se todos os dies exigirem a largura de banda máxima do Infinity Cache em uma configuração unificada, as transferências entre dies posicionados em cantos opostos exigirão 2 hops, consumindo ainda mais largura de banda de entrada
- Ao dividir a MI300X em vários domínios NUMA, a largura de banda agregada do Infinity Cache pode ser maior
- Uma alta taxa de acerto em L2 reduz a chance de gargalo e, quando a taxa de acerto no Infinity Cache é baixa, os links die-to-die da MI300X fornecem largura de banda suficiente para lidar com o tráfego de HBM
Coerência entre XCDs e funcionamento do L2
- O Infinity Cache não exige preocupação com coerência, mas o cache L2 precisa de tratamento separado
- O acesso geral à memória na GPU segue um modelo de coerência relaxada, mas o programador pode impor ordenação entre threads com atomics
- Os acessos à memória na GPU da AMD podem ser marcados com o bit GLC (Global Level Coherent)
- Nas GPUs AMD anteriores, atomics e acessos coerentes eram tratados no L2
- Um load com o bit GLC ativado ignora o L1 e busca os dados mais recentes no L2
- No MI300X, a cacheline mais recente pode estar no L2 de outro XCD, então só esse método não basta
- O CDNA 3 coloca um Coherent Master (CM) na conexão entre os XCDs e o die de I/O, como no Infinity Fabric do Ryzen, e posiciona um Coherent Slave (CS) ao lado de cada controlador de memória, junto com um slice do Infinity Cache
- Pela documentação do Ryzen, dá para ver que o Coherent Slave tem um probe filter e hardware para processar transações atômicas
- O MI300X também parece ter uma implementação de CS semelhante
- Quando uma escrita coerente chega ao CS, ela deve poder ser observada em uma leitura coerente por qualquer thread, independentemente de onde esteja executando na GPU
- Em uma implementação simples, o CS teria de fazer probe no L2 de todos os XCDs
- O probe filter rastreia quais XCDs armazenaram aquela linha em cache para evitar tráfego de probe desnecessário
- O whitepaper do CDNA 3 afirma que o snoop filter é grande o suficiente para cobrir os caches L2 de vários XCDs
- Ainda assim, dentro do XCD o CDNA 3 funciona de forma parecida com GPUs anteriores
- Uma escrita normal na memória não invalida automaticamente a linha nos caches pares como acontece na CPU
- O código precisa especificar explicitamente o writeback de linhas sujas do cache L2 e a invalidação de linhas L2 não locais em caches L2 pares
- A documentação relacionada do LLVM explica o uso de
buffer_wbl2 sc1ebuffer_inv sc0 sc1no target GFX942
Melhorias no cache L2 e L1
- Cada XCD do MI300X tem 4 MB de cache L2 perto das Compute Units
- O L2 é composto por 16 slices
- Cada slice de 256 KB oferece 128 bytes de largura de banda por ciclo
- A 2,1 GHz, isso dá 4,3 TB/s por XCD
- O MI300X tem uma relação entre largura de banda de L2 e capacidade de computação maior do que H100 e MI250X
- Como há um L2 em cada XCD, os produtos CDNA 3 aumentam naturalmente a largura de banda de L2 à medida que adicionam mais XCDs
- Isso evita o problema de conectar muitas Compute Units a um único cache grande e ainda precisar manter a largura de banda
- No PVC, conforme aumentam os Compute Tiles, cresce a demanda por mais largura de banda no L2 compartilhado do Base Tile
- A estrutura do PVC é simples do ponto de vista de projeto de cache, porque o L2 é o único ponto de coerência e serve de backstop para misses no L1
- Mas ela não oferece uma largura de banda tão alta quanto o L2 do MI300X
- O L1 do CDNA 3 também foi melhorado com foco em largura de banda
- O throughput do L1 aumentou de 64 bytes por ciclo para 128 bytes por ciclo
- A capacidade do L1 também subiu de 16 KB para 32 KB
- Um cache maior pode elevar a hit rate, reduzir a latência média de acesso à memória e melhorar a utilização das unidades de execução
- Como buscar dados a partir do L2 ou acima consome energia, aumentar a hit rate também pode ajudar na eficiência energética
- O Ponte Vecchio ainda se destaca no lado do L1
- Cada Xe Core oferece 512 bytes por ciclo
- A capacidade do L1 é de 512 KB
- Kernels limitados por memória que caibam no L1 podem funcionar bem na arquitetura da Intel
- Porém, como não há um cache intermediário no nível do Compute Tile, o desempenho pode cair bruscamente quando os dados ultrapassam o L1
Escalonamento e unidades de execução
- Além da estrutura de chiplets e cache que faz o MI300X parecer uma única GPU, o CDNA 3 também aprimora repetidamente a arquitetura da Compute Unit para lidar com o problema de utilização de FP32 do CDNA 2
- O CDNA 2 processava FP64 nativamente e oferecia FP32 em taxa dupla por meio de execução empacotada
- O compilador precisava empacotar dois valores FP32 em registradores adjacentes e executar a mesma instrução
- Sem o programador usar vetores explicitamente, muitas vezes era difícil para o compilador fazer isso bem
- O CDNA 3 contorna esse problema com um mecanismo de dual issue mais flexível
- Ele parece mais próximo de uma expansão do recurso de multi-issue do GCN do que do esquema VOPD/wave64 do RDNA 3
- A cada ciclo, o scheduler da CU escolhe um dos quatro SIMD e verifica se há threads prontas para execução
- Se várias threads estiverem prontas, o GCN podia enviar até cinco delas para as unidades de execução
- O dual issue do CDNA 3 provavelmente funciona melhor quando o programador, mais do que o compilador, expõe paralelismo em nível de thread com um dispatch size grande
- Se o SIMD estiver executando mais threads, aumenta a chance de encontrar ao mesmo tempo duas threads com instruções FP32
- É preciso ter pelo menos 2 threads ativas por SIMD para atingir o throughput total de FP32
- Na prática, é necessária uma occupancy maior por causa da latência de memória ou de execução
- A AMD aumentou muito a quantidade de threads que o SIMD do CDNA 3 pode rastrear, de 8 para 24
- Não foi mencionado aumento na capacidade do arquivo de registradores vetoriais, e essa capacidade muitas vezes limita o número de threads que um SIMD consegue manter ao mesmo tempo
- A capacidade de multi-issue pode funcionar melhor em kernels simples com baixo uso de registradores por thread
- O dual issue também pode transformar a largura de banda do arquivo de registradores em um problema
- O FP32 empacotado do CDNA 2 aproveitava portas largas do arquivo de registradores para transportar valores de 64 bits sem exigir leituras adicionais
- Instruções separadas podem referenciar registradores diferentes e exigir mais leituras
- A AMD afirma ter melhorado geracionalmente o source caching para que uma leitura de registrador vetorial dê suporte a mais operações vetoriais ou matriciais a jusante
- É possível que isso envolva um cache de registradores maior para aliviar conflitos de porta e alimentar dados às unidades de execução
Operações matriciais e desempenho em IA
- Com a expansão do machine learning, a importância da multiplicação de matrizes cresceu, e a Nvidia investiu pesado nessa área ao adicionar tensor cores no Volta e no Turing
- O AMD CDNA também suportava matrix multiply, mas as arquiteturas Nvidia da mesma época investiam mais no throughput matricial de tipos de dados de baixa precisão, como FP16
- O MI300X dobra o throughput matricial por CU em relação à geração anterior do CDNA
- O design em chiplets do MI300X permite um número muito alto de CUs, aumentando o throughput total
- A Nvidia continua sendo uma concorrente forte por ter alto desempenho matricial por SM, enquanto o CDNA 3, seguindo a linha da AMD, pressiona fortemente a Nvidia com desempenho vetorial FP64 e ao mesmo tempo mantém forte desempenho em IA por si só
Mudanças no cache de instruções
- A Compute Unit precisa buscar na memória não só os dados, mas também as próprias instruções
- Tradicionalmente, o código de GPU era simples e tinha tamanho reduzido, então a entrega de instruções era relativamente fácil
- As GPUs CDNA 2 e RDNA continuaram usando cache de instruções de 32 KB, mas a CDNA 3 aumentou isso para 64 KB
- a associatividade também aumentou de 4-way para 8-way
- isso eleva a taxa de acerto do cache de instruções em kernels maiores e mais complexos
- A AMD parece ter levado em conta casos em que código de CPU foi simplesmente portado para a GPU
- código de CPU complexo pode ser um peso para a GPU
- na GPU, é difícil esconder a latência de um cache miss de instruções com prefetch de instruções de longa distância e previsão de desvio precisa
- um cache de instruções maior ajuda a acomodar kernels grandes, e a associatividade mais alta reduz conflict misses
- Na CDNA 3, cada instância de cache de instruções é compartilhada por duas Compute Units, como na CDNA 2
- como kernels de GPU normalmente rodam com work size grande o suficiente para preencher muitas Compute Units, compartilhar o cache de instruções é uma forma eficiente de usar SRAM
- se mais Compute Units compartilhassem uma única instância de cache, poderia ser difícil atender à demanda de largura de banda de instruções
Diferenças entre MI300X e MI300A
- A maior mudança geracional da CDNA 3 está na hierarquia de memória, e a principal melhoria prática também está na adição do Infinity Cache
- O principal problema da MI250X era que ela estava mais próxima de duas GPUs no mesmo pacote do que de uma única GPU
- a largura de banda entre os dois GCDs era de 200 GB/s por direção
- a AMD concluiu que essa largura de banda não era suficiente para fazer a MI250X parecer uma única GPU, então aumentou bastante a largura de banda die-to-die
- A MI300 elevou a largura de banda total East-West para 2,4 TB/s por direção, um aumento de 12x em relação à MI250X
- a largura de banda total North-South é ainda maior, de 3,0 TB/s por direção
- com esse aumento de largura de banda, a MI300 pode parecer um único acelerador grande e integrado, em vez de dois aceleradores como a MI250X
- A largura de banda total de entrada de 4,0 TB/s de um único die de IO quase corresponde aos 4,2 TB/s que os dois XCDs podem usar, então na prática isso não é um grande problema
- ainda assim, um único die de IO não consegue aproveitar toda a largura de banda total de memória de 5,3 TB/s
- é parecido com a situação no Ryzen 7000, em que um único CCD não consegue utilizar totalmente a largura de banda da DDR5 por causa das limitações do Infinity Fabric
- na MI300X, a demanda por largura de banda é maior quando todos os dies trabalham juntos, e nesse caso cada die consome cerca de 1,3 TB/s, então obter 3/4 disso via cross-die link não é um problema
- A MI300A é uma APU “big iron” que reutiliza o mesmo base die e combina 6 XCDs CDNA3 com 24 núcleos Zen 4
- CPU e GPU podem compartilhar o mesmo espaço de endereçamento de memória
- isso elimina a necessidade de copiar dados por um barramento externo para manter a coerência entre CPU e GPU
1 comentários
Opiniões no Hacker News
Tecnicamente, as placas de consumo da AMD têm ótimo desempenho em computação. Por exemplo, o UE5 renderiza malhas triangulares via computação em vez de usar o pipeline gráfico https://www.youtube.com/watch?v=TMorJX3Nj6U
Além disso, como a nVidia priorizou ray tracing e DLSS em vez de desempenho de computação e largura de banda de memória, em muitos casos as placas da AMD ficam à frente das nVidia equivalentes.
O problema é que nenhuma empresa de tecnologia quer adicionar backends D3D ou Vulkan a bibliotecas de IA como o PyTorch. A nVidia não faz isso porque gosta do status quo; Intel e AMD não fazem porque querem substituir a CUDA por suas próprias alternativas proprietárias, em vez de APIs abertas de GPU
Ainda assim, não é nem segmentação de produto malfeita nem problema de arquitetura de alto nível. Produtos especializados fazem melhor aquilo para que foram feitos do que produtos de uso geral. A demanda por uma placa que seja boa tanto em computação quanto em jogos é pequena; essas pessoas existem, mas são poucas em comparação com quem se importa só com um dos lados.
O efeito de dividir a GCN em RDNA e CDNA foi imediato. Comparando a Radeon VII (GCN 5) com a RX 5700 XT (RDNA 1), em jogos elas ficam alternando a liderança e, em média, a Radeon VII fica ligeiramente à frente, mas a RX 5700 XT perde bastante em benchmarks de computação. Ambas são TSMC 7nm, mas a RX 5700 XT tem menos shaders (2560 contra 3840), um die menor (251 contra 311 mm2) e menor consumo (225 contra 300 W), mostrando que sua eficiência em jogos é muito melhor. Com consumo menor, menos ruído e preço centenas de dólares mais baixo, era uma placa muito mais atraente para gamers.
As placas CDNA parecem não ter componentes necessários para jogos, como unidades de saída de renderização. Por isso não há suporte oficial a DirectX, OpenGL ou Vulkan. Nunca vi um caso de alguém rodando jogos nelas. Em compensação, seu desempenho de computação é tão bom que, apesar do ecossistema CUDA dominante, várias empresas estão comprando essas placas em vez das da nVidia. Em 2013, um supercomputador baseado em GCN entrou no top 100, e esse foi o único sistema baseado em GCN no top 100. Hoje, 8 dos 10 supercomputadores mais eficientes em energia usam aceleradores CDNA, e o supercomputador mais rápido do mundo, número 1 geral, também usa CDNA
https://www.tomshardware.com/news/amd-enables-rocm-and-pytor...
No fundo, é uma empresa de hardware (como mostra também o histórico da Lisa Su) e demorou a aceitar que CUDA era o golpe decisivo. Lembro do @Bridgman, no Phoronix, travando uma batalha de retirada para tentar manter os desenvolvedores por perto. Era uma luta que não dava para vencer.
Até dá para entender em parte. A geração de hardware dos anos 80/90 enxerga instintivamente o hardware como o topo da stack, e a diretoria da AMD, incluindo Su, veio toda desse meio.
Kodura entendeu que a nVidia estava superando a AMD porque CUDA também rodava em placas de consumo. Por isso ele pressionou a Lisa Su pelo Radeon VII, e essa placa foi, até bem recentemente, a única placa de consumo com suporte do ROCm durante anos. Pouco depois ele foi, na prática, demitido, e a excelente RVII também foi rapidamente descontinuada. Depois entrou Wang e consolidou a separação entre consumo e profissional.
Agora a AMD está tentando desesperadamente voltar atrás, mas é tarde demais. Há vários tentando competir, mas na prática os únicos que valem mencionar são AAPL e Metal.
A AMD perdeu a oportunidade
Mesmo assim, isso não deve ter ajudado na adoção das placas AMD em cargas de computação. O legal da CUDA é que você não precisa de uma placa aceleradora especial para desenvolver código CUDA
A situação talvez fosse diferente se eles tivessem que comprar GPUs com o próprio dinheiro ou com verba de pesquisa pagando o mesmo preço de consumidores comuns.
Pessoalmente, acho muito antiética a forma como a NVidia se infiltra no meio acadêmico e nos ambientes de pesquisa universitária
Depois disso, continuou esperando e apostou várias vezes a empresa no fato de que o mercado para os produtos que ela criou “viria”.
Nos últimos anos isso de fato aconteceu, e se refletiu também no preço das ações. Os outros players estão basicamente 10 anos atrás e, considerando a euforia atual e a popularização dos fluxos de trabalho de IA/ML, parece quase impossível alguém alcançar
Em contraste, código CUDA continuou funcionando mesmo com novas gerações de placas Nvidia
A maioria está comprando A6000 ou superior pelo preço de consumidor em empresas como Exxact ou Supermicro
Desde a época da V100, ou seja, depois dos sistemas DGX-1, acho que nunca vi pesquisadores recebendo GPUs gratuitas
Ao contrário das CPUs, as GPUs não tentam compensar isso diretamente. Em vez de aceitar latências menores, elas aceitaram latências mais altas e paralelizaram de forma muito mais ampla, ou agressiva, do que as CPUs; inúmeros pseudo-threads paralelos fornecem o efeito de ocultação de latência
Dá para ver esse efeito, por exemplo, em apresentações sobre otimização de código em GPU
https://www.olcf.ornl.gov/wp-content/uploads/2019/12/03-CUDA...
As animações a partir do slide 11 são um exemplo disso
Ou seja, muito trabalho pode ser processado puramente em registradores e LDS, e o acesso à memória global é muito mais raro do que em CPUs, onde quase tudo fica na memória global e há algo em torno de 16 registradores arquiteturais
Ainda assim, a memória global é um problema. Não só por causa da latência, mas também por causa da largura de banda. Por isso RDNA2 e Ada adicionaram grandes quantidades de cache de último nível. Isso também ajuda a ocultar melhor a latência, mas o objetivo principal é funcionar como um amplificador de largura de banda
Very long instruction word (VLIW) se refere a uma arquitetura de conjunto de instruções projetada para explorar paralelismo em nível de instrução (ILP). Uma unidade central de processamento (CPU) comum geralmente permite que o programa apenas especifique instruções a serem executadas em sequência, mas um processador VLIW permite que o programa especifique explicitamente quais instruções devem ser executadas em paralelo. O objetivo desse projeto é obter maior desempenho evitando a complexidade inerente a outras abordagens
Métodos tradicionais para aumentar o desempenho de processadores incluem pipelining, que divide instruções em subetapas e executa algumas delas simultaneamente; arquiteturas superescalares, que enviam instruções individuais para serem executadas independentemente em partes diferentes do processador; e até execução fora de ordem, que executa instruções em uma ordem diferente da do programa. Essas abordagens tornam o hardware mais complexo, porque o processador precisa tomar internamente todas as decisões
https://en.wikipedia.org/wiki/Very_long_instruction_word
Não deu muito certo. Por isso era chamado de Itanic
A premissa era que o compilador conseguiria identificar dependências de forma suficientemente estática para colocar vários caminhos de execução sequenciais e alguns caminhos de execução com desvios dentro da mesma instrução. Mas, na prática, ficou claro que os compiladores não conseguiam fazer isso, então os processadores passaram a encontrar dinamicamente, a partir de um fluxo sequencial de instruções, quais dependências e instruções poderiam ser paralelizadas
Isso exige muito trabalho, muitos recursos do chip e muita energia. E funciona bem só até certo ponto; depois disso, bate em retornos decrescentes. Parece que é exatamente aí que estamos hoje
Não se trata da linguagem usada para enviar instruções, mas do próprio modo de processamento
E também vale ter em mente que termos como VLIW4 ou VLIW5 se referem a implementações específicas
https://en.wikipedia.org/wiki/Single_instruction,_multiple_d...
0: https://en.m.wikipedia.org/wiki/Amazon_Elastic_Compute_Cloud
1: https://trends.google.com/trends/explore?date=all&q=Compute&...