News Intel Xeon Phi: Knights Landing in vier Modellen ab 2.438 US-Dollar

[cbtestarossa]

Ich käme nie auf die Idee mir so etwas privat zu kaufen..Der "Pöbel" lässt sich vom Systemhaus fachmännisch beraten wenn er selbst keine Ahnung hat und stellt nicht zehn mal dieselbe Frage.

Warum soll sich nicht jemand privat soetwas zulegen bzw gleich in ein Systemhaus laufen die eventuell selbst keinen Plan von der Materie haben?
Ach komm mal wieder runter.

 

[SubZero22]

@nebulus

Sollte ein Witz sein oder? Bezüglich der Effizienz ist hier Intel ein großes Stück weiter. Denn Intel kann sich den kompletten Host sparen und spart sich hier locker schnell mal 200 bis 400W ein die alle anderen Lösungen von NV oder AMD bis dato benötigen. NV kann hier nicht mitziehen, da eine x86 Lizenz fehlt und AMD bis dato keine Lösung dafür vorgestellt hat. Vielleicht ist man mit Zen in der Lage ähnliches zu basteln.

Wer heute spitzen Flops pro Watt benötigt kommt, um die KNL nicht herum. Schaut man sich die neue Top500 Liste an, geht's wieder Richtung CPU statt GPUs:



http://www.heise.de/newsticker/meldung/Supercomputer-China-ueberholt-die-USA-3241342.html

ändert aber nichts dass in den meisten Benchmarks die ich gesehen haben GPUs schneller waren als Xeon Phis, selbst Xeon Phi kann ja Vektor Operation machen. Wenn man Xeon Phi und GPUs etwas abstrakter anschaut ist eigentlich kaum ein Unterschied vorhanden nur im Detail unterscheiden sie sich, es gibt sowohl bei Xeon Phi als auch bei GPUs Threads nur nicht im eigentlich Sinne, GPUs sind aber ein riesiger Vektor Prozessor. Der wirkliche Unterschied ist, dass "Threads" bei Xeon Phi bei weiten weniger Kosten als bei GPUs sprich wo viele Threads (nicht Vektor Operationen) notwendig sind ist man mit Xeon Phi schneller als mit GPUs, wo aber viele Vektor Operationen gemacht werden müssen ist man mit GPUs schneller siehe Matrix Vektor Operation

richtig interessant wird es man Xeon Phi als Scheduler für GPUs benutzt das bringt was aber so einfach übers Knie legen geht nicht, es gibt nun mal verschieden Algorithmen mit verschiedenen Anforderungen daher ist nicht jeder Hardware automatisch bei jeden Problem schneller nur weil es Paradedisziplinen für etwas gibt wo diese Hardware schneller ist

 

[strex]

Warum soll sich nicht jemand privat soetwas zulegen bzw gleich in ein Systemhaus laufen die eventuell selbst keinen Plan von der Materie haben?

Weil die einem beraten ob seine Software auch wirklich läuft und zweitens mögliche Anpassungen durchführen können damit es läuft. Da man, wie man man selbst gesehen hat, selbst das Wissen nicht mitbringt. Was bringt mir eine Phi, wenn ich dann die passende Software nicht habe, die Konfiguration nicht verstehe oder nicht selbst anpassen kann. Aber ja, jeder der zuhause ein bisschen am "PC gespielt hat" baut sich mal eben einen kleinen HPC-Cluster und beschäftigt sich mit den perfekten Einstellungen..

ändert aber nichts dass in den meisten Benchmarks die ich gesehen haben GPUs schneller waren als Xeon Phis, selbst Xeon Phi kann ja Vektor Operation machen.

Es ändert sich sogar sehr viel. Denn im HPC-Bereich ist die Leistungsaufnahme und Kühlung der limitierende Faktor. Ein weiterer wichtiger Faktor ist die Skalierung (Latenz,..) und Verteilung der Jobs. Sonst hätte man schon längst Millionen von Nodes zusammenschalten können. Wäre kein Problem so auf über 500 Petaflops zu kommen. Da stößt man aber an die Limits. Mit KNL kann ich aber deutlich mehr Blades verbauen als mit GPUs, denn für den Host welche ich bei einer Setup mit 4 GPUs verbau, kann ich bei der KNL locker zwei weitere Blades verbauen.

