Wie kann ein FPGA eine CPU übertreffen?

CPUs sind sequentielle Verarbeitungsgeräte. Sie zerlegen einen Algorithmus in eine Folge von Operationen und führen sie einzeln aus.

FPGAs sind (oder können als solche konfiguriert werden) Parallelverarbeitungsgeräte. Ein ganzer Algorithmus kann in einem einzigen Takt der Uhr oder im schlimmsten Fall in weit weniger Takten ausgeführt werden, als ein sequentieller Prozessor benötigt. Einer der Kosten für die erhöhte Logikkomplexität ist typischerweise eine untere Grenze, bei der das Gerät getaktet werden kann.

In Anbetracht des oben Gesagten können FPGAs CPUs bei bestimmten Aufgaben übertreffen, da sie die gleiche Aufgabe in weniger Takten erledigen können, wenn auch mit einer niedrigeren Gesamttaktrate. Die erzielbaren Gewinne sind stark vom Algorithmus abhängig, aber zumindest eine Größenordnung ist für so etwas wie eine FFT nicht untypisch.

Da Sie außerdem mehrere parallele Ausführungseinheiten in ein FPGA einbauen können, können Sie, wenn Sie große Datenmengen haben, die denselben Algorithmus durchlaufen möchten, die Daten auf die parallelen Ausführungseinheiten verteilen und einen um weitere Größenordnungen höheren Durchsatz erzielen als selbst mit einer Mehrkern-CPU erreicht werden kann.

Der Preis, den Sie für die Vorteile zahlen, ist der Stromverbrauch und die Kosten.

Markt hat damit größtenteils Recht, aber ich werde hier meine 2 Cent hineinwerfen:

Stellen Sie sich vor, ich hätte Ihnen gesagt, dass ich ein Programm schreiben möchte, das die Reihenfolge der Bits innerhalb einer 32-Bit-Ganzzahl umkehrt. Etwas wie das:

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

Nun, meine Implementierung ist nicht elegant, aber ich bin sicher, Sie stimmen mir zu, dass eine Reihe von Operationen erforderlich wären, um dies zu tun, und wahrscheinlich eine Art Schleife. Dies bedeutet, dass Sie in der CPU viel mehr als 1 Zyklus für die Implementierung dieser Operation aufgewendet haben.

In einem FPGA können Sie dies einfach als Latch-Paar verdrahten. Sie erhalten Ihre Daten in einem Register und verbinden sie dann in umgekehrter Bitreihenfolge mit den anderen Registern. Dies bedeutet, dass die Operation in einem einzigen Taktzyklus im FPGA abgeschlossen wird. Somit hat das FPGS in einem einzigen Zyklus eine Operation abgeschlossen, für deren Abschluss Ihre Allzweck-CPU viele tausend Zyklen benötigt hat! Außerdem können Sie wahrscheinlich einige hundert dieser Register parallel verdrahten. Wenn Sie also ein paar hundert Zahlen auf das FPGA übertragen können, wird es in einem einzigen Zyklus diese Tausende von Operationen hunderte Male ausführen, alles in einem FPGA-Taktzyklus.

Es gibt viele Dinge, die eine Allzweck-CPU tun kann, aber als Einschränkung richten wir verallgemeinerte und einfache Anweisungen ein, die notwendigerweise in Listen einfacher Anweisungen erweitert werden müssen, um einige Aufgaben zu erledigen. Also könnte ich die Allzweck-CPU mit einer Anweisung wie "umgekehrte Bitreihenfolge für 32-Bit-Register" versehen und der CPU die gleichen Fähigkeiten wie dem FPGA geben, das wir gerade gebaut haben, aber es gibt eine unendliche Anzahl solcher möglicher nützlicher Anweisungen, und so wir Setzen Sie nur diejenigen ein, die die Kosten in den gängigen CPUs rechtfertigen.

FPGAs, CPLDs und ASICs geben Ihnen alle Zugriff auf die Rohhardware, mit der Sie verrückte Operationen wie „AES256-verschlüsselte Bytes mit Schlüssel entschlüsseln“ oder „Einzelbild von H.264-Video decodieren“ definieren können. Diese haben Latenzen von mehr als einem Taktzyklus in einem FPGA, aber sie können auf viel effizientere Weise implementiert werden, als die Operation in Millionen von Zeilen von Allzweck-Assemblercode zu schreiben. Dies hat auch den Vorteil, dass die Festzweck-FPGA/ASIC für viele dieser Operationen energieeffizienter werden, da sie nicht so viel Fremdarbeit leisten müssen!

