News Intel-Prozessor: 15-Kern-Broadwell-Xeon trifft Altera-FPGA auf einem MCP

Volker · 15. März 2016

Zum Open Compute Summit hat Intel weitere Details zur Hochzeit eines Xeon-Prozessors mit einem FPGA-Chip von Altera, die mittlerweile zu Intel gehören, auf einem gemeinsamen Multi-Chip-Package (MCP) dargelegt. Demnach basiert der verwendete Xeon-Prozessor auf der Broadwell-Architektur und wird wahrscheinlich 15 Kerne bieten.

Zur News: Intel-Prozessor: 15-Kern-Broadwell-Xeon trifft Altera-FPGA auf einem MCP

honky-tonk · 15. März 2016

Auf sowas warte ich schon eine ganze Weile. Die Sache steht und fällt natürlich mit der SW Unterstützung. Es bleibt spannend

Radde · 15. März 2016

Wofür steht denn FPGA? Anscheinend können die FPGA-Kerne "zur Beschleunigung diverser Szenarien inklusive komplexer Ver- und Entschlüsselung" genutzt werden. Aber wie werden sie angesprochen? Sind die Altera.Kerne etwas proprietäres, oder gibt es verschiedene Hersteller solcher Kerne wie bei ARM?

Ehrlich gesagt, habe ich die News nicht verstanden. Wenn man nicht sowieso schon in der Materie tief drin steckt kann man aus diesem Text nichts neues dazulernen. Schade.

v_ossi · 15. März 2016

Genau davor hat mich meine Mutter immer gewarnt... ne, anders herum, genau das hat unser Prof. immer kommen sehen.
Sehe es aber wie honky-tonk, wenn die Software das nicht unterstützt, nutzt das beste Design nichts.

TenDance · 15. März 2016

Radde schrieb:
Wofür steht denn FPGA? Anscheinend können die FPGA-Kerne "zur Beschleunigung diverser Szenarien inklusive komplexer Ver- und Entschlüsselung" genutzt werden. Aber wie werden sie angesprochen? Sind die Altera.Kerne etwas proprietäres, oder gibt es verschiedene Hersteller solcher Kerne wie bei ARM?

Ehrlich gesagt, habe ich die News nicht verstanden. Wenn man nicht sowieso schon in der Materie tief drin steckt kann man aus diesem Text nichts neues dazulernen. Schade.

https://de.wikipedia.org/wiki/Field_Programmable_Gate_Array

Nicht verwechseln mit dem alten Intel-Sockel https://de.wikipedia.org/wiki/Flip-Chip_Pin_Grid_Array

Im Prinzip bekommst Du dadurch die Rechenleistung eines Xeons mit den spezifischen Eigenschaften eines FPGAs. Im Gegensatz zu heutigen Lösungen ist der FPGA aber sehr schnell angebunden und könnte theoretisch auf herkömmlichen mainboards genutzt werden - wenn der Sockel passt und die Firmware.

In der Praxis kannst Du Dir damit einen Teil der Rechenleistung zurechtoptimieren. Verschiedene Programme laufen auf unterschiedlichen Strukturen verschieden schnell/gut. Eine CPU kann zwar alles, ist aber für das meiste nicht optimal. Sieht man ja an GPUs, deren viele kurzen, dafür extrem zahlreichen pipelines sind für einige Berechnungen deutlich besser geeignet.
Du kannst Dir so den Chip direkt auf das Problem hin optimieren.

pipip · 15. März 2016

Radde
"Field Programmable Gate Array"

Im Endeffekt ist es so, du hast eine Anwendung die du sehr effizient abarbeiten möchtest. Am besten und schnellsten ist dann eine Hardware-Lösung, die für deine Problemlösung Schritt für Schritt angepasst ist.

Sagen wir, du hast jetzt eine Funktion a+b*c. Ein dummer x86 rechnet a+b, speicher in c, hole datei aus Arbeisspeicher und speicher in a und multipliziere dann a mit c ect (im schlimmsten Fall, benötigt eine dumme x86 CPU mehrere Schritte um zum Ergebnis zu kommen).
Im Verglich kannst du dann einfach eine Schaltung bauen die A+B*C in einen Schritt durchläuft. Solche Einheiten werden in CPUs oft als SIMD (Single Instruction, Multiple Data) implementiert. Natürlich gibt es auch noch die anderen drei Varianten (MIMD, SIMS, MISD) usw.

Sagen wir, du hast eine Server-Farm, die jetzt ganz spezielle Berechnungen ausführen soll und das möglichst effizient. Dann kannst du mit den FPGA quasi deinen eigenen Fix-Function Chip bauen und deine Software anpassen.

Das ein FPGA Chip sehr flexibel sein soll, damit man alle Schaltungen bauen kann, sind solche FPGA wesentlich teurer als "fertige" SIMD Lösungen und fallen releativ groß aus. Im Prinzip kannst du aber alle Schaltung aus NAND Gatter aufbauen.

