Comment un FPGA peut-il surpasser un processeur?

J'entends parler de personnes utilisant des FPGA pour améliorer les performances de systèmes tels que l'extraction de pièces de monnaie, le commerce électronique et le repliement de protéines.

Comment un FPGA peut-il concurrencer un processeur en termes de performances alors qu’il fonctionne généralement au moins un ordre de grandeur plus rapidement (en termes de vitesse d’horloge)?

Les processeurs sont des dispositifs de traitement séquentiel. Ils décomposent un algorithme en une séquence d'opérations et les exécutent une à la fois.

Les FPGA sont (ou peuvent être configurés comme) des dispositifs de traitement parallèle. Un algorithme entier peut être exécuté en un seul coup d'horloge ou, dans le pire des cas, beaucoup moins de ticks d'horloge qu'un processeur séquentiel. L’un des coûts de la complexité logique accrue est généralement une limite inférieure à laquelle le périphérique peut être cadencé.

Tenant compte de ce qui précède, les FPGA peuvent surpasser les tâches du processeur car ils peuvent effectuer la même tâche en moins de temps, bien qu’à un taux d’horloge global plus faible. Les gains pouvant être obtenus dépendent fortement de l'algorithme, mais au moins un ordre de grandeur n'est pas atypique pour quelque chose comme une FFT.

De plus, étant donné que vous pouvez créer plusieurs unités d’exécution parallèles dans un FPGA, vous pouvez répartir les données sur les unités d’exécution parallèles si vous souhaitez transférer un grand volume de données via le même algorithme et obtenir un débit plus élevé d’ordres de grandeur. que ce qui peut être réalisé même avec un processeur multi-core.

Le prix que vous payez pour les avantages est la consommation d’énergie et les $$$.

Markt a en grande partie raison, mais je vais ajouter 2 centimes ici:

Imaginez que je vous ai dit que je voulais écrire un programme qui inverserait l'ordre des bits à l'intérieur d'un entier 32 bits. Quelque chose comme ça:

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;
}

Maintenant, mon implémentation n'est pas élégante, mais je suis sûr que vous êtes d'accord pour dire que cela impliquerait un certain nombre d'opérations, et probablement une sorte de boucle. Cela signifie que dans la CPU, vous avez passé beaucoup plus d'un cycle pour implémenter cette opération.

Dans un FPGA, vous pouvez simplement le câbler comme une paire de verrous. Vous obtenez vos données dans un registre, puis vous les connectez dans un registre différent par ordre inverse des bits. Cela signifie que l'opération sera terminée en un seul cycle d'horloge dans le FPGA. Ainsi, en un seul cycle, le FPGS a effectué une opération qui a nécessité la réalisation de plusieurs milliers de cycles par votre CPU polyvalente! De plus, vous pouvez probablement connecter plusieurs centaines de ces registres en parallèle. Donc, si vous pouvez déplacer quelques centaines de chiffres sur le FPGA, en un seul cycle, il terminera ces milliers d'opérations des centaines de fois, le tout en un cycle d'horloge FPGA.

Un processeur à usage général peut effectuer beaucoup de choses, mais comme limitation, nous définissons des instructions simples et généralisées qui doivent nécessairement être développées en listes d'instructions simples pour effectuer certaines tâches. Ainsi, je pourrais faire en sorte que le processeur à usage général ait une instruction du type "ordre de bits inverse pour un registre à 32 bits" et donne au processeur la même capacité que le FPGA que nous venons de construire, mais il existe un nombre infini de telles instructions utiles, et nous ne mettez que ceux qui garantissent le coût dans les processeurs populaires.

Les FPGA, les CPLD et les ASIC vous donnent tous accès au matériel brut, ce qui vous permet de définir des opérations délirantes telles que "déchiffrer les octets chiffrés AES256 avec une clé" ou "décoder une image vidéo h.264". Celles-ci ont des latences de plus d'un cycle d'horloge dans un FPGA, mais elles peuvent être implémentées de manière beaucoup plus efficace que d'écrire l'opération en millions de lignes de code d'assemblage à usage général. Cela présente également l’avantage de rendre le FPGA / ASIC à usage fixe pour beaucoup de ces opérations plus économe en énergie, car ils ne nécessitent pas autant de travail supplémentaire!

