Como um FPGA pode superar uma CPU?

Ouvi falar de pessoas que usam FPGAs para melhorar o desempenho de sistemas que fazem coisas como mineração de moedas, comércio eletrônico e dobragem de proteínas.

Como um FPGA pode competir com uma CPU no desempenho, quando a CPU normalmente está executando pelo menos uma ordem de magnitude mais rápida (em termos de velocidade do relógio)?

As CPUs são dispositivos de processamento seqüencial. Eles dividem um algoritmo em uma sequência de operações e os executam um de cada vez.

Os FPGA são (ou podem ser configurados como) dispositivos de processamento paralelo. Um algoritmo inteiro pode ser executado em um único tique do relógio, ou, na pior das hipóteses, muito menos tiques do que um processador seqüencial. Um dos custos para o aumento da complexidade lógica é tipicamente um limite mais baixo no qual o dispositivo pode ter clock.

Tendo isso em mente, os FPGAs podem superar a CPU fazendo determinadas tarefas, porque podem fazer a mesma tarefa em menos clock, embora com uma freqüência geral mais baixa. Os ganhos que podem ser alcançados são altamente dependentes do algoritmo, mas pelo menos uma ordem de grandeza não é atípica para algo como uma FFT.

Além disso, como você pode criar várias unidades de execução paralela em um FPGA, se você tiver um grande volume de dados que deseja passar pelo mesmo algoritmo, poderá distribuir os dados pelas unidades de execução paralela e obter mais ordens de magnitude com maior taxa de transferência do que pode ser alcançado mesmo com uma CPU multi-core.

O preço que você paga pelas vantagens é o consumo de energia e os $$$.

Markt tem isso principalmente, mas vou jogar meus 2 centavos aqui:

Imagine que eu lhe disse que queria escrever um programa que revertesse a ordem dos bits dentro de um número inteiro de 32 bits. Algo assim:

int reverseBits(int input) {
    output = 0;
    for(int i = 0;i < 32;i++) {
        // Check if the lowest bit is set
        if(input & 1 != 0) {
            output = output | 1; // set the lowest bit to match in the output!
        }

        input = input >> 1;
        output = output << 1;
    }
    return output;
}

Agora, minha implementação não é elegante, mas tenho certeza de que você concorda que haveria um número de operações envolvidas e provavelmente algum tipo de loop. Isso significa que na CPU você gastou muito mais de 1 ciclo para implementar esta operação.

Em um FPGA, você pode simplesmente conectar isso como um par de travas. Você coloca seus dados em algum registro e os conecta a outro registro na ordem de bits reversa. Isso significa que a operação será concluída em um único ciclo de relógio no FPGA. Assim, em um único ciclo, o FPGS concluiu uma operação que levou muitos milhares de ciclos à sua CPU de uso geral! Além disso, você pode conectar provavelmente algumas centenas desses registros em paralelo. Portanto, se você puder mover algumas centenas de números para o FPGA, em um único ciclo, ele terminará essas milhares de operações centenas de vezes, tudo em um ciclo de relógio FPGA.

Há muitas coisas que uma CPU de uso geral pode fazer, mas como limitação, configuramos instruções simples e generalizadas que necessariamente precisam ser expandidas em listas de instruções simples para concluir algumas tarefas. Assim, eu poderia fazer com que a CPU de uso geral tivesse uma instrução como "ordem inversa de bits para registro de 32 bits" e fornecer à CPU a mesma capacidade que o FPGA que acabamos de criar, mas há um número infinito dessas instruções úteis possíveis e, portanto, coloque apenas aqueles que justificam o custo nas CPUs populares.

Todos os FPGAs, CPLDs e ASICs oferecem acesso ao hardware bruto, o que permite definir operações malucas como "descriptografar bytes criptografados AES256 com a chave" ou "decodificar o quadro do vídeo h.264". Eles possuem latências de mais de um ciclo de clock em um FPGA, mas podem ser implementados de maneiras muito mais eficientes do que escrever a operação em milhões de linhas de código de montagem de uso geral. Isso também tem o benefício de tornar o FPGA / ASIC de finalidade fixa para muitas dessas operações mais eficientes em termos de energia, porque eles não precisam fazer tanto trabalho estranho!

O paralelismo é a outra parte que markt apontou e, embora isso seja importante, o principal é quando um FPGA paralela algo que já era caro na CPU em termos de ciclos necessários para executar a operação. Quando você começa a dizer "Eu posso executar em 10 ciclos de FPGA uma tarefa que leva 100.000 ciclos à minha CPU, e eu posso executar essa tarefa em paralelo 4 itens por vez", você pode ver facilmente por que um FPGA pode ser muito mais rápido que uma CPU!