Sprich, solche FPGA + x86 Server Chips, werden wohl eher nur für spezielle Anwendungen gekauft. Bin also gespannt, wie sich das weiterentwickelt.

@News
Hatte lange geglaubt, dass FPGA sogar direkt in die CPU integriert wird, aber so ergibt das natürlich am meisten Sinn.

dicv81 · 15. März 2016

Ein FPGA (= Field Programmable Gate Array) ist ein integrierter Schaltkreis, in den eine logische Schaltung programmiert werden kann.
Anders als bei der Programmierung von Computern oder Steuerungen bezieht sich hier der Begriff Programm nur in zweiter Linie auf die Vorgabe zeitlicher Abläufe im Baustein, sondern vor allem auf die Definition von dessen Funktionsstruktur. Durch die Programmierung der Verschaltung der vorgegebenen Elemente wird die Funktionsweise einzelner Blöcke im FPGA und deren Verschaltung untereinander festgelegt.
FPGAs werden beispielsweise zur Echtzeit-Verarbeitung von einfachen bis komplexen Algorithmen genutzt, zur digitalen Signalverarbeitung im Rahmen von digitalen Filtern oder zur schnellen Fourier-Transformation. Aber auch Protokoll-Implementierungen wie Teile des Ethernet-MAC-Layers, die Kodierung von digitalen Videosignalen, die Verschlüsselung von Daten und Fehlerkorrekturverfahren sind Anwendungsgebiete.

strex · 15. März 2016

Das wird auch Zeit, wir führen damit das Packet Processing durch. Die PCIe Cards kann man sich dann sparen.

Das dürfte wohl erst der erste Schritt sein zur Integration von FPGAs in die CPU. Statt auf GPUs zu setzen, verwendet man für die Beschleunigung eine FPGA in der CPU bzw. MCP, das könnte die Zukunft sein. Damit könnte man sich von den fix functions eines ASICs verabschieden wo man nicht zu viel Leistung verliert aber völlig flexibel ist. Neuer Algorithmus für die Videobeschleunigung, kein Problem, wir laden einfach das neue Programm für den FPGA. Hardware-Beschleunigung für das Packet Processing, kein Problem Auslagerung auf die FPGA durch einfache Umprogrammierung.

honky-tonk schrieb:
Auf sowas warte ich schon eine ganze Weile. Die Sache steht und fällt natürlich mit der SW Unterstützung. Es bleibt spannend

In diesem Ausbau ist die Software eh schon da, da bestehende FPGAs verwendet werden die bereits die passenden Tools liefert. Die FPGAs stecken jetzt nur nicht mehr auf einem separaten Board. Später könnte on demand die passenden Algos auf die FPGA geladen, die gerade benötigt werden. Das könnte bye bye für die Beschleunigung von Software durch die GPU bedeuten.

Hopsekäse · 15. März 2016

pipip schrieb:
...
Sagen wir, du hast jetzt eine Funktion a+b*c. Ein dummer x86 rechnet a+b, speicher in c, hole datei aus Arbeisspeicher und speicher in a und multipliziere dann a mit c ect (im schlimmsten Fall, benötigt eine dumme x86 CPU mehrere Schritte um zum Ergebnis zu kommen).
...

Die Erklärung insgesamt ist gut, nur das Beispiel etwas ungeglücklich gewählt, weil ausgerechnet ein "fused multiply add" mittlerweile jede CPU auch ohne FPGA in einem Takt kann.

Luffy · 15. März 2016

JA GANZ TOLL noch mehr monopol!

pipip · 15. März 2016

Hopsekäse
Deshalb auch ein "dummer x86" ^^ Also da war nicht x86 als dumm gemeint, sondern ein sehr simples Modell basierend auf x86, quasi die Grundform. Beispiele muss man einfach "einfach" halten.
Hatte mir aber schon gedacht, dass das Misverstanden werden kann.

Radde · 15. März 2016

Vielen Dank an TenDance, pipip und dicv81. Habe ich heute doch etwas gelernt.

Hallo32 · 15. März 2016

@pipip

Schöne Erklärung. das einfache Beispiel ist für eine Einstiegserklärung iO.

AAS · 15. März 2016

Hoffentlich kommt das mal in den Consumer-Markt.
So würden sich ein Hardware-Upgrade für zukünftige Video-Codecs oder HDMI Protokolle erledigen.

Piktogramm · 15. März 2016

@AAS

Ein FPGA ist in der Regel weniger effizient / leistungsfähig als Lösungen direkt in Hardware. Da Mediacodecs möglichst effizient abgewickelt werden sollen wird das wohl eher weiterhin fix in Hardware gegossen werden. Zudem ist genauso zu erwarten, dass weiter entwickelte Codecs immer auch komplexere Logik brauchen, die erst auf zukünftigen ICs abgebildet werden kann.