Le parallélisme est l’autre élément que Markt a souligné, et bien que cela soit également important, l’essentiel est qu’un FPGA parallélise quelque chose qui coûtait déjà cher au processeur en termes de cycles nécessaires à l’exécution de l’opération. Une fois que vous commencez à dire "Je peux effectuer 10 cycles FPGA, une tâche qui prend 100 000 cycles à mon processeur, et je peux le faire en parallèle 4 éléments à la fois", vous pouvez facilement comprendre pourquoi un FPGA peut être extrêmement difficile. plus rapide qu'un processeur!

Alors, pourquoi n'utilisons-nous pas les FPGA, les CPLD et les ASIC pour tout? Car en général c'est une puce entière qui ne fait qu'une opération. Cela signifie que, bien que vous puissiez obtenir un processus permettant d'exécuter plusieurs ordres de grandeur plus rapidement dans votre FPGA / ASIC, vous ne pouvez pas le modifier ultérieurement lorsque cette opération n'est plus utile. La raison pour laquelle vous ne pouvez pas (généralement) changer un FPGA une fois dans un circuit est que le câblage de l'interface est fixe et que le circuit n'inclut pas de composants qui vous permettraient de reprogrammer le FPGA dans une configuration plus utile. Certains chercheurs tentent de construire des modules hybrides FPGA-CPU, dans lesquels une partie de la CPU peut être recâblée / reprogrammée comme un FPGA, ce qui vous permet de "charger" une partie efficace de la CPU,

Toutes les autres réponses populaires présentées ici parlent de différences littérales entre les FPGA et les CPU. Ils soulignent la nature parallèle du FPGA par rapport à la nature séquentielle d'un processeur, ou donnent des exemples de la raison pour laquelle certains algorithmes pourraient bien fonctionner sur un FPGA. Tous ces éléments sont bons et vrais, mais je suggérerais toutefois qu'il existe une différence plus fondamentale entre les processeurs et les FPGA.

Quel est le dénominateur commun entre un FPGA et un processeur? C'est qu'ils sont tous deux construits sur le silicium. Et dans certains cas, littéralement, les mêmes processus de silicium.

La différence fondamentale réside dans les abstractions que nous accumulons sur ce silicium. Il n’est pas possible pour un humain de comprendre tous les détails d’une conception de CPU moderne, du silicium au CI emballé. Ainsi, dans le cadre du processus d'ingénierie, nous divisons ce problème complexe en problèmes plus simples, gérables, que les humains peuvent comprendre.

Considérez ce qui est nécessaire pour transformer ce silicium en un processeur fonctionnel. Voici une vue quelque peu simplifiée des couches d'abstraction nécessaires à cet objectif:

1. Nous avons d’abord des ingénieurs qui savent créer des transistors en silicium. Ils savent comment concevoir de minuscules transistors capables de siffler et de commuter au rythme de 10 voire de 100 gigahertz, et de concevoir des transistors costauds capables de générer des signaux avec une puissance suffisante pour les envoyer via un circuit intégré et sur un circuit imprimé. à une autre puce.

2. Nous avons ensuite des concepteurs en logique numérique qui savent comment assembler ces transistors dans des bibliothèques comportant des centaines de cellules logiques différentes. Portes logiques, bascules électroniques, multiplexeurs et additionneurs, pour en nommer quelques-uns. Tous dans une variété de configurations.

3. Nous avons ensuite divers groupes d'ingénieurs qui savent comment assembler ces blocs numériques (et parfois analogiques) pour former des blocs fonctionnels de niveau supérieur, tels que des émetteurs-récepteurs à grande vitesse, des contrôleurs de mémoire, des prédicteurs de branche, des ALU, etc.