Das die GPUs in den Benchmarks schneller sind, liegt rein an der weit höheren Rohperformance. Der Overhead der hier aber liegen bleibt ist im Gegensatz zur KNL recht groß. Die kann ich jetzt mit der eingesparten Energie leicht kompensieren. Was hier zählt ist Perf/Watt und damit das maximale Setup was sich damit erreichen lässt. Nicht umsonst sollen die großen neuen Systeme >100/200/400 Petaflops mit Phi ausgerüstet werden.

Wenn man Xeon Phi und GPUs etwas abstrakter anschaut ist eigentlich kaum ein Unterschied vorhanden nur im Detail unterscheiden sie sich, es gibt sowohl bei Xeon Phi als auch bei GPUs Threads nur nicht im eigentlich Sinne, GPUs sind aber ein riesiger Vektor Prozessor. Der wirkliche Unterschied ist, dass "Threads" bei Xeon Phi bei weiten weniger Kosten als bei GPUs sprich wo viele Threads (nicht Vektor Operationen) notwendig sind ist man mit Xeon Phi schneller als mit GPUs, wo aber viele Vektor Operationen gemacht werden müssen ist man mit GPUs schneller siehe Matrix Vektor Operation

Nicht ganz, GPUs bekommen Probleme in hohen Matrixgrößen, Beschleuniger wie die Phi haben dies nicht in dieser Größe. Da gab es bei der ersten Serie schon schöne Tests von heise die das aufgezeigt haben. Zusätzlich davon kann weit mehr optimieren als bei GPUs, alleine schon weil ich aus dem riesigen Funds von x86 Software wählen kann. Die Software Tools (inklusive hoch optimierter Libs) von Intel im Bereich x86 erledigen dann den Rest, denn die können bequem von allen verwendet werden.

Genau das macht sich auf dem HPC-Markt bemerkbar, sonst würde Intel nicht so viele Systeme für sich gewinnen und das noch mit einer reinen Beschleunigerkarte.

 

[Simon]

ändert aber nichts dass in den meisten Benchmarks die ich gesehen haben GPUs schneller waren als Xeon Phis

Der einzige Benchmark, der schlussendlich auf den fertigen Systemen einmal läuft ist LINPACK, aber auch nur, um sich ggf. in die Top500-Liste eintragen zu lassen. Danach sieht das System andere Workloads, die mit LINPACK noch soviel zu tun haben, wie Currywurst Pommes und gesunde Ernährung.

Die Technologie wird letztlich danach ausgewählt, wo die größten Chancen bestehen, dass die eigenen Applikationen oder die der Kunden auf möglichst breiter Basis eine hohe Performance liefern und der manuelle und extrem kostenintensive Optimierungsaufwand möglichst klein gehalten wird.

In den letzten Jahren gab es da folgendes zur Auswahl:

1) x86 only (massen von Xeon E5-CPUs über Infiniband oder vergleichbaren Interconnects)
2) x86 + Xeon Phi (KNC) + Infiniband
3) x86 + GPU-Beschleuningung (meistens Nvidia Tesla) + Infiniband
4) BlueGene + GPU-Beschleunigung (meistens Nvidia Tesla) + Infiniband
5) SPARC / Custom DSP / etc.

jetzt kommen

7) Xeon Phi KNL only + OmniPath / Infiniband EDR
8) Xeon E5 + Xeon Phi KNL + OmniPath / Infiniband / Shasta (Cray)
9) Xeon E5 + GPU + NVlink
10) irgendwann vielleicht auch mal POWER8/9 + GPU + NVLink / IB EDR

dazu

Intel hat mit dem Xeon Phi halt mehrere große Vorteile:

a) wessen HPC-Code aktuell rein auf x86 basiert, kommt relativ schnell in den Genuss eines kräftigen Performance-Schubs. Von x86 zu x86 + AVX-512 ist der Weg deutlicher kürzer als bei x86 zu CUDA oder OpenCL

