Como um FPGA pode superar o desempenho de uma CPU?

CPU “s são dispositivos de processamento sequencial. Eles dividem um algoritmo em uma sequência de operações e as executam uma de cada vez.

FPGA” s 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, no pior caso, muito menos tiques do relógio do que um processador sequencial. Um dos custos do aumento da complexidade lógica é normalmente um limite inferior no qual o dispositivo pode ser sincronizado.

Tendo o acima em mente, os FPGAs podem superar os da CPU em certas tarefas porque eles podem fazer a mesma tarefa em menos tiques do clock, embora em uma taxa de clock geral menor. Os ganhos que podem ser obtidos são altamente dependentes do algoritmo, mas pelo menos uma ordem de magnitude não é atípica para algo como um FFT.

Além disso, porque você pode construir 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 de rendimento mais alto do que pode ser alcançado até mesmo com uma CPU multi-core.

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

Comentários

• +1; FPGAs no entanto não são tão dinâmicos quanto as CPUs, razão pela qual as CPUs geralmente são mais adequadas para PCs
• ” O preço que você paga pelas vantagens é o consumo de energia e $$$ ‘ s. ” – Isso geralmente é verdade, mas você pode bater diretamente uma máquina Intel Xeon multi- $ 1000 high-end com um barato $ 50 Xilinx Spartan-6 para muitos algoritmos. Mas isso normalmente leva muito tempo de engenharia e você pode acabar com um design muito personalizado que funciona apenas para um aplicativo e é difícil de alterar. Portanto, a compensação não é apenas poder e dinheiro, mas também tempo de desenvolvimento de algoritmo, capacidade de reutilização e flexibilidade. (Embora você possa argumentar sobre tempo == dinheiro.)
• markt, sobre sua última frase, os FPGAs não têm ‘ muito menos potência do que CPUs? Há uma ampla gama de dispositivos para CPUs e FPGAs, mas se olharmos para aqueles que são usados para coisas como mineração de moedas de bits, não são ‘ as CPUs usadas para eles tarefas com muito mais consumo de energia do que os FPGAs que seriam usados?
• @David: Ao falar sobre mineração de Bitcoins, a métrica relevante é o número de hashes por watt. Markt está falando sobre o consumo geral de energia. Ou seja, um determinado FPGA pode consumir 3x a energia de uma CPU típica, mas ser muito mais do que 3x mais rápido na mineração de Bitcoins; então, para Bitcoin que ‘ sa ganha.
• @Billy: o número de hashes por watt · segundo, não por watt.

Markt acertou em sua maioria, mas vou acrescentar meus 2 centavos aqui:

Imagine que eu lhe disse que queria escrever um programa que inverte a ordem dos bits dentro de um 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 certo número de operações envolvidas nisso, 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 conectá-lo como um par de travas. Você obtém seus dados em algum registro e, em seguida, conecta-os a um registro diferente na ordem reversa dos bits. Isso significa que a operação será concluída em um único ciclo de clock no FPGA. Assim, em um único ciclo, o FPGS concluiu uma operação que levou muitos milhares de ciclos para sua CPU de uso geral! Além disso, você pode conectar provavelmente algumas centenas desses registradores em paralelo. Então, se você puder mover algumas centenas de números para o FPGA, em um único ciclo ele terminará milhares de operações centenas de vezes, tudo em 1 ciclo de clock do FPGA.

Há muitas coisas que um CPU de uso geral pode fazer, mas como uma limitação, configuramos instruções generalizadas e simples que necessariamente precisam se expandir em listas de instruções simples para completar algumas tarefas. Então, eu poderia fazer com que a CPU de uso geral tivesse uma instrução como “ordem reversa dos bits para o registro de 32 bits” e dar à CPU a mesma capacidade do FPGA que acabamos de construir, mas há um número infinito de possíveis instruções úteis, e então nós coloque apenas os que justificam o custo nas CPUs populares.

