News Xeon Phi: Knights Landing als Prozessor zum IDF 2015 mit 60 Kernen

[Wadenbeisser]

Falsch, denn die Tesla K80 hat 2x GK210, lediglich eine DP Leistung von unter 2 TFLOP, zudem kostet sie lt. Geizhals deutlich mehr als die FirePro. (ca. 5000€ vs ca. 3000€)
http://www.nvidia.com/object/tesla-servers.html
Deine 2,91 TFLOP hat sie lediglich bei max. Boost Takt, wie lange auch immer der hält.

Zudem ist die FirePro nicht erst ab Anfang 2016 die die vorgestellte Phi erhältlich sondern bei Geizhals seit April 2014 gelistet.
Etwas was gute 2 Jahre später raus kommt wäre dann schneller...wer hätte das gedacht.
Was die neue Phi in der Realität wirklich leistet muss sie dann erst noch zeigen.

 

[strex]

Da liegst du leider falsch, beide also die Telsa und die FirePro geben Peak an. Natürlich unter Turbo, sonst wäre es ja kein Peak. Und der Peak wird bei beiden auch nur bei optimaler Matrixgröße ermittelt und erreicht.

Besser informieren ist angesagt.

 

[Wadenbeisser]

Besser lesen lernen.
In dem Link in meinem Posting stehen die Specs der K80 drin...direkt von nvidia.
Beim Basistakt klatscht sie auf 1,87 TFLOP runter. Die 2,91 TFLOP sind wohl eher fürs Papier.

 

[Nai]

Die Peak-Performance taugt allgemein nur fürs Papier, da sie diejenige Performance ist die unter maximaler Auslastung der Rechenkerne entsteht. Die maximale Auslastung wird jedoch in Praxis nie erreicht. Komplexere Probleme sind in der Regel sogar deutlich von der Peak-Performance entfernt. Meine Erfahrungswerte sind, dass man z.b. auf GPUs bei komplexeren Problemen wie Raytracing, Volumenrendering, oder Flüssigkeitssimulationen irgendetwas zwischen 3 \% und 20 \% der Peak-Performance übrig bleibt. Da hockt man sich erst nach einem Benchmark in die Ecke. und weint .

Nicht nur deshalb finde ich auch den Vergleich zwischen Xeon-Phis und GPUs an der Peak-Performance an den Haaren vorbei gezogen. Phis und GPUs haben beide einen stark unterschiedlichen innerlichen Aufbau - bei beiden entstehen dadurch Vor- und Nachteilen.

 

[Wadenbeisser]

Stimmt, letztendlich geht es darum was dabei raus kommt.
Damit sind aber die Angaben zur Peak Leistung bei beiden Varianten relativ nutzlos und es kommt primär auf das eingesetzte Programm an.

 

[Simon]

In den Gebieten, wo der Xeon Phi primär eingesetzt wird, ist die theoretische Rohleistung wohl nur in eher seltenen Fällen die maßgebliche Größe.

Da geht es auch um etwas mehr:

- gerade im HPC-Bereich: Interconnects
- Software-Support (Libraries, ggf. direkter Kontakt zu den Designern und Entwicklern)
- Implementierungskosten (Anpassung SW an HW)

Es hilft am Ende wenig, wenn der theoretische Durchsatz nur in den seltensten Fällen erreicht wird, weil alleine schon die Fabric zwischen den einzelnen Knoten vergleichsweise lahm ist und die Latenzzeiten in die Höhe gehen. Dann wartet ein Knoten u.U. öfter auf Daten, als das er gerade berechnen könnte.

Genauso wenig ist es erfolgsversprechend, wenn zwar die Hardware die Leistung bringen könnte, die Softwareentwicklung aber am Ende so aufwändig ist, dass die Hardware schon veraltet ist, bis meine Software entsprechend performant läuft. Und im Zweifelsfall erwarten die Integrationsdienstleister einen direkten Kontakt zu den Herstellern, wo ein dementsprechender Background vorhanden ist, um Probleme und Aufgabenstellungen mit Unterstützung schnell lösen zu können.

In Zukunft wird es vermutlich nur noch zwei Konkurrenten geben:

Intel mit Xeon-EP, Xeon Phi und OmniPath
IBM mit Power8+/9..., Nvidia (GPU) und Mellanox (Infiniband)

 

[Holt]

Was hier immer vergessen wird, KNL ist programmierbar wie jede x86 CPU mit Kompatibilität zu Xeon. Multithread-Programm, einfach laufen lassen. Nichts mit umständlicher Programmierung mit CPU und GPU teil.

Das ist der große Scharm den Xeons Phi, da hat Intel bisher einen klaren Vorteil.

Euch ist aber schon klar das es um ein Produkt geht das Tausende € kosten wird und spezielle Software benötigt?