b) bestehende Systeme mit Knights Corner können ggf. einfach durch Knights Landing Karten ersetzt werden. Auch hier ist zwar ein wenig Anpassung notwendig, da die Vektor-Einheit der P54C Kerne nicht binärkompatibel ist aber auch da dürfte Intel die passenden Softwaretools und Entwicklerressourcen bereitstellen, um das Problem zu lösen

c) entfällt bei neuen System nach Wunsch die Host-CPU (Option 7), die ggf. einfach zu Teilen brach liegt, weil eigentlich nur als PCIe-Root missbraucht.

d) bis zu 384 GB an zusätzlichem Systemspeicher direkt an der CPU. Gehen die 16 GB MCDRAM aus, geht die Bandbreite mit 100 statt 500 GB/s zwar deutlich in den Keller, dafür ist aber kein mühsamer Umweg über PCIe notwendig

___

Nebenbei bemerkt ist es schon erstaunlich, dass die TDP mit 245 Watt für das Topmodell doch noch halbwegs moderat. Dafür liegt die Performance mit 3,456 TFLOPs @DP (ohne Turbo) sogar ein kleines Stückchen über der lange Zeit erwarteten 3 TFLOP/s Marke, die auf allen Folien immer zu sehen waren.

Allerdings scheint der 14 nm Prozess nach wie vor so anfällig zu sein, dass selbst ein Ausschuss von 4 defekten Kernen (72 statt 76) nicht ausreichend ist, um eine entsprechende Stückzahl aus den Wafern zu pressen.

___

zu AMD: eigentlich schon verwunderlich, warum man dort nicht einfach mal den Sprung gewagt hat:

64 Cats Cores
2048 GCNs
HBM Speicher

Die Technologie war die letzten Jahre dafür ja grundsätzlich "da". Ist im Prinzip ja nix weiter als eine aufgebohrte Konsolen-Lösung.

So wird eine mögliche Greenland APU zwar vielleicht ganz nett sein aber wenn überhaupt erst 2017/2018 auf den Markt kommen und damit reichlich zu spät. Zu diesem Zeitpunkt werden Nvidia und Intel ihre Position vermutlich soweit gefestigt haben, dass da vermutlich kaum etwas zu holen sein wird.

 

[OrangeRot]

Sorry, es geht doch nicht um Zielgruppe, es geht doch darum, für welche Aufgabengebiete werden solche Chips hergestellt. Manch einer will einfach nur grobe Infos, ganz einfach nur deshalb, um seinen eigenen Computerhorizont zu erweitern.

 

[Simon]

Kernwaffenforschung.

 

[SubZero22]

Es ändert sich sogar sehr viel. Denn im HPC-Bereich ist die Leistungsaufnahme und Kühlung der limitierende Faktor. Ein weiterer wichtiger Faktor ist die Skalierung (Latenz,..) und Verteilung der Jobs. Sonst hätte man schon längst Millionen von Nodes zusammenschalten können. Wäre kein Problem so auf über 500 Petaflops zu kommen. Da stößt man aber an die Limits. Mit KNL kann ich aber deutlich mehr Blades verbauen als mit GPUs, denn für den Host welche ich bei einer Setup mit 4 GPUs verbau, kann ich bei der KNL locker zwei weitere Blades verbauen.

Das die GPUs in den Benchmarks schneller sind, liegt rein an der weit höheren Rohperformance. Der Overhead der hier aber liegen bleibt ist im Gegensatz zur KNL recht groß. Die kann ich jetzt mit der eingesparten Energie leicht kompensieren. Was hier zählt ist Perf/Watt und damit das maximale Setup was sich damit erreichen lässt. Nicht umsonst sollen die großen neuen Systeme >100/200/400 Petaflops mit Phi ausgerüstet werden.



Nicht ganz, GPUs bekommen Probleme in hohen Matrixgrößen, Beschleuniger wie die Phi haben dies nicht in dieser Größe. Da gab es bei der ersten Serie schon schöne Tests von heise die das aufgezeigt haben. Zusätzlich davon kann weit mehr optimieren als bei GPUs, alleine schon weil ich aus dem riesigen Funds von x86 Software wählen kann. Die Software Tools (inklusive hoch optimierter Libs) von Intel im Bereich x86 erledigen dann den Rest, denn die können bequem von allen verwendet werden.