Parallelität ist der andere Teil, auf den Markt hingewiesen hat, und obwohl das ebenfalls wichtig ist, ist die Hauptsache, wenn ein FPGA etwas parallelisiert, was in Bezug auf die für die Ausführung der Operation erforderlichen Zyklen in der CPU bereits teuer war. Wenn Sie anfangen zu sagen: „Ich kann in 10 FPGA-Zyklen eine Aufgabe ausführen, die meine CPU 100.000 Zyklen kostet, und ich kann diese Aufgabe parallel mit 4 Elementen gleichzeitig erledigen“, können Sie leicht erkennen, warum ein FPGA eine Menge sein könnte schneller als eine CPU!

Warum verwenden wir also nicht für alles FPGAs, CPLDs und ASICs? Denn im Allgemeinen ist es ein ganzer Chip, der nur eine Operation ausführt. Dies bedeutet, dass Sie zwar einen Prozess in Ihrem FPGA/ASIC um viele Größenordnungen schneller ausführen können, Sie ihn jedoch später nicht mehr ändern können, wenn diese Operation nicht mehr nützlich ist. Der Grund, warum Sie ein FPGA (im Allgemeinen) nicht ändern können, wenn es sich in einer Schaltung befindet, ist, dass die Verdrahtung für die Schnittstelle festgelegt ist und die Schaltung normalerweise keine Komponenten enthält, mit denen Sie das FPGA in eine nützlichere Konfiguration umprogrammieren können. Es gibt einige Forscher, die versuchen, hybride FPGA-CPU-Module zu bauen, bei denen es einen Abschnitt der CPU gibt, der wie ein FPGA neu verdrahtet/neu programmiert werden kann, sodass Sie einen effektiven Abschnitt der CPU "laden" können.

Alle anderen hier vorgestellten populären Antworten sprechen von wörtlichen Unterschieden zwischen FPGAs und CPUs. Sie weisen auf die parallele Natur des FPGA gegenüber der sequentiellen Natur einer CPU hin oder geben Beispiele dafür, warum bestimmte Algorithmen auf einem FPGA gut funktionieren könnten. All das ist gut und wahr, aber ich würde dennoch vorschlagen, dass es einen grundlegenderen Unterschied zwischen CPUs und FPGAs gibt.

Was ist der gemeinsame Nenner zwischen einem FPGA und einer CPU? Es ist so, dass sie beide auf Silizium aufgebaut sind. Und in einigen Fällen buchstäblich die gleichen Siliziumprozesse.

Der grundlegende Unterschied sind die Abstraktionen, die wir auf dieses Silizium stapeln. Es ist nicht möglich, dass ein einzelner Mensch alle Details eines einzelnen modernen CPU-Designs vom Silizium bis zum verpackten IC versteht. Als Teil des Engineering-Prozesses unterteilen wir dieses komplexe Problem in kleinere handhabbare Probleme, um die sich Menschen kümmern können.

Überlegen Sie, was nötig ist, um dieses Silizium in eine funktionierende CPU zu verwandeln. Hier ist eine etwas vereinfachte Ansicht der für dieses Ziel erforderlichen Abstraktionsebenen:

1. Erstens haben wir Ingenieure, die wissen, wie man Transistoren aus Silizium herstellt. Sie wissen, wie man winzige Transistoren entwirft, die Strom schlucken und mit einer Rate von 10 oder sogar 100 Gigahertz schalten, und sie wissen, wie man kräftige Transistoren entwirft, die Signale mit genug Leistung treiben können, um sie aus einem IC-Gehäuse und über eine Leiterplatte zu senden zu einem anderen Chip.

2. Dann haben wir Designer für digitale Logik, die wissen, wie man diese Transistoren zu Bibliotheken mit Hunderten von verschiedenen Logikzellen zusammenfügt. Logikgatter, Flipflops, Multiplexer und Addierer, um nur einige zu nennen. Alle in einer Vielzahl von Konfigurationen.

3. Als nächstes haben wir verschiedene Gruppen von Ingenieuren, die wissen, wie man diese digitalen (und manchmal analogen) Blöcke zusammensetzt, um Funktionsblöcke auf höherer Ebene wie Hochgeschwindigkeits-Transceiver, Speichercontroller, Verzweigungsprädiktor, ALUs usw. zu bilden.

4. Dann haben wir CPU-Designer, die High-End-CPU-Designs entwerfen, indem sie diese Funktionseinheiten zu einem vollständigen System zusammenführen.

Und es hört hier nicht auf. An diesem Punkt haben wir eine funktionierende CPU, die Assembler-Code ausführt, aber das ist keine Sprache, die die meisten Programmierer heutzutage schreiben.