4. Ensuite, nous invitons les concepteurs de CPU à concevoir des processeurs haut de gamme en rassemblant ces unités fonctionnelles dans un système complet.

Et ça ne s'arrête pas là. À ce stade, nous avons un processeur opérationnel qui exécute le code assembleur, mais ce n'est pas un langage que la plupart des programmeurs écrivent actuellement.

5. Nous pourrions avoir un compilateur C pour compiler en code assembleur (probablement via une représentation intermédiaire)
6. Nous pourrions ajouter une autre abstraction au-dessus de C pour obtenir un langage orienté objet
7. Nous pourrions même écrire une machine virtuelle au-dessus de C ou C ++ pour pouvoir interpréter des choses comme du code octet Java

Et les couches d'abstraction peuvent continuer à partir de là. Le point important ici est que ces couches d’abstraction se combinent pour donner un système basé sur un processeur qui évolue énormément et ne coûte qu’une fraction infime d’une conception en silicium personnalisée.

CEPENDANT, il est important de souligner que chaque abstraction a aussi un coût. Le concepteur de transistors ne construit pas le transistor parfait pour chaque cas d'utilisation. Il construit une bibliothèque raisonnable et utilise donc parfois un transistor qui consomme un peu plus de puissance ou un peu plus de silicium que ce qui est vraiment nécessaire pour le travail à accomplir. Et de même, les concepteurs logiques ne construisent pas toutes les cellules logiques possibles. Ils peuvent créer une porte NAND à 4 entrées et une porte NAND à 8 entrées, mais que se passe-t-il lorsqu'un autre ingénieur a besoin d'un NAND à 6 entrées? Il utilise une porte NAND à 8 entrées et lie 2 entrées inutilisées, ce qui entraîne une perte de ressources en silicium et une puissance réduite. Et ainsi cela monte dans la chaîne des abstractions. Chaque couche nous donne un moyen de gérer la complexité,

Maintenant, comparez ces abstractions à ce qui est nécessaire pour un FPGA. Essentiellement, les abstractions FPGA s'arrêtent au deuxième rang de la liste ci-dessus. Le FPGA permet aux développeurs de travailler au niveau de la couche logique numérique. Il est un peu plus sophistiqué que cela car les processeurs sont "codés en dur" sur cette couche et les FPGA doivent être configurés à l'exécution (ce qui explique pourquoi les processeurs utilisent généralement des fréquences beaucoup plus élevées), mais la vérité essentielle est peu d’abstractions pour les FPGA que pour les CPU.

Alors, pourquoi un FPGA peut-il être plus rapide qu'un processeur? Essentiellement, c'est parce que le FPGA utilise beaucoup moins d'abstractions qu'un processeur, ce qui signifie que le concepteur travaille plus près du silicium. Il ne paie pas les coûts de toutes les couches d'abstraction requises pour les processeurs. Il code à un niveau inférieur et doit travailler plus fort pour obtenir un certain nombre de fonctionnalités, mais la récompense est qu'il obtient de meilleures performances.

Mais bien sûr, il y a un inconvénient pour moins d'abstractions. Toutes ces abstractions de la CPU sont là pour une bonne raison. Ils nous donnent un paradigme de codage beaucoup plus simple, ce qui signifie que plus de personnes peuvent facilement se développer pour elles. Cela signifie qu'il existe de nombreuses autres conceptions de processeurs et que nous en tirons des avantages énormes en termes de prix, d'échelle et de mise sur le marché.

Donc là vous l'avez. Les FPGA ont moins d'abstractions et peuvent donc être plus rapides et plus efficaces, mais difficiles à programmer. Les processeurs ont de nombreuses conceptions d'abstractions pour les rendre faciles à développer, évolutives et bon marché. Mais ils abandonnent la vitesse et la puissance dans le commerce pour ces avantages.

