Die Nachricht hier legt tatsächlich viel zu viel Gewicht auf den Vergleich zu GPUs.
Die Xeon Phi, auch wenn sie ursprünglich mal aus einem fehlgeschlagenen GPU-Ansatz kamen, waren von Anfang an etwas Anderes. Auch die Varianten in PCIe-Form waren effektiv eigene Systeme, die nur über PCIe an einem anderen System hingen. Das spricht auch ganz andere Programmiermodelle an als die übliche GPU-Beschleunigung.
Hat dann aber auch gewisse Implikationen, die gerade im HPC-Bereich auch nicht zu vernachlässigen sind.
Die Teile haben dann quasi wie eigene Compute-Knoten funktioniert, haben sich aber ggf. zu mehreren das PCIe-System und meist auch die Netzwerk-Hardware eines Host-Systems geteilt, das man eigentlich gar nicht wirklich brauchte. Außerdem ist auf Steckkarten der verfügbare Speicher stets begrenzt. Für Speicherzugriffe auf den größeren RAM des Hosts zuzugreifen ist aber lahm, sodass man alles, was nicht in den lokalen Speicher passt eigentlich nicht rechnen will und sich dann für ordentliche Performance genauer um seine Daten kümmern muss.
Was liegt also nahe, wenn man eine "Beschleunigerkarte" hat, die eigentlich eigenständig ist, aber einige Nachteile mitbringt, die u.A. auch die Programmierung erschweren?
Man macht das Ding richtig eigenständig. Ein Knoten, der vorher vielleicht eine quasi-nutzlose CPU und 2 Phi beherbergt hat, wird dann halt zu zwei Knoten. Man hat dann natürlich Mainboards und Netzwerk-Hardware doppelt und RAM unter Umständen danach auch mehr als vorher, aber man spart sich die quasi ungenutzte CPU und hat dann auch eine viel homogenere Umgebung für die Programmierung. Selbst wenn man die dann mit normalen CPU vernetzt, dann haben die unterschiedlichen Knoten vielleicht andere Performance-Charakteristika, aber aber den ganzen Mist wer wo wie angebunden ist und wie viel Speicher er zur Verfügung hat etc. braucht man nicht mehr zu berücksichtigen.
Dann ist man statt bei Beschleunigerkarten bei klassischen Knoten mit anderer Architektur. Die Architektur war geeignet für viel Performance bei stark parallel Workloads. War für diese Tasks was Performance/Watt angeht nicht ganz so stark wie GPUs, aber deutlich mehr als normale CPUs und lässt sich aber programmieren wie eine CPU. Außerdem halt ohne das zusätzliche Host-System, das die GPUs definitiv brauchen, welches für GPUs auch durchaus benötigt und genutzt wird, aber idR auch da nicht zur Compute-Leistung dazuzählt. Vergleichsweise also auch quasi tote Watt, die man bei den GPUs dazuzählen muss.
So ganz nutzlos und fail, wie manch einer hier sagt, ist das Ganze nicht. Die Dinger stecken ja auch in den Top 9 + 10 Systemen der aktuellen Top500 drin.
Hat aber auch hier natürlich Nachteile. Z.B. ist ein einzelner Kern teilweise so langsam, dass Netzwerk-Kommunikation, für die sonst ein Thread/Kern reicht, da eben nicht reicht. Da kann dann teilweise ein Kern das Netzwerk nicht saturieren und für quasi einen "Task" mehrere Kommunikationsthreads zu benutzen ist auch nicht trivial und hat oft leider auch Nebenwirkungen.
Der Grund warum die Nachfolger sich jetzt in eine andere Richtung entwickeln, bzw eingestellt werden, liegt woanders.
@Simon liegt da schon richtig. Bei der alten MIC-Architektur hat man so viele schwache Kerne auf ein Die gefeuert, wie man es gerade hinbekommen hat. Mit EMIB ist man jetzt nichtmehr auf ein Die limitiert. Sprich man baut einfach CPUs mit deutlich mehr starken Kernen zusammen. Das passiert bereits mit Cascade-Lake.
Solche CPUs sollen angeblich noch diesen Herbst in ersten Systemen verbaut werden.
Daher gehe ich nicht davon aus, dass mit dem Nachfolger EMIB-CPUs gemeint sind. Vielleicht sind ja dann damit doch tatsächlich GPUs gemeint.