FPGAs, CPLDs e ASICs dão acesso ao hardware bruto, que permite definir operações malucas como “descriptografar bytes criptografados em AES256 com chave” ou “decodificar quadro de vídeo h.264”. Eles têm 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 propósito geral. Isso também tem a vantagem de tornar o FPGA / ASIC de propósito fixo para muitas dessas operações mais eficiente em termos de energia, porque elas não precisam fazer tanto trabalho estranho!

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

Então por que não usamos FPGAs, CPLDs e ASICs para tudo? Porque em geral é um chip completo que não faz nada além de uma operação. Isso significa que, embora você possa fazer com que um processo execute muitas ordens de magnitude mais rápido em seu FPGA / ASIC, você não pode alterá-lo posteriormente, quando essa operação não for mais útil. A razão pela qual você não pode (geralmente) alterar um FPGA uma vez O fato de estar em um circuito é que a fiação para a interface é fixa e, normalmente, o circuito não inclui componentes que permitiriam a você reprogramar o FPGA em uma configuração mais útil. Existem alguns pesquisadores tentando construir módulos FPGA-CPU híbridos, onde existe uma seção da CPU que é capaz de ser religada / reprogramada como um FPGA, permitindo que você “carregue” uma seção efetiva da CPU, mas nenhuma delas já chegaram ao mercado (tanto quanto eu sei).

Comentários

• Para o exemplo de bits reversos (e todos os outros bits tarefas de troca / seleção) não ‘ realmente leva 1 ciclo de clock, leva 0. Em seu exemplo, leva 1 ciclo de clock para armazenar dados em uma trava , que não é a mesma operação. Leva 1 ciclo de clock, quer você reverta os bits ou não. A operação de reversão dos bits é 0 ciclos de clock; sem sobrecarga, apenas roteamento diferente. A diferença não é apenas semântica, especialmente quando você está começando a adicionar coisas. Por exemplo, quanto tempo leva para deslocar uma palavra de 32 bits para baixo em 3 bits, depois trocar todos os outros nibble e depois invertê-los?
• ” FPGA-CP híbrido Módulo U ” – estão no mercado há muito tempo (consulte xilinx.com/products/silicon-devices/ soc / zynq-7000 / index.htm para um moderno bem-sucedido), mas mesmo sem suporte especial, a combinação de software & HDL é comumente feita por meio da implementação de uma CPU soft dentro o FPGA no tecido.
• @wjl Você ‘ está certo que tecnicamente não leva ciclos para realizar a operação em si. Eu diria que seu exemplo é apenas semanticamente diferente, principalmente porque fazer essas três operações logicamente se traduz em um padrão de bit fixo (ou seja, começo com b1b2b3b4 e termino com b3b1b4b2). Este foi o meu ponto em toda a resposta. Eu estava tentando apontar que descrever uma operação como uma série de etapas frequentemente só é necessário quando você tem um conjunto de instruções / arranjo de portas fixas.
• @wjl: A forma como David-gardner fez a pergunta, ele parece estar dizendo que ” CPU ” é equivalente a uma CPU Intel ou AMD x86 / x86_64 com alta freqüência, pipeline e otimizada. Existem muitos soft ” CPUs ” soft, mas nenhum dos projetados para sentar em um FPGA pode ser cronometrado como um i7, nem eles são quase tão otimizados ou capazes. Quanto aos híbridos, eu quis dizer algo assim: newsroom.intel.com/docs/DOC-1512 que aparentemente existe
• o Zynq realmente não é ‘ um processador muito ruim (ARM Cortex-A9 – a mesma coisa que executa tablets, etc), mas eu concordo que seria muito mais incrível ter um FPGA integrado com um x86_64 de alta velocidade. =)

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 sequencial de uma CPU, ou dão exemplos de porque certos algoritmos podem funcionar bem em um FPGA. Tudo isso é bom e verdadeiro, mas eu sugeriria, entretanto, 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 em cima de silício. E em alguns casos, literalmente, os mesmos processos de silício.