Alors que les autres réponses sont toutes correctes, aucune d’entre elles n’aborde l’exemple de l’exploration de bitcoins de votre question, qui est en effet un exemple décent. L'exploitation de Bitcoin implique le calcul répété d'une fonction de hachage cryptographique, SHA-256 du résultat d'un autre calcul SHA-256, de données dans lesquelles un seul entier entier 32 bits change, jusqu'à ce que le hachage résultant ait certaines propriétés. Chaque SHA-256 consiste en 64 répétitions du même algorithme impliquant des additions de 32 bits, des décalages de bits et quelques opérations de traitement de bits supplémentaires.

Si vous programmez cette boucle sur une CPU 32 bits (ou plus), vous verrez que son jeu d'instructions est très bien adapté à la tâche --- SHA-256 a été conçu pour fonctionner efficacement sur les CPU. Cependant, vous n'utiliserez peut-être que 2% de la surface de silicium d'un processeur moderne, avec des fonctionnalités intensives telles que la mise en cache, la multiplication, la division, le fonctionnement en virgule flottante, la prédiction de branchement et de dérivation, etc. amélioration de la performance pour cette tâche particulière.

Dans un matériel configurable comme un FPGA, il vous suffit simplement d’implémenter ces 2% et d’optimiser davantage en oubliant tout ce qui concerne l’exécution de code, en concevant plutôt des portes pour calculer directement chacune de ces sous-fonctions souvent répétées. Pipelées de telle sorte que chacune d’elles passe un résultat dans l’autre cycle à la fois et répétée 128 fois (et avec une logique supplémentaire spéciale dans laquelle chaque SHA-256 commence et se termine), vous obtenez un résultat à chaque cycle (pour 100 millions de hachages par seconde sur un FPGA annoncé pour prendre en charge 300 MHz sur une logique plus simple) alors que sur un processeur moderne, vous pouvez vous attendre à un résultat tous les quelques milliers de cycles d'horloge par cœur, soit 10 millions de hachages par seconde sur un multi-core multi-core. -GHz CPU.

Si cet exemple particulier vous intéresse, vous pouvez consulter ma réponse sur les composants internes des mineurs ASIC sur bitcoin.stackexchange, car de nombreux mineurs FPGA fonctionnent de la même manière en utilisant du matériel configurable plutôt que du matériel personnalisé. Par souci d’exhaustivité: il existe d’autres possibilités, telles que la limitation ou l’évitement du traitement en pipeline que j’ai décrit en faveur d’une parallélisation plus triviale à l’aide de plusieurs hashers indépendants SHA-256. En fonction des contraintes imposées par les composants internes de votre FPGA et de sa taille totale, cela peut même donner de meilleures performances, même s’il serait moins efficace en termes de nombre de portes et de temps de routage si vous aviez une liberté totale dans la conception de la puce, et pas seulement dans une configuration de FPGA. .

Les réponses ci-dessus, bien que correctes, ignorent pourquoi les FPGA (et les ASIC personnalisés) sont particulièrement utiles pour les calculs en bitcoins.

L'avantage réel réside dans le fait qu'une grande partie des calculs SHA-256 sont des opérations logiques (par exemple, des décalages sur les bits) pouvant être effectuées lors du câblage. Lorsque cela est fait de cette façon, ils nécessitent 0 cycle d'horloge.

Un autre avantage important est que les FPGA consomment beaucoup moins d'énergie (c'est-à-dire MIPS par Watt) que les processeurs, de sorte que la quantité d'énergie requise pour les calculs est bien moindre. Ceci est important car le coût de l’exploitation d’un bitcoin dépend de la quantité d’électricité que vous utilisez pour le fabriquer.

Les puces ASIC consomment moins d'énergie que les FPGA et peuvent donc exécuter le même code beaucoup moins cher. Vous pouvez également entasser plus d'unités d'exécution à bord pour les rendre plus rapides. L'inconvénient est que le coût de fabrication d'un ASIC personnalisé est très élevé, de sorte que vous devrez vendre quelques puces pour couvrir le coût de fabrication.

Les GPU sont également utilisés pour la fabrication de bitcoins, mais comme ils sont beaucoup moins éconergétiques, ils ont perdu du terrain face aux FPGA et aux ASIC personnalisés.