Tausende € ist möglich und wahrscheinlich, aber da es ein Produkt für das Enterprisesegment ist, sollte das keine große Rolle spielen und spezielle Software braucht man wohl eher beim GPU Computing. Aber klar, aus Heimanwendersicht ist fast allen spezielle SW was mehr als 4 Kerne auslasen kann

 

[Wadenbeisser]

So wie ich das verstanden habe arbeitet die Phi als System im System. Welche Software klassische kann damit umgehen?

Die Xeon Phi 7120P steht bei Alternate für über 3000€ drin und Intels Preisliste geht auf 4000€ rauf.
http://ark.intel.com/de/products/family/71840/Intel-Xeon-Phi-Coprocessors
Das ist also nicht nur warscheinlich sondern du kannst fest davon ausgehen.

 

[Nai]

So wie ich das verstanden habe arbeitet die Phi als System im System. Welche Software klassische kann damit umgehen?

Das ist eben der Witz vom Xeon Phi, dass er der Software vorgaukelt er sei ein vollkommen "normales" System mit CPU, Betriebssystem, Festplatte bzw Dateisystem und Netzwerkkarte. Deshalb funktioniert die normale Software auch drauf. Bei älteren Versionen vom Phi war zwar noch ein Neukompilieren nötig, weil die x86 kompabilität nicht komplett vorhanden war. Das Neukompelieren sollte bei neueren Verseionen aber wieder entfallen, sogar wenn es wegen Vektorisierung immer noch Vorteilhaft für die Performance sein kann.

Genauso wenig ist es erfolgsversprechend, wenn zwar die Hardware die Leistung bringen könnte, die Softwareentwicklung aber am Ende so aufwändig ist, dass die Hardware schon veraltet ist, bis meine Software entsprechend performant läuft.

Sehe ich ähnlich, m.E. auch einer der vielen Gründe, weshalb GPGPU auch auf absehbare Zeit ein Nieschendarsein fristen wird. Man sollte bedenken, dass ein Unternehmen bei nur einem Mannjahr Portierungszeit von CPU nach GPU Kosten in Höhe von 150 000 € hat. Davon kann es sich schon bereits einen Cluster von 30 bis 40 PHIs kaufen. Selbst wenn die PHI-Lösung bei der Anwendung etwas langsamer als eine optimierte GPU-Lösung ist, so können die 30 bis 40 PHIs, die man sich statt den Entwicklungskosten kaufen könnte, den Unterschied bei kleineren Clustern wieder mehr als wett machen. Das Risiko, dass die verwendete GPU-API, sei es CUDA oder OpenCL, in Zukunft mal veraltet sein wird, entfällt auch dadurch.

Meiner Meinung nach ist die einfachere Portierung bzw. die einfachere Programmierung auch ein weiterer Vorteil von CUDA im Vergleich zu OpenCL und einer der Gründe, weshalb sich CUDA statt OpenCL durchgesetzt hat. Bei kleineren Lösungen ist es nämlich auch hier egal, welcher Hersteller jetzt etwas schneller oder langsamer bzw teurer oder günstiger ist; da kommt es drauf an für welchen Hersteller man einfacher die Software portieren bzw programmieren kann.

 

[Flodul]

Wer von paralleler Programmierung einen Plan hat kann das nur als Unsinn verstehen. Die Regeln der Zusammenarbeit zwischen den Cores werden durch den Code defniert die die Cores ausführen und nicht durch "Koordinations-Cores".
Die zwei Cores werden wahrscheinlich abgeschaltet worden sein weil sie durch Fehler auf dem Die einfach defekt sind.

Ergänzung (23. August 2015)

Mit OpenCl und wird sich in nächsten Jahren weiter verbessern. ...

OpenCL ist wohl wenn es sich bei dem Kern um eine vollwertige CPU handelt kontraproduktiv, denn der Kern wäre damit langsamer als mit nativem Code.

 

[Nai]

OpenCL ist wohl wenn es sich bei dem Kern um eine vollwertige CPU handelt kontraproduktiv, denn der Kern wäre damit langsamer als mit nativem Code.

M.E. besitzt OpenCL sogar auf CPUs diverse Vorteile gegenüber der herkömmlichen Multithreading-Programmierung:
-Der OpenCL-Compiler kann CPU spezifisch optimieren
-OpenCL besitzt automatisch ein "implizites" Blocking über die Workgroups
-OpenCL definiert, dass die Workitems innerhalb einer Workgroup nebenläufig ausgeführt werden. Durch diese Nebenläufigkeit kann der Compiler Speicherabhängigkeiten zwischen zwei unterschiedlichen Workitems in einer Workgroup ausschließen. Das hilft wiederum, dass der Compiler über mehrere Workitems hinweg vektorisieren und einen höheren Instruction-Level-Parallelism verwenden kann. Würde man statt OpenCL zu verwenden versuchen die Workgroups über herkömmliche Schleifenkonstrukte zu implementieren, dann müsste man die Schleifen für die Vektorisierung und den ILP so gestalten, dass der Compiler die Speicherabhängigkeiten ausschließen kann.

 

