Perspectiva: MultiClet S1

Então, é hora de falar sobre a próxima geração de processadores multicelulares: MultiClet S1. Se esta é a primeira vez que você os conhece, verifique a história e a ideologia da arquitetura nestes artigos:

• "Um processador multicelular é o quê?"
• "Multiclet R1 - os primeiros testes"
• "Compilador C / C ++ baseado em LLVM para processadores multicelulares: ser ou não ser?"

No momento, o novo processador está em desenvolvimento, mas os primeiros resultados já apareceram e você pode avaliar do que ele será capaz.

Vamos começar com as maiores mudanças: recursos básicos.

Características

Está previsto atingir os seguintes indicadores:

1. Número de células: 64
2. Processo técnico: 28 nm
3. Frequência de clock: 1,6 GHz
4. O tamanho da memória no chip: 8 MB
5. Área de cristal: 40mm ²
6. Consumo de energia: 6 W

Os números reais serão anunciados com base nos resultados dos testes de amostras fabricadas em 2019. Além das características do próprio chip, o processador suporta até 16 GB de RAM padrão DDR4 3200MHz, barramento PCI Express e PLL.

Deve-se notar que o processo de fabricação de 28 nm é a faixa familiar mais baixa que não requer permissões especiais de uso, por isso foi ele quem foi escolhido. Pelo número de células, diferentes opções foram consideradas: 128 e 256, mas com um aumento na área do cristal, a porcentagem de rejeitos aumenta. Estabelecemos 64 células e, consequentemente, uma área relativamente pequena, o que proporcionará um rendimento maior de cristais adequados na placa. É possível um maior desenvolvimento na estrutura do ICS (sistema no caso) , onde será possível combinar vários cristais de 64 células em um caso.

Deve-se dizer que o objetivo e o uso do processador estão mudando radicalmente. O S1 não será um microprocessador projetado para incorporação, como P1 e R1, mas um acelerador de cálculos. Assim como a GPGPU, uma placa baseada em S1 pode ser inserida na placa-mãe PCI Express de um PC comum e usada para processamento de dados.

Arquitetura

No S1, o "multicel" é agora a unidade computacional mínima: um conjunto de 4 células executando uma certa sequência de comandos. Inicialmente, planejava-se combinar multicélulas em grupos chamados cluster para execução conjunta de comandos: um cluster precisava conter 4 multicells, no total havia 4 clusters separados no cristal. No entanto, cada célula tem uma conexão completa com todas as outras células do aglomerado e, com um aumento no grupo de ligações, torna-se excessiva, o que complica muito o design topológico do microcircuito e reduz suas características. Portanto, eles decidiram abandonar a divisão de cluster, uma vez que a complicação não justifica os resultados. Além disso, para obter o desempenho máximo, é mais benéfico executar o código em paralelo em cada multicell. Total, agora o processador contém 16 multicélulas separadas.

Um multicelular, embora constituído por 4 células, difere de um R1 de 4 células, no qual cada célula possui sua própria memória, seu próprio bloco de comandos de amostra e sua própria ULA. S1 é organizado de maneira um pouco diferente. A ALU possui 2 partes: um bloco aritmético de ponto flutuante e um bloco aritmético inteiro. Cada célula possui um bloco inteiro separado, mas existem apenas dois blocos com um ponto flutuante em uma multicélula e, portanto, dois pares de células os dividem entre si. Isso foi feito principalmente para reduzir a área do cristal: a aritmética de ponto flutuante de 64 bits, em contraste com a aritmética inteira, ocupa muito espaço. Ter uma ALU em cada célula acabou sendo redundante: os comandos de busca não fornecem o carregamento da ALU e eles estão ociosos. Embora reduza o número de blocos da ALU e mantenha o ritmo de busca de comandos e dados, como a prática demonstrou, o tempo total para resolver problemas praticamente não muda ou muda um pouco, e os blocos da ALU estão totalmente carregados. Além disso, a aritmética de ponto flutuante não é usada com tanta freqüência quanto com número inteiro.

Uma vista esquemática dos blocos dos processadores R1 e S1 é mostrada no diagrama abaixo. Aqui:

• CU (Unidade de controle) - unidade de busca de instruções
• ALU _FX - unidade lógica aritmética da aritmética inteira
• ALU _FP - Unidade lógica aritmética da aritmética de ponto flutuante
• DMS (Data Memory Scheduler) - unidade de controle de memória de dados
• DM - memória de dados
• PMS (Program Memory Scheduler) - programa de controle de memória
• PM - memória de programa

Diferenças arquitetônicas S1:

1. As equipes agora podem acessar os resultados da equipe dos parágrafos anteriores. Essa é uma alteração muito importante que permite acelerar significativamente as transições ao ramificar o código. Os processadores P1 e R1 não tiveram escolha a não ser gravar os resultados desejados na memória e lê-los imediatamente de volta com os primeiros comandos no novo parágrafo. Mesmo ao usar memória em um chip, as operações de gravação e leitura levam de 2 a 5 ciclos cada, o que pode ser salvo simplesmente referindo-se ao resultado do comando do parágrafo anterior
2. A gravação na memória e nos registros agora ocorre imediatamente, e não no final de um parágrafo, o que permite que você comece a escrever comandos antes do final do parágrafo. Como resultado, o tempo de inatividade potencial entre parágrafos é reduzido.
3. O sistema de comando foi otimizado, a saber:
   
   • Adicionado aritmética de número inteiro de 64 bits: adição, subtração, multiplicação de números de 32 bits, que retorna um resultado de 64 bits.
   • O método de leitura da memória foi alterado: agora para qualquer comando, você pode simplesmente especificar o endereço do qual deseja ler os dados como argumento, enquanto a ordem de execução dos comandos de leitura e gravação é preservada.
     
     Também tornou obsoleto um comando de leitura de memória separado. Em vez disso, o comando load value é usado na opção load (anteriormente, get ), especificando o endereço na memória como argumento:
     
     

     .data foo: .long 0x1234 .text habr: load_l foo ;      foo load_l [foo] ;    0x1234 add_l [foo], 0xABCD ;       ;   complete 

     
     
   • Foi adicionado um formato de comando que permite o uso de 2 argumentos constantes.
     Anteriormente, era possível especificar uma constante apenas como um segundo argumento, o primeiro argumento sempre deve ser um link para o resultado no comutador. A alteração se aplica a todas as equipes de dois argumentos. O campo constante é sempre de 32 bits, portanto esse formato permite, por exemplo, gerar constantes de 64 bits com um comando.
     
     Foi:
     
     

      load_l 0x12345678 patch_q @1, 0xDEADBEEF 

     
     Tornou-se:
     
     

      patch_q 0x12345678, 0xDEADBEEF 

     
     
   • Tipos de dados vetoriais modificados e suplementados.
     O que costumava ser chamado de tipos de dados "compactados" agora pode ser chamado de vetorial com segurança. Em P1 e R1, as operações em números compactados levaram apenas uma constante como o segundo argumento, isto é, por exemplo, ao adicionar, cada elemento do vetor foi adicionado com o mesmo número e isso não pôde ser aplicado de maneira inteligente. Agora, operações semelhantes podem ser aplicadas a dois vetores completos. Além disso, essa maneira de trabalhar com vetores é totalmente consistente com o mecanismo de vetores no LLVM, que agora permite ao compilador gerar código usando tipos de vetores.
     
     

      patch_q 0x00010002, 0x00030004 patch_q 0x00020003, 0x00040005 mul_ps @1, @2 ;  - 00020006000C0014 

     
     
   
   
