Man liest manchmal davon dass bereits daran geforscht wird CPUs zu entwickeln die einen FPGA Kern besitzen. Im Idealfall soll die CPU dabei für bestimmte Berechnungen eigenständig die Berechnung im FPGA Teil durchführen um die massiv parallele Verarbeitung nutzen zu können. Dabei müsste das FPGA Kern sehr schnell rekonfigurierbar sein während die CPU weiter läuft. Für wie realistisch haltet ihr diese Entwicklung? Welche großen Hürden gibt es? Und mit welchen Leistungssteigerungen sind zu rechnen? Ich weiß nicht inwiefern eine CPU eigenständig bestimmte Algorithmen automatisch erkennen und dann in FPGA implementieren kann. Realistischer erscheint mir wenn es für so eine CPU neue Befehle gibt und eine einfache SDK für Anwendungsentwickler oder für Spieleentwickler. So das die Entwickler selbst entscheiden können welche Berechnungen im FPGA Teil parallel stattfinden sollen. Die Programmierung sollte ähnlich wie bei OpenCL sein und nicht in Form einer Hardwarebeschreibungssprache erfolgen.
Xilinx ZYNQ macht das schon seit vielen Jahren zumindest so ähnlich. Die Beschreibung geht auch per HLS also in C und nicht in VHDL. Ist natürlich kein Desktop Prozessor, gibts halt "nur" bis Quadcore ARM.
Mac G. schrieb: > Ist natürlich kein Desktop Prozessor, gibts halt "nur" bis Quadcore ARM. Gibts bei den Xeons aber auch schon länger: https://www.golem.de/news/broadwell-ep-intel-zeigt-xeon-e5-mit-arria-fpga-auf-einem-package-1603-119772.html
Zi3 schrieb: > Man liest manchmal davon dass bereits daran geforscht wird CPUs zu > entwickeln die einen FPGA Kern besitzen. Vor einem Jahr hat Intel mit der Auslieferung begonnen: http://www.eweek.com/servers/intel-begins-shipping-xeon-chips-with-fpga-accelerators > Dabei müsste das FPGA Kern sehr schnell rekonfigurierbar sein während > die CPU weiter läuft. Man würde das wohl eher wie bei den GPUs machen und eine Aufgabe lange laufen lassen. > Und mit welchen Leistungssteigerungen sind zu rechnen? Kommt drauf an. Wie gut läßt sich der Algorithmus parallelisieren usw. Zi3 schrieb: > Ich weiß nicht inwiefern eine CPU eigenständig bestimmte Algorithmen > automatisch erkennen und dann in FPGA implementieren kann Das ist einfach zu beantworten: Gar nicht. Selbst die Parallelisierung durch die SIMD-Befehle (SSE, AVX) macht der Compiler (oder der Programmierer) und nicht die CPU.
Horst schrieb: > Mac G. schrieb: >> Ist natürlich kein Desktop Prozessor, gibts halt "nur" bis Quadcore ARM. > > Gibts bei den Xeons aber auch schon länger: > https://www.golem.de/news/broadwell-ep-intel-zeigt... Das sind allerdings ZWEI Chips in einem Modul. Und das Ding ist auch eher nicht für "Desktop" gedacht. Xeon E5 EP und Arria FPGA jeweils für sich alleine kosten schon einige tausend Euro, das ganze Modul dürfte so zwischen 4000 - 10000 Euro liegen, je nachdem welches FPGA genau verwendet wird ;-)
Diese CPU sind für Telekom und Internet Anwendungen, wo man oft die Algorithmen ändert, weil wieder neue Kompressionsverfahren oder Routingstrategien ausprobiert bzw. implementiert werden sollen. Von "Desktop" sind wir da bei fast allen Parametern fast schon diametral entfernt...
:
Bearbeitet durch Moderator
Zi3 schrieb: > Ich weiß nicht inwiefern eine CPU eigenständig bestimmte Algorithmen > automatisch erkennen und dann in FPGA implementieren kann. Algorithmisch tut sich bei heutiger Consumer-Software nicht so viel dass sich der Overhead für rekonfigurierbare Logik lohnen würde. Bei der Kryptographie ist seit >10 Jahren AES der Standard, Videodekodier-Standards entwickeln sich auch nicht schneller, und alles aus dem Bereich Signalverarbeitung (Videoeffekte, Spracherkennung, Bilderkennung etc.) braucht nur schnelle Grundrechenarten auf großen Vektoren.
:
Bearbeitet durch Admin
Zi3 schrieb: > Realistischer erscheint mir wenn es für so eine CPU neue Befehle gibt > und eine einfache SDK für Anwendungsentwickler oder für > Spieleentwickler. Perlen vor die Säue, Neuronale netzte wäre ein sinnvolleres Einsatzgebiet für FPGA-Beschleunige. > So das die Entwickler selbst entscheiden können welche Berechnungen im > FPGA Teil parallel stattfinden sollen. Warum das? > Die Programmierung sollte ähnlich wie bei OpenCL sein und nicht in Form > einer Hardwarebeschreibungssprache erfolgen. Warum das?
C. A. Rotwang schrieb: >> Die Programmierung sollte ähnlich wie bei OpenCL sein und nicht in Form >> einer Hardwarebeschreibungssprache erfolgen. > Warum das? Der ewige Traum: weil man dann Softwareentwickler schnelle Hardware machen lassen könnte...
C. A. Rotwang schrieb: >> Die Programmierung sollte ähnlich wie bei OpenCL sein und nicht in Form >> einer Hardwarebeschreibungssprache erfolgen. > Warum das? Damit die Akzeptanz größer ausfällt und die Unternehmen ihre Software Teams nicht mit weiteren Fachkräften für die Entwicklung von Digitaltechnik aufstocken müssen. Wobei sicher nichts dagegen spricht einfach verschiedene Abstraktionsebenen anzubieten.
C. A. Rotwang schrieb: > Neuronale netzte wäre ein sinnvolleres Einsatzgebiet für > FPGA-Beschleunige. Auch wenn es auf den ersten Blick naheliegend erscheint, in der Regel macht es keinen Sinn ein neuronales Netz in kombinatorischer Logik abzubilden. Die "Intelligenz" eines neuronalen Netzes steckt nicht in der Struktur, sondern in den Gewichtsmatrizen, deshalb wuerde man auch nicht viel von der flexibel konfigurierbaren Feinstruktur eines FPGAs profitieren. Die meiste Rechenzeit bei der Auswertung geht in die Multiplikation der Eingaenge eines Layers mit der Matrix der Gewichte – also klassische Vektorrechnung fuer die CPUs und GPUs heute eh schon optimiert sind. Google geht mit der TPU (https://en.wikipedia.org/wiki/Tensor_processing_unit) noch einen Schritt weiter und optimiert speziell Vektorrechnung mit niedriger Aufloesung (8 Bit). Dass solche Funktionen demnaechst auch in CPUs landen halte ich fuer eher denkbar (bei AVX ist m.W. nach unten hin bei 16 Bit Aufloesung Schluss).
Denkbar wäre ein neues Lisp-Machine-Design, wenn man an die vielen Lisp-Dialekte denkt ;)
Nvidia ist den Weg auch schon gegangen: https://www.heise.de/newsticker/meldung/GTC-2017-Nvidias-Volta-Architektur-ein-Meilenstein-im-GPU-Design-3712206.html Microsoft kommt allerdings auch zu interessanten Ergebnissen: https://www.microsoft.com/en-us/research/publication/accelerating-deep-convolutional-neural-networks-using-specialized-hardware/?from=http%3A%2F%2Fresearch.microsoft.com%2Fpubs%2F240715%2Fcnn%2520whitepaper.pdf Andreas S. schrieb: > C. A. Rotwang schrieb: >> Neuronale netzte wäre ein sinnvolleres Einsatzgebiet für >> FPGA-Beschleunige. > > Auch wenn es auf den ersten Blick naheliegend erscheint, in der Regel > macht es keinen Sinn ein neuronales Netz in kombinatorischer Logik > abzubilden. Die "Intelligenz" eines neuronalen Netzes steckt nicht in > der Struktur, sondern in den Gewichtsmatrizen, deshalb wuerde man auch > nicht viel von der flexibel konfigurierbaren Feinstruktur eines FPGAs > profitieren. Die meiste Rechenzeit bei der Auswertung geht in die > Multiplikation der Eingaenge eines Layers mit der Matrix der Gewichte – > also klassische Vektorrechnung fuer die CPUs und GPUs heute eh schon > optimiert sind. Google geht mit der TPU > (https://en.wikipedia.org/wiki/Tensor_processing_unit) noch einen > Schritt weiter und optimiert speziell Vektorrechnung mit niedriger > Aufloesung (8 Bit). Dass solche Funktionen demnaechst auch in CPUs > landen halte ich fuer eher denkbar (bei AVX ist m.W. nach unten hin bei > 16 Bit Aufloesung Schluss).
Zi3 schrieb: > Wobei sicher nichts dagegen spricht einfach verschiedene > Abstraktionsebenen anzubieten. Diese Ebenen gibt es ja schon und sie werden auch bedient. Es geschieht nur eben nicht automatisch, wie es sich mancher Träumer vorstellt. Das Markante an der Problematik ist einfach, das es ja die typischen "Softwareaspekte" sind, die abstrahiert und "vereinfacht" werden (sollen). Wenn da der Fokus liegt, geht das prima. Es bleibt aber der Umstand, dass eine effektive Softwareentwicklung immer Kenntnisse der HW erfordert, d.h. eine bekannte Struktur voraussetzt. Es läuft also immer wieder auf die Nutzung eines Cores hinaus, weil keiner ständig eine neu adaptierte HW bauen möchte. Die über diese Anforderungen darüber hinaus noch zu implementierende Sonderhardwarefunktion erfordert aber immer wieder eine spezielle Schaltung, die sich eben nur zum Teil durch ihren Ablauf beschreiben und sich nicht aus der SW-Beschreibun ableiten lässt. Das ist nun mal so und grundsätzlich niemals zu ändern. Was sich nur ändert, ist nur der Fokus, also das Verhältnis von SW und HW bei einer APP: Man wird sich aus (kosten)technischen Gründen eher mal mit suboptimaler HW zufrieden geben und mehr in die SW verlagern, wenn die HW preiswerter wird und man etwas verschwenderischer damit umgehen kann. Den Prozess haben wir ja heute schon. Es wird mit mehr Tempo und weniger Optimierungseinsatz entwickelt und zwar was HDL für FPGAs und auch CPP für MCUs angeht. Was das muntere Austauschen von HW-Funktionen in FPGAs in Echtzeit angeht, sehe Ich da enge Grenzen: FPGAs sind aufgrund der Universalität letztlich ziemlich langsam und profitieren von speziellen Strukturen, die nur bei bestimmten Randbedingungen wirklich effektiv sind. Besonders pipelines und multithreading FSMs liefern ganz bestimmte Soll-Verhältnisse für Kanalzahl, Frequenz und Zugriffsoptionen. Da lässt sich nur schwer was umändern, um dynamisch schneller zu werden. Die FPGAs im Umfeld der CPUs haben mithin ihre Hauptbedeutung weiterhin darin, sich gegen Fehler bei Auslieferung zu schützen oder sich auf mögliche Änderungen der Funktion oder künftige, zum Zeitpunkt der Entwicklung noch unbekannte Peripherie vorbereiten zu können. Und genau das macht Intel.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.