[Mr.Seymour Buds]

Das Projekt ist ein pures Forschungsprojekt. Ob es jemals erfolgreich wird? Oder doch auch mal eingestampft bzw. maximal ein Nischenprodukt? Intel (und auch andere Firmen) hatte genügend IT-Projekte/Produkte, die letztlich gescheitert sind: Intel Itanium, Intel i860, EMT64 (ja, hier hat AMDs x64 gewonnen!), ...

Die parallelen Prozessoren haben heute auch immer noch Alltagsprobleme: so kann beispielsweise ein Windows (Server) mit den 72 Kernen des größten Xeons nix anfangen... da scheitert bereits das Betriebssystem, ohne dass überhaupt eine Anwendung laufen muss.

Ne, das sehe ich gar nicht so. Das wird ein riesen Erfolg. Die Nachfrage nach solchen Produkten steigt gewaltig.

Selbst die US-Regierung hat nun den Export von bspw. Hochleistungs Xeon CPU nach China verboten.

Immer wieder die Frage, ob das x86 kompatibel ist. Ich glaube von x86 kommen wir nie wieder weg. Das wäre so, als würde man das abc löschen.

Ergänzung (23. August 2015)

Die Peak-Performance taugt allgemein nur fürs Papier, da sie diejenige Performance ist die unter maximaler Auslastung der Rechenkerne entsteht. Die maximale Auslastung wird jedoch in Praxis nie erreicht. Komplexere Probleme sind in der Regel sogar deutlich von der Peak-Performance entfernt. ...

Dazu möchte ich feststellen, dass die meisten Probleme durch die Bandbreite limitiert sind. Die Recheneinheiten verhungern also. In der Regel ist diese Maximalleistung eine Angabe fürs Papier. Wenn ein konkretes Problem über 60% der Bandbreite auslastet, wäre das schon gut. Alles über 70% eher sehr gut und alles über 80% überragend gut. Worauf ich hinaus will ist: Bandbreite ist das Zauberwort.

 

[Nai]

Immer wieder die Frage, ob das x86 kompatibel ist. Ich glaube von x86 kommen wir nie wieder weg. Das wäre so, als würde man das abc löschen.

Das ist meiner Meinung nach aber auch ein selbstgemachtes Problem. Würde man die komerzielle Software aus Copyrightgründen nicht als Maschinencode sondern als Quelltext oder leicht zu parsende Assembly nahe Sprache bzw Zwischenrepräsentation ausliefern, dann bräuchte man die ganze Rückwärtskompabilität nicht. CPUs könnten sich dann die Rückwärtskompabilität sparen und müssten auch nicht gut darinnen sein Code auszuführen, der nicht für sie spezifisch kompiliert würde. Optimierungen für nicht optimalen Code wie Register-Renaming (https://de.wikipedia.org/wiki/Registerumbenennung ) würden dann auch entfallen. Ich nehme an, dass CPUs dann auch ein deutliches Stück schneller wären. Interessanterweise ist das ja bei GPUs schon von Anfang an der Fall. Da werden Shader in einer Assembly nahen Sprache oder als Quelltext ausgeliefert. Shader werden dann zur Laufzeit spezifisch für die jeweilige GPU kompiliert und dabei optimiert. Deshalb besitzt auch fast jede GPU-Generation ihren eigenen überarbeiteten Befehlssatz.

 

[Holt]

So wie ich das verstanden habe arbeitet die Phi als System im System. Welche Software klassische kann damit umgehen?

Das hatten wir doch schon geklärt:

Habe ich das nun richtig verstanden, von der PCIe Karte wandert der Xeon Phi in den S. 2011-3 und ersetzt die normale CPU dort?!?

Korrekt, ist ein Host Prozessor in BGA. Gibt aber noch als Infiniband- und Co-Prozessor-Variante. Vermutlich 2011-3 und kann theorethisch per QPI mit anderen Xeons kommunizieren. Bootet (nur BGA Variante) Windows oder Linux, da binärkompatibel zu Xeon.

Warum eine S. 2011-3 Variante nicht auch ein Linux booten könnte oder binärkompatibel zu Xeon sein sollte, erschiesst sich mir aber nicht. Damit hat man dann eben keinen Xeon mit 4, 8, 12 oder 18 Kernen, sondern einen mit 70.

Die Xeon Phi 7120P steht bei Alternate für über 3000€ drin und Intels Preisliste geht auf 4000€ rauf.

Das ist auch noch der alte, aber die neuen werden wohl kaum billiger, nur sind die 18 Kern CPU mit Preise die bei 4200€ beginnen, auch nicht wirklich günstig und wenn deren Kerne natürlich leistungsstärker sind, der Phi hat dann einfach viel mehr Kerne.