4. Sinalizadores do processador removidos.
   
   Como resultado, foram removidas cerca de 40 equipes baseadas apenas nos valores das bandeiras. Isso reduziu significativamente o número de equipes e, consequentemente, a área do cristal. E todas as informações necessárias agora são armazenadas diretamente na célula do switch.
   
   
   • Ao comparar com zero, em vez do sinalizador zero, agora apenas o valor no comutador é usado
   • Em vez do sinalizador, agora é usado um bit correspondente ao tipo de comando: 7º para byte, 15º para abreviação, 31º para long, 63º para long, 63º para quad. Devido ao fato de o caractere se multiplicar até o 63º bit, independentemente do tipo, você pode comparar números de tipos diferentes:
     
     

      .data long: .long -0x1000 byte: .byte -0x10 .text habr: a := load_b [byte] ;     0xFFFFFFFFFFFFFFF0, ;   byte 7    63. b := loadu_b [byte] ;     0x00000000000000F0, ; ..  loadu_b    c := load_l [long] ;     0xFFFFFFFFFFFFF000. ge_l @a, @c ;   "  "  1: ;   31 ,   . lt_s @a, @b ; 1, .. b     complete 

     
     
   • O sinalizador de transporte não é mais necessário, pois há aritmética de 64 bits
   
   
5. O tempo de transição de parágrafo para parágrafo foi reduzido para 1 medida (em vez de 2-3 em R1)

Compilador baseado em LLVM

O compilador da linguagem C para S1 é semelhante ao R1 e, como a arquitetura não mudou fundamentalmente, os problemas descritos no artigo anterior, infelizmente, não desapareceram.

No entanto, no processo de implementação do novo sistema de comando, a quantidade de código de saída diminuiu por si só, simplesmente devido à atualização do sistema de comando. Além disso, existem muitas otimizações menores que reduzirão o número de instruções no código, algumas das quais já foram executadas (por exemplo, gerar constantes de 64 bits com uma única instrução). Mas há otimizações ainda mais sérias que precisam ser feitas e elas podem ser construídas em ordem crescente de eficiência e complexidade de implementação:

1. A capacidade de gerar todos os comandos de dois argumentos com duas constantes.
   
   Gerar uma constante de 64 bits via patch_q é apenas um caso especial, mas precisamos de um caso geral. De fato, o objetivo dessa otimização é permitir que as equipes substituam apenas o primeiro argumento como uma constante, uma vez que o segundo argumento sempre pode ser uma constante, e isso tem sido implementado há muito tempo. Esse não é um caso muito frequente, mas, por exemplo, quando você precisa chamar uma função e escrever o endereço de retorno na parte superior da pilha, pode
   
   

    load_l func wr_l @1, #SP 

   
   otimizar para
   
   

    wr_l func, #SP 

   
   
2. A capacidade de substituir o acesso à memória por meio de um argumento em qualquer comando.
   Por exemplo, se você precisar adicionar dois números da memória, poderá
   
   

    load_l [foo] load_l [bar] add_l @1, @2 

   
   otimizar para
   
   

    add_l [foo], [bar] 

   
   Essa otimização é uma extensão da anterior, no entanto, a análise já é necessária aqui: essa substituição só pode ser realizada se os valores carregados forem usados ​​apenas uma vez neste comando de adição e em nenhum outro lugar. Se o resultado da leitura for usado mesmo em apenas dois comandos, é mais lucrativo ler da memória uma vez como um comando separado e nos outros dois referenciá-lo através do switch.
   
3. Otimização da transferência de registros virtuais entre unidades base.
   Para R1, a transferência de todos os registradores virtuais foi feita através da memória, o que gera um número muito grande de leituras e gravações na memória, mas simplesmente não havia outra maneira de transferir dados entre parágrafos. S1 permite acessar os resultados dos comandos dos parágrafos anteriores; portanto, teoricamente, muitas operações de memória podem ser removidas, o que daria o maior efeito entre todas as otimizações. No entanto, essa abordagem ainda é limitada pela opção: não mais que 63 resultados anteriores, tão longe de toda transferência do registro virtual pode ser implementada dessa maneira. Como fazer isso não é uma tarefa trivial, e uma análise das possibilidades para resolvê-lo ainda precisa ser feita. As fontes do compilador podem aparecer em domínio público; portanto, se alguém tiver idéias e você desejar ingressar no desenvolvimento, você poderá fazê-lo.
   

Benchmarks

Como o processador ainda não foi lançado no chip, é difícil avaliar seu desempenho real. No entanto, o código do kernel RTL já está pronto, o que significa que você pode fazer uma avaliação usando simulação ou FPGA. Para executar os seguintes benchmarks, usamos uma simulação usando o programa ModelSim para calcular o tempo exato de execução (em medidas). Como é difícil simular todo o cristal e leva muito tempo, portanto, uma multicélula foi simulada e o resultado foi multiplicado por 16 (se a tarefa foi projetada para multithreading), pois cada multicélula pode funcionar completamente independentemente das outras.