Então, por que não usamos FPGAs, CPLDs e ASICs para tudo? Porque, em geral, é um chip inteiro que não faz nada além de uma operação. Isso significa que, embora você possa obter um processo para executar muitas ordens de magnitude mais rapidamente no seu FPGA / ASIC, não será possível alterá-lo mais tarde quando essa operação não for mais útil. O motivo pelo qual você não pode (geralmente) alterar um FPGA quando está em um circuito é que a fiação da interface é fixa e, normalmente, o circuito não inclui componentes que permitem reprogramar o FPGA em uma configuração mais útil. Alguns pesquisadores estão tentando construir módulos híbridos FPGA-CPU, onde há uma seção da CPU capaz de ser reconectada / reprogramada como um FPGA, permitindo que você "carregue" uma seção eficaz da CPU,

Todas as outras respostas populares apresentadas aqui falam sobre diferenças literais entre FPGAs e CPUs. Eles apontam a natureza paralela do FPGA versus a natureza seqüencial de uma CPU ou dão exemplos de por que certos algoritmos podem funcionar bem em um FPGA. Tudo isso é bom e verdadeiro, mas eu sugeriria, no entanto, que há uma diferença mais fundamental entre CPUs e FPGAs.

Qual é o denominador comum entre um FPGA e uma CPU? É que ambos são construídos sobre silicone. E, em alguns casos, literalmente, os mesmos processos de silício.

A diferença fundamental são as abstrações que empilhamos sobre esse silício. Não é possível para um ser humano entender os detalhes completos de um único design moderno de CPU, do silício ao IC empacotado. Assim, como parte do processo de engenharia, dividimos esse problema complexo em problemas menores e fáceis de administrar, com os quais os humanos podem entender.

Considere o que é necessário para transformar esse silício em uma CPU em funcionamento. Aqui está uma visão um pouco simplificada das camadas de abstração necessárias para esse objetivo:

1. Primeiro, temos engenheiros que sabem como criar transistores a partir de silício. Eles sabem como projetar transistores minúsculos que consomem energia e comutam na taxa de 10 ou mesmo 100 gigahertz, e sabem como projetar transistores robustos que podem gerar sinais com energia suficiente para enviá-los de um pacote de IC e através de uma PCB para outro chip.

2. Depois, temos designers de lógica digital que sabem como reunir esses transistores em bibliotecas com centenas de células lógicas diferentes. Portões lógicos, chinelos, muxes e somadores, para citar alguns. Tudo em uma variedade de configurações.

3. A seguir, temos vários grupos de engenheiros que sabem como montar esses blocos digitais (e às vezes analógicos) para formar blocos funcionais de nível superior, como transceptores de alta velocidade, controladores de memória, preditores de ramificação, ALUs, etc.

4. Então, temos designers de CPU para arquitetar projetos de CPU de ponta, reunindo essas unidades funcionais em um sistema completo.

E não para por aí. Neste ponto, temos uma CPU funcional que executa o código de montagem, mas essa não é uma linguagem que a maioria dos programadores escreve atualmente.

5. Podemos ter um compilador C para compilar no código de montagem (provavelmente através de alguma representação intermediária)
6. Poderíamos adicionar outra abstração em cima de C para obter uma linguagem orientada a objetos
7. Podemos até escrever uma máquina virtual sobre C ou C ++ para interpretar coisas como código de bytes Java

E as camadas de abstração podem continuar a partir daí. O ponto importante aqui é que essas camadas de abstração se combinam para produzir um sistema baseado em CPU que escala enormemente e custa uma pequena fração de um design de silicone personalizado.

No entanto, o ponto importante a ser destacado aqui é que cada abstração também acarreta um custo. O designer do transistor não cria o transistor perfeito para todos os casos de uso. Ele constrói uma biblioteca razoável e, portanto, às vezes é usado um transistor que consome um pouco mais de energia ou um pouco mais de silício do que o necessário para o trabalho em questão. Da mesma forma, os designers de lógica não constroem todas as células lógicas possíveis. Eles podem construir um portão NAND de 4 entradas e um portão NAND de 8 entradas, mas o que acontece quando outro engenheiro precisa de um NAND de 6 entradas? Ele usa uma porta NAND de 8 entradas e amarra 2 entradas não utilizadas, o que resulta em perda de recursos de silício e energia da cintura. E assim sobe a cadeia de abstrações. Cada camada nos fornece uma maneira de lidar com a complexidade,

Agora compare essas abstrações com o que é necessário para um FPGA. Essencialmente, as abstrações do FPGA param em # 2 na lista acima. O FPGA permite que os desenvolvedores trabalhem na camada de lógica digital. É um pouco mais sofisticado do que isso, porque as CPUs são 'codificadas' nesta camada e os FPGAs devem ser configurados no tempo de execução (que, BTW, é o motivo pelo qual as CPUs normalmente executam frequências muito mais altas), mas a verdade importante é que isso está longe poucas abstrações para FPGAs do que para CPUs.