5. Wir könnten einen C-Compiler haben, der in Assembler-Code kompiliert (wahrscheinlich durch eine Zwischendarstellung)
6. Wir könnten eine weitere Abstraktion über C hinzufügen, um eine objektorientierte Sprache zu erhalten
7. Wir könnten sogar eine virtuelle Maschine auf C oder C++ schreiben, damit wir Dinge wie Java-Bytecode interpretieren können

Und die Abstraktionsschichten können von dort aus weitergehen. Der wichtige Punkt hier ist, dass diese Abstraktionsschichten kombiniert werden, um ein CPU-basiertes System zu ergeben, das massiv skaliert und einen winzigen Bruchteil eines benutzerdefinierten Siliziumdesigns kostet.

Wichtig ist hier jedoch, dass jede Abstraktion auch selbst Kosten verursacht. Der Transistordesigner baut nicht für jeden Anwendungsfall den perfekten Transistor. Er baut eine vernünftige Bibliothek, und so wird manchmal ein Transistor verwendet, der etwas mehr Strom oder etwas mehr Silizium verbraucht, als für die jeweilige Aufgabe wirklich benötigt wird. Und ebenso bauen die Logikdesigner nicht jede mögliche Logikzelle. Sie könnten ein NAND-Gatter mit 4 Eingängen und ein NAND-Gatter mit 8 Eingängen bauen, aber was passiert, wenn ein anderer Ingenieur ein NAND mit 6 Eingängen benötigt? Er verwendet ein NAND-Gatter mit 8 Eingängen und bindet 2 ungenutzte Eingänge ab, was zu verlorenen Siliziumressourcen und verschwendeter Leistung führt. Und so geht es die Kette der Abstraktionen hinauf. Jede Schicht gibt uns eine Möglichkeit, die Komplexität zu bewältigen, stellt uns aber gleichzeitig zusätzliche zusätzliche Kosten in Bezug auf Silizium und Strom in Rechnung.

Vergleichen Sie nun diese Abstraktionen mit dem, was für ein FPGA benötigt wird. Im Wesentlichen enden die FPGA-Abstraktionen bei Nr. 2 in der obigen Liste. Das FPGA ermöglicht es Entwicklern, auf der digitalen Logikschicht zu arbeiten. Es ist etwas ausgefeilter als das, da CPUs auf dieser Ebene „fest codiert“ sind und FPGAs zur Laufzeit konfiguriert werden müssen (was übrigens der Grund dafür ist, dass CPUs normalerweise viel höhere Frequenzen ausführen), aber die wesentliche wichtige Wahrheit ist, dass dies weit ist wenige Abstraktionen für FPGAs als für CPUs.

Warum kann ein FPGA also schneller sein als eine CPU? Im Wesentlichen liegt es daran, dass das FPGA viel weniger Abstraktionen verwendet als eine CPU, was bedeutet, dass der Designer näher am Silizium arbeitet. Er zahlt nicht die Kosten für all die vielen Abstraktionsschichten, die für CPUs erforderlich sind. Er codiert auf einem niedrigeren Niveau und muss härter arbeiten, um ein gewisses Maß an Funktionalität zu erreichen, aber als Belohnung erhält er eine höhere Leistung.

Aber natürlich gibt es auch eine Kehrseite für weniger Abstraktionen. All diese CPU-Abstraktionen gibt es aus gutem Grund. Sie geben uns ein viel einfacheres Kodierungsparadigma, was bedeutet, dass mehr Leute leicht für sie entwickeln können. Das wiederum bedeutet, dass es viel mehr CPU-Designs gibt und wir daher massive Preis-/Skalierungs-/Time-to-Market-Vorteile von CPUs haben.

Da haben Sie es also. FPGAs haben weniger Abstraktionen und können daher schneller und energieeffizienter sein, sind aber schwer zu programmieren. CPUs haben viele Abstraktionsdesigns, um sie einfach zu entwickeln, skalierbar und billig zu machen. Aber sie geben Geschwindigkeit und Macht im Handel für diese Vorteile auf.

Während die anderen Antworten alle richtig sind, geht keine von ihnen auf das Bitcoin-Mining-Beispiel aus Ihrer Frage ein, das in der Tat ein anständiges Beispiel ist. Beim Bitcoin-Mining wird wiederholt eine kryptografische Hash-Funktion, SHA-256, aus dem Ergebnis einer anderen SHA-256-Berechnung von Daten berechnet, bei denen sich nur eine einzige 32-Bit-Ganzzahl ändert, bis der resultierende Hash bestimmte Eigenschaften aufweist. Jeder SHA-256 besteht aus 64 Wiederholungen desselben Algorithmus, der 32-Bit-Additionen, Bitverschiebungen und einige weitere Bit-Mangling-Operationen beinhaltet.