A diferença fundamental são as abstrações que empilhamos em cima desse silício. Não é possível para um ser humano compreender todos os detalhes de um único design moderno de CPU, desde silício até IC empacotado. Então, como parte do processo de engenharia, dividimos esse problema complexo em problemas menores gerenciáveis que os humanos podem resolver.

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

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

2. Então temos designers de lógica digital que sabem como colocar esses transistores juntos em bibliotecas com centenas de células lógicas diferentes. Portas lógicas, flip-flops, muxes e somadores, para citar alguns. Tudo em uma variedade de configurações.

3. Em seguida, temos vários grupos de engenheiros que sabem como colocar esses blocos digitais (e às vezes analógicos) juntos 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 designs de CPU de ponta reunindo essas unidades funcionais em um sistema completo.

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

5. Podemos ter um compilador C para compilar em assembly código (provavelmente através de alguma representação intermediária)
6. Poderíamos adicionar outra abstração no topo de C para obter uma linguagem orientada a objetos
7. Podemos até escrever uma máquina virtual em cima de C ou C ++ para que possamos interpretar coisas como o 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 muito e custa uma pequena fração de um design de silício personalizado.

NO ENTANTO, o ponto importante a ser feito aqui é que cada abstração também acarreta um custo. O projetista do transistor não constrói o transistor perfeito para cada caso de uso. Ele constrói uma biblioteca razoável e, por isso, às vezes é usado um transistor que consome um pouco mais de energia ou um pouco mais de silício do que o realmente necessário para o trabalho em questão. E da mesma forma, os designers lógicos não constroem todas as células lógicas possíveis. Eles podem construir uma porta NAND de 4 entradas e uma porta NAND de 8 entradas, mas o que acontece quando outro engenheiro precisa de uma porta NAND de 6 entradas? Ele usa uma porta NAND de 8 entradas e conecta 2 entradas não utilizadas, o que resulta em perda de recursos de silício e potência reduzida. E assim sobe na cadeia de abstrações. Cada camada nos dá uma maneira de lidar com a complexidade, mas ao mesmo tempo nos cobra um custo incremental adicional em termos de silício e energia.

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 em tempo de execução (o que, BTW, é por que as CPUs normalmente executam frequências muito mais altas), mas a verdade essencial 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 do 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 que são necessárias para CPUs. Ele codifica em um nível inferior e tem que se esforçar mais para obter uma determinada funcionalidade, mas como recompensa, ele obtém um desempenho maior.

Mas é claro que há um lado negativo para menos abstrações também. Todas essas abstrações da CPU existem por um bom motivo. Eles nos fornecem um paradigma de codificação muito mais simples, o que significa que mais pessoas podem desenvolver facilmente para eles. Isso, por sua vez, significa que existem muitos mais designs de CPU e, portanto, temos enormes benefícios de preço / escala / tempo de comercialização com as CPUs.

Então, aí está. 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, escalonáveis e baratas. Mas eles abrem mão de velocidade e poder na troca por esses benefícios.

Comentários

• Além disso, FPGA ‘ s são projetados com blocos repetitivos simples que realizam tarefas lógicas simples. Eles são feitos sob medida para certos tipos de tarefas.CPU ‘ s, OTOH, tem muitas partes funcionais complexas, todas fazendo coisas diferentes. Pode-se considerar que uma CPU é um grupo de muitos dispositivos diferentes do tipo FPGA (afinal, ela ‘ é apenas silício, eletrônica e matemática). Portanto, ‘ não trata apenas de abstrações, mas ‘ trata de complexidade. CPU ‘ s são dispositivos complexos compostos de muitos tipos diferentes de dispositivos elétricos, enquanto um FPGA é composto de alguns. Uma CPU é uma espingarda, enquanto um FPGA é um rifle.