Genau das macht sich auf dem HPC-Markt bemerkbar, sonst würde Intel nicht so viele Systeme für sich gewinnen und das noch mit einer reinen Beschleunigerkarte.

Schwachsinn der limitierende Faktor ist die Leistungsaufnahme pro Flop im Grunde, die GPUs haben eine weit höher TFLOPs angaben als die von Xeon Phi, vielleicht braucht man mehr Blades um auf die gleiche Performance zu kommen unter dem Schluss muss über das Netzwerk kommuniziert werden und das betrifft sowohl GPUs als auch Xeon Phi ob ich jetzt Assembler oder OpenCL programmiere macht kaum einen Unterschied viel näher kann man nicht programmieren und wenn man von Latenz sprich dann sollte man erwähnen die alten Xeon Phis hatten ein sehr großes Problem wenn man Daten in den Speicher laden musste was die GPUs nicht hatten und sehr wohl spürbar war und der Hauptgrund warum Xeon Phi immer so was von nicht performant waren

 

[Krautmaster]

du scheinst in Deutsch ja echt gut aufgepasst zu haben. Ich musste den Post 5 mal lesen bis er halbwegs ankam - und dabei trotzdem Käse bleibt

 

[Pure Existenz]

Die Frage hier ist doch:

Can it run Crysis?

Wird langweilig...

 

[DrakeHamString]

Wozu dient eigentlich dieser Fabric Anschluss an der Seite des Prozessors? Hab den bisher noch nie gesehen...

 

[strex]

Schwachsinn der limitierende Faktor ist die Leistungsaufnahme pro Flop im Grunde..

Da setzen wir uns lieber einmal hin und lesen ein paar HPC sheets.

 

[konkretor]

___

Nebenbei bemerkt ist es schon erstaunlich, dass die TDP mit 245 Watt für das Topmodell doch noch halbwegs moderat. Dafür liegt die Performance mit 3,456 TFLOPs @DP (ohne Turbo) sogar ein kleines Stückchen über der lange Zeit erwarteten 3 TFLOP/s Marke, die auf allen Folien immer zu sehen waren.

Allerdings scheint der 14 nm Prozess nach wie vor so anfällig zu sein, dass selbst ein Ausschuss von 4 defekten Kernen (72 statt 76) nicht ausreichend ist, um eine entsprechende Stückzahl aus den Wafern zu pressen.

___

Danke für die Info die TDP hatte mich interessiert.
Mal sehen in ein paar Jahren gibts es diese Teile dann auf Ebay zum rum basteln :-)
Interessant finde ich das es einen Sockel gibt für diese Beschleuniger mal sehen wie sich das Entwickelt.

Ergänzung (21. Juni 2016)

Kernwaffenforschung.

Oder das Wetter, Börsenkurse, die Zahl Pi berechnen


http://www.top500.org/lists/

 

[SubZero22]

Da setzen wir uns lieber einmal hin und lesen ein paar HPC sheets.

wenn man sich anschaut, dass Xeon Phi laut Golem ca. 7.5 TFlop hat bei einer Größe von 700 mm^2 aber der G100 bei über 10 TFlop sein wird bei 600 mm^2 und beide Karten eine vergleichsweise hohe Leistungsaufnahmen haben welches Design ist dann effizienter ? Flops / Watt ist noch immer wichtiger als nur Watt vor allem haben sehr wohl GPUs als auch Xeon Phis eine ähnliche Leistungsaufnahme daher ist einfach der Faktor Flops/Watt wichtiger

 

[dgschrei]

wenn man sich anschaut, dass Xeon Phi laut Golem ca. 7.5 TFlop hat bei einer Größe von 700 mm^2 aber der G100 bei über 10 TFlop sein wird bei 600 mm^2 und beide Karten eine vergleichsweise hohe Leistungsaufnahmen haben welches Design ist dann effizienter ?