Ao mesmo tempo, a modelagem multicelular foi realizada no Xilinx Virtex-6 para testar o desempenho do código do processador em hardware real.

Coremark

CoreMark - um conjunto de testes para uma avaliação abrangente do desempenho de microcontroladores e processadores centrais, bem como de seus compiladores C. Como você pode ver, o processador S1 não é um nem o outro. No entanto, pretende-se executar um código absolutamente arbitrário, ou seja, qualquer pessoa que possa estar executando no processador central. Portanto, o CoreMark é adequado para avaliar o desempenho do S1 não pior.

O CoreMark contém trabalho com listas vinculadas, matrizes, uma máquina de estado e cálculo de soma de CRC . Em geral, a maior parte do código acaba sendo estritamente sequencial (que testa a força do paralelismo multicelular de hardware ) e com muitas ramificações, motivo pelo qual os recursos do compilador desempenham um papel significativo no desempenho final. O código compilado contém alguns parágrafos curtos e, apesar do aumento da velocidade de transição entre eles, a ramificação inclui o trabalho com memória, o que gostaríamos de evitar ao máximo.

Cartão de pontuação CoreMark:

	Multiclet R1 (compilador llvm)	Multiclet S1 (compilador llvm)	Elbrus-4C (R500 / E)	Texas Inst. AM5728 ARM Cortex-A15	Baikal-t1	Intel Core i7 7700K
Ano de fabricação	2015	2019	2014	2018	2016	2017
Frequência de clock, MHz	100	1600	700	1500	1200	4500
Pontuação geral do CoreMark	59.	18356	1214	15789	13142	182128
Coremark / MHz	0,59	11,47	5.05	10,53	10,95	40,47

O resultado de um multicell é 1147, ou 0,72 / MHz, que é maior que o de R1. Isso fala das vantagens do desenvolvimento de arquitetura multicelular no novo processador.

Wheatstone

Whetstone - um conjunto de testes para medir o desempenho do processador ao trabalhar com números de ponto flutuante. Aqui a situação é muito melhor: o código também é seqüencial, mas sem um grande número de ramificações e com boa simultaneidade interna.

O Whetstone consiste em muitos módulos, o que permite medir não apenas o resultado geral, mas também o desempenho em cada módulo específico:

1. Elementos de matriz
2. Matriz como parâmetro
3. Saltos condicionais
4. Aritmética de número inteiro
5. Funções trigonométricas (tan, sin, cos)
6. Chamadas de procedimento
7. Referências de matriz
8. Funções padrão (sqrt, exp, log)

Eles são divididos em categorias: os módulos 1, 2 e 6 medem o desempenho das operações de ponto flutuante (linhas MFLOPS1-3); módulos 5 e 8 - funções matemáticas (COS MOPS, EXP MOPS); módulos 4 e 7 - aritmética de números inteiros (FIXPT MOPS, IGUAL MOPS); módulo 3 - saltos condicionais (SE MOPS). Na tabela abaixo, a segunda linha do MWIPS é um indicador geral.

Ao contrário do CoreMark, o Whetstone será comparado em um núcleo ou, como no nosso caso, em uma multicélula. Como o número de núcleos é muito diferente em diferentes processadores, para a pureza do experimento, consideramos os indicadores por megahertz.

Cartão de pontuação da pedra de amolar:

CPU	MultiClet R1	MultiClet S1	Core i7 4820K	ARM v8-A53
Frequência, MHz	100	1600	3900	1300
MWIPS / MHz	0,311	0,343	0,887	0,642
MFLOPS1 / MHz	0,157	0,156	0,341	0,268
MFLOPS2 / MHz	0,153	0,111	0,308	0,241
MFLOPS3 / MHz	0,029	0,124	0,167	0,239
MOPS COS / MHz	0,018	0,008	0,023	0,028
MOPS EXP / MHz	0,008	0,005	0,014	0,004
FIXPT MOPS / MHz	0,714	0,116	0,998	1.197
SE MOPS / MHz	0,081	0,196	1,504	1.436
MOPS IGUAIS / MHz	0,143	0,149	0,251	0,439