strex · 15. März 2016

@Piktogramm

Effizienter durchaus, der FPGA braucht auch mehr Platz. Jedoch braucht man für Mediacodecs nicht zu viel Leistung. Der Platz für Hardware-Einheiten in einer GPU sind jetzt auch nicht allzu groß. Rechnet man davon 30 bis 40fach größere Strukturen aus, die nach Analysen den Unterschied zwischen ASIC vs. FPGA ausmachen, reichen dazu auch nicht die ganz großen. Es gibt für gängige FPGAs H.265 Encoder die flüssig und ohne Probleme arbeiten. Das ist kein Problem. Beispiele für 265 und FPGA gibt es bei google genug. Wir können hier mit größeren FPGAs auch 100G Wirespeed analysieren.

Da sollte ein FPGA mit der in dem Zeitrahmen der Nutzung erscheinende Codes locker wegstecken.

http://www.hhi.fraunhofer.de/depart...tions/hevc-4k-real-time-hardware-decoder.html

Einzig und alleine der Preis ist hier der größte Faktor.

Crass Spektakel · 15. März 2016

Ein FPGA kann durchaus allgemein programmiert werden, es gibt dafür mehrere Hardware description language die relativ normal daherkommen.

Ein paar Beispiele die ich gesehen habe: Sort-Algorithmus, eine gzip-Implementierung, einige MPEG4-Encoder-Eigenschaften, eine Implementierung eines GNU-Chess-Algorithmus, neuronale Netzer zur Sprach- und Bilderkennung. Im Allgemeinen war die daraus resultierende Lösung um ein vielfaches schneller und stromsparender als normale CPUs.

goldmomo · 15. März 2016

Naja, man muss die Sache auch in einem Softwarekontext sehen.
Klar kann man diverse Algorithmen in einem FPGA schneller (paralleler) erledigen, aber die Logik braucht Platz, ist um einige Faktoren langsamer getaktet und braucht dann auch meist eins oder mehre schnelle Interfaces/Caches etc. um bedient zu werden (dann auch wieder OS-Treiber, Sicherheitsmechanismen,… ).

Wenn man es direkt als eine Exec-Port in der CPU ansprechen könnte (laut dem Bild wohl nicht), braucht man wieder Compiler-anpassungen (Kompatibilität,…).

Auch die HDL-Synthese dauert recht lang (je nach Design/Größe/Timing auch Stunden) als wird nicht jeder Task-switch speziellen HDL-Code verarbeiten und dann den FPGA (oder Teile) neu konfigurieren.

Also wohl eher ein HDL-Design für eine längere Laufzeit, also eher für sehr spezielle Anwendung brauchbar (eigenes Device mit eigenen Treiber).

Ob so etwas für den Endkunden irgendwann von Bedeutung wird, ich glaube es nicht (in dieser Form). Vielleicht ist es auch nur ein erster Schuss und neuere Designs bieten dann einen direktere Verschmelzung von CPU/FPGA … Intel wird schon wissen

cirrussc · 15. März 2016

pipip schrieb:
Das ein FPGA Chip sehr flexibel sein soll, damit man alle Schaltungen bauen kann, sind solche FPGA wesentlich teurer als "fertige" SIMD Lösungen und fallen releativ groß aus. Im Prinzip kannst du aber alle Schaltung aus NAND Gatter aufbauen.

Man könnte auch sagen, ein FPGA ist der 3D Drucker des (digitalen) Chip Designs

Damit ist dann wirklich fast alles möglich. Von einfachen Grundschaltungen bis echten CPUs oder GPUs. Man könnte beispielsweise einen ARM Core daraus machen. Praktisch wird man stattdessen doch eher spezielle Algorithmen darin umsetzen.

Haldi · 16. März 2016

strex schrieb:
Es gibt für gängige FPGAs H.265 Encoder die flüssig und ohne Probleme arbeiten. Das ist kein Problem. L

Wie ist das eig. Bei FPGAs haben die eine fixe Anzahl Transistoren die man programmieren kann oder durch was unterscheiden die sich voneinander?
Wenn man nun H265 in 8k 120fps encoden wollte, wirds einfach langsamer als FullHD oder muss man dazu den kompletten FPGA neu beschreiben?

News Intel-Prozessor: 15-Kern-Broadwell-Xeon trifft Altera-FPGA auf einem MCP

Ost 1

Commodore

Commodore

Commodore

Commodore

Fleet Admiral

Cadet 4th Year

Lt. Commander

Lt. Commander

Lt. Junior Grade

Fleet Admiral

Commodore

Commodore

Lt. Commander

Admiral

Lt. Commander

Lieutenant

Ensign

Lieutenant

Admiral

Ähnliche Themen

Passend zum Thema