Der Xeon Phi. Weil die TDP der Tesla egal ist, weil die gleichzeitig noch einen Leistung ziehenden Xeon braucht um überhaupt was rechnen zu können. Bei KNL spart man sich das einfach.

Mal ganz abgesehen davon, dass GPUs die Differenz zwischen den theoretischen TFLOPs und der der tatsächlich erreichten Leistung erheblich größer ist, als bei den x86 Kernen im Xeon Phi.

Und was den Anwender die Chipfläche interessieren sollte, versteh ich ehrlich gesagt nicht.

 

[Buttermilch]

Wozu dient eigentlich dieser Fabric Anschluss an der Seite des Prozessors? Hab den bisher noch nie gesehen...

http://www.hardwareluxx.de/images/s...ing/2016/Intel-Xeon-Phi-Knights-Landing-3.jpg da ist der interconnector für Glasfaser dran. Omnipath

 

[SubZero22]

Der Xeon Phi. Weil die TDP der Tesla egal ist, weil die gleichzeitig noch einen Leistung ziehenden Xeon braucht um überhaupt was rechnen zu können. Bei KNL spart man sich das einfach.

Mal ganz abgesehen davon, dass GPUs die Differenz zwischen den theoretischen TFLOPs und der der tatsächlich erreichten Leistung erheblich größer ist, als bei den x86 Kernen im Xeon Phi.

Und was den Anwender die Chipfläche interessieren sollte, versteh ich ehrlich gesagt nicht.

nur mal so so in ziemlich jeden Benchmark den ich gesehen hab schlägt eine GPU eine Xeon Phi

https://www.paralution.com/single-node-benchmarks/

https://www.xcelerit.com/computing-benchmarks/libor/intel-xeon-phi-vs-nvidia-tesla-gpu/

vor allem bei Benchmarks wo Xeon Phi schneller sein sollte weil höhere Bandbreite wird diese dennoch von GPUs geschlagen, wenn eine GPU mehr Flops bei ungefähr gleicher TDP hat als eine Xeon Phi Karte und dadurch natürlich schneller ist, ist eine GPU noch immer effizienter weil eben mehr Flops bei vergleichsweise gleicher TDP gegenüber von Xeon Phi


und nur weil man die CPU weglassen kann bedeutet das ja nicht zwangsweise dass es für alle Anwendungen gilt

 

[strex]

wenn man sich anschaut, dass Xeon Phi laut Golem ca. 7.5 TFlop hat bei einer Größe von 700 mm^2 aber der G100 bei über 10 TFlop sein wird bei 600 mm^2 und beide Karten eine vergleichsweise hohe Leistungsaufnahmen haben welches Design ist dann effizienter ? Flops / Watt ist noch immer wichtiger als nur Watt vor allem haben sehr wohl GPUs als auch Xeon Phis eine ähnliche Leistungsaufnahme daher ist einfach der Faktor Flops/Watt wichtiger

Wenn man natürlich nur auf die Rohperformance reinfällt und vergisst das sämtliche GPUs einen Host mit in der Regel 200 bis 400W benötigen, sieht die Rechnung ganz anders aus. Von den Vorteilen das man einfach bestehende x86 Software betreiben kann, ohne Anpassung oder das der Algo komplett umgeschrieben werden muss einmal ganz abgesehen. Denn nicht alle Probleme lassen sich so einfach auf GPUs verteilen wie viele hier annehmen oder ein Benchmark.

Nicht umsonst hat Intel in wenigen Jahren NV ordentlich Butter vom Brot genommen und das mit reinen Beschleunigern und deutlich weniger Rohleistung. Auch AMD, trotz massiver Rohleistung (als die anderen beiden), kommt hier kein Meter weit. Dürfte nach deiner Angabe ja nicht so sein. Intel hat hier mit einer langsamen Phi innerhalb weniger Jahre 1/3 vom Markt erobert. Das hat AMD in der gesamten Zeit nicht geschafft mit stärkerer Hardware. Gäbe es keine guten Gründe hier wieder auf x86 zu setzen, hätte sich die CUDA Dominanz weiter durchgesetzt. Das sehen die Betreiber aber ganz anders.