O Whetstone contém operações computacionais muito mais diretamente do que o CoreMark (o que é muito perceptível quando se olha o código abaixo), por isso é importante lembrar aqui: o número de ALUs de ponto flutuante é reduzido pela metade. No entanto, a velocidade de computação quase não foi afetada, em comparação com R1.

Alguns módulos se encaixam muito bem em uma arquitetura multicelular. Por exemplo, o módulo 2 conta muitos valores em um ciclo e, graças ao suporte total de números de ponto flutuante de precisão dupla, tanto pelo processador quanto pelo compilador, após a compilação, obtemos parágrafos grandes e bonitos que realmente revelam os recursos computacionais de uma arquitetura multicelular:

popcnt

Para refletir as características da própria arquitetura (independentemente do compilador), mediremos algo escrito no assembler, levando em consideração todos os recursos da arquitetura. Por exemplo, contando os bits da unidade em um número de 512 bits (popcnt). Por óbvio, pegaremos os resultados de uma multicélula, para que possam ser comparados com R1.

Tabela de comparação, o número de ciclos de clock por ciclo de cálculo de 32 bits:

Algoritmo	Multiclet r1	Multiclet S1 (um multicell)
Bithacks	5.0	2.625

Novas instruções vetoriais atualizadas foram usadas aqui, o que nos permitiu reduzir pela metade o número de instruções em comparação com o mesmo algoritmo implementado no assembler R1. A velocidade do trabalho, respectivamente, aumentou quase duas vezes.

Ethereum

Os benchmarks são, é claro, bons, mas temos uma tarefa específica: criar um acelerador de computação, e seria bom saber como ele lida com tarefas reais. As criptomoedas modernas são as mais adequadas para essa verificação, porque os algoritmos de mineração são executados em muitos dispositivos diferentes e, portanto, podem servir como referência para comparação. Começamos com o Ethereum e o algoritmo Ethash, que é executado diretamente no dispositivo de mineração.

A escolha do Ethereum deveu-se às seguintes considerações. Como você sabe, algoritmos como o Bitcoin são implementados com muita eficiência por chips ASIC especializados, de modo que o uso de processadores ou placas de vídeo para minerar o Bitcoin e seus clones se torna economicamente desvantajoso devido ao baixo desempenho e alto consumo de energia. A comunidade de mineradores, na tentativa de fugir dessa situação, está desenvolvendo criptomoedas em outros princípios algorítmicos, concentrando-se no desenvolvimento de algoritmos que usam processadores de uso geral ou placas de vídeo para mineração. É provável que esta tendência continue no futuro. Ethereum é a criptomoeda mais famosa com base nessa abordagem. A principal ferramenta para mineração do Ethereum são as placas de vídeo, que em termos de eficiência (hashrate / TDP) estão significativamente (várias vezes) à frente dos processadores de uso geral.

Ethash é um algoritmo chamado de limite de memória , ou seja, seu tempo de cálculo é limitado principalmente pela quantidade e velocidade da memória, e não pela velocidade dos próprios cálculos. Agora, para a mineração Ethereum, as placas de vídeo são as mais adequadas, mas sua capacidade de executar muitas operações simultaneamente não ajuda muito, e ainda permanecem na velocidade da RAM, o que é claramente demonstrado neste artigo . A partir daí, você pode tirar uma foto ilustrando a operação do algoritmo para explicar por que isso acontece.



O artigo divide o algoritmo em 6 pontos, mas é possível distinguir três estágios para uma obviedade ainda maior:

1. Início: SHA-3 (512) para calcular o Mix 0 original de 128 bytes (ponto 1)
2. Recálculo de 64 vezes da matriz Mix, lendo os próximos 128 bytes e misturando-os com os anteriores através da função de mixagem, para um total de 8 kilobytes (parágrafos 2-4)
3. Finalização e verificação do resultado