Então, por que um FPGA pode ser mais rápido que uma CPU? Em essência, é porque o FPGA usa muito menos abstrações que uma CPU, o que significa que o designer trabalha mais próximo do silício. Ele não paga os custos de todas as muitas camadas de abstração necessárias para as CPUs. Ele codifica em um nível mais baixo e precisa trabalhar mais para obter um determinado nível de funcionalidade, mas a recompensa é que ele obtém um desempenho superior.

Mas é claro que também há um lado negativo em menos abstrações. Todas essas abstrações de CPU estão lá por um bom motivo. Eles nos dão um paradigma de codificação muito mais simples, o que significa que mais pessoas podem se desenvolver facilmente para elas. Isso, por sua vez, significa que existem muitos outros designs de CPU e, portanto, temos enormes benefícios de preço / escala / tempo de colocação no mercado das CPUs.

Então aí está. Os FPGAs têm menos abstrações e, portanto, podem ser mais rápidos e mais eficientes em termos de energia, mas difíceis de programar. As CPUs têm muitas abstrações projetadas para torná-las fáceis de desenvolver, escaláveis ​​e baratas. Mas eles perdem velocidade e poder no comércio por esses benefícios.

Embora as outras respostas estejam todas corretas, nenhuma delas ainda aborda o exemplo de mineração de bitcoin da sua pergunta, que é realmente um exemplo decente. A mineração de Bitcoin envolve o cálculo repetido de uma função de hash criptográfico, SHA-256 do resultado de outro cálculo SHA-256, de dados em que apenas um único número inteiro de 32 bits é alterado, até que o hash resultante tenha certas propriedades. Cada SHA-256 consiste em 64 repetições do mesmo algoritmo, envolvendo adições de 32 bits, turnos de bits e mais algumas operações de manipulação de bits.

Se você programar esse loop em uma CPU de 32 bits (ou mais), encontrará seu conjunto de instruções muito adequado para a tarefa - o SHA-256 foi projetado para executar com eficiência nas CPUs. Ainda assim, você estará usando apenas 2% da área de silício de uma CPU moderna, com funcionalidade intensiva em área, como cache, multiplicação, divisão, operação de ponto flutuante, previsão de ramificação e brach, etc. aumento de desempenho para esta tarefa específica.

Em hardware configurável como um FPGA, você simplesmente implementa esses 2% e otimiza ainda mais esquecendo tudo sobre a execução de código, em vez de projetar portas para calcular diretamente cada uma dessas subfunções frequentemente repetidas. Com pipelines, de modo que cada um deles passe um resultado para o próximo ciclo de cada relógio e repetido 128 vezes (e com alguma lógica adicional especial em que cada SHA-256 começa e termina), você acaba obtendo um resultado a cada ciclo de relógio (por talvez 100 milhões de hashes por segundo em um FPGA anunciado para suportar 300 MHz em lógica mais simples que essa) enquanto em uma CPU moderna, você pode esperar um resultado a cada poucos milhares de ciclos de clock por núcleo, digamos 10 milhões de hashes por segundo em um multi-core CPU de -GHz.

Se este exemplo em particular for do seu interesse, você pode dar uma olhada na minha resposta relacionada sobre os internos de mineradores ASIC no bitcoin.stackexchange, já que muitos mineradores de FPGA trabalham da mesma maneira usando hardware configurável em vez de personalizado. Por uma questão de completude: existem outras possibilidades, como limitar ou evitar o pipelining que descrevi em favor de uma paralelização mais trivial usando vários hashers SHA-256 independentes. Dependendo das restrições dadas pelos internos do seu FPGA e de seu tamanho total, isso pode até proporcionar um melhor desempenho, embora seja menos eficiente em termos de contagem de portas e sobrecarga de roteamento se você tiver a liberdade perfeita no design de todo o chip, não apenas na configuração de um FPGA .

As respostas acima, embora corretas, não entendem por que os FPGAs (e ASICs personalizados) são especialmente bons para cálculos de bitcoin.

A vantagem real é que uma grande proporção dos cálculos do SHA-256 são operações lógicas (por exemplo, troca de bits) que podem ser feitas na fiação. Quando feitos dessa maneira, eles exigem 0 ciclos de relógio.

Outra vantagem importante é que os FPGAs são muito mais eficientes em termos de energia (ou seja, MIPS por Watt) que as CPUs, portanto a quantidade de energia necessária para os cálculos é muito menor. Isso é importante porque o custo da mineração de um bitcoin depende da quantidade de eletricidade que você usa para produzi-lo.

Os chips ASIC são mais eficientes em termos energéticos do que os FPGAs, portanto, eles podem executar o mesmo código com muito mais baixo custo. Você também pode amontoar mais unidades de execução a bordo para torná-las mais rápidas. A desvantagem é que o custo de criar um ASIC personalizado é muito alto, portanto você precisará vender alguns chips para cobrir o custo de fabricação.

As GPUs também são usadas na fabricação de bitcoins, mas, como são muito menos eficientes em termos de energia, estão perdendo espaço para FPGAs e ASICs personalizados.