Intel hat im Sommer heimlich still und leise eine neue Xeon-CPU vorgestellt, in die ein FPGA integriert ist. http://www.extremetech.com/extreme/184828-intel-unveils-new-xeon-chip-with-integrated-fpga-touts-20x-performance-boost Abgesehen von den dort bereits genannten Optionen, der Anpassung an spezielle Hardware, sowie der von mir jetzt mal frech angenommenen Möglichkeit des bugfixings: Wo seht ihr da Anwendungen? Liessen sich bestimmte Berechnungen in dem FPGA durchführen?
FPGA-Phreak schrieb im Beitrag #3813839: > Intel hat im Sommer heimlich still und leise eine neue Xeon-CPU > vorgestellt, in die ein FPGA integriert ist. Der umgekehrte Weg ist ja schon ein URALTER Zopf aus dem letzten Jahrtausend: FPGAs mit CPU(s). > Wo seht ihr da Anwendungen? Das hängt davon ab, wie Intel den Zugang zu diesem FPGA gestaltet. Wenn da jeder eine Entwicklungsumgebung herunterladen kann, dann wird es schnell still um das FPGA. Dieser Satz hier ohne ein Wort zur konkreten Anwendung ist bloßes Altweibergeschwätz:
1 | to turbo-charge their critical algorithms.” Intel estimates that the |
2 | Xeon+FPGA will see massive performance boosts in the 20x range |
3 | (for code executed on the FPGA instead of a conventional x86 CPU |
"conventional x86" ist damit ein 8086 gemeint? Auf jeden Fall ist ein dedizierter ASIC immer schneller als ein für die gleiche Anwendung konfiguriertes FPGA. > Wo seht ihr da Anwendungen? Ich könnte mir gut vorstellen, dass die Filmindustrie an so einer (schnell umkonfigurierbaren) Lösung Interesse haben könnte.
Dieser Artikel gab ein bisschen Einblick in die Anwendung um Suchmaschinen zu beschleunigen (erwähnt werden Bing und Baidu): http://www.eetimes.com/document.asp?doc_id=1323500
Direkt neu ist die Idee nicht. Gabs schon öfter, aber mit im Vergleich dazu eher schwacher CPU. Also FPGA mit Hilfsmotor. Neu hier ist, dass es eine Highend-CPU ist. Die aber statt einer GPU ein FPGA drauf hat. Es gibt derzeit einen Trend, eine Onchip-GPU aka APU nicht bloss für Grafik, sondern auch für andere Jobs zu nutzen. Speziell AMD ist da rührig und integriert diese APU stärker und dichter in die Anwendungsprogrammierung. Und nun kommt eben von Intel ein FPGA in ähnlicher Rolle wie AMDs APU. Der Unterschied zu reinen FPGAs (oder gar ASICs) ist auch, dass man kein spezielles Board für eine FPGA/ASIC-Lösung eines anspruchsvollen Problems braucht. Sondern die gute Infrastruktur normaler PC- und Serverboards nutzen kann, Betriebssystem inklusive. Das FPGA ist dabei nur für einen speziellen Teil der Gesamtlösung zuständig, jenen, den man mit CPU Programmierung schlecht hinbekmmt.
>Das FPGA ist dabei >nur für einen speziellen Teil der Gesamtlösung zuständig, jenen, den man >mit CPU Programmierung schlecht hinbekmmt. Die Frage ist vor allem wie ist der FPGA ins System integriert. Hab ich eventuell sogar direkt access (PCI-E) over dma, oder hängt da ein buss dazwischen, den man füttern muss. usw.. >Der Unterschied zu reinen FPGAs (oder gar ASICs) ist auch, dass man kein >spezielles Board für eine FPGA/ASIC-Lösung eines anspruchsvollen >Problems braucht. Sondern die gute Infrastruktur normaler PC- und >Serverboards nutzen kann, Betriebssystem inklusive. 100% ACK. Find ich auch spannend. gruß JOnas
Da wir jetzt schon viele Cores haben aber die Software im Schnitt sich immer noch recht schwer tut diese effektiv zu nutzen, scheint mir die Zurückhaltung von Intel beim Marketing des "FPGA-Coprozessors" weise. Bis in jedem Allerweltsrechner so ein FPGA sinnvoll genutzt und es deswegen auch gerne bezahlt wird, ist es noch ein langer Weg, vielleicht ist es aber auch ein absterbender Ast der Rechnerevolution, so wie vieles andere. Denn das Silizium eines FPGA effektiv zu nutzen kostet einen qualifizierten Ingenieur, der zudem teuter als ein Allerweltssoftwareingenieur ist, ein vielfaches an Zeit. Man kann nur auf die automatische, superschnelle und hocheffektive Parallelisierung von single Threaded Software und Algorithmen ins FPGA hoffen. Und dann schaue man sich nur einmal an was eine Arbeit und Rechenzeit es bedeutet die Logik ins FPGA zu übersetzen, zu platzieren und zu routen und dabei das Timing sicherzustellen. Um hier nicht unheimlich viel Power des FPGA-Siliziums zu verschwenden was es unwirtschaftlicher aber auch "einfacher" in der Handhabung machen würde, damit dieser Kompromiss unter dem Strich ein positiver ist muss noch so etwas wie ein Wunder geschehen, denn es konkurrieren GPU's und Multimediaacceleratoren, SIMD, u.v.a. mit, schon lange erfolgreich.
Raymund H. schrieb: > Denn das Silizium eines FPGA effektiv zu nutzen kostet einen > qualifizierten Ingenieur, der zudem teuter als ein > Allerweltssoftwareingenieur ist, ein vielfaches an Zeit. Soweit musst du gar nicht gehen, schreibst du ja selber: Raymund H. schrieb: > Da wir jetzt schon viele Cores haben aber die Software im Schnitt sich > immer noch recht schwer tut diese effektiv zu nutzen Ein qualifizierter Ingenieur, der es schafft das Silizium eines modernen Intelprozessors effektiv zu nutzen, ist auch teuer und benötigt viel Zeit. Raymund H. schrieb: > Man kann nur auf die automatische, superschnelle und hocheffektive > Parallelisierung von single Threaded Software und Algorithmen ins FPGA > hoffen. Genau das machen "Allerweltssoftwareingenieure" seit den 80er Jahren. Und sie werden weiter vergeblich hoffen. Ein kleiner Lichtblick: Ich kenne aktuell in meinem Umfeld einen Informatik Studenten an der ETH Zürich, der wird schon im 1. Semester mit Konzepten zu paralleler Programmierung geprügelt :-) Raymund H. schrieb: > damit dieser Kompromiss unter dem Strich ein positiver ist muss > noch so etwas wie ein Wunder geschehen, denn es konkurrieren GPU's und > Multimediaacceleratoren, SIMD, u.v.a. mit, schon lange erfolgreich. Auch nur wenn sie von qualifizierten Ingenieuren benutzt werden. Das Wunder von dem du sprichst könnte OpenCL sein, wir werden sehen wie sich das entwickelt und ob OpenCL sich in der Praxis überhaupt für FPGAs eignet (Altera versucht es ja schon, keine eigene Erfahrung). Die anderen von dir genannten techniken werden auch weiterhin auf dem Markt bestehen bleiben. (Math Star mit dem field programmable object array [FPOA] ist ja tod)
Christoph Z. schrieb: > Raymund H. schrieb: >> Da wir jetzt schon viele Cores haben aber die Software im Schnitt sich >> immer noch recht schwer tut diese effektiv zu nutzen > > Ein qualifizierter Ingenieur, der es schafft das Silizium eines modernen > Intelprozessors effektiv zu nutzen, ist auch teuer und benötigt viel > Zeit. Ingenieure sind verschieden Teuer, ergo unterscheiden sie sich in ihrem Nutzen, zumindest dem Vermeintlichem für die die das Geld geben. Darf man das sagen? Nun, ich will/wollte darauf hinaus dass ein Ingenieur (eher ein Team) der/das einen Intel Prozessor mit FPGA effektiv nutzt, teurer (und evtl. auch gestresster) als einer der "nur" SSE4, und X64 nutzt ist, denn da ist ja vieles durch Compiler automatisiert. Der Markt ist gnadenlos und "rechnet" das gegen den Nutzen den es ihm tatsächlich bringt (und natürlich auch den "Bling"- oder "Buzz"-Faktor) und tut sich wohl schwer mit dem FPGA + Intelx64-Chip. > Raymund H. schrieb: >> Man kann nur auf die automatische, superschnelle und hocheffektive >> Parallelisierung von single Threaded Software und Algorithmen ins FPGA >> hoffen. > > Genau das machen "Allerweltssoftwareingenieure" seit den 80er Jahren. > Und sie werden weiter vergeblich hoffen. Ganz vergeblich nicht. denke ich, denn schaut man zurück dann hielt die x86-Architektur ja schon sehr lange durch, hat sich in kleinen Schritten zu dem was wir heute haben evolviert, wo wir doch mal so ein RISC-Hype hatten und der böse CISC x 86 immer gedisst wurde, an allem schlechten in der IT Schuld war, auch daran dass W95 so oft abgestürzt ist. Genau da vermute ich auch das größte Potential: Die Architektur nur so weit ändern dass die meisten Ingenieure immer noch effektiv damit umgehen können aber es dabei schaffen trotzdem mehr Leistung aus dem Silizium was man fertigen kann zu holen. Was soll auch anderes passieren? > Ein kleiner Lichtblick: Ich kenne aktuell in meinem Umfeld einen > Informatik Studenten an der ETH Zürich, der wird schon im 1. Semester > mit Konzepten zu paralleler Programmierung geprügelt :-) Nun, man könnte meinen das Problem ist zumindest erkannt. Doch der Mensch hat grob zwei Extreme mit Problemen umzugehen: Vermeidung (Flucht) Lösung (Kampf) Praktisch ist es meist irgend was dazwischen, also eine Vereinfachung des Problems um nicht so viel Kämpfen zu müssen. > Auch nur wenn sie von qualifizierten Ingenieuren benutzt werden. Das > Wunder von dem du sprichst könnte OpenCL sein, wir werden sehen wie sich > das entwickelt und ob OpenCL sich in der Praxis überhaupt für FPGAs > eignet (Altera versucht es ja schon, keine eigene Erfahrung). > Die anderen von dir genannten techniken werden auch weiterhin auf dem > Markt bestehen bleiben. Ich weiß nicht so recht. Parallelität ist so schlecht skalierbar, so störrisch, das Puzzle ist so schwer zusammenzusetzen. Der Wunsch ist klar, siehe oben, doch warten wir es ab, bleibt auf jeden Fall spannend. > (Math Star mit dem field programmable object array [FPOA] ist ja tod) Ich denke so Sachen und auch "Systolic Arrays" o.ä. leben in der Nische und im Geschlossenen weiter, es gibt bestimmt ein paar praktische Anwendungen in Silizium auf der Welt, muss ja keiner wissen. Was ich mir bei Altera und dem C-V mit Arm schon gedacht hab ist dass da Arm auch einen gewissen Einfluss bei der Entwicklung hatte. Ich denke das HPS mit dem ARM ist keine alleinige Altera-Eigenentnwicklung, logisch, zumindest der ARM Core schon mal nicht, vieles der Peripherie ist auch aus dem ARM-IP Programm, was die FPGA-spezifischeren Dinge angeht mag, wie gesagt, Arm da ja einen Teil geleistet oder sogar vorgearbeitet haben, vielleicht hat man sich was davon versprochen. Vielleicht hatte Arm sogar mal Pläne selbst ein FPGA (mit arm natürlich) zu machen, in der Embedded Welt vielleicht viel eher mit Erfolgsaussicht als im PC-x86 Markt, durch die andere Anwendungsstruktur und die anderen Ingenieurstypen. Doch dann haben die vielleicht gemerkt was die FPGA-Player in die EDA-Software stecken müssen. Doch Intel hat das gesehen und wollte auch was tun, wenn es auch nur erstmal zum "Probieren" ist. Egal, genug spekuliert.
Cool, kann man dann neuerdings Rechner auch per Malware-FPGA-Configfile ins Hardware-Jenseits schicken? Wäre mal was neues, wenn man ganze Datencenter mit nem einfachen Virus dauerhaft lahmlegen könnte, DDoS wird langsam langweilig.
Virenprogger schrieb: > Cool, kann man dann neuerdings Rechner auch per Malware-FPGA-Configfile > ins Hardware-Jenseits schicken? Jede Zelle ein Ringoszillator und das Licht geht aus, oder an, ich schätze ich weiss nicht so genau. Das ist aber in der Tat eine interessante Idee auf die du mich da bringst: Die CPU hat eine MMU und ein Betriebssystem. Wie wird das FPGA vor Schadcode geschützt? Und wie wird es zwischen den Prozessen aufgeteilt? Wie werden die gegeneinander abgeschirmt? Wie macht man Kontextumschaltung? Der Kontext eines FPGA's hat viele Größenordungen mehr Bits als die paar Prozessorregister. Das braucht Zeit und Energie. Braucht das FPGA dann einen User- und Supervisor-Mode? Was darf man im User Mode das FPGA noch tun lassen? Kann man überhaupt sinnvoll per FPGA-Betriebssytem überwachen ob Schadcode eine extreme Verlustleistung / Schaltaktivität (asynchron) evtl. mit der Folge der Zerstörung oder Fehlfunktion von Digitallogik durch Übersprechen bewirkt? Braucht das FPGA auch eine art Bitstreampolizei und -Feuerwehr? Doch so weit muss es überhaupt erst mal kommen, bei den größeren Problemen die ich schon aufgezählt habe.
Raymund H. schrieb: > Bis in jedem Allerweltsrechner so ein FPGA sinnvoll genutzt und es > deswegen auch gerne bezahlt wird, ist es noch ein langer Weg, vielleicht > ist es aber auch ein absterbender Ast der Rechnerevolution, so wie > vieles andere. Ein breiter Massenmarkt wird das wahrscheinlich nicht. Allein schon deshalb, weil bei ausreichend Masse spezifische Prozessorerweiterungen für die typischerweise damit gelösten Aufgaben auftauchen werden. Die dann natürlich wesentlich effizienter sind als ein FPGA. Die FPGA-Phase wäre für solche Fälle nur eine Art Prototypenstadium auf dem Weg zur eigentlichen Lösung. > Und dann schaue man sich nur einmal an was eine Arbeit und Rechenzeit es > bedeutet die Logik ins FPGA zu übersetzen, zu platzieren und zu routen > und dabei das Timing sicherzustellen. Das gilt aber nicht nur für FPGAs in CPUs, sondern für FPGAs allgemein. Und es lässt sich kaum übersehen, dass FPGAs tatsächlich eingesetzt werden, obwohl der Aufwand nicht unbeträchtlich ist. ;-) Allerdings kann man die Probleme, die man mit FPGAs löst, vereinfachend in zwei Klassen einteilen, die ich mal hardware-bezogene Probleme und algorithmische Probleme nennen will. Die hardware-bezogenen Probleme setzen anwendungsspezifische Interfaces voraus, vulgo Pins mit entsprechender Programmierung. Es versteht sich von selbst, dass Intels Ansatz hier nicht weiterhilft. Bei den algorithmischen Problemen geht es um spezielle Aufgaben, die man ebensogut mit normalen PC-Programmen lösen könnte, wenn die dafür nur schnell genug wären. Sowas wie Bitcoin-Mining beispielsweise. Genau da setzt Intels Ansatz an. Bisher konnte man, um FPGAs für solchen algorithmischen Aufgaben einzusetzen, ein FPGA über PCIe anbinden. Dabei ist allerdings die Kooperation mit der CPU eher lose, mit entsprechen hohen Latenzen. Am meisten Sinn ergibt eine Integration in die CPU deshalb, wenn das FPGA deutlich enger mit der CPU kooperiert, als das mit PCIe möglich ist. Beispielsweise indem Caches konstruktiv berücksichtigt statt leergeräumt werden und indem man verwendete Speicheradressen nicht erst umständlich durch den Wolf der Speicherverwaltung drehen muss, bevor man sie dem FPGA vorwerfen kann. Ich wäre freilich auch nicht erstaunt, wenn diese Entwicklung nicht allein eine Idee von Intel war. Sondern bestimmte mit viel Geld ausgestattete Nischenmärkte ein Interesse an durchsatzstarken Lösungen haben, mit denen man sich in relativ kurzer Zeit neuen Problemen widmen kann.
:
Bearbeitet durch User
Raymund H. schrieb: >> Raymund H. schrieb: >>> Man kann nur auf die automatische, superschnelle und hocheffektive >>> Parallelisierung von single Threaded Software und Algorithmen ins FPGA >>> hoffen. >> >> Genau das machen "Allerweltssoftwareingenieure" seit den 80er Jahren. >> Und sie werden weiter vergeblich hoffen. > > Ganz vergeblich nicht. denke ich, denn schaut man zurück dann hielt die > x86-Architektur ja schon sehr lange durch, hat sich in kleinen Schritten > zu dem was wir heute haben evolviert, wo wir doch mal so ein RISC-Hype > hatten und der böse CISC x 86 immer gedisst wurde, an allem schlechten > in der IT Schuld war, auch daran dass W95 so oft abgestürzt ist. > > Genau da vermute ich auch das größte Potential: Die Architektur nur so > weit ändern dass die meisten Ingenieure immer noch effektiv damit > umgehen können aber es dabei schaffen trotzdem mehr Leistung aus dem > Silizium was man fertigen kann zu holen. Seit ich diesen Artikel gelesen habe (und mir der Kopf gehörig geraucht hat danach) habe ich die Hoffnung definitv aufgegeben: http://www.heise.de/artikel-archiv/ct/2014/12/176_Matrix-reloaded Ja, es sind alles Compiler Tricks, aber man muss sie richtig einsetzen und den richtigen Compiler zur Hand haben. Und sein Problem überhaupt überblicken, was im Artikel eine "simple" Matrix Multiplikation ist. Raymund H. schrieb: >> Ein qualifizierter Ingenieur, der es schafft das Silizium eines modernen >> Intelprozessors effektiv zu nutzen, ist auch teuer und benötigt viel >> Zeit. [...] > Nun, ich will/wollte darauf hinaus dass ein Ingenieur (eher ein Team) > der/das einen Intel Prozessor mit FPGA effektiv nutzt, teurer (und evtl. > auch gestresster) als einer der "nur" SSE4, und X64 nutzt ist, denn da > ist ja vieles durch Compiler automatisiert. Ja, kann ich dich voll unterstützen. Ein Team aus x86 Experten wird viel effizienter sein als ein Team aus x86 und FPGA Experten (Bei gleichen kosten oder Anzahl Personen)
Christoph Z. schrieb: >> Nun, ich will/wollte darauf hinaus dass ein Ingenieur (eher ein Team) >> der/das einen Intel Prozessor mit FPGA effektiv nutzt, teurer (und evtl. >> auch gestresster) als einer der "nur" SSE4, und X64 nutzt ist, denn da >> ist ja vieles durch Compiler automatisiert. Automatisierter durch einen Compiler erzeugter Code ist aber meist ineffizienter als einer bei dem vor dem Code nachgedacht wurde wie der in der CPU abgearbeitet wird. Es ist ein verbreiter Irrgaluben das ein optimierender Compiler aus einer hingeklatschenden Algorithmus Beschreibung optimalen Code erzeugt. Der Compiler ist nicht klüger als der User der ihn benutzt - a fool with a tool is still a foll. MfG,
@ Logische Wahrheit Sicher doch. Bedenke aber auch dass Prozessoren heute auf automatische Optimierung des Codes hin entwickelt werden (Out of order execution, automatische paralellisierung), das macht die "Handoptimierung" im Vergleich zur automatischen evtl. deutlich unwirtschaftlicher und die Wahrscheinlichkeit dass die Handoptimierung nix ist außer Zeitverschwendung steigt. Und das ist es am Ende: Ein Kompromiss der sich wirtschaftlich trägt.
:
Bearbeitet durch User
Raymund H. schrieb: > @ Logische Wahrheit > > Sicher doch. > > Bedenke aber auch dass Prozessoren heute auf automatische Optimierung > des Codes hin entwickelt werden (Out of order execution, automatische > paralellisierung), das macht die "Handoptimierung" im Vergleich zur > automatischen evtl. deutlich unwirtschaftlicher und die > Wahrscheinlichkeit dass die Handoptimierung nix ist außer > Zeitverschwendung steigt. Nein, automa(t|g)ische Optimierung funktiniert nicht bei schrottigen Code/Algorithmus. Die "Handoptimierung" ist hier nicht zeitverschwendet sondern notwendig. Handoptimierung bedeutet hier nicht assemblercode zu schreiben sondern seinen Code so zu schreiben das die Voraussetzungen für die optimale auslastung von CPU-features erfüllt sind. Beispielsweise wird eine DFT deutliche schneller wenn man die sin - table viertelt und so Symmetrien ausnutzt. Die adressberechnung braucht zwar einnen Opcode mehr aber alle daten können lokal im Cache gehalten werden. Alle Daten optimal klein und zeitlich/örtlich lokal halten kann kein Compiler. Optimierung ausnutzen jederzeit, aber dazu muß man wissen wo welche Optimierung greift. Einfach Code hinschmieren und dann das Zauberwort "automatische Optimierung" murmeln bringt keinen optimalen Code. MfG MfG,
Fpga Kuechle schrieb:
Sagte ich handoptimierung ist generell sinnlos?
Das beispiel mit der dft ist nicht so glücklich, denn der handoptimierer
weiss nicht wie groß der cache gerade ist auf dem es läuft.
Außerdem gibt es wohl schon compiler die die zugriffsmuster auf die
sin/cos tabelle erkennen und u.u. Numerisch äquivalente optimierungen
machen die so eine tabelle vierteln.
Der schritt für den compiler dann die phasen sukzessiv per
matrixmultiplikation zu berechnen und damit aus dem cache zu nehmen ist
nicht mehr groß, wenn sie auch nicht numerisch äquivalent wären und
explizit enabled würden müssten.
Doch das problem der "skalierbarkeit" auf die maschine die den code
ausführt bleibt, weswegen ich denke diese optimierungen werden evtl. zum
teil ins betriebssystem und den prozessor wandern.
Betriebssysteme könnten ja eine neue innovationswelle nach html5
gebrauchen.
FPGA-Phreak schrieb im Beitrag #3813839: > Wo seht ihr da Anwendungen? High Speed Trading, die Finanzgeier zahlen für alles.
Christoph Z. schrieb: > Ja, kann ich dich voll unterstützen. Ein Team aus x86 Experten wird viel > effizienter sein als ein Team aus x86 und FPGA Experten (Bei gleichen > kosten oder Anzahl Personen) Ich nehme an, Du meinst, "so ein Team wird in der gleichen Zeit mehr nutzbare Funktion auswerfen" denn (Arbeits)effizienz/Teameffizienz ist ja noch mal was ganz anderes. Ich stimme Dir zu - aber der Vergleich ist auf jedes Projekt anwendbar, wo Neuentwickung (Hardwareerzeugung) mit der Nutzung bereits vorhandener Hardware (Softwareerzeugung) verglichen wird. Diese Frage, ob ein FPGA sinnvoller ist oder DSP/CPU sind meines Erachtens genrell Unfug, weil das Ergebnis der Betrachtung schon vorher feststeht, da nur Themen verglichen werden können, die beide leisten und da ist kaufen immer besser, als bauen :-) Die Fragestellung ist doch eigentlich eine ganz andere: a) Wann brauche ich die spätere Anpassbarkeit einer Hardware, um auf high speed / low level-Niveau z.B. bugs beseitigen oder Adaptionen an Unbekanntes erzeugen zu können, weil es eben in SW nicht gehen wird b) In welchen Fällen brauche ich die parallele Architektur von FPGAs, weil ich eine Rechenpipeline bauen will, die viele sequenzielle Berechnungen für viele time slots oder Kanäle durcführen soll Wenn diese Bedingungen erfüllt sind, scheiden DSPs und MCUs aus und es wird ein FPGA, auch wenn ein DSP es von der Funktion her grundsätzlich leisten könnte. Was ich mich hier nun frage; - Wie umfangreich wird dieser FPGA? - Wie ist er an die CPU angebunden? - Wie komme ich an den dran? Eine Option für ein solches System wäre z.B. das system monitoring in der Entwicklung. Auch die Verschlüsselung eines Busses aus Sicherheitsgründen wäre denkbar. Ein effektives pipeline prozessing ist nur machbar, wenn das Ding eigenes DP-RAM hat und auch eine parallele Anbindung an den RAM-Speicher des Systems. Wenn der FPGA nur zwischen Peripherie und CPU sitzt und mitguckt, ist da wenig zu tun. Der FPGA braucht eigenes DDR-RAM und viel BRAM, zudem breiten parallelen 64 Bit Zugriff auf die CPU-Register. Wenn es nur um ein COPRO System geht, wo FPGA und Intel kommunitzieren, müsste da nichts Neues her, das wird heute schon gebaut.
Vor ein Paar Jahren gabs es ja schon eine Intel-CPU (Atom, glaube ich) mit einem FPGA drauf (also ein Arria-Die neben der CPU in einem Package). Soweit ich mir erinnern kann, war das FPGA mit einem PCIe Bus an die CPU angebunden. Bei neueren Xeons wird es sicherlich nicht anders sein. Je nach dem, welches FPGA drauf ist, wird PCIe 2.0/3.0 verwendet, 1x, 2x, 4x oder vielleicht sogar 8x Links. Es wird nichts anderes sein, als ein normalter Processor mit einer PCIe-Karte drauf. Deshalb ist auch die ganze Diskussion, was man alles damit anstellen kann etwas sinnfrei -- man wird damit alles anstellen können, was man auch mit einem PCIe-Board mit einem FPGA machen kann. Altera pusht jetzt OpenCL, das finde ich gut. Leider habe ich mich damit noch nicht auseinandergesetzt. Im Prinzip, wird man OpenCL-Algorithmen mit der Grafikkarte entwickeln können und dann einfach auf das FPGA portieren können -- ohne, dass man sich mit FPGAs überhaupt auskennen muss. FPGA braucht keinen eigenen Speicher -- wozu auch, wenn man den Arbeitsspeicher einfach reinmappen kann und über PCIe darauf zugreifen kann? Vielleicht funktioniert das ganze auch mit dem Cache von der CPU. Grüße Kest
Nachtrag: ich nehme alles zurück und behaupte das Gegenteil -- so wie es ausschaut, verwendet Intel doch QPI und nicht mehr PCIe :-D Noch besser.
Kest schrieb: > FPGA braucht keinen eigenen Speicher -- wozu auch, wenn man den > Arbeitsspeicher In dem Punkt muss ich wiedersprechen. Wenn Du eine vollständige virtuelle pipeline bauen willst, und nur damit bekommst Du einen maximalen Datendurchsatz in der kompletten Schaltungslogig, weil anders als in sequenziellen Systemen nicht jeweils ein Elemetent eine Funktion ausführt, sondern zu jedem Zeitpunkt jedes Element seine Funktion vollführt, brauchst Du eine kontinuierliches mapping aller Parameter und "Variablen" = Zustandspeicher und dies geht nur über dual port RAMs die beide von beiden Seiten mit jedem Takt beschrieben werden. Wollte man das in sequenzieller Speichertechnolgie lösen braucht es die 2fache Bandbreite für jede geschriebene Variable und auch bei einem 64Bit Bus ist da schnell Schluss.
Man hast doch QPI: darüber wird mit der CPU kommuniziert. Das FPGA hat sicherlich ausreichend BlockRAMs (je nach FPGA sind bis zu wenigen MBytes möglich). DDR3/4 Speicher wird keiner im selben Package machen. Zum einen sind die CMOS-Technologien einfach unterschiedlich zum einem muss man sehr viel Wärme abführen. Speicher auf das Mainboard (extra für das FPGA) wird auch keiner packen... Stacked-RAM ist auch noch zu früh davon zu sprechen. Also bleibt nur SRAM im FPGA selber. Als FPGA wird da auch nicht unbedingt ein Cyclone drin stecken sondern mindestens Arria 10 (wegen der Technologie) und das FPGA hat auch mindestens schon einen Megabyte an BlockRams -- da kann man schon was basteln :-D Kest
Kest schrieb: > Speicher auf das Mainboard (extra für das FPGA) wird > auch keiner packen... Bei AMDs Sideport Momory damals wurde das gemacht. ;)
Kann es sein, Intel hier über das Hintertürchen in den FPGA-Markt eindringen möchte? Eigentlich kann ich mir nicht vorstellen, dass die ein derart grosses FPGA mit beipacken, wie Kest das hier vermutet.
Andi F. schrieb: > Kann es sein, Intel hier über das Hintertürchen in den FPGA-Markt > eindringen möchte? Das tut Intel doch schon in dem sie angeblich für Altera Silizium liefern. Vielliecht war Intel neidisch dass Altera so schöne Dual-Core Arms mit FPGA von ihnen bekommt und will auch "mitspielen"? Im massen PC-Markt scheint mir das kaum lohnend, der Embedded Markt ist da viel dankbarer.
Raymund H. schrieb: > Andi F. schrieb: >> Kann es sein, Intel hier über das Hintertürchen in den FPGA-Markt >> eindringen möchte? > > Das tut Intel doch schon in dem sie angeblich für Altera Silizium > liefern. Tun sie auch NOCH nicht. Arria 10: TSMC 20 nm Stratix 10: Intel Tri-Gate transistor technology (2015) http://www.altera.com/technology/system-tech/next-gen/process-technologies.html Altera ist übrigens nicht der einzige FPGA Hersteller mit Zugang zur Intel 14 nm FAB. > > Vielliecht war Intel neidisch dass Altera so schöne Dual-Core Arms mit > FPGA von ihnen bekommt und will auch "mitspielen"? Schwachsinn. Intel hat eine ARM Architecture Lizense und könnte jederzeit mitspielen. Nur lohnt es sich für Intel einfach nicht. > > Im massen PC-Markt scheint mir das kaum lohnend, der Embedded Markt ist > da viel dankbarer. Klar, nur geht hier um einen Xeon. Ganz andere Klasse.
Lattice User schrieb: > Schwachsinn. Intel hat eine ARM Architecture Lizense und könnte > jederzeit mitspielen. Nur lohnt es sich für Intel einfach nicht. Schwachsinn zurück, sie bräuchten eine "Altera Architecture License" und die ganze Software oder sie müssten es neu machen. Selbst ein Schwergewicht im Halbleitermarkt wie Intel sieht es wohl als nicht lohnenswert an so ein riesiges Investment mit bescheidenen Aussichten zu tun. Eher kauft Intel Altera. Da der Intel FPGA nicht breit vermarktet wird ist er wohl ein Nischenprodukt für Facebook, Goolge, Serverfarmen, Cisco, Netzwerk, Telecom etc. oder so etwas in der Art, für einen kleinen Markt weit abseits des Mainstreampcs, denn wie schon gesagt täte der Massenmarkt sich sehr schwer dieses Silizium effektiv zu nutzen.
Raymund H. schrieb: > Lattice User schrieb: >> Schwachsinn. Intel hat eine ARM Architecture Lizense und könnte >> jederzeit mitspielen. Nur lohnt es sich für Intel einfach nicht. > > Schwachsinn zurück, sie bräuchten eine "Altera Architecture License" und > die ganze Software oder sie müssten es neu machen. Eine "Altera Architecture License" gibt es natürlich nicht. Die Arm License sehr wohl. > > Selbst ein Schwergewicht im Halbleitermarkt wie Intel sieht es wohl als > nicht lohnenswert an so ein riesiges Investment mit bescheidenen > Aussichten zu tun. Das ist jetzt aber eine andere Aussage wie deine vorige: > Vielliecht war Intel neidisch dass Altera so schöne Dual-Core Arms mit > FPGA von ihnen bekommt und will auch "mitspielen"? > > Eher kauft Intel Altera. Es gibt noch andere Hersteller von Highend FPGa's. Achronix oder Tabula wären mundgerechtere Übernahmekandidaten, vor allen weil beide bereits bei Intel fertigen lassen. > > > Da der Intel FPGA nicht breit vermarktet wird ist er wohl ein > Nischenprodukt für Facebook, Goolge, Serverfarmen, Cisco, Netzwerk, > Telecom etc. oder so etwas in der Art, für einen kleinen Markt weit > abseits des Mainstreampcs, denn wie schon gesagt täte der Massenmarkt > sich sehr schwer dieses Silizium effektiv zu nutzen. Genau. Nur hat das nichts mit der Zielgruppe von existierenden FPGA SoCs zu tun.
Lattice User schrieb: > Das ist jetzt aber eine andere Aussage wie deine vorige: Nun, da Intel nicht von FPGA+x86 lebt, ist es für sie (noch) ein Spiel. Natürlich kann sich daraus etwas entwickeln wie Erfahrungen/Erkenntnisse für zukünftige Entscheidungen. Lattice User schrieb: > Nur hat das nichts mit der Zielgruppe von existierenden FPGA SoCs zu > tun. Sag ich doch.
Noch mal ein paar Informationen zu den Forschungsarbeiten von Microsoft: http://www.eetimes.com/document.asp?doc_id=1324372&_mc=NL_EET_EDT_EET_programmablelogicdesignline_20141023&cid=NL_EET_EDT_EET_programmablelogicdesignline_20141023&elq=386258bf50fa48028ce09c89e2630c98&elqCampaignId=19852 Entgegen meiner Annahme arbeiten sie gar nicht mit Kombie-Prozessoren:
1 | Microsoft has not evaluated CPUs with FPGA co-processors linked on a |
2 | coherent interconnect with shared memory, an approach companies such as |
3 | Intel and IBM are promoting. “But that’s a whole different programming |
4 | model, and it’s not clear how you share data and control structures -- |
5 | I don’t think anyone has figured that out yet.” |
Christoph Z. schrieb: > Microsoft has not evaluated CPUs with FPGA co-processors linked on a > coherent interconnect with shared memory Sieht aus als mache es mehr Sinn das FPGA in den Netzwerkchip zu packen. Ein hardened Crypto Acellerator + FPGA Netzwerk/Switch/Router chip oder so was in der Art. Gibts das nicht schon? Ich weiss einfach nicht recht mit dem FPGA + x86 im Allerweltsrechner was das soll. Da hat man ja offensichtliche netzwerkbezogene Durchsatzprobleme aber der Markt ist zu klein für den Netzwerbeschleunigerchip?
"Bisher konnte man, um FPGAs für solchen algorithmischen Aufgaben einzusetzen, ein FPGA über PCIe anbinden. Dabei ist allerdings die Kooperation mit der CPU eher lose, mit entsprechen hohen Latenzen. Am meisten Sinn ergibt eine Integration in die CPU deshalb, wenn das FPGA deutlich enger mit der CPU kooperiert, als das mit PCIe möglich ist." Bei einem Serverboard: -freut man sich über jede auf dem Board integrierte Hardware da PCIe-Slots gerade in 1HE-Chassis wertvolle Mangelware sind -flucht man über jede integrierte Hardware weil sie im Defektfall nicht trivial austauschbar ist* und, auch wenn nicht genutzt und abgeschaltet wird,immer ein gewisses Stör-und Sicherheitsrisiko darstellt. *bei höheren Xeon-Modellen kostet es mitunter mehr eine CPU als ein Board zu tauschen daher gilt da dasselbe...
Den Einwand sehe ich, aber gerade ein FPGA birgt ja die Möglichkeit, solche bugs gfs noch zu beheben. Und: Man hätte die Chance, die Operationen umzuschalten: Denken wir mal an das Interrupthandling und das Verteilen von threads. ei eher streaming-getriebenen Anforderungen sähe das management hierfür ganz anders aus, als bei mehreren heterogenen Prozessen mit random access. Man könnte dann je nach Aufgabe, die Funktion und Strategie mit einem Klick umschalten, wenn man die zugehörige FPGA-Architektur austauscht oder in Echtzeit umswitched. Man könnte auch den einen Kern so und den anderen so laufen lassen. Passend zur Applikation. Die Art, wie eine CPU mit dem Cache und dem Speicher interargiert, wäre ein solches Ziel von Optimierung. Da ist viel rauszuholen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.