Wenn Sie diese Schleife auf einer 32-Bit-CPU (oder mehr) programmieren, werden Sie feststellen, dass ihr Befehlssatz sehr gut für die Aufgabe geeignet ist – SHA-256 wurde entwickelt, um effizient auf CPUs ausgeführt zu werden. Dennoch werden Sie nur vielleicht 2 % der Siliziumfläche einer modernen CPU verwenden, wobei flächenintensive Funktionen wie Caching, Multiplikation, Division, Gleitkommaoperation, Verzweigung und Brach-Vorhersage usw. entweder überhaupt nicht verwendet werden oder nicht in der Lage sind, signifikante Leistungen zu erbringen Leistungssteigerung für diese spezielle Aufgabe.

In konfigurierbarer Hardware wie einem FPGA implementieren Sie einfach nur diese 2 % und optimieren weiter, indem Sie die gesamte Codeausführung vergessen und stattdessen Gates entwerfen, um jede dieser oft wiederholten Unterfunktionen direkt zu berechnen. So geleitet, dass jeder von ihnen in jedem Taktzyklus ein Ergebnis an den nächsten weitergibt und 128-mal wiederholt wird (und mit einer speziellen zusätzlichen Logik, wo jeder SHA-256 beginnt und endet), erhalten Sie am Ende jeden Taktzyklus ein Ergebnis (für vielleicht 100 Millionen Hashes pro Sekunde auf einem FPGA, das für die Unterstützung von 300 MHz bei einer einfacheren Logik als dieser beworben wird), während Sie auf einer modernen CPU alle paar tausend Taktzyklen pro Kern ein Ergebnis erwarten können, sagen wir 10 Millionen Hashes pro Sekunde auf einem Multi-Core-Multi -GHz-CPU.

Wenn dieses spezielle Beispiel für Sie von Interesse ist, sollten Sie sich meine verwandte Antwort zu den Interna von ASIC-Minern auf bitcoin.stackexchange ansehen, da viele FPGA-Miner auf die gleiche Weise arbeiten und eher konfigurierbare als maßgeschneiderte Hardware verwenden. Nur der Vollständigkeit halber: Es gibt andere Möglichkeiten, wie das Einschränken oder Vermeiden des von mir beschriebenen Pipelining zugunsten einer trivialeren Parallelisierung durch die Verwendung mehrerer unabhängiger SHA-256-Hasher. Abhängig von den Einschränkungen, die durch die Interna Ihres FPGAs und seine Gesamtgröße gegeben sind, kann dies sogar eine bessere Leistung liefern, obwohl es in Bezug auf die Gate-Anzahl und den Routing-Overhead weniger effizient wäre, wenn Sie vollkommene Freiheit beim Design des gesamten Chips hätten, nicht nur bei der Konfiguration eines FPGA .

Die obigen Antworten sind zwar richtig, verfehlen aber den Punkt, warum FPGAs (und benutzerdefinierte ASICs) besonders gut für Bitcoin-Berechnungen geeignet sind.

Der wirkliche Vorteil besteht darin, dass ein großer Teil der SHA-256-Berechnungen logische Operationen (z. B. Bitverschiebungen) sind, die in der Verkabelung durchgeführt werden können. Auf diese Weise benötigen sie 0 Taktzyklen.

Ein weiterer wichtiger Vorteil besteht darin, dass FPGAs viel energieeffizienter sind (dh MIPS pro Watt) als CPUs, sodass die für die Berechnungen benötigte Energiemenge viel geringer ist. Dies ist wichtig, da die Kosten für das Schürfen eines Bitcoins davon abhängen, wie viel Strom Sie für seine Herstellung verbrauchen.

ASIC-Chips sind energieeffizienter als FPGAs, sodass sie den gleichen Code viel billiger ausführen können. Sie können auch mehr Exekutionseinheiten an Bord stopfen, um sie schneller zu machen. Der Nachteil ist, dass die Kosten für die Herstellung eines benutzerdefinierten ASIC sehr hoch sind, sodass Sie einige Chips verkaufen müssten, um die Herstellungskosten zu decken.

GPUs werden auch zur Herstellung von Bitcoins verwendet, aber da sie viel weniger energieeffizient sind, haben sie gegenüber FPGAs und kundenspezifischen ASICs an Boden verloren.