Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsIntel Xeon Phi: Die ersten Knights Landing gehen, Knights Mill kommt
Intel hat in dieser Woche nicht nur bereits die ersten Knights-Landing-Produkte aus dem letzten Jahr in den Ruhestand geschickt, sondern auch einige Details zum Refresh Knights Mill preisgegeben. Der Zwischenschritt bei den Xeon Phi zum echten Nachfolger Knights Hill ist für Deep-Learning-Anwendungen gedacht.
Und wieder ein erbitterter Zweikampf: Intel gegen NVIDIA in der Arena der TOP500-Supercomputer.
In the Top 10, the No. 2 system, Tianhe-2, the No. 6 Cori, and the No. 7 Oakforest-PACS uses Intel Xeon Phi processors to speed up their computational rate. The No. 3 system Piz Daint and the No. 4 system Titan are using NVIDIA GPUs to accelerate computation.
Naja man könnte das recht easy umsetzen, aber derzeit würde das in der Regel eher Nachteile als Vorteile bringen.
Diverse Anwendungen kommen mit zu vielen Kernen nicht zurecht und der Windows CPU Scheduler ist ebenfalls völlig überfordert.
Bei optimierten Systemen, Servern mit Linux bzw. Generell Opensource Software ist das alles kein Problem (sparc und Power CPUs können so was seit Jahren), aber unter Windows hat man damit nix als Ärger.
Also nein, so was wird es für Desktop CPUs wohl erst Mal nicht geben.
Von SMT profitiert man ja indem die Rechnenwerke möglichst gut ausgelastet werden. Die anderen Threads springen ja immer dann ein um die Rechenwerke auszulasten, wenn ein Thread auf I/O wartet, was auch davon abhängt, wie gut die Vorhersagen wie die Sprungvorhersagen und das Datenprefetching funktionieren. Gerade letzere kann natürlich auch keine Wunder vollbringen, wenn die Algorithmen mehr Daten anfordern als das RAM überhaupt liefern kann, ist es unmöglich diese Daten immer schon vorab in den Cache geladen zu haben und daher hängt es eben auch sehr von der Anwendung ab wie viel SMT bringt.
Schade eigentlich, dass die Co-Prozessoren flöten gehen. Immerhin beraubt man sich so die Möglichkeit, monolitische Systeme mit 2x Xeon SP als Basis und 3-4 Xeon Phi Co-Prozessoren in ein System zu bauen.
Ganz Verschwinden werden sie ja wohl nicht, nur sind sie dann wohl nur für besondere Kunden erhältlich, vermutlich um den Support Aufwand zu vermindern.
Je nach Anwendung kann es durchaus sinnvoll sein.
Ich durfte in meine Master Arbeit mit einem Xein Phi PCI Coprozessor spielen und kam aufgrund der hohen Cache Zurgiffe auf keine nennenswerte Steuerung der Leistung bei Verwendung von 4 Threads auf einem Kern im Vergleich zu 1 Thread pro Kern.
Gerade bei Spielen sind viele Kerne oft nicht von Vorteil, weil die wenigsten Spiele diese überhaupt nutzen, aber über Spiele in einem Thread zum Xeon Phi zu schreiben könnte deplatzierter nicht sein.
Was HT bringt, hängt sehr vom Programm ab. Der Nachteil ist, dass zwei Threads sich die Caches des Kerns teilen müssen und daher die Gefahr höher ist, dass ein Thread seine Daten dort nicht findet. Außerdem kann es passieren, dass der Task Scheduler ausgerechnet zwei SW Thread auf die beiden Threads des gleichen Kerns schiebt, die eben gerade nicht auf I/O warten müssten und auf unterschiedlichen Kernen wirklich parallel abgearbeitet werden könnten. Der Vorteil ist, dass wenn ein Thread eben auf I/O Zugriffe warten muss, der andere die Recheneinheiten des Kerns nutzen kann.
Gerade bei Spielen sind viele Kerne oft nicht von Vorteil, weil die wenigsten Spiele diese überhaupt nutzen, aber über Spiele in einem Thread zum Xeon Phi zu schreiben könnte deplatzierter nicht sein.
1) ich habe nicht damit angefangen, 2) sind echte Kerne immer besser als simulierte Kerne was in Tests schon des öfteren bewiesen wurde.
Danke fürs akzeptieren
*scnr*
