News Intel Xeon Gold 6138P: Erster Server-Prozessor mit integriertem FPGA gestartet
ghecko
Digital Caveman
- Registriert
- Juli 2008
- Beiträge
- 26.775
Die Einsatzszenarien in Servern für FPGAs sind nahezu unbegrenzt zahlreich. Allem voran Machine Learning, welches mehr und mehr an Bedeutung gewinnt. Ein FPGA ist die Ideale Architektur für einen Prozessor, der sich durch seine Aufgaben selbst optimiert und verändert.
Und das sind nur die Server, im HPC-Bereich werden solche Prozessoren ebenfalls ihre Anwender finden.
Die Frage ist nun, wie geht AMD damit um? Xilinx kaufen?
Und das sind nur die Server, im HPC-Bereich werden solche Prozessoren ebenfalls ihre Anwender finden.
Die Frage ist nun, wie geht AMD damit um? Xilinx kaufen?
yurij
Lt. Commander
- Registriert
- Jan. 2008
- Beiträge
- 1.055
Atom C3xxx mit 4 bis 8 Cores, PCIe 3.0, mit 10GE PHY im SoC und mid-range FPGA, alles so um 20-25W TDP wäre der feuchte Traum am oberen Ende im embedd Bereich. Es gibt zwar ein Paar ARM SoC/FPGA Kombis, aber die sind alle FPGA zentrisch, CPU ist nur Beigabe. Oft brauchen wir aber performante Mehrkern-CPU und FPGA nur für spezielle Teilaufgaben.
Dieses Intel hier ist mit über 100W TDP natürlich eine ganz andere Liga.
Dieses Intel hier ist mit über 100W TDP natürlich eine ganz andere Liga.
Zuletzt bearbeitet:
Der Artikel oder die eingebundene Anandtech/Intel Bildchen machen irgendwie nicht so ganz deutlich was jetzt der Vorteil der Integration ins Prozessorgehäuse ist. Die Anbindung von CPU und FPGA ist so dünn (1xPCIe und 1xUPI und asncheinend ein paar I/Os..) das man dafür nicht mal EMIB braucht - alle diese Interfaces landen aber üblicherweise schon auf dem Mainboard - sprich man hätte die Verdrahtung genauso auf dem Mainboard machen können.
Oder liegt der Vorteil eigentlich in der standardisierten Struktur sprich Anbindung des (definierten) FPGA inkl. HSSI - (an dem z.B. viele Echtzeit 10/25/40 GbE, implementiert im FPGA, angeflanscht werden können) - und der Möglichkeit für diese Struktur spezialisierte HSSI I/O Adapter und einen Markt für Drittanbietercode(FPGA+CPU) aufzumachen ?
Oder liegt der Vorteil eigentlich in der standardisierten Struktur sprich Anbindung des (definierten) FPGA inkl. HSSI - (an dem z.B. viele Echtzeit 10/25/40 GbE, implementiert im FPGA, angeflanscht werden können) - und der Möglichkeit für diese Struktur spezialisierte HSSI I/O Adapter und einen Markt für Drittanbietercode(FPGA+CPU) aufzumachen ?
Zuletzt bearbeitet:
Hill Ridge
Banned
- Registriert
- Mai 2018
- Beiträge
- 1.142
AMD soll einen eigenen FPGA entwickeln.ghecko schrieb:
Ob daraus was wurde oder ob es überhaupt stimmt weis ich nicht, man hört darüber nichts mehr.
AMD müßte Xilinx aber nicht gleich kaufen, wenn die Xeons mit FPGA sich verbreiten, wird Xilinx sicher gerne FPGAs an AMD liefern.
nebulus
Banned
- Registriert
- Mai 2015
- Beiträge
- 2.012
new Account() schrieb:
Danke für die interessanten Links...
Ich komme mir auf jeden Fall bestätigt vor, das die fpgas nur für ganz spezielle Sonderfälle einen gewissen Vorteil bieten. Das on-the-fly neu rendern eines Bildes in Hardware ist ein gutes Beispiel das auf einem Server Vorteile bringt. Aber ich kann mir nicht vorstellen, das diese paar spezielaufgaben den Durchbruch des fpga bedeuten würde. Denn der fpga ist hoch komplex und sehr kompliziert zu programmieren. Es gibt keine Möglichkeit einen z.B. jpeg algorithmus von c/c++ nach vhdl/hdl zu konvertieren. Fpgas werden in einer Hadrwarenahen Sprache programmiert. Es bedarf eine immer wierder kompletten neuen Implementierung...
Wie komplex Hardwarenahe fpgas sind, kann man daran sehen, wie lange es dauert z.B. mining Software auf Fpgas zu implementieren. Für Monero soll sowas kommen, für Bitcoin gab es sowas, usw... Allerdings hat sich dann raus gestellt, das Grafikkarten mit ihren jetzt bald 10.000 Shadern sehr viel Leistungsfähiger sind, als FPGAs.
Und das glaube ich auch, in Zukunft werden 10.000 Shader die Parallell ein Problem lösen können und zudem einfach in C Programmiert werden, sehr viel mehr Leisten, als ein FPGA in einer CPU.
Da Intel keine GPUs bauen kann und keine 10.000 Shaderkerne in die CPU verfrachten kann, kommt jetzt eben der FPGA. Ein absolutes Niechenprodukt, unflexible und sehr teuer. In Zukunft werden eindeutig GPUs die in Cuda oder Shaderlanguage programmiert sind, in die Server einzug halten, aber nicht die FPGAs.
Ergänzung ()
Laut deren ihrer Beschreibung haben die eine properitäre LAN Karte gebaut. Die zu nichts kompatible ist... Ich sehe schon die Admins fluchen, wenn der ESX Server ein Update bekommt und diese Hardware nicht mehr supportet wird...xexex schrieb:
Zuletzt bearbeitet:
Ich möchte ein Paar Sachen zum FPGA sagen. Seit 15 Jahren beschäftige ich mich damit. Was jetzt mit intel & FPGA, Cloud & Co abgeht, weiß ich quasi aus eigener Erfahrung.
Ein FPGA kann beliebig oft konfiguriert werden. Die Zeiten sind so bei 100-500 ms. Das heißt, dass man beliebige Konfiguration zur Laufzeit nachladen kann, je nach der Aufgabe. Wenn ich z.B. einen Ethernet Switch reingeladen habe, muss die CPU dann nichts mehr machen. Wenn ich mit dem Switchen der Packete fertig bin, dann kann ich das FPGA für Machine-Learning umprogrammieren und so weiter.
Allerdings wird es so gut wie nie gemacht, weil unpraktikabel und man stellt lieber 2 Server für 2 Aufgaben hin, als auf einem ständig umzuprogrammieren.
FPGA müssen nicht nur mit Verilog/VHDL programmiert werden. Man kann auch OpenCL nehmen oder eben C++ oder andere Sprachen. Die Compiler machen daraus dann die Konfigurationsdatei (Bit-File). Ein Kompiler-Durchlauf dauert von Minuten bis mehreren Stunden. Ich kann mir vorstellen, dass später vorgefertigten Bit-Files schon verfügbar sind und angeboten werden (IP-Cores). Man lädt diese rein und kann sofort los legen.
Intel versucht jetzt eingenes Framework zu pushen:
https://www.altera.com/solutions/acceleration-hub/acceleration-stack.html
Die ganze Sache sieht sehr interessant aus. Zur Zeit ist es aber schwierig Leute (Community) dafür zu gewinnen, weil die Initialkosten sehr hoch sind. Sowohl für FPGAs als auch für die Tools zum syntetisieren.
Ich habe so ein Arria10 Board auf dem Tisch -- Kostenpunkt 5000$ ohne Software. Man kann sich also vorstellen, dass kaum einer sich das zum Ausprobieren leisten kann. Aber mit der Zeit, hoffe ich, werden kleinere CPUs mit kleineren FPGAs rauskommen und im Consumer-Markt eintreffen (vielleicht in 2-5 Jahren).
Deshalb sind auch gerade die Großen (Amazon AWS, Microsoft, Google, Dell, Fujitsu...), die jetzt davon profitieren. Im industriellen Umfeld sind aber die FPGAs schon seit den 80ern nicht mehr wegzudenken.
Ein FPGA kann beliebig oft konfiguriert werden. Die Zeiten sind so bei 100-500 ms. Das heißt, dass man beliebige Konfiguration zur Laufzeit nachladen kann, je nach der Aufgabe. Wenn ich z.B. einen Ethernet Switch reingeladen habe, muss die CPU dann nichts mehr machen. Wenn ich mit dem Switchen der Packete fertig bin, dann kann ich das FPGA für Machine-Learning umprogrammieren und so weiter.
Allerdings wird es so gut wie nie gemacht, weil unpraktikabel und man stellt lieber 2 Server für 2 Aufgaben hin, als auf einem ständig umzuprogrammieren.
FPGA müssen nicht nur mit Verilog/VHDL programmiert werden. Man kann auch OpenCL nehmen oder eben C++ oder andere Sprachen. Die Compiler machen daraus dann die Konfigurationsdatei (Bit-File). Ein Kompiler-Durchlauf dauert von Minuten bis mehreren Stunden. Ich kann mir vorstellen, dass später vorgefertigten Bit-Files schon verfügbar sind und angeboten werden (IP-Cores). Man lädt diese rein und kann sofort los legen.
Intel versucht jetzt eingenes Framework zu pushen:
https://www.altera.com/solutions/acceleration-hub/acceleration-stack.html
Die ganze Sache sieht sehr interessant aus. Zur Zeit ist es aber schwierig Leute (Community) dafür zu gewinnen, weil die Initialkosten sehr hoch sind. Sowohl für FPGAs als auch für die Tools zum syntetisieren.
Ich habe so ein Arria10 Board auf dem Tisch -- Kostenpunkt 5000$ ohne Software. Man kann sich also vorstellen, dass kaum einer sich das zum Ausprobieren leisten kann. Aber mit der Zeit, hoffe ich, werden kleinere CPUs mit kleineren FPGAs rauskommen und im Consumer-Markt eintreffen (vielleicht in 2-5 Jahren).
Deshalb sind auch gerade die Großen (Amazon AWS, Microsoft, Google, Dell, Fujitsu...), die jetzt davon profitieren. Im industriellen Umfeld sind aber die FPGAs schon seit den 80ern nicht mehr wegzudenken.
nebulus schrieb:
Das ist nichts für ESX Server und kleine SMB Buden. Das sind Speziallösungen die für einen entsprechenden Anwendungsfall angepasst werden. Im vorliegenden Fall geht es um Datenreplikation zwischen Rechenzentren mit 40GBE und interessiert vielleicht 1% der Unternehmen, die jedoch das Geld, die Ressourcen und den Bedarf für solche Lösungen haben. Das gleiche gilt für die weiter genannten Anwendungsfälle bezüglich Big Data Verarbeitung. Sowas kaufen dann Unternehmen wie Microsoft, Amazon oder Google für ihre Rechenzentren und passen die FPGAs auch entsprechend an.
Es ist eine Spezial-CPU für Spezialanwendungen, was soll daran floppen? Da kannst du genauso behaupten ein Xeon Platinum 8180M wäre ein Flop, weil doch niemand 10k für eine CPU ausgibt, 1,5TB Speicher bezahlen kann oder einen Server mit 8 Sockeln einsetzt.
@kest
wenn du dicht dran bist - kannst du uns mal ein Update verpassen was man an Software für die Entwicklung braucht - z.B. reicht die Altera/Intel hauseigene Software oder braucht man zwingend kommerzielle Synthesizer ? Was kostet der Spaß minimal ?
Und ne Anmerkung zu Anwendungen: vor etlichen Jahren als ich Projekte mit u.a. FPGAs betreut habe war die Hauptverwendung im Interfacebereich - zur Implementation kompletter Audio/Video Interfaces, die es in fast unendlichen Variationen in professinellen Gerätschaften (Broadcast, Studio) gab. Bis hin zu den zugehörigen Protokollen die die Bits dann mundgerecht für die CPU/DSP aufbereiteten. Und natürlich Glue Logic - um die Platinen von kleinteiliger Logik zu befreien und wie mit den multiplen Interfaces in einem FPGA zu kompakten und später per Update wartbaren Geräten zu kommen. Auch gab's grundsätzlich ne Menge Sonderwünsche bei jedem einzelnen Kunden .. so konnte man eine Standardplatine entwickeln die dann gut war für mehrere Kunden.
Natürlich ist die Entwicklung von FPGAs etwas langatmiger als Software - der Ändern-Compilieren-Testen Zyklus dauert auch oft länger. Ein gewaltiger Vorteil ist aber die Echtzeitfähigkeit - bei typ. CPU basierten Systemen kann man sich auf kurze Reaktionszeiten nicht verlassen, selbst bei vergleichsweise langen wie Millisekunden ist das oft ein Problem - außer bei Threadprioritäten bei denen man vom OS-Oberguru ne gedachte Verwarnung erhält weil man sich erdreistet eigenen Code laufen zu lassen .., mit einem FPGA ist das keinerlei Problem und geht bis herunter in den nanosec Bereich. Und Kunden im professionellen A/V Bereich sehen es gar nicht gern wenn die erzeugten Bilder/Töne gelegentlich mal Ruckler oder Spratzer haben .. Sprich alles was Echtzeit braucht packt man ins FPGA und alles was komplexe Algorithmen braucht packt man in die CPU Software. Außer vielleicht eng umrissene Rechnereien z.B. mit ungewöhnlicher Arithmetik oder Bitgefummel bei dem der CPU Befehlssatz irgendwas vermissen läßt. Aber angesichts der angesprochenen 10..GbE Schnittstellen seh ich doch eher das Anbinden externer Hardware an den Rechner sprich die I/O Anwendungen - jedenfalls stärker als die des Rechenbeschleunigers. Aber man soll niemals nie sagen - die Anbindung an die System CPU mit ca 150Gbps (UPI) oder 100Gbps (PCIe3x16) ist auch nicht so übel. Aber auch nicht wirklich toll - im Vergleich zum CPU Hauptspeicher (6xDDRx - TBit/s je Proz.) oder gar zum GPU Videospeicher (TByte/s) ist das ein superenger Flaschenhals. Ein übliches Problem bei Software ist auch das man bei Vorliegen mehrerer I/O Takte eigentlich exakte Beziehungen zwischen diesen Takten herstellen muß - aber in der CPU bestenfalls ungenau das Ankommen eines Datenworts oder ähnlich grob ausmessen kann, mal davon abgesehen das Zeitmessung in der CPU bei MultiCPU Sytemen immer noch ein Problem darstellt gibt's .. - im FPGA hat man solche Probleme nicht, da kann man locker mit zig Takten jonglieren, bzw. die der CPU fehlende Timestamping Hardware eben an die Seite stellen. (Beispiel: asynchrone Audio oder Video Takte relative zueinander timestampen - zum samplegenauen Mischen in Software und anschließender Ausgabe mit definierter Latenz).
Du weißt aber schon das wir noch nicht bei den 10000 compute units a 32 bit in einer GPU sondern eher bei unter 5000 sind und das ein einzelner Skylake mit seinen 28 CPUs auch umgerechnet an die 1000 compute units a 32 bit in seinen AVX512 Einheiten enthält ? (28*512/32*2). Sprich 4 von diesen CPUs, wie es durch die üblicherweise 3 UPI Links direkt unterstützt wird, im Verbund hängen hinter den aktuellen GPUs nicht wirklich mehr soweit zurück .. auch nicht im Systempreis .. da hat Intel schon kräftig dran gearbeitet. Hat schon seinen Grund warum die inzwischen XEON-Phi haben fallen lassen ..
wenn du dicht dran bist - kannst du uns mal ein Update verpassen was man an Software für die Entwicklung braucht - z.B. reicht die Altera/Intel hauseigene Software oder braucht man zwingend kommerzielle Synthesizer ? Was kostet der Spaß minimal ?
Und ne Anmerkung zu Anwendungen: vor etlichen Jahren als ich Projekte mit u.a. FPGAs betreut habe war die Hauptverwendung im Interfacebereich - zur Implementation kompletter Audio/Video Interfaces, die es in fast unendlichen Variationen in professinellen Gerätschaften (Broadcast, Studio) gab. Bis hin zu den zugehörigen Protokollen die die Bits dann mundgerecht für die CPU/DSP aufbereiteten. Und natürlich Glue Logic - um die Platinen von kleinteiliger Logik zu befreien und wie mit den multiplen Interfaces in einem FPGA zu kompakten und später per Update wartbaren Geräten zu kommen. Auch gab's grundsätzlich ne Menge Sonderwünsche bei jedem einzelnen Kunden .. so konnte man eine Standardplatine entwickeln die dann gut war für mehrere Kunden.
Natürlich ist die Entwicklung von FPGAs etwas langatmiger als Software - der Ändern-Compilieren-Testen Zyklus dauert auch oft länger. Ein gewaltiger Vorteil ist aber die Echtzeitfähigkeit - bei typ. CPU basierten Systemen kann man sich auf kurze Reaktionszeiten nicht verlassen, selbst bei vergleichsweise langen wie Millisekunden ist das oft ein Problem - außer bei Threadprioritäten bei denen man vom OS-Oberguru ne gedachte Verwarnung erhält weil man sich erdreistet eigenen Code laufen zu lassen .., mit einem FPGA ist das keinerlei Problem und geht bis herunter in den nanosec Bereich. Und Kunden im professionellen A/V Bereich sehen es gar nicht gern wenn die erzeugten Bilder/Töne gelegentlich mal Ruckler oder Spratzer haben .. Sprich alles was Echtzeit braucht packt man ins FPGA und alles was komplexe Algorithmen braucht packt man in die CPU Software. Außer vielleicht eng umrissene Rechnereien z.B. mit ungewöhnlicher Arithmetik oder Bitgefummel bei dem der CPU Befehlssatz irgendwas vermissen läßt. Aber angesichts der angesprochenen 10..GbE Schnittstellen seh ich doch eher das Anbinden externer Hardware an den Rechner sprich die I/O Anwendungen - jedenfalls stärker als die des Rechenbeschleunigers. Aber man soll niemals nie sagen - die Anbindung an die System CPU mit ca 150Gbps (UPI) oder 100Gbps (PCIe3x16) ist auch nicht so übel. Aber auch nicht wirklich toll - im Vergleich zum CPU Hauptspeicher (6xDDRx - TBit/s je Proz.) oder gar zum GPU Videospeicher (TByte/s) ist das ein superenger Flaschenhals. Ein übliches Problem bei Software ist auch das man bei Vorliegen mehrerer I/O Takte eigentlich exakte Beziehungen zwischen diesen Takten herstellen muß - aber in der CPU bestenfalls ungenau das Ankommen eines Datenworts oder ähnlich grob ausmessen kann, mal davon abgesehen das Zeitmessung in der CPU bei MultiCPU Sytemen immer noch ein Problem darstellt gibt's .. - im FPGA hat man solche Probleme nicht, da kann man locker mit zig Takten jonglieren, bzw. die der CPU fehlende Timestamping Hardware eben an die Seite stellen. (Beispiel: asynchrone Audio oder Video Takte relative zueinander timestampen - zum samplegenauen Mischen in Software und anschließender Ausgabe mit definierter Latenz).
Ergänzung ()
nebulus schrieb:
Du weißt aber schon das wir noch nicht bei den 10000 compute units a 32 bit in einer GPU sondern eher bei unter 5000 sind und das ein einzelner Skylake mit seinen 28 CPUs auch umgerechnet an die 1000 compute units a 32 bit in seinen AVX512 Einheiten enthält ? (28*512/32*2). Sprich 4 von diesen CPUs, wie es durch die üblicherweise 3 UPI Links direkt unterstützt wird, im Verbund hängen hinter den aktuellen GPUs nicht wirklich mehr soweit zurück .. auch nicht im Systempreis .. da hat Intel schon kräftig dran gearbeitet. Hat schon seinen Grund warum die inzwischen XEON-Phi haben fallen lassen ..
Ergänzung ()
Zuletzt bearbeitet:
nebulus
Banned
- Registriert
- Mai 2015
- Beiträge
- 2.012
senf.dazu schrieb:
Ich glaube Du würfelst da ganz schön was durcheinander...
Ein i9 Skylake hat 2 AVX-512 Einheiten, den sich alle CPU-Cores teilen müssen. Wobei die Zahl 512 nicht irgend welche Cores angibt, sondern die Bandbreite in Bit für die AVX Befehle. AVX Befehle sind neue Assemblerbefehle die besonders gut Langzahlarethemtik können. Abenfalls gibt es spezielle Befehle für Vectorenrechnung.
AVX2 / AVX-512 Programmierung ist etwas ganz anderes als eine Shaderlanguage.
AVX Programme bringen in der Realizät keinen Zugewinn an Performance. Der Performancegewinn CPU zu AVX beträgt c.a. 10% bei einer Optimierung durch den Compiler.
Zuletzt bearbeitet:
nebulus schrieb:
Ja MME,SSE,AVX,AVX2,AVX512 sind Instruktionserweiterungen, die die Ausführung von SIMD (single instruction multiple data) für x86 cores ermöglichen.
Bei AVX512 bedeuted das inzwischen das mit jedem AVX512er Befehl 512/32=16 parallele 32 bit Operationen ausgeführt werden wobei die Operanden in 512 bit breiten Registern liegen. Deswegen sind z.B. die L1/L2 Caches und die internen Datenwege in jedem Core(!) auch 512 bit breit, so daß auch in jedem Zyklus ein neuer "Vector"operand an ALU&Registersatz geliefert (bzw. geschrieben) werden kann.
Ab AVX ist der Vektorbefehlssatz auch komplett hinsichtlich arithmetik&logik - sprich man kann die 16 Recheneinheiten in einer einzelnen AVX512 unit auch als 16 compute elements verstehen. Das ist soweit nicht anders als bei GPUs - bei einer NVidia beschreibt der Basisbefehlsatz 32fach SIMD Operationen - sprich jede Assemblyinstruktion (PTX) wird logisch auf 32er Vektoren (von 32 bit Zahlen) ausgeführt.
AVX512 kann aber auch statt z.B. 16 float multiply auf 16 Operanden gleichzeitig genauso 8 double mulitiplies auf 8 Operanden (8*64=512) ausführen - die Sicht auf 32 bit compute elements ist also nur ein Ausschnitt auf den AVX512 Befehlssatz. Oder auch viel 16 bit oder 8 bit integer Operationen.
Und es ist nicht so das AVX Befehle drauf beschränkt sind Langzahlarithmetik besonders gut zu können. Sondern sie bilden einen kompletten Arithmetisch Logischen Befehlssatz ab um paralleles Rechnen zu ermöglichen - da ja die Frequenz der CPUs seit ca. 2005 über die 4 GHz nicht mehr weiter gesteigert werden konnte. Parallelisierung ist für Intel seither, genauso wie für die GPU Hersteller, der Weg um die Rechenleistung weiter entsprechend des Moore's Law zu steigern - also seit 2005 um viele Faktoren von 2 - da gibt's übrigens von Intel Videos/Präsentation die genau das thematisieren.
Also rechnen wir nochmal - jeder der 28 cores hat 2 AVX512 Einheiten - jede AVX512 Einheit entspricht 16 32 bit ALUs die integer und float Befehle können - also 28 * 512/32 * 2 = 896 32 bit ALUs. Und jede dieser ALUs kann einen float FMA Befehl (fused multiply add) mithin 2 float Operationen je Zyklus. Die Taktrate bei Vollast AVX512 ist reduziert auf irgendwas zwischen 1 und 2 GHz. Das ist aber für GPUs auch typisch - die meisten GPUs lagen bis vor kurzem unter 1 Ghz Taktfrequenz - die Spiztenmodelle liegen nun auch etwas drüber. Der Grund für diese Taktreduktion ist wohl ein energieeffizientes Design - sprich wie krieg ich die maximale float Performance per Watt Verlustleistung. Also - auch ein schlichter Skylake liegt inzwischen deutlich jenseits des TFlop/s. Selbst bei double. (Sonst würden die heute bei 28*4 GFlop/s peak liegen ..)
Und - Nvidia GPUs werden mit Cuda programmiert (meist). AMD und Intel (aber auch NVidia) dann eher mit open-cl. Wobei bei Intel sowohl die embedded GPUs (lohnt nicht, auch kein double) aber auch AVX. Darüber hinaus könne die C-Compiler inzwischen auch Parallelisierung - mit openMP gibt's für den C-Compiler eine Standarderweiterung für parallele Programmierung. Selbst NVidia hat (oder hatte) für seinen Cuda Compiler mal eine Option auch x86 Code zu generieren.
Zuletzt bearbeitet:
nebulus
Banned
- Registriert
- Mai 2015
- Beiträge
- 2.012
senf.dazu schrieb:
Und genau das stimmt nicht, alle 28 Cores müssen sich 2 AVX512 Einheiten teilen.
https://segmentnext.com/2018/02/16/intel-skylake-x-cpus-2-avx-512-units/
senf.dazu schrieb:
Die Synthese-Tools der Hersteller kosten ca. 3-5kEuro pro Jahr (mit Support). Wenn man kleinere FPGAs nimmt, dann sind die Tools kostenlos. Sollte man abgefahrene IP-Cores verwenden wollen, dann ist man schnell ein Paar zig Tausend Euro weg (als Beispiel 10G-Eth Core kostet ca. 20kEuro).
Aber! Möchte man z.B. die FPGAs von Amazon verwenden: AWS F1 Instanzen, dann bezahlt man nur stundenweise für EC2-Instanz, worin die komplette Xilinx Entwicklungsumgebung installiert ist (allerdings nur für einen Chip, genau den, der bei der Amazon-Instanz verwendet wird).
Langsam passiert da was. Und Intel/Altera möchten da mitmischen. Was Intel wohl vor hat ist, dass später nur ein Kompiler sowohl für CPU als auch FPGA den code rausspuckt. Das Programm wird abgespielt, wenn ein FPGA in der CPU (so wie dieser Xeon) vorhanden ist, wird dieses mit dem Bit-File geladen und so wird die Ausführung beschleunigt. Ist das FPGA nicht vorhanden, wird das in der CPU emuliert.
Da hat man dann die Wahl: eine CPU für 1000,- die 12 Stunden an einer Aufgabe rechnet oder für 5000,-, die in 10 Minuten fertig ist.
Man kann sich das so vorstellen, dass Performance/Power bei einem Arria10 FPGA etwa doppelt so gut ist, wie bei einer Titan oder ähnlichen Grafikkarten. Bei Stratix 10 wahrscheinlich sogar 5-10 Mal besser. (alles aus dem Bauch heraus, ich lese viele Papers, deshalb habe ich etwa die Übersicht). Ein FPGA braucht 5-15 Watt, eine GPU 100-250 Watt. Do the math.
-- Nachtrag
Ach so. Die Frequenzen bei so einem FPGA liegen wohl etwa bei 500-800 MHz. Ist nicht viel, aber man bedenkt, dass da drinne 3000 Multiplizierer drin sind, dann ist es schon eine Ganze Menge. Dazu noch ein Paar MByte an Speicher, der 1 Takt Latenz hat und beliebig breit konfiguriert werden kann :-o
Zuletzt bearbeitet:
kest schrieb:
nebulus schrieb:
Hmm was seh ich ? Ein (1) Skylake Core + 1 AVX512 unit.
Und so sieht dann das ganze Chipfoto für einen 8180 - 28 core aus: ..
https://www.heise.de/newsticker/mel...c-3765089.html?seite=all&hg=1&hgi=1&hgf=false
Für ein 4 Sockel System sind dort Linpack 5777 GFlops genannt.
Der Heise Artikel "erklärt" übrigens auch was es mit der "drangeklebten" einen AVX512 unit auf sich hat - im core werden da noch die zwei existierenden AVX2 units zu einer AVX512er zusammengeschaltet - mit der drangeklebten macht's dann 2x AVX512 ..
Oder die Intel Folien am Ende des Artikels. (Man beachte den Kasten unter Compute)
Zuletzt bearbeitet:
Hill Ridge
Banned
- Registriert
- Mai 2018
- Beiträge
- 1.142
Nein, das sieht man hier nicht.nebulus schrieb:
Auf dem Bild sieht man einen Kern.