A leitura aleatória de 128 bytes da RAM leva muito mais tempo do que parece. Se você usar a placa de vídeo MSI RX 470, que possui 2048 dispositivos de computação e uma largura de banda de memória máxima de 211,2 GB / s, para equipar cada dispositivo, você precisa de 1 / (211,2 GB / (128 b * 2048)) = 1241 ns ou cerca de 1496 ciclos em uma determinada frequência. Dado o tamanho da função de mixagem, podemos assumir que leva várias vezes mais tempo para ler a memória de uma placa de vídeo do que para recalcular as informações recebidas. Como resultado, o estágio 2 do algoritmo leva muito tempo, muito mais do que os estágios 1 e 3, que no final têm pouco efeito no desempenho, apesar de conterem mais cálculos (principalmente no SHA-3). Você pode ver o hashrate desta placa de vídeo: 26.375 megachashes / s teóricos (limitado apenas pela largura de banda da memória) versus 24 megachehes / s reais, ou seja, os estágios 1 e 3 levam apenas 10% do tempo.

No S1, todos os 16 multicells podem funcionar em paralelo e em código diferente. Além disso, a RAM de canal duplo será instalada, ao longo de um canal para 8 multicells. No estágio 2 do algoritmo Ethash, nosso plano é o seguinte: uma multicélula lê 128 bytes da memória e começa a recontá-los, depois a próxima lê a memória e reconta, e assim por diante até o dia 8, ou seja, uma multicélula, após ler 128 bytes de memória, possui 7 * [tempo de leitura de 128 bytes] para recalcular a matriz. Supõe-se que essa leitura levará 16 ciclos, ou seja, 112 medidas são dadas para recontagem. O cálculo da função de mixagem leva aproximadamente o mesmo ciclo de clock, portanto, o S1 está próximo da proporção ideal de largura de banda da memória e desempenho do processador. Como o tempo não é desperdiçado no segundo estágio, as partes restantes do algoritmo devem ser otimizadas o máximo possível, pois elas realmente afetam o desempenho.

Para avaliar a velocidade de computação SHA-3 (Keccak), um programa C foi desenvolvido e testado, com base no qual sua versão ideal no assembler está sendo criada. A programação de avaliação mostra que uma multicélula executa o cálculo de SHA-3 (Keccak) em 1550 ciclos de clock. Portanto, o tempo total para calcular um hash por um multicelular será 1550 + 64 * (16 + 112) = 9742 ciclos. Com uma frequência de 1,6 GHz e 16 multicélulas paralelas, a taxa de hash do processador será de 2,6 MHash / s.

Acelerador	MultiClet S1	NVIDIA GeForce GTX 980 Ti	Radeon RX 470	Radeon RX Vega 64	NVIDIA GeForce GTX 1060	NVIDIA GeForce GTX 1080 Ti
Preço		$ 650	$ 180	$ 500	$ 300	$ 700
Taxa de hash	2,6 MHash / s	21,6 MHash / s	25,8 MHash / s	43,5 MHash / s	25 MHash / s	55 MHash / s
TDP	6 W	250 W	120 W	295 W	120 W	250 W
Hashrate / TDP	0,43	0,09	0,22	0,15	0,22	0,21
Tecnologia de processo	28 nm	28 nm	14 nm	14 nm	16 nm	16 nm

Ao usar o MultiClet S1 como uma ferramenta de mineração, 20 ou mais processadores podem realmente ser instalados nas placas. Nesse caso, o hashrate de uma placa desse tipo será igual ou superior ao hashrates das placas de vídeo existentes, enquanto o consumo de energia de uma placa com S1 será metade, mesmo que o de placas de vídeo com padrões topográficos de 16 e 14 nm.

Concluindo, devo dizer que a principal tarefa agora é a fabricação de uma placa multiprocessadora para um minerador de criptomoeda multicelular e um supercomputador. A competitividade está planejada para ser alcançada devido ao pequeno consumo de energia e arquitetura, o que é adequado para computação arbitrária.

O processador ainda está em desenvolvimento, mas você já pode iniciar a programação em linguagem assembly, bem como avaliar a versão atual do compilador. Já existe um SDK mínimo contendo montador, vinculador, compilador e modelo funcional, no qual você pode iniciar e testar seus programas.