Enquanto as outras respostas estão corretas , nenhum deles ainda aborda o exemplo de mineração de bitcoin de sua pergunta, que é de fato um exemplo decente. A mineração de bitcoins envolve o cálculo repetido de uma função hash criptográfica, SHA-256, do resultado de outro cálculo SHA-256, de dados em que apenas um único inteiro de 32 bits muda, 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, mudanças de bits e mais algumas operações de manipulação de bits.

Se você programar este loop em uma CPU de 32 bits (ou mais) , você encontrará seu conjunto de instruções muito adequado para a tarefa — SHA-256 foi projetado para funcionar com eficiência em CPUs. Mesmo assim, você usará apenas 2% da área de silício de uma CPU moderna, com funcionalidade de área intensiva como cache, multiplicação, divisão, operação de ponto flutuante, ramificação e previsão de braquiária, etc., ou não usada ou incapaz de fornecem um aumento significativo de desempenho para esta tarefa em particular.

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 computar diretamente cada um de essas subfunções frequentemente repetidas. Canalizadas de modo que cada uma delas passe um resultado para o próximo a cada ciclo do relógio e repetidas 128 vezes (e com alguma lógica adicional especial onde cada SHA-256 começa e termina), você acaba obtendo um resultado a cada ciclo de clock (por talvez 100 milhões de hashes por segundo em um FPGA anunciado para suportar 300 MHz em uma lógica mais simples do que esta), enquanto em uma CPU moderna, você poderia esperar um resultado a cada poucos milhares de ciclos de clock por núcleo, digamos 10 milhões de hashes por segundo em uma CPU multinúcleo e multi-GHz.

Se este exemplo em particular for do seu interesse, você pode querer dar uma olhada em meu relacionado resposta sobre os detalhes internos dos mineiros ASIC em bitcoin.stackexchange, uma vez que muitos mineiros FPGA trabalham da mesma forma usando hardware configurável em vez de hardware personalizado. Apenas para fins 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 fornecidas pelos internos do seu FPGA” e seu tamanho total , que pode até oferecer melhor desempenho, embora seja menos eficiente em termos de contagem de portas e sobrecarga de roteamento se você tivesse liberdade perfeita para projetar o chip inteiro, não apenas a configuração de um FPGA.

Comentários

• Esse ‘ é um ponto muito bom sobre a utilização de silício.
• Mas talvez (sem querer!) enganoso, considerando que um FPGA consiste em células um tanto complexas com muitas portas físicas, das quais uma aplicação típica usa apenas uma fração, permitindo que seus fabricantes anunciem contagens de portas equivalentes na tentativa de dizer quanto tudo isso pode valer em um ” típico ” aplicativo …

As respostas acima, embora corretas, erram o ponto sobre porque FPGAs (e ASICs personalizados) são especialmente bons para cálculos de bitcoin.

A vantagem real é que uma grande proporção dos cálculos SHA-256 são operações lógicas (por exemplo, deslocamentos de bits) que podem ser feitas em fiação. Quando feito dessa forma, eles exigem 0 ciclos de clock.

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

Os chips ASIC são mais eficientes em termos de energia do que os FPGAs, portanto, podem executar o mesmo código de maneira muito mais barata. Você também pode colocar mais unidades de execução a bordo para torná-las mais rápidas. A desvantagem é que o custo de fazer um ASIC personalizado é muito alto, então você precisa vender alguns chips para cobrir o custo de fabricação.

As GPUs também são usadas para fazer bitcoins, mas desde que são com muito menos eficiência energética, eles vêm perdendo terreno para FPGAs e ASICs personalizados.

Comentários

• Se você olhar para o algoritmo de hashing Monero, também conhecido como cryptonight, verá que uma implementação FPGA é quase impossível devido à grande quantidade de a memória precisava ser acessada aleatoriamente (2 MB). A CPU tem a vantagem neste caso.
• @ lucas92 você não consegue integrar RAM no FPGA para acomodar a quantidade de memória necessária?
• Você provavelmente ganhou ‘ t tem elementos lógicos suficientes no FPGA para isso.