vor allem bei Benchmarks wo Xeon Phi schneller sein sollte weil höhere Bandbreite wird diese dennoch von GPUs geschlagen, wenn eine GPU mehr Flops bei ungefähr gleicher TDP hat als eine Xeon Phi Karte und dadurch natürlich schneller ist, ist eine GPU noch immer effizienter weil eben mehr Flops bei vergleichsweise gleicher TDP gegenüber von Xeon Phi

Schau mal deine Benches an, die sind von der alten Generation. Dort teilen sie sich wie alle anderen nur GDDR5 und somit die gleiche/ähnliche Bandbreiten je nach Modell. Von höhere Bandbreite kann hier also keine Rede sein.

und nur weil man die CPU weglassen kann bedeutet das ja nicht zwangsweise dass es für alle Anwendungen gilt

Doch, die GPU braucht immer einen Host egal welche Applikation, die Phi im Host-Mode braucht in keinerlei Applikation einen extra Host. Wer kommt denn auf solche eine Idee.

http://www.hardwareluxx.de/images/s...ing/2016/Intel-Xeon-Phi-Knights-Landing-3.jpg da ist der interconnector für Glasfaser dran. Omnipath

Korrekt, der Omnipath Controller sitzt direkt im Package und ist über PCIe x16 angebunden.

 

[Simon]

Es ist trotzdem schade, dass die Xeon Phi x200 Beschleunigerkarten erst deutlich verzögert kommen. Mit den Dinger lassen sich sämtliche Installationen, die in den letzten 1-2 Jahren mit Xeon E5 v2/v3 gepaart mit Xeon Phi x100 aufgebaut werden, mit relativ wenig Aufwand mal eben in der Leistungsfähigkeit fast verdreifachen, ohne ein komplettes System tauschen zu müssen.

 

[dgschrei]

nur mal so so in ziemlich jeden Benchmark den ich gesehen hab schlägt eine GPU eine Xeon Phi

Ja und Benchmarks sind halt nunmal komplett fürn Arsch. Da wird ein utopischer Usecase hochoptimiert gefahren und am Ende kommt raus wer den höheren Durchsatz schafft.

Mit der Performance in einem echten HPC Use-Case hat das nur halt leider so gut wie gar nix zu tun. GPUs sind extrem gut darin genau die gleiche Operation extrem oft parallel abzuarbeiten. In dem Moment wo die Applikation komplexer wird und mehr verschiedene Berechnungen gleichzeitig machen will, fällt diese theoretische Rechenleistung aber in sich zusammen und es bleibt nur noch ein Bruchteil der theoretischen Leistung über. Das Problem haben x86 Kerne nicht. Ist ja im Endeffekt eine normale CPU mit allen Features und verhält sich auch genau so.

Außerdem ignorierst du immer noch geflissentlich dass PCIe-basierte Teslas eben eine CPU brauchen die sie ansteuert und die müßig Strom verballert. Das kann man bei Knights Landing komplett weglassen. Der Chip ist eine "normale" x86 CPU also läuft auch das OS darauf problemlos. Und wenn man das OS drauf zum laufen kriegt, dann kriegt man auch alle Anwendungen drauf zum Laufen.

 

[strex]

@Simon

Jopp, 1 Jahr früher hätte es überhaupt keine Möglichkeit gegeben überhaupt zu kontern. Jetzt muss man sich gegen P100 stellen. Lag aber an den Yields, wirklich super läuft 14nm wohl immer noch nicht. Sonst müsste man nicht so viele 72Core Varianten bevorraten damit man diese Version liefern kann.

zu AMD: eigentlich schon verwunderlich, warum man dort nicht einfach mal den Sprung gewagt hat:

Die APU leidet aber auch an der Problematik wie jede GPU, damit kein Vorteil außer vielleicht hoher Packungsdichte. Das ist aber gar nicht AMD's größtes Problem in diesem Bereich, dass ist einfach Software und Support. Die Menge an Tools und Hilfe die NV und Intel hier liefern, könnte wohl AMD personal- und finanztechnisch gar nicht stemmen. Deshalb kriegen sie auch mit hoher Rohleistung keinen Fuß in den Markt.