Xeon Phi - Knights Corner - MIC

[AnarchX]

http://blogs.intel.com/technology/files/2012/06/phi_coprocessor_TEASER1.jpg

http://blogs.intel.com/technology/2012/06/intel-xeon-phi-coprocessors-accelerate-discovery-and-innovation/

Datenblatt zu Xeon Phi: https://www-ssl.intel.com/content/dam/www/public/us/en/documents/product-briefs/xeon-phi-datasheet.pdf
Entwickler-Handbuch: http://software.intel.com/sites/default/files/article/334766/intel-xeon-phi-systemsoftwaredevelopersguide.pdf

[Godmode]

Soeben auf CB gelesen. Wird dann wohl direkt gegen GK110 ins Rennen geschickt. Bin sehr gespannt wie sich das entwickeln wird, wobei ich eher auf Intel tippe, als auf nVidia.

[robbitop]

Intel hat bei HPC schonmal 2x Vorteile:

- Fertigungsprozess
- Design muss keine Anteile für Grafikberechnung "mitschleppen"

Wenn sie beides schlau nutzen, ist ein Sieg keine große Leistung.

[Ailuros]

Intel hat bei HPC schonmal 2x Vorteile:

- Fertigungsprozess
- Design muss keine Anteile für Grafikberechnung "mitschleppen"

Wenn sie beides schlau nutzen, ist ein Sieg keine große Leistung.

Bei wieviel GFLOPs DP/Watt genau?

[Spasstiger]

Das Intel-Discovery-System (http://i.top500.org/system/177816) in der TOP500-Liste (http://www.top500.org/list/2012/06/200) kommt mit laut Heise (http://www.heise.de/newsticker/meldung/Supercomputer-USA-holen-Spitzenposition-zurueck-1619629.html) 140 Knights-Corner-Karten und 280 Xeon E5 (8-Core) auf durchschnittliche 119 TFlops (Rmax) und 181 TFlops in der Spitze (Rpeak).
Da die Xeons rund 44 TFlops peak beisteuern (knapp 157 GFlops pro Xeon E5), wären das rund 980 GFlops peak pro Knights Corner. Allerdings wird bei Discovery offenbar noch nicht Knights Corner im Vollausbau verwendet, sondern nur mit 54 von 62 Cores. Somit könnte eine Xeon-Phi-Karte im Vollausbau sogar über 1100 TFlops liefern.

Die Leistungsaufnahme beim Discovery-System finde ich noch nicht so überzeugend, umgerechnet 850 Watt pro TFlops Rmax. Die IBM-Bluegene/Q-Systeme sind fast doppelt so energieeffizient.

[Gipsel]

Mit Peakleistung/W kann Intel nicht wesentlich davonziehen (schon gegen Tahiti ist man nur knapp davor [wenn überhaupt] und gegen GK110 liegt man wohl hinten), trotz dem Fertigungsvorteil. Der Vorteil soll sich daraus ergeben, daß man anders als bei GPUs auch bei kleinteiligeren Problemen einen großen Teil der Peakleistung nutzen kann. Allerdings gehen die Entwicklungen bei AMD und vor allem bei nV mit GK110 (GCN2 wird da aber natürlich weitermachen) in eine ähnliche Richtung (zumindest vom Effekt her).

Ein großer Vorteil für Intel dürfte zum einen die Fertigung sein. Damit werden auch eigentlich prinzipiell nachteilige Entscheidungen bei der Hardware (wie die Vektoreinheiten auf das Registerfile zugreifen können mit der Shuffle-Einheit dazwischen mag ja für die Programmierung ganz nett sein, energieeffizient ist es aber nicht, da haben GPUs die bessere Wahl getroffen; nVidias Shuffle-Befehl, der bei Kepler die gleiche Funktionalität auch ohne Nutzung des local memory erreicht, ist dagegen ein sehr interessanter Kompromiß, imo ofc) ausgeglichen werden können.
Der andere vermutliche Vorteil kommt von der riesigen Erfahrung mit sehr guten Compilern (und die hat intel nun mal). Da könnte es schnell passieren, daß sogar nVidias CUDA Probleme beim Vergleich der Qualitäten der Softwareumgebung bekommt.

[M4xw0lf]

Sehr puristisches I/O-shield, das steht schonmal fest ;D

[ENKORE]

Für DHE ist das sicher sinnvoll. Der Kühlkörper sieht ja auch recht mächtig aus...

[=Floi=]

wie kommen die denn auf so krumme core-zahlen? gibt es da mehr details zur architektur?

[y33H@]

Was ist an 64 im Vollausbau komisch?

[AnarchX]

Vollausbau ist laut Intel 62. Aber wahrscheinlich sind es 64 Cores, wovon immer zwei für Verwaltungsaufgaben reserviert sind.

[Gipsel]

Vollausbau ist laut Intel 62. Aber wahrscheinlich sind es 64 Cores, wovon immer zwei für Verwaltungsaufgaben reserviert sind.
Wahrscheinlicher läßt man zwei aus yield-Gründen deaktiviert (weil es recht viele Dies gibt, bei denen nicht alle 64 funktionieren und 3% weniger Kerne sind doch echt zu verschmerzen). Der 22nm Prozeß ist noch relativ neu und das Die wohl auch nicht ganz klein.

[AnarchX]

Aber warum lässt man diese 2 Cores bei der 54(56)-Core-Variante deaktiviert? ;)
Bei Knights Ferry waren wohl auch nur 30 von 32 Cores aktiv.

[BlackBirdSR]

Eine Einheit fungiert als Controller und Distributor, die andere macht Powermanagement? ;)

Intel muss ja nicht alles Tiles mit den identischen Kernen versehen.

[Gipsel]

Aber warum lässt man diese 2 Cores bei der 54(56)-Core-Variante deaktiviert? ;)Wo steht denn das so?
Das sind laut intel ausdrücklich noch nicht finale pre production Versionen. Nach meiner Lesart sind auf denen 54 (von 64) Kernen aktiv, die finalen Versionen (noch ein Stepping? ich vermute eher simples Warten auf bessere yields) werden 62 von 64 Kernen aktiv haben.

[AnarchX]

wobei der Xeon Phi noch nicht mit voller Kraft fuhr, nämlich nur mit 54 seiner geplanten 62 Rechenkerne
http://www.heise.de/newsticker/meldung/ISC12-Intel-stellt-HPC-Beschleuniger-Xeon-Phi-vor-1619632.html

Anfangs sprach ja Intel immer von 50+ Cores, womit 8er Clustern wohl die 56C(-2 Verwaltung-Cores) gemeint waren.
Ansonsten hätte man die Pre-Production-Version auch auf 56 nutzbare Cores deaktivieren können.

[Gipsel]

Und? Widerspricht das meiner Deutung? Wieso soll es 8er-Cluster geben?

[ndrs]

Ich biete 17er Cluster. Bietet jemand mehr?

Im Ernst: Intel wird jeden Core einzeln deaktivieren können. Und ich schätze auch die aktuellen Samples haben schon 64 Kerne. Wie Gipsel sagte, eine reine Yield-Sache.

[AnarchX]

Das wäre wie gesagt aber ein seltsamer Zufall, dass es beim Sample auch nur 54 Core sind. Auf LRB Knight Ferry waren auch nur 30 von 32 Cores nutzbar für Anwendungen.

Aber interessanter als die Core-Zahl sind wohl eher Vebrauchswerte und die nötige Die-Size. Charlie spricht von 8GiB GDDR5 für Xeon Phi.

[Gipsel]

Das wäre wie gesagt aber ein seltsamer Zufall, dass es beim Sample auch nur 54 Core sind. Auf LRB Knight Ferry waren auch nur 30 von 32 Cores nutzbar für Anwendungen.Und bei GF100 nur 15 von 16 SMs. So what? Da wurde auch keiner für irgendein Betriebssystem reserviert. Oder weißt Du mehr?

Und die 54 bei diesen speziellen Vorserienmodellen, das ist wahrscheinlich genauso viel oder wenig Zufall, wie es wohl auch 58 oder 52 Kerne hätten sein können. Aber das werden wir spätestens mit dem Launch erfahren.

Und 8GB GDDR5 ist zu erwarten (16 Chips an einem 512Bit-Interface). Alles andere würde mich überraschen.

[S940]

Intel hat bei HPC schonmal 2x Vorteile:

- Fertigungsprozess
- Design muss keine Anteile für Grafikberechnung "mitschleppen"

Naja, dafür schleppt Intel x86-Ballast mit herum. Bleibt sich irgendwie gleich. Wie gipsel schon sagte ist der Vorteil auch nicht sooo groß. Was eigentlich etwas verwundert, da Intels 22nm Prozess inkl. 3D-Transistoren ja schon ne weiter voraus ist, als der Abstand zu 28nm suggeriert. Ohne 22nm würde sich die Sache für Intel wohl nicht rentieren, weswegen es wohl auch keine kommerziellen Larrabee-Ableger gab.
Mal schauen, wie sich die Sache entwickelt, ich denke der größte Trumpf ist die Software-, Compiler- und Toolseite. RapidMind war seinerzeit toll und unterstützte nvidia/ati/cell und SIMD CPUs ... seinerzeit ... :(
http://www.hpcwire.com/hpcwire/2009-08-20/rapidmind_gets_swallowed_by_intel.html

[Coda]

- Design muss keine Anteile für Grafikberechnung "mitschleppen"
Dafür haben sie 64 x86-Decoder und den ganzen restlichen Legacy-Müll. Wenn man das so oft duplizieren muss und die Cores simpel sind, dann macht das auch tatsächlich ne Menge aus.

Die jetztigen AMD- und NVIDIA-GPUs sind völlig simpel. Die Instructions können praktisch direkt verarbeitet werden und selbst die Abhängigkeiten werden schon vom Compiler aufgelöst.

[X.Perry_Mental]

In diesem Zusammenhang vielleicht auch ganz interessant: Das Prozessorgeflüster aus der aktuellen C'T (Heft 14/12) von Andreas Stiller (http://www.heise.de/ct/artikel/Prozessorgefluester-1616972.html):



... zum Innenleben des restlichen CPU-Kerns wusste man wenig. Es hieß nur, dass man von einem auf 64 Bit aufgebohrten altertümlichen Pentium-Kern auf einen etwas moderneren, mehr Atom-ähnlichen Kern wechselt, ausgestattet mit vierfachem Hyper-Threading.

Im CPUID findet man in Blatt 4 unter „Maximum number of processor cores in this physical package (minus one) = 61“, dass, wie hier schon vor längerer Zeit verpetzt, maximal 62 Prozessoren bei Knights Corner aktiv sind. Klar: Das Die hat insgesamt 64 Kerne, zwei verbleiben als Reserve. Die Kerne kennen weder MMX noch SSE und unterstützen nicht einmal die nützlichen P6-Befehle wie CMOV oder FCMOV. Selbst die I/O-Befehle IN/OUT hat man gestrichen, die werden wohl durch Memory mapped I/O ersetzt.

Dem Register für deterministische CacheParameter kann man zudem entnehmen, dass alle Caches achtfach assoziativ sind und sowohl der Instruktions- als auch der inklusive Datencache 32 KByte aufweisen (Atom hat derzeit nur einen sechsfach assoziativen, 24 KByte großen L1-Datencache). Der gemeinsame L2-Cache müsste gemäß diesem Registereintrag 512 KByte groß sein – dem widerspricht allerdings das Extended CPUID-Register auf 0x80000006, das lediglich 256 KByte vermeldet. Aber das ist nicht die einzige Unstimmigkeit im CPUID; so meldet es, dass der Prozessor keinen POPCNT-Befehl unterstützt, der ist nun aber explizit im Manual aufgelistet …

[Ailuros]

Wahrscheinlicher läßt man zwei aus yield-Gründen deaktiviert (weil es recht viele Dies gibt, bei denen nicht alle 64 funktionieren und 3% weniger Kerne sind doch echt zu verschmerzen). Der 22nm Prozeß ist noch relativ neu und das Die wohl auch nicht ganz klein.

Beim originalen LRB leakte direkt vom engineering team raus dass sie die Hitze nicht kontrollieren koennen wenn alle Kerne voll ausgelastet werden und das sogar nach 12 hw Revisionen. In solch eine Richtung zu denken ist zwar zugegeben absoluter Wahnsinn nach so langer Zeit, aber es wuerde auch sowieso keiner merken wenn es wirklich so ein absurder Fall waere.

[Skysnake]

Ich würde eher sagen, das es kein Power Problem ist

Ich hab mal aus den Daten der Top500 runter gerechnet, wieviel ein XeonPhi so schluckt und bin auf ~220W gekommen. Damit ist man bei 6+8Pin und so ziemlich dem Limit, was man sich erlauben kann in Servern. Die sind einfach auf maximal 225W ausgelegt.

Ich bin dabei auch auf 54 verwendete Cores gekommen, was beuten würde, das man bei (allen) 62 Cores im Einsatz auf ~252W kommen würde. Das ist nicht sonderlich viel mehr als die 225W. Wenn die Yealds kein Problem wären, bzw. gleichmäßige Yealds, kann sollte man eigentlich ohne Probleme durch leichte Taktsenkung auch mit 62 Cores auf 225W kommen. Das sind ja nicht mal 30W....

[Lord Wotan]

Wo schließt man denn an der Intel Karte den Monitor an. Ich sehe da auf den Bild keine Anschlüsse. Wie soll das als Grafikkarte Funktionieren?

[Ravenhearth]

Das ist keine Grafikkarte.

[Lord Wotan]

Das ist keine Grafikkarte.
Was denn dann. Etwa der neue Steckplatz für Intel CPU´s über PCIe?


Und lest hier!
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9349227&postcount=2

Wird gegen NVidias Grafikchip ins rennen geschickt.

Also das teil bis auf die fehlenden Anschlüsse sieht wie eine Grafikkarte aus und wird gegen eine Grafikkarte ins rennen geschickt. Was soll das also anderes sein als eine Grafikkarte?

[Ravenhearth]

Es ist eine HPC-Karte, die im professionellen Segment zum Einsatz kommt. Das hat mit klassischer 3D-Grafik nichts zu tun.

[Lord Wotan]

Es ist eine HPC-Karte, die im professionellen Segment zum Einsatz kommt. Das hat mit klassischer 3D-Grafik nichts zu tun.
Was ist HPC?

OK

http://de.wikipedia.org/wiki/Hochleistungsrechnen

[Twodee]

was ist google?

[robbitop]

Das Ding ist wie eine Nvidia Tesla ein reiner Rechenknecht für hoch parallelisierten Code.

[Ravenhearth]

Was ist HPC?


High Performance Computing, also ist diese Kate - sehr einfach gesagt - für Aufgaben bei denen viel Rechenleistung gefordert wird, gedacht. Eine CPU ist es eigentlich auch nicht.

[Lord Wotan]

Also betreibt Intel 64 Multi- CPU`s mit Karte per PCIe in einen Computer. Also eine neue CPU Schnittstelle mit PCIe. Also geht der Weg wieder weck von Sockel. Wie bei Intel Pentium II zum Slot statt Sockel. Nur dieses mal eben zum PCIe Slot!

[Gipsel]

Was ist HPC?
High Performance Computing, das was die Supercomputer machen. Und da benötigt man an einem Cluster mit ein paar tausend solcher Karten sicherlich keine Monitoranschlüsse. Was wollte man auf den paar tausend Monitoren denn so anzeigen? Da geht es um die Berechnung oder Simulation von irgendwas, nicht um die Visualisierung und Anzeige (das macht man auf einem PC/einer Workstation nach der Berechnung, in dem man sich die Daten [über's Netzwerk natürlich, als normaler Nutzer bekommst Du die Kisten nie zu sehen] dort hin holt und dann auswertet/verarbeitet).

Übrigens haben viele Tesla-Karten von nVidia aus dem selben Grund auch keine Monitoranschlüsse:

http://images.anandtech.com/doci/5840/Tesla_GK104_K10_3Qtr_Covr_575px.jpg

Edit:
Also betreibt Intel 64 Multi- CPU`s mit Karte per PCIe in einen Computer. Also eine neue CPU Schnittstelle mit PCIe. Also geht der Weg wieder weck von Sockel. Wie bei Intel Pentium II zum Slot statt Sockel. Nur dieses mal eben zum PCIe Slot!
Ach Quatsch. Das ist gewissermaßen erstmal eine Beschleunigerkarte, auf die man geeignete Teilprobleme auslagert. Läuft genau wie GPGPU auf Grafikkarten. Das hat mit Slot vs. Sockel überhaupt nichts zu tun (was bei Deinem Beispiel des PII auch nur eine mechanische Frage war).

[y33H@]

Nein.

[Lord Wotan]

Ich verstehe denn Sinn dieser Karte nicht. Es ist keine CPU. Obwohl es Multi CPUs sind. Die Grafikfunktionen machen. Und das ohne das es eine Grafikkarte ist. Zum Schluss wird das als PCIe Karte rausgebracht.

Was soll das also sein? Wie gesagt ich verstehe den Sinn der Karte nicht.

[Ravenhearth]

Diese Karte ist garnicht für den normalen Konsumenten, sondern für den professionellen Einsatz in Großrechnern gedacht und erfüllt weder die Aufgabe einer CPU noch einer GPU (bezügl. Grafikberechnungen). Stattdessen ist die Aufgabe - wie robbitop und Gipsel richtig sagten - die Verarbeitung von hochparallelisiertem Code zB. für wissenschaftliche Berechnungen.

[Gipsel]

Ich verstehe denn Sinn dieser Karte nicht. Es ist keine CPU. Obwohl es Multi CPUs sind. Die Grafikfunktionen machen. Und das ohne das es eine Grafikkarte ist. Zum Schluss wird das als PCIe Karte rausgebracht. Ohne das man als Kunde das Braucht oder bezahlen kann oder sonstwas.

Was soll das also sein? Verstehe den Sinn der Karte nicht.
Das ist offensichtlich.


Also mal ein Versuch der Erklärung:

Irgendetwas soll berechnet werden. Der Rechenaufwand ist extrem hoch, so daß eine einzelne CPU beinahe ewig dafür benötigen würde. Hier kommen die HPC-Cluster ins Spiel, wo die Berechnung in viele kleinere Teile parallel auf den vielen CPUs so eines Clusters ausgeführt werden. So, das hat man seit vielen Jahren. Je nach Aufgabe funktioniert so eine Aufteilung mehr oder weniger gut.

CPUs sind üblicherweise darauf optimiert, eine einzelne Aufgabe (oder zumindest wenige) möglichst schnell auszuführen. Dies tuen sie sehr gut, allerdings kostet das auch relativ viel Strom.
Die typischen Grafikberechnungen bestehen aus extrem vielen kleinen Aufgaben, die sehr gut parallel abgearbeitet werden können. Die extra für diese Aufgabe entwickelten GPUs sind also auf solche Arten von Problemen optimiert. Eine einzelne Aufgabe erledigen sie nur sehr langsam. Deswegen sind GPUs bei Grafikberechnungen sehr viel schneller als eine CPU (Softwarerendering) bei einem vergleichbaren Stromverbrauch.

GPUs haben sich in der letzten Zeit so weiterentwickelt, daß man nicht mehr nur Grafikberechnungen darauf ausführen kann, sondern auch allgemeine Berechnungen (GPGPU, General Purpose GPU). Damit das gut funktioniert, muß aber die Berechnung sich sehr gut in viele kleine Teile aufteilen lassen.

Bringen wir jetzt mal alles zusammen. HPC-Cluster rechnen meistens an Problemen, die man sowieso schon auf viele Prozessoren aufteilen muß. Hat man jetzt eine Rechenaufgabe, die sich extrem gut in sehr viele sehr kleine Teile zerlegen läßt, ist es einfach schneller, diese Aufgabe auf vielen GPUs (bzw. GPU-ähnlichen Prozessoren wie Intels Xeons Phi) auszuführen. Man baut also einen Cluster der neben den normalen CPUs auch spezialisierte Karten (wie GPUs oder eben Intels MIC/Xeon Phi) für solche Aufgaben enthält. Bei bestimmten Rechenaufgaben kann man die sehr gut nutzen, bei anderen nicht so gut oder gar überhaupt nicht richtig. Je flexibler diese auf extreme Parallelität ausgelegten Prozessoren werden, desto häufiger kann man sie gewinnbringend einsetzen.

[Coda]

Also betreibt Intel 64 Multi- CPU`s mit Karte per PCIe in einen Computer. Also eine neue CPU Schnittstelle mit PCIe. Also geht der Weg wieder weck von Sockel. Wie bei Intel Pentium II zum Slot statt Sockel. Nur dieses mal eben zum PCIe Slot!
:facepalm:

[Skysnake]

Was denn dann. Etwa der neue Steckplatz für Intel CPU´s über PCIe?


Und lest hier!
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9349227&postcount=2

Wird gegen NVidias Grafikchip ins rennen geschickt.

Also das teil bis auf die fehlenden Anschlüsse sieht wie eine Grafikkarte aus und wird gegen eine Grafikkarte ins rennen geschickt. Was soll das also anderes sein als eine Grafikkarte?
Also da muss ich jetzt echt mal den Picar auspacken...
:facepalm:

Lies doch was geschrieben wird. Das Ding ist ein Accelerator(auf deutsch: Beschleuniger). Das Ding ist einfach nur dafür da gewisse Dinge zu berechnen, die halt auf der Karte mit weniger Stromverbrauch realisiert werden können als auf ganz stink normalen CPUs. Dafür sind Sie halt in anderen Dingen schlechter als CPUs.... Lies dir einfach nochmal durch, was Gipsel schreibt, der hat das schon ganz gut erklärt, wobei er nur das "viele gleichartige kleine Probleme" vergessen hat. Bei GPUs und auch hier bei XeonPhi hast du immer gleich mehrere Threads, die den selben Programmcode ausführen nur auf anderen Daten. Das geht in die Richtung von Vektorrechnern. Allein das spart schon einiges an Strom, macht das ganze Ding aber halt auch unflexibler...

Also bitte, das Ding braucht wirklich keinen Monitoranschluss, ist keine GPU, und ist auch kein Umschwenk von Sockel auf Slot bei CPUs :ugly:

[Ravenhearth]

Also da muss ich jetzt echt mal den Picar auspacken...
:facepalm:
Wohl nicht nur du...
:facepalm:
Ihr beiden seid aber wirklich pöhse. Nun hab ich mir den Picard mühselig verkniffen und ihr haut ihn gleich im Doppel raus:unono:

[Gipsel]

der hat das schon ganz gut erklärt, wobei er nur das "viele gleichartige kleine Probleme" vergessen hat. Bei GPUs und auch hier bei XeonPhi hast du immer gleich mehrere Threads, die den selben Programmcode ausführen nur auf anderen Daten.Hey, da ging es um die Basics. Ich wollte kein Kapitel eines Buches über SIMD- bzw. Vektor-Architekturen verfassen um dann noch eines über HPC anzuhängen. ;)


@all:
Haltet Euch mal ein wenig zurück und prügelt nicht so auf LW ein.

[Skysnake]

@Raven, das Doppelpack war keine Absicht. Dann hätte ich ihn mir auch verkniffen ;D

@Gipsel, weiß ich doch ;)

[Hugo78]

Mit welchem Takt, bei welcher Spannung wird ein Xeon Phi jetzt betrieben?
Der Tri-Gate Vorteil soll ja um so markanter werden, je niedriger die Spannungen ist.
http://www.computerbase.de/bildstrecke/34387/10/

[Skysnake]

Kannste ja grob Abschätzen:

(~960GFLop/s) / (54 Cores * 512Bit-Vector-size/64Bit)= ~2,2GHz

Aber NUR wenn man kein FMA/MAD nutzt, was man aber wird, womit man nur noch bei 1,1GHz wäre. Den Spaß mit 1DP-FP als 2FP zu rechnen, weil man da einfach das SP unterschlägt, geht hier nicht, da man wirklich immer von DP-Flops spricht.

Find ich jetzt aber auch nen bischen viel :ugly:

Sind die Vectoren doch breiter? Auf Wikipedia (http://en.wikipedia.org/wiki/Intel_MIC) steht aber, das es 512Bit Vector-Register seien.

[Hugo78]

Also 1,1GHz klingt ja erstmal realistisch, wo Knights Ferry ja schon 1,2 GHz hatte und wenn man nun in Relation mehr Kerne bei etwas weniger Takt hat,
um wiederum ne niedrigere Spannung zu fahren, würd das ja erstmal ins Bild passen.

[Skysnake]

Ja, nur muss man sich dann fragen, warum nicht alle Cores aktiv und noch weniger Takt?

Wie skaliert den die 22nm Fertigung so in den unteren Taktbereich mit der Leistungsaufnahme?

Man kann ja auch nur bis zu einem gewissen grad die Spannung senken. MAn muss ja noch die Schaltspannung der Transistoren aufbringen.

[Gipsel]

Die ~1,1 GHz stimmen schon.
Und die 54 Kerne sind doch noch pre production Versionen. Die finale Version (Warten auf bessere yields? Ist ja kein ganz kleines Die) soll doch mit 62 aktiven Kernen kommen. Vielleicht noch ein paar MHz mehr, und man ist bei 1,2 TFlop/s Peak. Ist jetzt aber nichts, wo nV (mit GK110) oder auch AMD jetzt schon mit Tahiti vor Schreck im Boden versinken. Hier muß intel noch zeigen, daß die Leistung wirklich besser/flexibler/effizienter genutzt werden kann.

[Skysnake]

definitiv, wobei ich als größten Vorteil aber eh nicht die reine Rechenleistung und Effizienz seh, sondern die "leichte" Verfügbarkeit eines Speedups. Intel soll ja Programme recht einfach auf XeonPhi portierbar gemacht haben. So was kann man aber nicht abschätzen. Das muss sich einfach in freier Wildbahn dann zeigen, obs auch wirklich so ist.

Programme auf GPUs umschreiben/optimieren ist ja meist nicht ganz trivial.

[Ailuros]

Ich würde eher sagen, das es kein Power Problem ist.

Wie ich schon sagte, klingt es total unwahrscheinlich dass nach so vielen Chip Generationen das Problem immer noch existiert.

Ich hab mal aus den Daten der Top500 runter gerechnet, wieviel ein XeonPhi so schluckt und bin auf ~220W gekommen. Damit ist man bei 6+8Pin und so ziemlich dem Limit, was man sich erlauben kann in Servern. Die sind einfach auf maximal 225W ausgelegt.

Ich bin dabei auch auf 54 verwendete Cores gekommen, was beuten würde, das man bei (allen) 62 Cores im Einsatz auf ~252W kommen würde. Das ist nicht sonderlich viel mehr als die 225W. Wenn die Yealds kein Problem wären, bzw. gleichmäßige Yealds, kann sollte man eigentlich ohne Probleme durch leichte Taktsenkung auch mit 62 Cores auf 225W kommen. Das sind ja nicht mal 30W....

Der Haken ist eben dass es bis jetzt noch keine chips gibt wo alle cores operativ sind. Und die obrigen Punkte lassen mich ziemlich kalt; als reales Gegenbeispiel: GF100 mit einem cluster deaktiviert und 700MHz core clock hatte einen TDP von 250W. HPC war fuer GF100 bis zu 14 SMs only und haetten sie 16 SM cluster chips fuer desktop vom GF100 benutzt, haetten sie in der brutalen Mehrzahl 1 chip pro wafer mit 16 operativen SMs bekommen und ein paar Aussnahmen 2 chips/wafer und dazu mit einem brutal hohem Stromverbrauch der wohl nichts mit der 15SM/250W TDP Analogie zu tun hatte. Kaputtes interconnect und nur nach wenigen Monaten kam GF110 mit allen 16SMs mit 10% hoeherem Takt und "nur" 244W TDP an.

Nein die beiden Faelle sind durchaus nicht vergleichbar da total verschiedene Architekturen aber ich frag mich immer noch wieso Intel engineering nach einer Unmenge von LRB1 chip Revisionen und darauf noch zich chip Generationen danach es immer noch nicht schafft von Anfang an chips zu haben wo alle cores operativ sind. Ja natuerlich sind die chips hochkompliziert und wahrscheinlich auch ziemlich riesig (mehr cores trotz zunehmend kleineren Prozessen), aber falls die finale Produktion nicht mit allen cores aktiviert ankommt bekommst Du es mir nicht so leicht aus dem Schaedel dass irgend etwas nicht stimmt.

Und nein in solch einem Fall waere nicht das engineering Schuld sondern die buerokratischen Fritzen im Intel Management die wie immer ihre Finger in Sachen haben von den sie wenig verstehen.

[Skysnake]

Naja, man wird eventuell Cache-Kohärenz haben. Wenn ja, dann ist das ziemlich kompliziert, und würde eine relativ einfache Erklärung dafür liefern, das Sie es so lange noch nicht hinbekommen haben. Einfach weil immer noch irgendwelche Bugs da sind :ugly:

[Ailuros]

Naja, man wird eventuell Cache-Kohärenz haben. Wenn ja, dann ist das ziemlich kompliziert, und würde eine relativ einfache Erklärung dafür liefern, das Sie es so lange noch nicht hinbekommen haben. Einfach weil immer noch irgendwelche Bugs da sind :ugly:

Bugs koennten sehr schnell beseitigt werden. Meine obrigen Kommentare sind alles andere als reiner Zufall. Es geht dem Management hauptsaechlich um R&D Kosten. Es wird eben selten irgendwo zusaetzlich eingegriffen wenn das Resultat als "gut genug" empfunden wird. Das einzige was ich die ganze Zeit sagen will, ist dass die Intel engineers eben nicht irgendwelche schlampige unerfahrene Heinis sind eher das brutale Gegenteil.

[ENKORE]

Sonst würde Intel auch kaum den weltbesten Prozess fahren und die schnellsten Prozessoren überhaupt herstellen, wage ich mal zu behaupten...

[Skysnake]

Bugs koennten sehr schnell beseitigt werden. Meine obrigen Kommentare sind alles andere als reiner Zufall. Es geht dem Management hauptsaechlich um R&D Kosten. Es wird eben selten irgendwo zusaetzlich eingegriffen wenn das Resultat als "gut genug" empfunden wird. Das einzige was ich die ganze Zeit sagen will, ist dass die Intel engineers eben nicht irgendwelche schlampige unerfahrene Heinis sind eher das brutale Gegenteil.

Bei Cachekohärenzprotokollen und Implementierungsbugs hat das auch NICHTS mit unfähig zu tun. Das ist einfach abartig aufwendig zu debuggen.

Du musst ja bedenken, dass du in dem Chip bis zu 64 parallele Datenverarbeitunge MIT ooO Execution hast. Die Validierung von so ner CPU dauert nicht ohne Grund verdammt lange.

Es kann schon Probleme geben, die Sie einfach mit vernünftigen Latenzen/Taktraten nicht gelöst bekommen.

Bringt ja auch nichts, 20% mehr Kerne zu haben, wenn ich dann wegen Timings usw. dann der Takt soweit senken muss, das ich dann doch wieder 0 auf 0 raus komme.

Das sind aber halt alles nur Spekulationen. Wirklich wissen, werden es wohl nur die Ingenieure von Intel.

[Coda]

Larrabee hat keine Out of Order Execution.

[Skysnake]

Gut, dann wirds VIEL einfacher :ugly:

Dann sollte selbst, wenn Sie Cache-Cohärenz über alle Cores haben, das nicht sooo viel schwieriger sein als bei ner normalen CPU. ooO macht halt vieles sehr hässlich und schwierig.

Na dann hab ich auch keine Idee, warum die so wenige Cores verwenden, außer halt, dass die Yealds noch immer Scheise sind...

Dann hätte man aber auch einfach mal nen kleineren Chip nutzen können. Ist ja nicht so, als ob sich Intel das nicht recht leicht leisten könnte :ugly:

[Hugo78]

Out of Order also garnicht so wichtig, wenn man CPU x86 Code schnell für Phi portieren will,
weil dann der Treiber für Phi, einfach einen weiteren seiner Kerne, wie eine CPU Pipeline mit Platz für den Befehl, behandelt?!
Oder stell ich mir das jetzt zu einfach vor?

[Gipsel]

Eher falsch. Das hat miteinander überhaupt nichts zu tun.

[ENKORE]

Ich würde mal vermuten, dass Intel für das Teil wohl nur eine OpenCL-Schnittstelle, vielleicht (halte ich für unwahrscheinlich) auch dieses headless DirectX-Dingen, anbietet.
Damit hat der Compiler also die Möglichkeit den Code auf exakt die verbauten Cores zuzuschneiden und die Befehle daher schon passend umzusortieren. ooO würde vermutlich kaum was bringen, wenn man die Möglichkeit hat, den generierten Assembler auf nur eine einzige CPU zuzuschneiden.


Mein gänzlich unqualifizierter Gedankengang dazu ;)

[Ronny145]

Ich würde mal vermuten, dass Intel für das Teil wohl nur eine OpenCL-Schnittstelle, vielleicht (halte ich für unwahrscheinlich) auch dieses headless DirectX-Dingen, anbietet.



http://software.intel.com/en-us/blogs/2012/06/05/knights-corner-micro-architecture-support/


Schau in die Comments. OpenCL derzeit nicht.

[Gipsel]

Viel spannender ist ja eigentlich, daß für die Kommunikation zwischen Host und MIC eine virtuelle Netzwerkkarte benutzt wird, das läuft also offenbar durch den TCP/IP-Stack. Die MIC-Karte bootet dann schlicht über dieses Netzwerk (von der Platte des Hosts). Auch auf Bibliotheken und die Binaries wird so zugegriffen.

Achja, einen Turbo hat KnightsCorner übrigens auch (gibt es zusammen mit ECC allerdings erst seit der Version K1OM [ka eins oooh em], wahrscheinlich ist das die letzte Larrabee-Inkarnation genannt KnightsCorner).

[Skysnake]

Out of Order also garnicht so wichtig, wenn man CPU x86 Code schnell für Phi portieren will,
weil dann der Treiber für Phi, einfach einen weiteren seiner Kerne, wie eine CPU Pipeline mit Platz für den Befehl, behandelt?!
Oder stell ich mir das jetzt zu einfach vor?
Wie Gipsel schon gesagt hat, ooO hat NICHTS aber auch rein gar nichts mit paralleler Programmierung zu tun, auf die XeonPhi abzielt. OoO ist dafür da, in sequenziellen Code die Codeparallelität zu extrahieren. Du hast also sequenziellen Code, der eigentlich Anweisung für Anweisung abgearbeitet werden müsste. Auch solcher Code hat aber Instructionlvlparallelism. Also die Möglichkeit, Anweisungen parallel aus zu führen, da sie eben nicht voneinander abhängen. Damit erhält man halt einen Geschwindigkeitsvorsprung. Die GPUs machen das etwas anders. Wenn Sie warten müssen, arbeiten Sie einfach an anderen Sachen. Der Thread/Context-Wechsel braucht einfach praktisch keine Zeit. Auf ner CPU sieht das halt komplett anders aus. Da kostet das sehr viel Zeit, weswegen das keine Alternative zu ooO ist.

Ich würde mal vermuten, dass Intel für das Teil wohl nur eine OpenCL-Schnittstelle, vielleicht (halte ich für unwahrscheinlich) auch dieses headless DirectX-Dingen, anbietet.
Damit hat der Compiler also die Möglichkeit den Code auf exakt die verbauten Cores zuzuschneiden und die Befehle daher schon passend umzusortieren. ooO würde vermutlich kaum was bringen, wenn man die Möglichkeit hat, den generierten Assembler auf nur eine einzige CPU zuzuschneiden.


Mein gänzlich unqualifizierter Gedankengang dazu ;)
Nein, das Ding wird kein OpenCL unterstützen, oder zumindest nicht mehr als jede x86 CPU von Intel. Der Witz ist es ja gerade eben NICHT auf etwas wie OpenCL angewiesen zu sein, sondern eben ganz normal seinen Code schreiben zu können ;)

Und bzgl ooO. Dafür hat man die Hardware :ugly: DAs hat apriori nichts mit dem Compiler usw zu tun.

Viel spannender ist ja eigentlich, daß für die Kommunikation zwischen Host und MIC eine virtuelle Netzwerkkarte benutzt wird, das läuft also offenbar durch den TCP/IP-Stack. Die MIC-Karte bootet dann schlicht über dieses Netzwerk (von der Platte des Hosts). Auch auf Bibliotheken und die Binaries wird so zugegriffen.

Oh oh oh... :biggrin: Da ist aber jemand auf was spannendes gestoßen :biggrin:

Da sollte man vielleicht noch etwas tiefer bohren, und seine Fantasie spielen lassen :cool:;D


Achja, einen Turbo hat KnightsCorner übrigens auch (gibt es zusammen mit ECC allerdings erst seit der Version K1OM [ka eins oooh em], wahrscheinlich ist das die letzte Larrabee-Inkarnation genannt KnightsCorner).
Naja, war ja zu erwarten, das Sie so was einbauen. Ist ja heutzutage state-of-the-art

[Coda]

Nein, das Ding wird kein OpenCL unterstützen, oder zumindest nicht mehr als jede x86 CPU von Intel.
Um was wetten wir?

Der Witz ist es ja gerade eben NICHT auf etwas wie OpenCL angewiesen zu sein, sondern eben ganz normal seinen Code schreiben zu können ;)
"Ganz normaler Code" wird auf Xeon Phi ungefähr so gut laufen wie ein Trabant auf einer Autobahn.

[Nighthawk13]

"Ganz normaler Code" wird auf Xeon Phi ungefähr so gut laufen wie ein Trabant auf einer Autobahn.
Zwar schlecht, aber immer noch besser als auf ner GPU;)
Wenn die Kerne "nur" 4x HT haben, dürfte die Instruktion-Latency auch eher bei 4 Takten liegen.

Um OpenCL-Support kommen sie wohl kaum rum. Wie gut der wird, ist eine andere Frage... (Werden die OpenCL Threads auf die Cores oder Vektorlanes gemapped?)

[Coda]

Zwar schlecht, aber immer noch besser als auf ner GPU;)
Nö. Eben nicht.

Das will Intel uns erzählen, es stimmt aber einfach nicht. Ohne die Vektor-Einheit auszulasten ist das Ding genauso ein Krüppel wie eine GPU mit "normalem Code".

[Aquaschaf]

Das will Intel uns erzählen, es stimmt aber einfach nicht. Ohne die Vektor-Einheit auszulasten ist das Ding genauso ein Krüppel wie eine GPU mit "normalem Code".

Mir wurde vor ein paar Monaten erzählt ein Core von MIC wäre nur um einen Faktor 2-4 langsamer bei "normalem Code" als ein Core von i7. Aber ich glaube es auch erst wenn ich es sehe.

[Skysnake]

Um was wetten wir?

Ich sag doch, das OpenCL möglich ist, genau so wie bei ner CPU auch. Zumindest ich hab mit OpenCL auf CPUs aber keine guten Erfahrungen gemacht, was die Performance anbelangt. Kann bei XeonPhi wieder anders aussehen, aber ich denke OpenCL wird eher eine Randerscheinung auf XeonPhi bleiben. Da wird "normales" C/C++ drauf laufen mit nem paar Compilerpragmas, oder wie auch immer die das gelöst haben.

Nicht ohne Grund stellt Intel es so stark heraus, das man den Code nur leicht abändern muss, und hat nen extra Compiler für XeonPhi gebaut.

Auf ner normalen CPU läuft ja auch OpenCL. Siehst du viele CPU-OpenCL Programme? Ich nicht. Hab mich da wohl unglücklich ausgerückt.


"Ganz normaler Code" wird auf Xeon Phi ungefähr so gut laufen wie ein Trabant auf einer Autobahn.
Was ist für dich "ganz normaler Code"? Code aus ner Wald und Wiesen Anwendung, oder HPC Code, der schon parallelisiert ist für Cluster?

Letzteres soll ja angeblich mit ein paar Anpassungen ja schon recht performant laufen, wobei die Anpassungen geringer sein sollen als bei CUDA/OpenCL, und da hält es sich bei solchen Anwendungen ja schon realtiv im Rahmen.

Nö. Eben nicht.

Das will Intel uns erzählen, es stimmt aber einfach nicht. Ohne die Vektor-Einheit auszulasten ist das Ding genauso ein Krüppel wie eine GPU mit "normalem Code".
Das Programm läuft aber wenigstens :ugly:

Die GPU kann halt rein gar nichts mit nem normalen Programm anfangen. Wie performant das ist, ist wieder was GANZ anderes, aber es läuft schon mal. Ganz abgesehen davon, das eben wie gesagt nicht soo schwer sein soll. Vielleicht darf/muss ich aber eh bald mit XeonPhi arbeiten. Wenn ja, kann ich dazu ja dann mehr sagen ;)

PS: Vergesst bitte nicht, was Gipsel gesagt hat bzgl XeonPhi und "virtueller Netzwerkkarte" :wink:

[ENKORE]

@Skysnake:
Ich weiß nicht, wie nVidia das macht, aber AMD APP benutzt auch immer die CPU, ist ein extra Device mit genausovielen CUs wie Cores.
Intels OpenCL Dingen lüppt ja auch auf der CPU...

...sind halt nicht so parellel wie ne GPU.

Wenn Intel hierfür aber kein CL anbietet, müsste ich ja Programme speziell anpassen, während das bei CL zur Laufzeit geht. Also scheint Intel auf keinen Fall den Pro-Bereich anzupeilen oder auch nur tangieren zu wollen, sondern rein in den HPC-Bereich reinzugehen...?!

[Spasstiger]

Was soll so eine Karte eigentlich grob kosten? 2000$, 5000$, 10.000$? Oder wird es gar keine MSRP geben, weil jeder Partner die Preise selber aushandelt? Ich vermute ja mal, dass Intel typischerweise ganze Bundles aus Xeon-E5-Prozessoren und Xeon-Phi-Karten verkauft und die Karten erst über Komplettworkstations von OEMs zum Endkunden gelangen.

[Gipsel]

Wenn die Kerne "nur" 4x HT haben, dürfte die Instruktion-Latency auch eher bei 4 Takten liegen.Sehr wahrscheinlich ja. Das Problem ist, daß Larrabee/MIC/KnightsCorner etwas mehr Kopfstände machen muß, um die Latenzen von Speicherzugriffen zu verstecken (wofür man mehr als 4 Threads benötigt). Die Registerfiles sind ja im Vergleich zu GPUs sehr klein, so daß der Kontext dann immer schön aus dem Cache rein und rausgeswapped werden muß (wie halt bei den meisten CPUs). Man hat den Vorteil der gut angebundenen Caches aber den Nachteil, daß das auch ständig genutzt werden muß.
Werden die OpenCL Threads auf die Cores oder Vektorlanes gemapped?OpenCL work items werden auf die Vektor Lanes gemapped werden.

Aber Intel hat natürlich auch wieder eigene Begriffe definiert (die sie hoffentlich inzwischen nicht mehr verwenden), wahrscheinlich vor allem, damit das Schlagwort des "braided parallelism" so richtig zur Geltung kommt. So heißen die work items auch "strands" und die work groups "fibers". Die Fibers werden übrigens komplett per Software (Compiler oder programmierer selbst) gehandhabt, die Hardware hat nichts, um das zu unterstützen.

[Fragman]

Mir wurde vor ein paar Monaten erzählt ein Core von MIC wäre nur um einen Faktor 2-4 langsamer bei "normalem Code" als ein Core von i7. Aber ich glaube es auch erst wenn ich es sehe.

das waere aber sehr langsam. im endeffekt ist die karte dann nur rund doppelt so schnell wie ein 6core mit ht@4ghz, bei nur halber geschwindigkeit. wenns gar 4 mal langsamer ist wuerd das ja nicht sehr gut aussehen. oder uebersehe ich da was?

[Nighthawk13]

Das will Intel uns erzählen, es stimmt aber einfach nicht. Ohne die Vektor-Einheit auszulasten ist das Ding genauso ein Krüppel wie eine GPU mit "normalem Code".

Lantency Kepler: ~12 Cycles, Latency Phi: ~4 Cycles
Ansonsten gleich schlecht, da gebe ich dir recht. In naiv seriellem Code ohne Vektornutzung würde ein Atom mit wenigen Watt das Teil versägen.

Die Registerfiles sind ja im Vergleich zu GPUs sehr klein, so daß der Kontext dann immer schön aus dem Cache rein und rausgeswapped werden muß (wie halt bei den meisten CPUs). Man hat den Vorteil der gut angebundenen Caches aber den Nachteil, daß das auch ständig genutzt werden
Die ISA-Register für die HT-Threads sind sicher komplett in Hardware vorhanden. Das ist auch auf CPUs so(die Schattenregister fürs Register Renaming sind ohnehin schon da).

Dass das Registerfile kleiner ist, zieht natürlich mehr trotzdem Register-Spilling und unnötige Load/Stores nach sich. Sehe da weniger das Problem beim Cache, sondern bei den Instruktionen.
Auf CPUs mit den vielen Execution Ports und OoO sind die Load/Stores in den Cache kein Problem, aber auf nem simplen Many-Core?

[Gipsel]

Mir wurde vor ein paar Monaten erzählt ein Core von MIC wäre nur um einen Faktor 2-4 langsamer bei "normalem Code" als ein Core von i7. Aber ich glaube es auch erst wenn ich es sehe.
Ein normales Single-Thread-Programm einfach nur durch einen Compiler für MIC gejagt, dürfte noch langsamer sein. Immerhin reden wir hier von einem extrem einfachen in-order Kern bei ~1GHz. Die IPC dürfte da wahrscheinlich schon nur bei einem Viertel im Vergleich zu Sandy/Ivy liegen. Zusammen mit dem Takt würde ich da locker von einem Faktor um 10 ausgehen. Man muß die Vektoreinheit mit entsprechend angepaßten Code benutzen. Tut man das nicht, ist es eine Krücke und man ist mit einer normalen CPU sicher besser bedient.

[Gipsel]

Lantency Kepler: ~12 Cycles, Latency Phi: ~4 CyclesGCN: 4 Cycles
Kepler hat für einfache Dinge meiner Meinung nach übrigens 10 Zyklen Latenz, wovon wahrscheinlich 4 für den Registerzugriff draufgehen (Kepler kann offensichtlich genau wie Fermi kein Result-Forwarding!). Die eigentliche ALU-Pipeline besteht wohl aus 6 Stufen (einige Instruktionsarten benötigen mehr), MIC und GCN kommen mit 4 aus.
Das allein sagt Dir aber nicht viel.
Die ISA-Register für die HT-Threads sind sicher komplett in Hardware vorhanden. Das ist auch auf CPUs so(die Schattenregister fürs Register Renaming sind ohnehin schon da).
Die ISA-Register sind gerade mal 16 Stück * 4 Threads für den Skalarteil (zumindest im 64Bit-Modus, sonst nur je 8 wie halt bei x86). Aber das wichtige ist ja die Vektoreinheit. Und da gibt es 32 Register * 4 Threads. Wow! Bahnbrechende 8 kB für eine vec16-ALU. GCN hat dafür 64kB, kann also viel mehr workgroups parallel da drin halten ohne das ständig in den L1-Cache swappen zu müssen.
Und mit register renaming ist da übrigens gar nichts. ;)
Dass das Registerfile kleiner ist, zieht natürlich mehr trotzdem Register-Spilling und unnötige Load/Stores nach sich. Sehe da weniger das Problem beim Cache, sondern bei den Instruktionen.
Auf CPUs mit den vielen Execution Ports und OoO sind die Load/Stores in den Cache kein Problem, aber auf nem simplen Many-Core?
MIC ist so designed (auch vom Instruktionssatz), daß man auf Operanden vom Stack (also aus dem L1-Cache) angewiesen ist. Ein typischer Compute Kernel nutzt die architektonisch vorhandenen Register bereits vollständig aus. Wie willst Du da mit den Instruktionen gegensteuern? Normalerweise würde so eine Wahl eine komplette Bauchlandung hinlegen, weil sie Null Möglichkeit hätte, Latenzen zu verstecken. Intel hat dagegen den Instruktionssatz so gestaltet, daß es sehr einfach ist, Speicheroperanden zu benutzen. So lange die im L1-liegen, geht das sogar mit voller Geschwindigkeit, der L1-D wirkt gewissermaßen als 32kB Erweiterung des arg beschränkten Registerspaces.
Das relativ kleine Registerfile konnte nun so optimiert werden, daß es (bei GPUs unmögliche) Swizzles über den kompletten Vektor beim Lesen aus den Registern erlaubt (das dürfte übrigens ordentlich Stromverbrauch/Latenz kosten, womit es bei größeren Registerfiles extrem schwierig wird). Die Aufteilung geht auf einer ganz abstrahierten Ebene ein wenig in die Richtung des Registerfile-Caches von nV (der aber nur 5 oder 6 Einträge groß sein sollte, nicht 32 wie bei Intel).

[Skysnake]

@Skysnake:
Ich weiß nicht, wie nVidia das macht, aber AMD APP benutzt auch immer die CPU, ist ein extra Device mit genausovielen CUs wie Cores.
Intels OpenCL Dingen lüppt ja auch auf der CPU...

...sind halt nicht so parellel wie ne GPU.

Wenn Intel hierfür aber kein CL anbietet, müsste ich ja Programme speziell anpassen, während das bei CL zur Laufzeit geht. Also scheint Intel auf keinen Fall den Pro-Bereich anzupeilen oder auch nur tangieren zu wollen, sondern rein in den HPC-Bereich reinzugehen...?!

Ich hab doch gesagt, das es gehen wird, aber ob es Sinn macht, das bezweifle ich halt.... DER Vorteil von XeonPhi soll ja eben sein, keine Kopfstände mit so Sachen wie OpenCL machen zu müssen, sondern anders zu programmieren, bzw. halt einfach die Programme weiter nutzen zu können, die schon da sind.... Daher gehe ich auch nicht davon aus, das man XeonPhi großartig mit OpenCL programmieren wird in der freien Laufbahn, eben wie man eben auch CPUs nicht groß mit OpenCL programmiert, OBWOHL! es möglich ist.... Jetzt verstanden?

Gipsel ignoriert ja aber auch gekonnt meinen kleinen Wink mim Zaunpfahl, aber scheinbar brauchts doch den Vorschlaghammer, oder er will dazu nichts sagen :ugly:

[Nighthawk13]

Die Aufteilung geht auf einer ganz abstrahierten Ebene ein wenig in die Richtung des Registerfile-Caches von nV
Ja so sehe ich es auch. Die 8KB Register gewissermassen als L0-Cache für die Register im L1. Wobei man mit 32 Registern schon ganz gut leben kann.
(Typische Cuda-Kernels, mit den ich arbeite, verlieren <10% wenn man sie von 48 auf 32 Register runterzwingt, und da ist das Spilling teurer mangels Memory-Operanden).

GCN hat dafür 64kB, kann also viel mehr workgroups parallel da drin halten ohne das ständig in den L1-Cache swappen zu müssen
Parallele workgroups sind für sich genommen kein Vorteil, eher sogar ein Nachteil: ich will als Programmierer so wenig Parallelität wie nötig, um die Kiste auszulasten.
Die Frage ist ob/wie Phi Memory-Latenzen mit nur 4xHT verstecken kann? Sind das auch ~500 Cycles wie bei einer GPU?

[Gipsel]

Ja so sehe ich es auch. Die 8KB Register gewissermassen als L0-Cache für die Register im L1. Wobei man mit 32 Registern schon ganz gut leben kann.
(Typische Cuda-Kernels, mit den ich arbeite, verlieren <10% wenn man sie von 48 auf 32 Register runterzwingt, und da ist das Spilling teurer mangels Memory-Operanden).So eine Aussage kann man sehr schwer verallgemeinern, das hängt wirklich vom Problem ab. Die 10% Verlust sagen mir eher, daß Du da gar kein Registerspilling hast und der Compiler nur etwas anders optimiert, um mit weniger Platz auszukommen (in dem einige selten benötigte Sachen schlicht nicht in Registern gehalten und bei Bedarf neu berechnet werden). ;)
Parallele workgroups sind für sich genommen kein Vorteil, eher sogar ein Nachteil: ich will als Programmierer so wenig Parallelität wie nötig, um die Kiste auszulasten.Go AMD! Die sind in der Beziehung etwas besser (auf Kosten einer höheren Granularität, was das wieder zu einem Großteil zunichte macht). ;)
Die parallelen workgroups (oder auch große, die somit aus mehreren Hardwarethreads aka Warps/Wavefronts bestehen) ermöglichen Dir aber das extrem gute Verstecken von Latenzen für Probleme mit hohere Datenparallelität. Wenn man die nicht hat, ist man momentan schon ziemlich aufgeschmissen. Larrabee (und auch GK110 bzw. sogar GCN, falls die Features mal irgendwann vernünftig unterstützt werden) können aber im Prinzip auch Task-Parallelität nutzen (bzw. die bereits erwähnte "braided parallelism" genannte Mixtur mitsamt self scheduling bzw. task graph execution).
Die Frage ist ob/wie Phi Memory-Latenzen mit nur 4xHT verstecken kann? Sind das auch ~500 Cycles wie bei einer GPU?Da MIC genau wie GPUs GDDR5 benutzt, sollten die Speicherlatenzen nicht wesentlich niedriger liegen. gemacht wird das über Softwarescheduling innerhalb eines Hardwarethreads. Also z.B. workgroups (sind auf MIC wie gesagt reine Software) die größer als 16 Elemente sind (da benötigt man dann aber auch mehr Register). Und dann natürlich echte Thread-Switches, wie man das von CPUs kennt, also wirklich Kontext aus den Registern in Speicher/L1-schreiben und neuen laden und mit einem anderen Hardware-Thread weitermachen. Da der Kontext pro Thread ja nur 2kB und ein bißchen sind, geht das sogar halbwegs akzeptabel und lohnt sich damit bei einem Speicherzugriff mit einer Latenz von ein paar hundert Takten. Außerdem hat MIC einen recht großen L2-Cache von 256kB pro Kern (was bei der finalen Variante mit 62 Kernen dann insgesamt 15,5 MB sind). Für einige Probleme senkt das die effektive Speicherlatenz doch erheblich (GPUs haben bisher maximal 768kB L2).

[Nighthawk13]

Und dann natürlich echte Thread-Switches, wie man das von CPUs kennt, also wirklich Kontext aus den Registern in Speicher/L1-schreiben und neuen laden und mit einem anderen Hardware-Thread weitermachen. Da der Kontext pro Thread ja nur 2kB und ein bißchen sind, geht das sogar halbwegs akzeptabel und lohnt sich damit bei einem Speicherzugriff mit einer Latenz von ein paar hundert Takten.

Im Prinzip würde das gehen, aber wer entscheidet, wann das gemacht wird? Eigentlich will man das ja nur bei einem Cache-Miss haben, das kann der Compiler nur schwer erraten.

Außerdem müsste ich als Programmierer ja doch mehr Threads/Work-items vorgeben als 64x4x16=4096. Darin sehe ich im Moment den grössten Vorteil von Phi: geringere Mindestanforderung an die Datenparallelität.

Vielleicht ist das Kalkül: Der grössere Cache senkt die Latenzen weit genug. Gibt es auch nen L3 Cache? In den L2-Caches werden ja oft die gleichen Daten für jeden Core liegen....

[ENKORE]

Ich hab doch gesagt, das es gehen wird, aber ob es Sinn macht, das bezweifle ich halt.... DER Vorteil von XeonPhi soll ja eben sein, keine Kopfstände mit so Sachen wie OpenCL machen zu müssen, sondern anders zu programmieren, bzw. halt einfach die Programme weiter nutzen zu können, die schon da sind.... Daher gehe ich auch nicht davon aus, das man XeonPhi großartig mit OpenCL programmieren wird in der freien Laufbahn, eben wie man eben auch CPUs nicht groß mit OpenCL programmiert, OBWOHL! es möglich ist.... Jetzt verstanden?

Gipsel ignoriert ja aber auch gekonnt meinen kleinen Wink mim Zaunpfahl, aber scheinbar brauchts doch den Vorschlaghammer, oder er will dazu nichts sagen :ugly:Was heißt den Kopfstand? Ich baue ein Programm mit OpenCL und kann es später auf ziemlich beliebiger Hardware laufen lassen. GPUs, CPUs, Cluster (zumindest theoretisch), scheißegal, OpenCL abstrahiert mir das weg.
Hierfür muss ich mein Programm speziell nur für diesen Coprozessor anpassen und mit irgendeinm Intelcompiler neubauen.

Daher wiederhole ich meine Frage: Intel will damit nicht in den Workstationmarkt, oder? Sondern eher Supercomputer, HPC, Cluster...?

[Gipsel]

Außerdem müsste ich als Programmierer ja doch mehr Threads/Work-items vorgeben als 64x4x16=4096. Darin sehe ich im Moment den grössten Vorteil von Phi: geringere Mindestanforderung an die Datenparallelität.Na sicher mußt Du das. Auch bei GPUs mußt Du ja mehr als #SPs * arithmetische Latenz (ergibt bei Tahiti 8192, bei GK104 15360 bis 18432*) work items haben, damit einen die Speicherzugriffe nicht killen (daß man nur in Registern rumhantiert, ist doch etwas sehr synthetisch).

So ein Thread-Switch kann übrigens durchaus vom Compiler erzwungen werden (bzw. per Hand vom Programmierer), wenn er weiß, daß ein Cache-Hit unwahrscheinlich ist (und das weiß man häufig).

Edit:
*:
Sehr vereinfacht. Fermi und Kepler können gegebenenfalls instruction level parallelism nutzen, so daß sich der theoretische Minimalwert verringert. Praktisch will man natürlich trotzdem eher mehr haben. Ob Larrabee/MIC das auch kann, weiß ich nicht. Das hängt davon ab, ob die 4 Threads wirklich wie beim Barrel Processing stur round robin abgearbeitet werden oder ob ein Hardware-Thread mehrere unabhängige Instruktionen nacheinander absetzen kann (was einen entsprechenden dependency check seitens des Prozessors erfordert; Fermi macht dies, bei Kepler erledigt das der Compiler statisch, was bei MIC aber ausscheidet [würde die ISA ändern und wäre dokumentiert]).

[Coda]

Mir wurde vor ein paar Monaten erzählt ein Core von MIC wäre nur um einen Faktor 2-4 langsamer bei "normalem Code" als ein Core von i7. Aber ich glaube es auch erst wenn ich es sehe.
Wahrscheinlich mit Auto-Vektorisierung per ICC. Anders ist das kaum zu erreichen.

[Ronny145]

And, it did work - according to our high level sources in both China and Singapore, in some cases the code porting time differential is huge, like a few months to handle CUDA becoming few days to complete the MIC code port.

Well, that's where the second point comes in from the sources. Intel is still tuning the clock speeds and final performance of the initial generation Xeon Phi,

http://vr-zone.com/articles/intel-xeon-phi-steals-top-hpc-tenders-more-skus-to-come/16410.html#ixzz1ytKReDvL

[Godmode]

http://vr-zone.com/articles/intel-xeon-phi-steals-top-hpc-tenders-more-skus-to-come/16410.html#ixzz1ytKReDvL

Also wenn Intel Nvidia dort das Wasser abgräbt, dürfte das ziemlich blöd für die Grünen sein? Kann mir gut vorstellen das die Hersteller von Supercomputern eher zu einer Lösung aus einer Hand tendieren, als Gerätschaften von zwei Herstellern zu verbauen.

Wird spannend.

[Rogue]

Ich hab hier auf der Arbeit ne recht anspruchsvolle Software die eig. jede CPU (auch Quadcore und mehr) in die Knie zwingt.

Kann man diese Xeaon Phi z.B. "einfach so" nutzen?
Taucht die karte dann als CPU im Taskmanager auf?
Muss die Software speziell angepasst werden um auf dieser Karte zu rechnen?
Wenn ja, wie komplex ist diese Anpassung?

[ENKORE]

Der Coprozessor ist ein eigenes Gerät, was als Netzwerkkarte erscheint.
Programme müssen eigens dafür angepasst werden, ob Intel OpenCL-Support bietet ist bislang unbekannt.

Auf der Karte läuft ein Linux was über eine hostseitige Netzwerkkarte mit dem Host kommuniziert. Wie das genau aus Anwendungssicht abläuft, kann man noch nicht wirklich einschätzen.

Es dürfte wohl einfacher sein, günstige GPUs zu verbauen und auf OpenCL zu setzen...

[Coda]

http://vr-zone.com/articles/intel-xeon-phi-steals-top-hpc-tenders-more-skus-to-come/16410.html#ixzz1ytKReDvL
Ich glaub das immer noch nicht. Es mag dann zwar irgendwie laufen, aber mit miserabler Performance.

[ENKORE]

Es fällt mir irgendwie sehr schwer zu glauben, dass Code schneller auf den MIC portiert ist, als auf CUDA oder OpenCL...

[Gipsel]

Och, irgendein einfacher Spezialfall, ein paar #pragma xyz Statements in den C-Code einfügen, alles durch Intels-MIC-Compiler jagen und Du bist fertig. :rolleyes:

Die Hauptarbeit bei der Anpassung ist doch meisten, daß man die ganzen Datenstrukturen und damit dann auch den Algo anpassen muß, damit es wirklich gut läuft. Der Vorteil von MIC könnte da sein, daß ein wenig weniger Parallelität reicht und so Sachen, die unter dem Schlagwort "braided parallelism" laufen jetzt schon funktionieren (und nicht erst mit irgendeiner zukünftigen CUDA- bzw. einer noch zukünftigeren OpenCL-Version).
Oder es bezieht sich auf irgendwelche bereits auf Cluster angepaßte hochparallele HPC-Codes, wo es unter Umständen einfacher gehen könnte (wohlgemerkt könnte, allgemein ist die Aussage nicht, der bisher auf den einzelnen Knoten/Cores ausgeführte Code ist oft auch ähnlich ungeeignet für MIC wie bei normalen Programmen).

[Nighthawk13]

Schnell-mal-Parallelisierung über Pragmas geht auch mit openACC/Cuda:
http://developer.nvidia.com/openacc

IMO ist das aber eher fürs was Prototyping, die pragma-Wüste wird irgendwann unübersichtlich.

Bisher sehe ich noch nichts fundamentales, was Phi von GPUs unterscheidet. Vielleicht ist die Performance je Thread besser, so dass auch kurze Passagen mit wenig Parallelität noch erträglich schnell sind.

[Skysnake]

Also Leute, so langsam glaub ich wirklich ihr wollt mich hier verarschen :ugly:

Ihr stellt Fragen, und trampelt dann kurz darauf über die Lösung dieser Frage dutzendfach drüber. Gipsel hat schon ziemlich früh einen SEHR interessanten Punkt angesprochen, der praktisch das Zentrum all eurer Fragen darstellt. Trotz zweimaligem Hinweis darauf geht darauf aber keiner ein :ugly: Ok, bei Gipsel kann ich mir vorstellen, das er nicht mehr wissen will. Ich weiß ja auch nichts zu diesem Punkt...

Was heißt den Kopfstand? Ich baue ein Programm mit OpenCL und kann es später auf ziemlich beliebiger Hardware laufen lassen. GPUs, CPUs, Cluster (zumindest theoretisch), scheißegal, OpenCL abstrahiert mir das weg.
Hierfür muss ich mein Programm speziell nur für diesen Coprozessor anpassen und mit irgendeinm Intelcompiler neubauen.

Daher wiederhole ich meine Frage: Intel will damit nicht in den Workstationmarkt, oder? Sondern eher Supercomputer, HPC, Cluster...?
Ja, es ist hauptsächlich der HPC-Bereich angepeilt, Workstations passen nicht so gut ins MIC Konzept, einfach weil diese anders programmiert werden im Normalfall. Workstations sind Shared Memory Systeme, HPC/Supercomputer sind eigentlich IMMER! non-shared Memory Systeme. Man hat also nicht nur einen globalen Adressraum.

Das hat gewisse Auswirkungen auf die Programmiermodelle/Konzepte, wobei MIC eben "perfekt" auf eines der beiden abziehlt, und somit praktisch keinen Programmieraufwand hat. Im Workstationsbereich ist das egal. Da wird man dann wohl schlicht OpenCL oder vergleichbares nutzen.

Und nochmal, JA du musst nen Kopfstand machen. Die normale Anwendung im HPC-Bereich hat weder CUDA noch OpenCL drin. Du musst das alles erst neu dazu programmieren und umschreiben. Bei MIC musst du das nicht, da nimmste dein Programm und machst nur noch kleine Änderungen. Das ist aber was TOTAL anderes, als wenn du CUDA/OpenCL da noch integrieren mussst.


Irgendetwas soll berechnet werden. Der Rechenaufwand ist extrem hoch, so daß eine einzelne CPU beinahe ewig dafür benötigen würde. Hier kommen die HPC-Cluster ins Spiel, wo die Berechnung in viele kleinere Teile parallel auf den vielen CPUs so eines Clusters ausgeführt werden. So, das hat man seit vielen Jahren. Je nach Aufgabe funktioniert so eine Aufteilung mehr oder weniger gut.

CPUs sind üblicherweise darauf optimiert, eine einzelne Aufgabe (oder zumindest wenige) möglichst schnell auszuführen. Dies tuen sie sehr gut, allerdings kostet das auch relativ viel Strom.
Die typischen Grafikberechnungen bestehen aus extrem vielen kleinen Aufgaben, die sehr gut parallel abgearbeitet werden können. Die extra für diese Aufgabe entwickelten GPUs sind also auf solche Arten von Problemen optimiert. Eine einzelne Aufgabe erledigen sie nur sehr langsam. Deswegen sind GPUs bei Grafikberechnungen sehr viel schneller als eine CPU (Softwarerendering) bei einem vergleichbaren Stromverbrauch.

GPUs haben sich in der letzten Zeit so weiterentwickelt, daß man nicht mehr nur Grafikberechnungen darauf ausführen kann, sondern auch allgemeine Berechnungen (GPGPU, General Purpose GPU). Damit das gut funktioniert, muß aber die Berechnung sich sehr gut in viele kleine Teile aufteilen lassen.

Bringen wir jetzt mal alles zusammen. HPC-Cluster rechnen meistens an Problemen, die man sowieso schon auf viele Prozessoren aufteilen muß. Hat man jetzt eine Rechenaufgabe, die sich extrem gut in sehr viele sehr kleine Teile zerlegen läßt, ist es einfach schneller, diese Aufgabe auf vielen GPUs (bzw. GPU-ähnlichen Prozessoren wie Intels Xeons Phi) auszuführen. Man baut also einen Cluster der neben den normalen CPUs auch spezialisierte Karten (wie GPUs oder eben Intels MIC/Xeon Phi) für solche Aufgaben enthält. Bei bestimmten Rechenaufgaben kann man die sehr gut nutzen, bei anderen nicht so gut oder gar überhaupt nicht richtig. Je flexibler diese auf extreme Parallelität ausgelegten Prozessoren werden, desto häufiger kann man sie gewinnbringend einsetzen.
Nur nochmal zu Erinnerung eine gute Übersicht von Gipsel. Ich hab mal die wichtigen Punkte fett markiert.
@ENKORE: Die Programme, die du für XeonPhi nutzt sind halt schon auf eine gewisse Art und Weise parallelisiert. Das macht den Aufwand für einen Port auf XeonPhi sehr viel einfacher. Wenn man erst anfangen muss überhaupt ein Programm zu schreiben und dieses zu parallelisieren, dann macht es keinen soooo großen Unterschied mehr, ob man jetzt XeonPhi oder CUDA/OpenCL nutzt.

Viel spannender ist ja eigentlich, daß für die Kommunikation zwischen Host und MIC eine virtuelle Netzwerkkarte benutzt wird, das läuft also offenbar durch den TCP/IP-Stack. Die MIC-Karte bootet dann schlicht über dieses Netzwerk (von der Platte des Hosts). Auch auf Bibliotheken und die Binaries wird so zugegriffen.

Ja was ist das nur für ein Kommunikation :ugly: Und nein Gipsel ich glaub dir nicht, das du das nicht weißt :ugly:


Wenn Intel hierfür aber kein CL anbietet, müsste ich ja Programme speziell anpassen, während das bei CL zur Laufzeit geht. Also scheint Intel auf keinen Fall den Pro-Bereich anzupeilen oder auch nur tangieren zu wollen, sondern rein in den HPC-Bereich reinzugehen...?!
Wie gesagt, das hat damit nichts zu tun. Im HPC Bereich, wo XeonPhi angesiedelt ist, hast du IMMER auf eine gewisse Art und Weise parallelisierte Probleme. Dadurch wird der Portierungsaufwand auf XeonPhi klein, da eben ein Großteil der Arbeit schon gemacht ist, und man nicht wie bei CUDA/OpenCL erst mal nen riesen Klumpatsch an Overhead ak Initialisierung usw. programmieren muss.

Der Coprozessor ist ein eigenes Gerät, was als Netzwerkkarte erscheint.
Programme müssen eigens dafür angepasst werden, ob Intel OpenCL-Support bietet ist bislang unbekannt.

Auf der Karte läuft ein Linux was über eine hostseitige Netzwerkkarte mit dem Host kommuniziert. Wie das genau aus Anwendungssicht abläuft, kann man noch nicht wirklich einschätzen.

Es dürfte wohl einfacher sein, günstige GPUs zu verbauen und auf OpenCL zu setzen...
Du hast aber den größeren Programmieraufwand um CUDA/OpenCL zu nutzen, und wie ein Vortrag auf der ISC gezeigt hat, gibt es einen EXTREMEN Fachkräftemangel im HPC-Bereich. Ganz zu schweigen von Leuten, die auch noch GPUGPU können, von GPGPU auf Clustern fangen wir mal lieber gar nicht erst an...

Ich weiß nicht, wos war, ich glaub hier, gabs ja auch ein Statement, das Eine Protierung auf CUDA/OpenCL Monate braucht, und auf XeonPhi Tage. Das sollte man sich unter obigem Gesichtspunkt mal auf der Zunge zergehen lassen. Mal ganz davon abgesehen, das eine längere Portierung auch wieder Geld kostet.

Man muss es ja so auch sehen. Wenn ich entweder ein Problem 40% schneller (Effizienter) machen kann, oder 5 Probleme 10%, und alle gleich lang laufen, dann sind die 10% halt am Ende doch besser....

Es fällt mir irgendwie sehr schwer zu glauben, dass Code schneller auf den MIC portiert ist, als auf CUDA oder OpenCL...
Doch, und wenn ihr mal auf die Punkte, auf die ich euch ständig stoße mal eingehen würde, wäre euch auch recht schnell klar, warum dem so ist...

Och, irgendein einfacher Spezialfall, ein paar #pragma xyz Statements in den C-Code einfügen, alles durch Intels-MIC-Compiler jagen und Du bist fertig. :rolleyes:

Sicher, das es "nur" ein Spezialfall ist? Ich geb zu, ich hab noch nicht mit ihm Programmiert, aber ich seh keinen Grund, warum es schlechter gehen sollte als mit den Dingen, die normal auch verwendet werden.



Die Hauptarbeit bei der Anpassung ist doch meisten, daß man die ganzen Datenstrukturen und damit dann auch den Algo anpassen muß, damit es wirklich gut läuft. Der Vorteil von MIC könnte da sein, daß ein wenig weniger Parallelität reicht und so Sachen, die unter dem Schlagwort "braided parallelism" laufen jetzt schon funktionieren (und nicht erst mit irgendeiner zukünftigen CUDA- bzw. einer noch zukünftigeren OpenCL-Version).

DAS ist eben eine sehr gute Frage. So wie ich das bis jetzt einschätzen kann, musst du eben an der Datenstruktur nichts ändern.


Oder es bezieht sich auf irgendwelche bereits auf Cluster angepaßte hochparallele HPC-Codes, wo es unter Umständen einfacher gehen könnte (wohlgemerkt könnte, allgemein ist die Aussage nicht, der bisher auf den einzelnen Knoten/Cores ausgeführte Code ist oft auch ähnlich ungeeignet für MIC wie bei normalen Programmen).
Natürlich wird da NUR von HPC-Code, welcher auf Clustern läuft ausgegangen. Bei allem anderen verschwindet der Vorteil von XeonPhi sofort bzgl des Portierungsaufwandes. Du brauchst Code, der für ein non-shared Memory System geeignet ist...

Und btw. wer sagt, das man den Code eines "einzelnen Knoten/Cores" auf XeonPhi nur ausführt?


Machen wirs mal anders. Welche Möglichkeiten zur Parallelisierung auf shared und non shared Memory Systemen kennt ihr denn? Zählt einfach mal alle Möglichkeiten auf, und überlegt euch, wie das mit den Eigenschaften von XeonPhi zusammen passt..

[ENKORE]

Ich hab halt nur von shared-memory Systemen grob ne Ahnung. Da fallen mir in der Reihenfolge Threads/Prozesse/OpenMP/OpenACC und OpenCL ein, wobei ja "Threads" und "OpenMP" im Prinzip das gleiche sind, nur dass OpenMP schneller reingepfuscht werden kann...

Ohne gemeinsamen Speicher... fällt mir direkt eigentlich nur MPI ein...

[Skysnake]

Wir haben also grob OpenMP und MPI als Möglichkeiten um parallel zu programmieren.

Wie funktioniert denn OpenMP und wie funktioniert denn MPI? Fällt einem dabei vielleicht etwas auf?

Das war zu XeonPhi dann auch das letzte was ihr von mir hört.... Viel Spaß noch, und nehmt mal das Brett vom Kopf ;)

[Gipsel]

Es ist aber sicher nur eine Möglichkeit, innerhalb von MIC "OpenMP-artige"-Parallelisierung (und die muß ja auch noch gemacht werden!) zu benutzen und extern halt MPI. Aber so wird das schon meistens laufen.

[mrt]

Es ist aber sicher nur eine Möglichkeit, innerhalb von MIC "OpenMP-artige"-Parallelisierung (und die muß ja auch noch gemacht werden!) zu benutzen und extern halt MPI. Aber so wird das schon meistens laufen.
Bei XeonPhi gehts doch um HPC, es is völlig normal da auf einem Knoten mit OpenMP zu werken und Internodekommunikation per MPI zu machen.

[Gipsel]

Bei XeonPhi gehts doch um HPC, es is völlig normal da auf einem Knoten mit OpenMP zu werken und Internodekommunikation per MPI zu machen.
Habe ich irgendwo Gegenteiliges behauptet?

Im Übrigen kenne ich ein paar Leute, die bevorzugen nur ein System gleichzeitig zu benutzen, also MPI auch innerhalb der Knoten. Das verringert die Komplexität.

[mrt]

Ich wollte damit nur unterstreichen, dass das ein wichtige möglichkeit ist und es eh schon einiges gibt, dass OpenMP nutzt. Ich bin mir sicher, dass Intels Compiler damit gut was anzufangen weiß -> Portierungsaufwand minimal

Ja spricht auch nichts dagegen wenn man nicht auf maximalen Durchsatz abzielt.

[Gipsel]

Ja spricht auch nichts dagegen wenn man nicht auf maximalen Durchsatz abzielt.
Oder man ein Problem hat, bei dem OpenMP auf einem Knoten keinen (oder keinen wesentlichen) Performancevorsprung gegenüber MPI liefert und man dadurch wie erwähnt Komplexität sparen kann. ;)

[mrt]

Jo wenn man zB nicht viel Kommunikationsoverhead hat.
Die Programme sind dabei auch schon parallelisiert und ich halte auch hier den Portierungsaufwand auf Phi für überschaubar und geringer als auf CUDA/OpenCL.

[sloth9]

Was denn dann. Etwa der neue Steckplatz für Intel CPU´s über PCIe?


Und lest hier!
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9349227&postcount=2

Wird gegen NVidias Grafikchip ins rennen geschickt.

Also das teil bis auf die fehlenden Anschlüsse sieht wie eine Grafikkarte aus und wird gegen eine Grafikkarte ins rennen geschickt. Was soll das also anderes sein als eine Grafikkarte?

Autsch! Autsch! Autsch!

[Hugo78]

Mögliche 62 Cores @ 1,3GHz für 1,5TFLOPs.
http://www.computerbase.de/news/2012-08/peilt-intel-fuer-xeon-phi-die-1.3-ghz-marke-an/

[boxleitnerb]

Wie wird die Flopzahl bei Xeon-Phi eigentlich berechnet?

Bei 1500GFlops/1,3GHz*62 komme ich auf ca. 18.

[Spasstiger]

Wie wird die Flopzahl bei Xeon-Phi eigentlich berechnet?

Bei 1500GFlops/1,3GHz*62 komme ich auf ca. 18.
512-Bit-SIMD pro Core macht acht 64-Bit-FMA-Operationen pro Core und Takt, macht 16 DP-Flops pro Core und Takt (ein FMA ist eine Addition und eine Multiplikation in einem, wird als zwei OPs gerechnet).

[Gipsel]

Und damit kommt man nur auf
62 Kerne * 16 DP-FLOPs * 1,3 GHz = 1289,6 GFlop/s

Man wird also die 1,5 GFlop/s Marke nicht erreichen. Aber Intels Ziel dürfte es sein, bereits bei den prestigeträchtigen Matrixoperationen auf eine vergleichbare nutzbare Leistung zu kommen (nV hat bei DGEMM traditionell ein paar Schwächen) und bei komplizierteren Kommunikationsmustern/Datenlayouts dann einen Vorteil zu haben. Dafür würde das vermutlich bereits reichen.

[Hübie]

Auch CB (http://www.computerbase.de/news/2012-09/intel-gibt-offizielle-technische-details-zu-xeon-phi-bekannt/) heißt es:

Auf den restlichen Folien lassen sich dann schnell die Skalierbarkeit der maximal 64 Kerne inklusive dem L2-Cache erkennen.

Ich habe die Folien durchgesehen und finde da nix von 64 maximal aktiven Kernen. Die rede ist immer nur von 50+ :confused: Irgendwie stinkt das doch immer noch?!
Wieso scheut man auch den direkten Vergleich mit aktuellen Kepler/Tahiti-GPGPUs??
Edit: SP : DP ratio liegt bei 1:2 :eek:

[y33H@]

Es sind 64 vorhanden, aktiv aber idR maximal 62.

[Hübie]

Na dann braucht man auch nicht 64 schreiben. Das führt nur in die Irre. :rolleyes:

[Ronny145]

Es gibt nach aktuellem Stand verschiedene Konfigurationen von 57 über 60 bis 61 oder 62. In 50+ sehe ich nichts außergewöhnliches.

[Hübie]

Nein, aber in 64 sehe ich was ungewöhnliches.

[Ronny145]

Was ungewöhnliches siehst du daran?

[Hübie]

Herrje. Ist das so schwer zu verstehen?
Es steht in der News dass es 64 Kerne gibt, jedoch nicht dass diese 64 nie aktiv sind. Das könnte in die Irre führen. Ich hörte bisher nicht mal dass 62 Kerne genutzt werden konnten. Da aber alle eine Verschwiegenheitspflicht unterzeichneten gibt es eh nichts "offizielles". Halt nur von Leuten aus Unis bzw. Projekten die so etwas unter der Hand sagen. Mehr kann und darf ich ja nun selbst nicht ausplaudern.

[Knuddelbearli]

Wieso scheut man auch den direkten Vergleich mit aktuellen Kepler/Tahiti-GPGPUs??


weill sie da untergehen würden. selbst gegen amd 40nm schaffen sie mit 22nm und intel eigene! folien nur knapp mehr als nen gleichstand

[Hübie]

Das war eigentlich auch eine rhetorische Frage ;D

[Skysnake]

Herrje. Ist das so schwer zu verstehen?
Es steht in der News dass es 64 Kerne gibt, jedoch nicht dass diese 64 nie aktiv sind. Das könnte in die Irre führen. Ich hörte bisher nicht mal dass 62 Kerne genutzt werden konnten. Da aber alle eine Verschwiegenheitspflicht unterzeichneten gibt es eh nichts "offizielles". Halt nur von Leuten aus Unis bzw. Projekten die so etwas unter der Hand sagen. Mehr kann und darf ich ja nun selbst nicht ausplaudern.

Selbst da darfste nichts sagen, und wenn ich nichts sage, dann meine ich auch wirklich nichts. Was Intel selbst raus rückt, oder eben durch das Deep-Projekt zwangsweise raus kommt, über das kann man reden, aber bei allem anderen, würde dir auf die Finger gehauen, bis Sie brechen :freak:

[y33H@]

64 64 64 64 64 64 64 :upara:

[Hübie]

Na vor allem nicht hier ;) Im Chat oder pers. Gespräch ists was anderes. Meiner Meinung nach ist das eh fauler Zauber, wenn man nicht gleich mit offenen Karten spielt. Aber gut vor Veröffentlichung ist es legitim.

LG Hübie

y33h@: Jetzt komm noch mit XDR :freak:

[Coda]

Herrje. Ist das so schwer zu verstehen?
Es steht in der News dass es 64 Kerne gibt, jedoch nicht dass diese 64 nie aktiv sind. Das könnte in die Irre führen. Ich hörte bisher nicht mal dass 62 Kerne genutzt werden konnten. Da aber alle eine Verschwiegenheitspflicht unterzeichneten gibt es eh nichts "offizielles". Halt nur von Leuten aus Unis bzw. Projekten die so etwas unter der Hand sagen. Mehr kann und darf ich ja nun selbst nicht ausplaudern.
Es wird immer ein Kern als Scheduler gebraucht und einer für I/O, von daher sind bei einer 62 Kern-Karte schon 64 "aktiv".

[StefanV]

Es wird immer ein Kern als Scheduler gebraucht und einer für I/O, von daher sind bei einer 62 Kern-Karte schon 64 "aktiv".
Warum macht man sowas und verbaut nicht echte Scheduler bzw einen eigenen IO Dingsda??

[AnarchX]

Warum macht man sowas und verbaut nicht echte Scheduler bzw einen eigenen IO Dingsda??
Yield-Gründe? Wenn hier 2 Kerne defekt sind, hat man noch 62 andere Kerne, die diese Aufgaben übernehmen können.
Zumal man wohl auch das Sheduling auf noch mehr Kerne skalieren könnte, falls nötig.

[Skysnake]

Und vor allem könnte der Kern in der Zwischenzeit, wenn er kein I/O oder Sheduling macht, ja noch immer mit rechnen ;)

[Coda]

Warum macht man sowas und verbaut nicht echte Scheduler bzw einen eigenen IO Dingsda??
Flexibilität.

Und vor allem könnte der Kern in der Zwischenzeit, wenn er kein I/O oder Sheduling macht, ja noch immer mit rechnen ;)
Du willst da keine Latenz-Probleme haben. Es ergibt schon Sinn, das dediziert auf einen Core zu pinnen.

[AnarchX]

Nur $400 für eine Xeon Phi Karte? http://www.brightsideofnews.com/news/2012/9/26/exclusive-intel-xeon-phi-preferred-pricing-revealed---only-24400-per-card.aspx

[Skysnake]

wäre schon ein schleuderpreis

[robbitop]

Ist ja auch verständlich. Sie wollen ja ersteinmal in den Markt hineinkommen.

[fondness]

Die Hardware ist ja auch nicht gerade eine Offenbarung und was da schon Milliarden versenkt wurden will man wohl zumindest mal ein bisschen Umsatz generieren. Eine entsprechende AMD FirePro W9000 Karte kostet exakt das zehnfache ($3999), eine Tesla K20 dürfte kaum billiger werden.

[Coda]

Die Hardware ist vor allem für Intel 22nm keine Offenbarung. AMD oder NVIDIA hätten da wohl 4 TFLOPs rausgeholt ;)

[Hübie]

Es wird immer ein Kern als Scheduler gebraucht und einer für I/O, von daher sind bei einer 62 Kern-Karte schon 64 "aktiv".

Hm. Ergibt Sinn. Dachte eher an Deaktivierung durch Ausbeutemangel.

@AnarchX: 400€ wären wirklich lächerlich...

[Spasstiger]

Ich glaub, da fehlt eine 0. Hätte Xeon Phi auf 2000-4000 US-$ geschätzt genau wie die FirePros und die Quadro FXs.

[AnarchX]

Vielleicht ist im Preis eine Ausgleichszahlung für die Pro-Watt-Leistung enthalten? ;D

[Hübie]

Na ja. Intel hat so ein fettes Polster, dass die so ein Teil auch verschenken würden um einen guten Einstieg zu meistern ;)

[Spasstiger]

Wenn die offizielle Preisempfehlung bei nur 400$ und somit rund einem Zehntel von vergleichbaren Konkurrenzprodukten liegt, bleiben doch Einige skeptisch, ob das Produkt halten kann, was es verspricht. Intel kann ja immer noch hinter verschlossenen Türen die Karten zum Sonderpreis anbieten, aber die MSRP sollte schon dem Wert des Produkts entsprechen. Viele Unternehmen halten sich ja auch an das Motto: Wer billig kauft, kauft zweimal.

Allerdings: Bei 400$ werden sich die Universitäten drauf stürzen. Und die Leute, die an der Uni mit einem Xeon Phi arbeiten, wollen den vielleicht später auch in der Wirtschaft nutzen.

[=Floi=]

bei 4000$ wäre es wohl für die käufer ein zu großes risiko. bei ati oder nv bekommt man ja solide und bekannte technik. die software muß auch noch umgeschrieben werden. intel möchte damit wohl auch ihre cpu-systeme puschen.

ich verstehe aber nicht, warum man da nicht zwei linien aufbaut. einmal die normale zu 400$ und dann noch die professional für 2000-4000$.

[Spasstiger]

Xeon Phi richtet sich ausschließlich an Professionals. Daher auch das "Xeon" im Namen. Und solide und bekannte Technik würde ich Xeon Phi mit der x86-Unterstützung eher unterstellen als AMD und Nvidia mit CUDA/AMD App/OpenCL/etc.

[=Floi=]

es gibt auch günstige xeons für normale boards. Es würde sicherlich möglichkeiten geben die karten zu diversifizieren.

[Aquaschaf]

Die Hardware ist vor allem für Intel 22nm keine Offenbarung. AMD oder NVIDIA hätten da wohl 4 TFLOPs rausgeholt ;)

Wenn ich die Zeit dafür hätte würde ich trotzdem gerne damit herumspielen. Man kann auf dem Teil einen Linux-Kernel laufen lassen und mit pthreads programmieren. Nicht dass das viel Sinn ergeben würde. Aber es geht :freak:

[Coda]

Läuft nicht sogar immer ein Linux auf dem Kontroll-Kern?

[Ailuros]

Sagt mal wo steht denn genau in Theo's/BSN's writeup dass der Preis tatsaechlich nur bei $400 liegen wird? Es wird sogar Intel selber in diesem zitiert wo Intel klipp und klar sagt dass sie nicht auf Geruechte bzw. Spekulationen antworten. Warum auch?

Sonst waere man naiv zu glauben dass je groesser die Bestellung fuer N hw der Preis sich nicht senken wird, aber Intel ist weder so verzweifelt die Dinger nur um $400 das Stueck zu verkaufen noch ist Intel generell nicht billig.

Es ist eben wohl nicht so dass Intel so weit runter auf $400 gegangen ist und ebenso auch nicht so dass NV bei grossen K20 Volumen immer noch $3200 pro Stueck verlangt. Aber es ist halt Theo und fuer den Kerl ist leider keine Palme zu klein :rolleyes:

Thus, the nature of the $400 price can be traced with the fact that TACC took most of pre-production Xeon Phi boards.

WTF? Selbst Intel waere nicht so bloed und so grosse pre-production wafer runs zu machen die zu =/<7000 operativen chips fuehren wuerden. Also bitte.

Noch schlimmer wieso hat der Stampede supercomputer ueberhaupt 2 Tesla K20 wenn man mit Theo's Preisrelation fuer die fast $6400 fuer die Dinger stattdessen 16 zusaetzliche Xeon Phis haette bekommen koennen. 16 gegen 2 TFLOPs DP bei gleichem theoretischem Preis?

[Skysnake]

Weil die Intel karten Süffel Süffel machen mit dem Strom? ;D

Ne, die K20 sind wohl nur zur Visualisierung drin, soweit ich das überblicken kann. Da kannste XeonPhi einfach nicht für verwenden. Sind also mehr oder weniger 2 getrennte Sachen, für die K20 und XeonPhi eingesetzt werden

[Ailuros]

Weil die Intel karten Süffel Süffel machen mit dem Strom? ;D

Kann ich auch akzeptieren; in solch einem Fall verkauft man halt (angenommen NV gibt Rabbatt bei grossen Mengen fuer K20 und jegliche kostet $2000 oder weniger), dann verkauft halt Intel hypothetisch jegliche Phi bei grossen Mengen sagen wir mal bei $1500; $400 ist ziemlich absurd. Es ist zwar so dass HPC GPUs verdammt grosse Margen haben, aber von der anderen Seite ist nicht alles zwischem den Kosten der Chipherstellung und dem finalen Preis Gewinn.

Natuerlich kann es sich Intel leisten verdammt nahe oder am break even point zu verkaufen, aber sie machen es auch nicht in anderen Maerkten wo ihre Angebote im klaren Nachteil sind. Ihre small form factor SoCs sind in der Mehrzahl der Faelle teurer als die der Konkurrenz und sind dazu meistens auch rundum schwaecher.

Wo ist meine Erklaerung fuer den angebliche 6-7k chips pre-production wafer run? :freak:

Ne, die K20 sind wohl nur zur Visualisierung drin, soweit ich das überblicken kann. Da kannste XeonPhi einfach nicht für verwenden. Sind also mehr oder weniger 2 getrennte Sachen, für die K20 und XeonPhi eingesetzt werden

Wusste ich nicht; mal wieder was dazugelernt. In dem Fall kann natuerlich NV locker >6k dafuer kassiert haben.

[fondness]

Intel präsentiert fünf Modelle des Xeon Phi „Knights Corner“
http://www.computerbase.de/news/2012-11/intel-praesentiert-fuenf-modelle-des-xeon-phi-knights-corner/

[Hugo78]

Sollte Xeon Phi nicht irgendwie "verlustfrei" rechnen?!
Stand das nicht im Raum, als der große Vorteil ggü. klassischen GPUs?!
Mich wundert, dass man im DGEMM ect. nur 75-82% vom, ohnhin schon kleineren Peak erreicht, wo NV schon mit der billigen 13SMX Version mehr und 76-93% bietet.

[Skysnake]

Ist schon etwas wenig. Man hatte da schon mir mehr gerechnet.

Ein großer Vorteil bleibt aber bestehen. Man muss kein CUDA/OpenCL schreiben, sondern kann eben direkt in C/C++/Fortran arbeiten.

[AnarchX]

Ein großer Vorteil bleibt aber bestehen. Man muss kein CUDA/OpenCL schreiben, sondern kann eben direkt in C/C++/Fortran arbeiten.
Laut NV will Phi Assembler ähnlichen Code:
http://www.4gamer.net/games/121/G012181/20121110004/SS/014.jpg

[Skysnake]

Der Link funktioniert nicht.

Was nVidia erzählt würde ich aber nicht für all zu voll nehmen, oder meinste die versuchen die Vorteile der Konkurrenz dar zu stellen?

[Hugo78]

Was nVidia erzählt würde ich aber nicht für all zu voll nehmen, oder meinste die versuchen die Vorteile der Konkurrenz dar zu stellen?

In dem Fall würden sie nur darstellen, das Phi auch extra Code braucht.
Zumal ich glaub nicht, dass man in dem Profi-Bereich sich irgendwelche Ammenmärchen erlauben kann.

Eher noch hat sich Intel zuletzt die Glaubwürdigkeit verspielt, als sie DX11 per VCL Video verkaufen wollten. :D
http://www.youtube.com/watch?feature=player_embedded&v=Otcge1cn8Os

[Skysnake]

Naja, probiers doch einfach aus.

Das Softwarepaket zu MIC gibts bei Intel frei zum Download. Ich weiß nur nicht, ob der ICC dabei ist.

XeonPhi kann man halt nicht so linear sehen wie GPUs. Der Protierungsaufwand ist halt sehr unterschiedlich, genau wie bei CPUs halt auch der Entwicklungsaufwand sehr unterschiedlich ist. An manchen stellen schreibst du da ja auch heute noch Assambler, aber das ist ein SEHR kleiner Teil.

Man hat halt verdammt gute Compiler. XeonPhi ist halt auch ein Softwareprodukt und nicht nur ein Hardwareprodukt.

XeonPhi kannste halt "jedem" Wald und Wiesen Programmierer in die Hand drücken, der Erfahrung mit OpenMP/MPI und C/C++ hat. Das ist halt schon was anderes, als sich erst mal mit GPU-Programmierung und deren Eigenarten auseinander zu setzen.

[Gipsel]

Übrigens sind laut dem Die-Foto wirklich nur 62 Kerne physisch vorhanden. Nix mit 64 Kernen und (mindestens) 2 aus Yield-Gründen deaktiviert. Es gibt echt nicht mehr.

[Skysnake]

Und einer ist für spezielle Aufgaben abgestellt (sheduling wird genannt, aber Netzwerk io fällt sicherlich auch darunter) ;)

[Ailuros]

Auf jeden Fall lag Theo nur 4-7x Mal unter den realen MSRPs fuer Phi :D

[Gipsel]

Auf jeden Fall lag Theo nur 4-7x Mal unter den realen MSRPs fuer Phi :DImmerhin hat das Vorzeichen gestimmt, er lag also auf der richtigen Seite der Null. ;D

Zu seiner Verteidigung kann man vielleicht anführen, daß in dem Cluster, zu dem die Aussage kam, Vorserienversionen drinstecken. Die könnte Intel eventuell schon gegen den Selbstkostenpreis oder so rausgerückt haben.

[Ailuros]

Immerhin hat das Vorzeichen gestimmt, er lag also auf der richtigen Seite der Null. ;D

Zu seiner Verteidigung kann man vielleicht anführen, daß in dem Cluster, zu dem die Aussage kam, Vorserienversionen drinstecken. Die könnte Intel eventuell schon gegen den Selbstkostenpreis oder so rausgerückt haben.

Ich kann zwar nicht mit Sicherheit wissen was Intel generell macht in solchen Faellen, aber dass sie so brutal grosse pre-production runs machen wie sie Theo "wissen" will, will ich immer noch ernsthaft bezweifeln.

[Gipsel]

Ich kann zwar nicht mit Sicherheit wissen was Intel generell macht in solchen Faellen, aber dass sie so brutal grosse pre-production runs machen wie sie Theo "wissen" will, will ich immer noch ernsthaft bezweifeln.Intel hat das sogar selber in der Präsentation erwähnt.

[boxleitnerb]

Wäre tragisch und witzig zugleich, wenn die Phis auf mittlere bis lange Sicht GPGPU fast komplett überflüssig machen so wie semiaccurate schreibt. Die Karten sind günstiger, die Programmierer kann man für einen Hungerlohn (relativ gesehen) anheuern...ob das die Zukunft ist? Wäre bitter für Nvidia und AMD, wobei AMD als "Anfänger" in dem Bereich noch sehr glimpflich davonkommen würde.

[Skysnake]

Kommt drauf an, wie gut die Architektur skaliert UND vor allem auch, wie die Konkurrenz reagiert.

Da ist noch gar nichts geschwätzt. Vor allem mit HSA können zumindest die GPUs von AMD einige Nachteile von der Liste streichen.

nVidia seh ich da auf dem wackeligsten Stuhl im Moment sitzen. Die haben zwar ne gute Grundlage, und insbesondere die Software ist ganz gut, aber Sie bekommen halt von allen Seiten druck, und der Ausweg, den Sie haben mit den ARM-Cores dabei, wird sich erst noch zeigen müssen. Auf nVidia rollt halt ein "Tsunamie" zu. Nicht schnell, aber unaufhaltsam. Man muss halt nur immer nen stückchen schneller sein, dann ist das relativ ungefährlich, aber wenn man sich mal ausruht, dannn ist man verloren, und ich frage mich wirklich, ob nVidia das auf Dauer durchhält.

[boxleitnerb]

Was hier auch mit reinspielt ist, ob Intel den Fertigungsvorsprung halten kann, gar ausbauen oder ob er schrumpft. Sie liegen bei der Effizienz trotz 22nm hinten, teilweise sehr weit (SP).

[Skysnake]

Naja, den "Vorsprung" halten werden Sie auf Dauer nicht können. Wie schon mehrfach gesagt. Wir laufen ~2020 in ne Sackgasse, weil es sich dann ausgeshrinkt hat, und genau das könnte dem MIC-Konzept von Intel dann halt am Ende doch das Genick brechen, einfach weil Effizienz >>>> all wird. Wenn du einfach nur noch durch noch mehr Masse schneller werden kannst, dann werden die Entwicklungskosten halt immer kleiner.

AMD hat mit GCN ja auch noch die Möglichkeit in der Hinterhand auf 1:2 SP:DP zu gehen. Das sollte man auch nicht vergessen.

Wie gesagt, da ist noch nichts endgültig entschieden, sondern alle kämpfen verbissen gegeneinander.

[y33H@]

Wieso werden sie ihn nicht halten können? Intel forscht sicherlich an weiteren Straßen und nicht nur an Sackgassen ;-)

[Skysnake]

Klar tun Sie das, aber aktuell ist eigentlich nichts bekannt, was bis zum Ende der Shrinks Silizium ersetzen kann in der Massenproduktion. Stacked Chips usw sind da ja auch "nur Notlösungen" Das Problem and und für sich, das es keine Shrinks mehr gibt, wird dadurch nicht gelöst.

Und mit mehr Chips, hat man zwar mehr DIE-Size, und kann damit niedriger takten, aber das hat auch seine Grenzen, und man verlängert auch die Wege, und gerade das kostet einen ja schon heute viel Power.

Mich würde es ungemein freuen, wenn noch VOR dem Ende der Shrinks eine neue Technologie da wäre, die Silizium ersetzt, aber ich glaub nicht dran. Wir werden auf jeden Fall eine Übergangstechnologie benötigen. Ich bin mir sogar recht sicher, das wir einige Jahre der Stagnation haben werden ~2-10 Jahre, bevor es dann mit neuer Technologie wieder richtig vorwärts geht.

[Ronny145]

Naja, den "Vorsprung" halten werden Sie auf Dauer nicht können. Wie schon mehrfach gesagt. Wir laufen ~2020 in ne Sackgasse


Mal angenommen es stimmt (was ich nicht glaube), was ist mit den 8 Jahren dazwischen? Zählt die nicht? Wie es 2020 aussieht ist doch für heute und in mittelfristiger Zukunft unerheblich. Echt komisches Argument.

[Skysnake]

8 Jahre sind ne verdammt kurze Zeit. Die meisten möglichen Alternativen sind ja wenn überhaupt im Laborstadium, aber nichtmal Kleinserientauglich.

Mal als kleinen Vergleich: Seit wievielen Jahren ist in 20 Jahren die Kernfusion verfügbar?

Es ist ja nicht so, das man einfach weiter macht mit dem wie bisher, sondern sich was GANZ anderes überlegen muss. Zudem geht man eben "einfach" davon aus, das die Prozesse bis 5-7 nm halt einfach funktionieren. Garantieren kann dir das aber keiner.

Wie schonmal gesagt, im wissenschaftlichen Bereich gibts schon genug Leute, die von wissenschaftlichen "Stillstand/Stagnation" sprechen, wenn nicht nahtlos neue Techniken kommen.

Es ist halt nicht so, das man binnen ein oder zwei Jahren ne Fertigung aus dem Labor in der Massenfertigung hat. Vor allem halt nicht in diesen Bereichen. Wir sind halt echt an den Grenzen des physikalisch machbaren.

[Ronny145]

8 Jahre sind verdammt lange im IT Sektor. In der Zeit kommen und gehen so viele neue Generationen. Das mit 2020 geht sich eh nicht aus, also eher 10 Jahre weil sich das bis 5nm nicht strikt im 2 Jahres Rhythmus ausgehen wird. Und wenn Intel vielleicht 2022 bei 5nm angekommen ist, wo liegen die anderen? Dann müssten die erstmal aufschließen was nochmal ein paar zusätzliche Jahre dauern kann. Wir sprechen hier eher über ein Zeitfenster irgendwo zwischen 2022-2025. Es macht absolut null Sinn, die überlegene oder unterlegene Fertigung heute und in den kommenden Jahren mit dem Argument beiseite zu räumen, weil 2020+ irgendwann der Vorsprung angeblich schmilzt. Als ob das AMD und Konsorten heute was bringt. Bis dahin kann Intel mehrere Generation mit einem Fertigungsvorteil auf den Markt bringen.

[Skysnake]

Hier gehts aber nicht vordergründig um IT-Produkte, sondern um Lithographieverfahren bzw. deren Alternativen, und die brauchen eben ganz andere Zeiten, und btw. selbst in der IT hast du lange R&D Zeiten. Nur weil jedes Jahr neue Hardware kommt, heißt das nicht, dass die da nur ein Jahr dran gearbeitet haben. Denk mal eher an 3+ Jahre, bis ein Design wirklich vob Grund auf neu designed ist, und selbst für die kleinen Updates, welche eigentlich nur Detailverbesserungen sind, kannste gut 2 Jahre einplanen.

[fondness]

Mal angenommen es stimmt (was ich nicht glaube),

Da gibt es nichts zu glauben. Wir sind heute beim 22nm Prozess bereits in einem Bereich wo < 100 Atomlagen die Leitungen voneinander isolieren.

[Undertaker]

Hier gehts aber nicht vordergründig um IT-Produkte, sondern um Lithographieverfahren bzw. deren Alternativen, und die brauchen eben ganz andere Zeiten, und btw. selbst in der IT hast du lange R&D Zeiten. Nur weil jedes Jahr neue Hardware kommt, heißt das nicht, dass die da nur ein Jahr dran gearbeitet haben. Denk mal eher an 3+ Jahre, bis ein Design wirklich vob Grund auf neu designed ist, und selbst für die kleinen Updates, welche eigentlich nur Detailverbesserungen sind, kannste gut 2 Jahre einplanen.

Dies bedeutet dann entsprechend, dass sich Intel eben ab 2019-2022 Gedanken machen muss. Auch darüber lohnt es sich imo heute noch nicht zu spekulieren. :wink:

[Skysnake]

Warum?

Schau dir XeonPhi an. Wie lange hat es gedauert, bis Sie von Larrabee zur Marktreife gekommen sind?

Und das grundlegende "Problem" ist halt schon noch da, das XeonPhi zwar effizienter ist als normale CPUs, aber je nach Aufgabe aber halt nicht an GPUs heranreicht, und das TROTZ dem Fertigungsvorsprung. Da muss sich Intel halt noch ziemlich heftig auf den Hosenboden setzen und dran arbeiten das Problem zu lösen, denn das Problem ist alles nur nicht trivial.

Wobei ein paar triviale Möglichkeiten gibt es schon, nur leider hat die Konkurrenz die gleichen Ideen ;D

[Ronny145]

Hier gehts aber nicht vordergründig um IT-Produkte, sondern um Lithographieverfahren bzw. deren Alternativen, und die brauchen eben ganz andere Zeiten, und btw. selbst in der IT hast du lange R&D Zeiten. Nur weil jedes Jahr neue Hardware kommt, heißt das nicht, dass die da nur ein Jahr dran gearbeitet haben. Denk mal eher an 3+ Jahre, bis ein Design wirklich vob Grund auf neu designed ist, und selbst für die kleinen Updates, welche eigentlich nur Detailverbesserungen sind, kannste gut 2 Jahre einplanen.


Es geht letztlich um kaufbare Produkte, die im jeweiligen Prozess gefertigt werden. Und 10 Jahre sind verdammt lange ob du es glaubst oder nicht. Bis 2022-2025 kann so viel passieren. Das ist ein Zeitrahmen, der es nicht wert ist diskutiert zu werden. Selbst die größten AMD Fanboys reden sich den Fertigungsrückstand nicht schön, indem sie 10 Jahre absitzen oder einfach ignorieren wollen. Die reden sich das anders schön. Mittelfristig dürfte der Abstand eher steigen, das hätte schon eher eine Relevanz.

Da gibt es nichts zu glauben. Wir sind heute beim 22nm Prozess bereits in einem Bereich wo < 100 Atomlagen die Leitungen voneinander isolieren.


Natürlich gibt es das. Niemand kann heute sagen, wann 5nm erreicht werden. Die 8 Jahre halte ich schonmal viel zu optimistisch und deswegen glaube ich nicht, dass es 2020 schmilzt.

[Ailuros]

Es wagen nichtmal waschreine hw engineers ueber ein halbes Jahrzehnt zu spekulieren. Die Problematik der heutigen Herstellungsprozesse ist bekannt und wie es alle IHVs und alle foundries in der weniger absehbaren Zukunft loesen werden bleibt abzusehen.

Dass Phi fuer 3D nichts besonderes taugt ist kein Geheimnis mehr. Die eigentliche Frage IMO ist dann eher ob es fuer Intel wirklich der Rede wert waere eine high end GPU neben HPC auch fuer high end 3D zu entwickeln. Fuer HPC sind sie momentan gut angelegt und in der absehbaren Zukunft koennten sie damit durchaus noch konkurrenzfaehiger werden.

Sonst bedient Intel mit ihren SoC von small form factor bis zu notebook/PC SoCs. Je groesser die letzteren werden mit der Zeit desto mehr koennte Intel's Marktanteil zuwachsen. Wenn sie jetzt nie an standalone >mainstream GPUs je auf den Markt bringen ist unter den heutigen Bedingungen wohl kein besonderer Kopfschmerz mehr. Kopfschmerzen duerfte ihnen eher langfristig small form factor machen, da sie eben nicht gegen ARM als CPU IP provider konkurrieren sondern all die anderen semiconductor Hersteller die solche IP benutzen, ist aber auch ein ganz anderes Kapitel.

Das einzige was die Phi Nachfolger wirklich brauchen IMHO ist eine bessere perf/W, was mir aber gerade bei Intel und ihren Herstellungsprozessen keine besondere Sorge macht. Ueberhaupt wenn Intel ihre Prozesse fuer GPUs generell besser anpasst.

[Coda]

Die Shot:
http://semiaccurate.com/assets/uploads/2012/11/XeonPhiDie_02.jpg

Ich glaube ich sehe 8 (Quad?)-TMUs. Und es sind tatsächlich nur 62 Cores.

[ndrs]

TMUs? Ich dachte Phi hat keine Grafikfähigkeiten mehr.

[Hübie]

Ja hab auch schon gezählt. Da hatte man uns wohl früher mit alten shots gelumpt. Eine Menge Caches und ein fetter Memorybus fallen besonders auf. Was dieses Gewölbe links und rechts ist leuchtet mir nur nicht ein :redface:

Mal was anderes: Mir fiel nun mal so auf dass immer öfter Giga-Transfers als "Größenordnung" angegeben werden. Ist das im Prinzip die Taktflanke auf der Daten übertragen werden? Also bei 5.5 GT/s = 5.5 GHz.

Was mich stutzig macht: Xeon Phi 5110P, 61 Kerne und 225 Watt TDP. Die 3100er <61 Kerne und dann aber 300 Watt TDP. Da schraubt jemand offenbar ordentlich am Takt, nur frage ich mich wo da der Vorteil liegt wenn die Bandbreite gleichzeitig so schrumpft? Einfach nur Pres-/Leistung?

[Ailuros]

Die Shot:
http://semiaccurate.com/assets/uploads/2012/11/XeonPhiDie_02.jpg

Ich glaube ich sehe 8 (Quad?)-TMUs. Und es sind tatsächlich nur 62 Cores.

Ich erlaube mir mal den OT Scherz: jedesmal wenn ich den die shot sehe erinnert es mich an Unlimited Detail :biggrin:

[Skysnake]

Ja hab auch schon gezählt. Da hatte man uns wohl früher mit alten shots gelumpt. Eine Menge Caches und ein fetter Memorybus fallen besonders auf. Was dieses Gewölbe links und rechts ist leuchtet mir nur nicht ein :redface:

Das sollte eigentlich "relativ" einfach sein, zumindest fällt mir nichts anderes ein.

Das sollten "schlicht" Crossbars sein. Halt ziemlich heftige Crossbars, die halt eine komplette parallele Durchschaltung erlauben.

Warum die Dinger so fett ausfallen erschließt sich mir zwar nicht, da man ja eigentlich "nur" die Hops des Ringbuffers bedienen sollte, aber ok.

Eentuell ist es aber eben auch genau das. Man kontaktiert die Ringbuffer per Crossbar durch, damit jeder Hop des Ringbuffers auf den kompletten Teil des auf seiner Seite befindlichen Speichercontrollers zugreifen kann.

Damit ließe sich halt "Speichercontroller" virtualisierung betreiben usw.

Was besseres fällt mir dazu zumindest nicht ein, was irgendwie Sinn machen würde.
Mit den Crossbars bin ich mir auf jeden Fall ziemlich sicher.


Mal was anderes: Mir fiel nun mal so auf dass immer öfter Giga-Transfers als "Größenordnung" angegeben werden. Ist das im Prinzip die Taktflanke auf der Daten übertragen werden? Also bei 5.5 GT/s = 5.5 GHz.

Ähm wenn ich es gerade im Kopf habe "praktisch" ja. Das Problem ist halt, das man Pakete hat, und keine "Signale". Also in Paketen wird eben Information übertragen, und damit kann man eben variable Busbreiten haben. Daher macht GT/s mehr Sinn als GHz, da man eben besser vergleichen kann.


Was mich stutzig macht: Xeon Phi 5110P, 61 Kerne und 225 Watt TDP. Die 3100er <61 Kerne und dann aber 300 Watt TDP. Da schraubt jemand offenbar ordentlich am Takt, nur frage ich mich wo da der Vorteil liegt wenn die Bandbreite gleichzeitig so schrumpft? Einfach nur Pres-/Leistung?
Ja, macht mich durchaus auch stutzig. Je nachdem wird da aber halt am Binning gedreht, oder eben Taktraten angehoben von Caches usw.

[Ailuros]

http://www.anandtech.com/show/6451/the-xeon-phi-at-work-at-tacc

[Coda]

TMUs? Ich dachte Phi hat keine Grafikfähigkeiten mehr.
Könnten auch die GDDR-Controller sein.

[Skysnake]

Ja macht durchaus Sinn, wenn man Ailuros Anandtech link sich anschaut mit dem Blockbild.

Da sind die GDDR-Controller mit in den Ringbuffer integiert, aber eben als 2er Blöcke.

Ich würde, auch aus Gründen zum Speicherinterface die Bereiche, die ich als Crossbars bezeichnet habe, als GDDR-Controller bezeichnen. Das macht auch durchaus sinn, denn Crossbar+GDDR-Controller würde dann von der Größe her auch deutlich besser passen. Insgesamt sind die Dinger aber noch immer ziemlich gewaltig.

Deswegen tippe ich auch am ehesten auf nen richtig fetten Crossbar, der eben jedwede Permutation zulässt, innerhalb eines 256 (eher nicht 128) Bit Blocks zulässt. Mindestens aber 64Bit Permutationen, so könnte man jeweils 1/8 einer Cacheline getrennt auslesen, oder eben eine Cacheline auf einen rutsch. Kommt halt dann immer drauf an, wie die Daten abgelegt wurden. Intel sollte da aber doch einiges an Logik reinstecken, um den Writeaufwand möglichst gering zu halten. eine 64 Bit Unterteilung wäre da durchaus sinnvoll, da man so jeweils ein Double einer Cacheline schreiben könnte, also im Optimalfall halt in einer Cacheline nur den Wert, der sich auch wirklich geändert hat.

[SavageX]

http://www.anandtech.com/show/6451/the-xeon-phi-at-work-at-tacc

Each of these cores is a 64-bit x86 core. However, only 2% of the core logic (excluding the L2-cache) is spent on x86 logic. The SIMD unit does not support MMX, SSE or AVX: the Xeon Phi has its own vector format.

Dumme Frage, ist das Ding ohne SSE(2) allen Ernstes x86-64 kompatibel? Dort wäre ja SSE2 eigentlich "das Mindeste", was man erwarten könnte.

[Hübie]

Äh. SSE2 hat nur doppelte Genauigkeit (2*32 bit) für floatingpoint operanden eingeführt. Das hat mit den 64-Bit Registern von x86-64 wenig zu tun oder bin ich nun auf dem Holzweg? :|

[Acid-Beatz]

Ich glaube es ist sogar so, dass im 64 Bit Modus unter Windows komplett auf SSE2 verzichtet wurde was auch der Grund war, warum die ersten Meroms unter 64 Bit langsamer waren als unter 32 Bit.


Greez

[Hübie]

Könnten auch die GDDR-Controller sein.

Das ist dann aber schon ziemlich "fett" wie skysnake schon sagte. Nun ist der shot aber auch zu grob um da mehr herauszulesen also warte ich mal lieber. Selbst wenn dass Mem-Controller+Crossbar sind fänd ich das schon sehr dicke...

Wieviel mm² hat der Die?

Edit: Danke für die Erklärung bzgl. Giga-Transfers.

[Gipsel]

Dumme Frage, ist das Ding ohne SSE(2) allen Ernstes x86-64 kompatibel? Dort wäre ja SSE2 eigentlich "das Mindeste", was man erwarten könnte.
Offiziell ist es nicht komplett x86-64, aber auch nicht so weit weg.
Äh. SSE2 hat nur doppelte Genauigkeit (2*32 bit) für floatingpoint operanden eingeführt. Das hat mit den 64-Bit Registern von x86-64 wenig zu tun oder bin ich nun auf dem Holzweg? :|
Ja bist Du. x86-64 erfordert SSE2-Support (64Bit Floating Point Operationen in den XMM Registern).
Ich glaube es ist sogar so, dass im 64 Bit Modus unter Windows komplett auf SSE2 verzichtet wurde was auch der Grund war, warum die ersten Meroms unter 64 Bit langsamer waren als unter 32 Bit.Andersrum wird eher ein Schuh draus. Die Nutzung der x87-FPU im 64Bit-Modus kann vom Betriebssystem abhängig sein (das OS ist nicht unbedingt verpflichtet, den x87-State bei einem Threadwechsel zu sichern bzw. wieder herzustellen). Im Kernel-Mode (z.B. Treiber) sind x87-Instruktionen bei allen 64Bit Windows-Versionen explizit verboten (es funktioniert aber problemlos im User-Mode, sprich für alle normalen Programme). Typischerweise erzeugen allerdings die meisten 64Bit Compiler automatisch SSE2-Code, keinen x87er-Code.

Edit:
Bei MS findet sich das (http://msdn.microsoft.com/en-us/library/windows/hardware/ff545910(v=vs.85).aspx):
In 64-bit versions of Windows, the operating system preserves the MMX/x87 registers across thread (and process) switches. However, there is no explicit calling convention for the MMX/x87 registers. Code that is produced by the 64-bit compiler for x64 processors does not use these registers and does not preserve them across function calls.
The use of the MMX/x87 registers is strictly prohibited in 64-bit kernel-mode code. Typically, this restriction affects only assembly-language programmers. The 64-bit compiler for x64 processors automatically converts floating-point operations to SSE instructions.

[y33H@]

Ausführliches Datenblatt - via Skysnake (http://extreme.pcgameshardware.de/user-news/251275-intel-veroeffentlicht-ausfuehrliches-hardwaredokument-zu-xeonphi-mic.html).

https://www-ssl.intel.com/content/dam/www/public/us/en/documents/product-briefs/xeon-phi-datasheet.pdf

[Skysnake]

Thx für die Blumen :D

[Hübie]

Keine Frequenzangaben. Merkwürdig. Aber wenigstens nicht so ein marketing "whitepaper" alá nVidia ;D

[Ailuros]

Keine Frequenzangaben. Merkwürdig. Aber wenigstens nicht so ein marketing "whitepaper" alá nVidia ;D

Undankbare Users ts ts ts :rolleyes:

Wie sieht's damit aus?

http://software.intel.com/sites/default/files/article/334766/intel-xeon-phi-systemsoftwaredevelopersguide.pdf

[Skysnake]

;D

Hat das auch endlich mal jemand gefunden ;D

[Ailuros]

;D

Hat das auch endlich mal jemand gefunden ;D

Ich selber auf jeden Fall nicht. Nur bekomm ich von meinen Freunden Schokoladen und keine Blumen :P

[Hübie]

Undankbare Users ts ts ts :rolleyes:

Wie sieht's damit aus?

http://software.intel.com/sites/default/files/article/334766/intel-xeon-phi-systemsoftwaredevelopersguide.pdf

Nope. Da steht nur dass es bei 600 MHz losgeht. Interessant fand ich aber dass keine PCU vorhanden ist. Alles wird vom onboard OS gesteuert. Die Sensoren melden was Sache ist und dann wird alles reguliert. Das bedeutet man kann dass Ding auch mal in den Tod fahren wenn mans falsch angeht :freak:
Muss Intel aber echt mal loben: Die Dokumentationen sind schon sehr geil. Kann sich nVidia ne Scheibe von abschneiden :rolleyes:

[Coda]

Das bedeutet man kann dass Ding auch mal in den Tod fahren wenn mans falsch angeht :freak:
Das glaub ich kaum. Da wird schon noch eine Temperatur-Diode sein, die notfalls ausmacht.

[Hübie]

Ja aber das kannst halt umgehen. Ist aber so als ob du Selbstmord begehst ;D Das throttle-Signal wird gesendet aber du kannst es ja ignorieren. 61 Kerne dynamisch rauf- und runtertakten ist sicher schon eine recht aufwändige Rechenoperation. Vielleicht wird ja doch ein Kern dafür "geopfert"? Muss mir bei Zeiten mal dass Whitpaper durchlesen.

[Coda]

Ja aber das kannst halt umgehen.
Nö. Sowas implementiert man in Hardware.

[Hübie]

Die Überwachung ist auch in Hardware aber die interpretation liegt beim onboard OS. Steht im whitepaper ;)

[Coda]

Nein, die Fan Control ist im OS. Das ist etwas völlig anderes als eine Not-Komplett-Abschaltung des Chips bei Überhitzung. Sorry, aber sowas ist bei Intel schon seit PIII-Zeiten Standard und auch völlig trivial zu bauen, wenn man die Dioden sowieso hat.

[Hübie]

Ja, hab eben noch mal genau nachgelesen. Es gibt ein Modul welches die P-States automatisch selektiert. Beim ersten überfliegen sah es so aus als ob es ins OS integriert wäre weil vermerkt wurde dass keine PCU vorhanden ist. Seite 67 & 68 beschreiben dass genauer.

[Skysnake]

Sehr lustig:

Charlie will mal wieder Geld machen, und steht auf dem Schlauch:http://semiaccurate.com/2013/04/04/why-is-intel-so-secretive-about-phis-die/

Nur so zum Spaß:
http://extreme.pcgameshardware.de/user-news/251275-intel-veroeffentlicht-ausfuehrliches-hardwaredokument-zu-xeonphi-mic.html

;D

Man das ist heute einfach ein guter Tag :biggrin:

[Ronny145]

Zeigt doch wieder nur deutlich auf, dass der Clown nicht ernzunehmen ist. So verpeilt wie Charlie kann man nicht sein, der ist eher gezwungen abstruse Geschichten für seine Bezahlartikel zu erfinden. Dem kannst du das datsheet schicken, jucken wird dem das nicht die Bohne.

[Coda]

Er sagte, dass man die die size nicht kennt und die wird in dem Dokument halt auch nicht erwähnt.

[Skysnake]

Naja, schaumer mal, in "nicht mal" mehr 30 Tagen wissen wir es. Er wird aber wohl kaum ein Bild ohne IHS, also nur vom DIE haben. Zumindest lässt der Anfang dies nicht vermuten.

[Ronny145]

http://www.cpu-world.com/news_2013/2013051001_Specifications_of_upcoming_Xeon_Phi_co-processors.html


Refresh kommt bald.

[Ronny145]

http://www.computerbase.de/news/2013-06/neue-xeon-phi-und-ausblick-auf-14-nm-ableger-von-intel/
http://www.pcgameshardware.de/Xeon-Phi-Hardware-256199/News/Intel-Xeon-Phi-Knights-Landing-14-nm-1074730/


Jetzt offiziell angekündigt. Danach folgt Knights Landing in 14nm.

[Skysnake]

Hihi, das passt sogar, aber nicht so wie du denkst ;)

Ihr seht den Wald vor lauter Bäumen mal wieder nicht :tongue:

[ndrs]

Ich übersetze das mal.
Hier ich, ich weiß was. Ich sag's euch aber nicht, weil ich so besser wie der Super-Insider rüberkomme :tongue:
Findest du das nicht etwas kindisch?

[StefanV]

Hab mirs mal angeschaut.

Was mir aufgefallen ist, in dem Dokument von Ail:
GDDR ist Mist,
"Periphery connected solution will run into pin count issues"

Dazu noch irgendwelche Myten:
1. GP Prozessoren sind dof, man braucht SP Prozessoren
2. Single Thread Performance und Legacy Features sind doof
3. IA Memory Model, Cache coherence doof
4. Caches sind doof, verschwenden Energie

Dann steht da noch was von Speicher Die auf Logik Die kleben...

Und dass das irgendwie ohne PCIe funzen soll...

[Skysnake]

@ndrs:
1. "Ein bischen Spaß muss sein"
und
2. sei doch froh, das ich nen Wink mit dem Zaunpfahl geb. Zu dem Thema habe ich schon vor einiger Zeit was gepostet/angedeutet, aber seis drum.

Wie würdest du denn nen Rechner bauen, mit so nem KNL?

Denk mal drüber nach. Vielleicht kommt dir das Konzept ja bekannt vor. :tongue:

@StefanV
Ja da sind dir einige Sachen aufgefallen, wobei ich darauf eigentlich gar nicht raus wollte.

Wenn man sich das mit dem "Near Memory" und dem "Logic-DIE" anschaut, dann kommt einem das doch verdammt bekannt vor nicht? ;)


HMC nicht wahr ;)


Die "Mythen" sind eh der Knaller. Da fragt man sich doch echt, was der Ersteller geraucht hat. Wer kommt denn bitte auf die Idee, das Caches nichts bringen in HPC :freak:

Und das mit GPU vs. CPU ist ja auch mal ähmm.. ja. MIC zieht ja auch gar nicht einen wesentlichen Teil aus extrem breiten Registern. Nein wie komm ich denn nur darauf :freak:

GPUs und CPUs nähern sich immer mehr an, bzw verschmelzen. Nur die Ausganspunkte sind unterschiedliche..

[Ailuros]

Hihi, das passt sogar, aber nicht so wie du denkst ;)

Ihr seht den Wald vor lauter Bäumen mal wieder nicht :tongue:

Ich sehe in der Praesentation lediglich stinknormale Radieschen, von einem Baum (und schon gar nicht einem Wald) keine Rede.

Sonst klingt mir mit Verlaub Knights Landing immer noch nach jack of all trades master of none. Eine sehr konkurrrenzfaehige HPC Loesung? Ja; aber danach auch die Sintflut.

[StefanV]

Naja, aber dass der ganze x86 Kram 'nur' 6% Verlustlesitung haben soll, ist auch nicht ohne.

Bei 250W wären das immerhin ~16W...

[ndrs]

2. sei doch froh, das ich nen Wink mit dem Zaunpfahl geb.
Ein Wink mit dem Zaunsphafl wäre eine angedeutete Info. In deinem Post steckt aber Null-Info, lediglich ein großer Klugschiss.
Ich find's nur reichlich herablassend, zu meinen, dass man andere zum Denken anregen muss. Dann doch lieber garnichts posten.
Zu dem Thema habe ich schon vor einiger Zeit was gepostet/angedeutet, aber seis drum.

Wie würdest du denn nen Rechner bauen, mit so nem KNL?

Ich weiß und ich bin mir ziemlich sicher damals selber drauf geantwortet zu haben.

Sorry, falls das etwas OT war. Ich werd nicht weiter drauf rumhacken, aber der ein oder andere ist sicher meiner Meinung.

[Skysnake]

So, ich hab doch tatsächich nen Link interessanten Link gefunden.

http://www.deep-project.eu/deep-project/EN/Project/Hardware/Autumn_2013_Hardware_Bring_up.html?nn=1115832

Findet noch jemand die Ankündigung bzgl KNL auf einmal gar nicht mehr so spannend? ;)

[Ailuros]

Werde ich jetzt gesteinigt wenn ich sage dass mir Knights Landing nach nichts anderem klingt als Larabee mit einem fetten Batzen Schminke? :weg:

[ndrs]

Naja, was außer der üblichen Evolution hast du denn erwartet?

Das einzig spannende scheint mir die selber die Verwendung von stacked-RAM als monströser LLC zu sein. Der Rest ist einfach nur logische Konsequenz aus dem was schon da ist.

[Skysnake]

Werde ich jetzt gesteinigt wenn ich sage dass mir Knights Landing nach nichts anderem klingt als Larabee mit einem fetten Batzen Schminke? :weg:
Jaein.

Also an sich ja, weil das Grundkonzept soweit ich das überblicken kann unverändert bleibt. Andererseits aber auch NEIN! weil man so manche Pferdefuß mit dem neuen CPU-Core umgeht.

KNC unterstützt z.B. kein sfence und noch einige andere Sachen sind nicht wirklich soo cool. Zudem schmerzt der fehlende SSE-Support aktuell noch ziemlich heftig.

Das wird mit dem Umstieg auf AVX schon sehr viel angenehmer.

Ganz abgesehen davon ist der nearMemory ne sehr coole Sache. Aber an sich eigentlich auch "nur" ein logischer Schritt. Es war an sich absehbar.

Intel geht halt konsequent den Weg weiter, den ich schon vor einiger Zeit aufgezeigt habe. Zumindest im HPC-Bereich werden Knoten nicht mehr so aussehen wie wir das heute kennen. Also als quasi klassische Workstation PCs.

Man kann sich einfach nicht mehr leisten auf nur irgendwas unnützes mit rum zu schleppen.

Schau dir mal KNL an. Wenn du das konsequent durchziehst, dann ist eine Karte ein kompletter Knoten.

[Hugo78]

Wie ist das jetzt?

KNL soll anfang 2015 in 14nm + FinFET kommen bei 225-300W (?!) TDP mit 3TFLOPs DP, oder?
Klingt für mich jetzt nicht so spannend, wenn man auch 2,5 - 3 TFLOP DP vom Big Maxwell ende 2014 in 20nm ohne FinFET @ 225W/235W erwarten darf.

Allein lauffähig wird Big Maxwell dank ARM Cores wohl auch sein, also hält KNL auch nur wieder mit,
dank Fertigungsvorteil und (mittlerweile völligem ?!) Verzicht auf GPU-Fähigkeiten oder überseh ich da grad was?!

[Skysnake]

Du hast einen x86 Cluster on a Chip mit KNL. Du brauchst nur noch irgendwas, was dir die Anbindung zur Karte bringt. Das wars dann. Das ist ein EXTREM schlanker Rechnerknoten ;)

Ansonsten gibt es natürlich noch extreme Unterschiede beim RAM. Maxwell sollte noch keinen Near-Memory haben, und halt massig weniger.

Naja, und ob das Ding wirklich allein läuft ist halt auch noch so ne Sache bei Maxwell. Von Project Denver hat man ja nichts mehr gehört aus Barcelona, und von nVidia auch nicht.

Und selbst wenn das Ding alleine läuft, müsste man erstmal nen Linux drauf porten und ne Platform haben. Da muss nVidia noch richtig richtig richtig viel Arbeit rein stecken. Selbst Intel hat das nicht mal eben so gemacht...

KNL/XeonPhi kannst du als Entwickler im Prinzip vom Verhalten her nicht mehr von nem normalen Clusterknoten unterscheiden. Das ist schon irgendwie SEHR cool! Vor allem das Debuggen von Programmen geht halt um Welten schneller und einfacher als mit OpenCL oder CUDA.

Und aus was besteht das Ding noch groß?

XeonPhi+PCB inkl RAM, und dann noch ne Backplane für PCI-E und ne Netzwerkkarte. Das wars, wobei du theoretisch auch alles drei auf ein PCB packen könntest. Das Ding wäre maximal so groß wie nen 1U half size MB, mit fast nichts drauf, was unnötig ist und eben Energie frisst.

[Hugo78]

Ok, die leichtere Programmierbarkeit war ja schon immer der Pluspunkt.

Und selbst wenn das Ding alleine läuft, müsste man erstmal nen Linux drauf porten und ne Platform haben. Da muss nVidia noch richtig richtig richtig viel Arbeit rein stecken. Selbst Intel hat das nicht mal eben so gemacht...

Das Problem ist doch schon abgehakt.
Linux unterstützt ARM Cores ab ARMv5 IIRC und CPU-seitig setzt sich NV selber,
mit Linux spätestens seit den ersten Tegra Gehversuchen auseinander.
- https://developer.nvidia.com/linux-tegra

[Skysnake]

Achso, CUDA ist auf ARM schon portiert?

CULIB ist auf ARM portiert?

Die Myrinet und schlag mich tot Treiber sind schon auf Arm portiert?

Nur weil Linux an sich auf einem ARM läuft, heist das noch lange nicht, dass das auch mit dem Ding läuft, das nVidia da bringen will. Die Tücke steckt da im Detail....

Wenn das Ding keinen PCI-E Rootport hat, wirds auch interessant usw usw usw

So lange das kein 100% vollwertige CPU ist, läuft da nicht so einfach ARM drauf. Allein schon das Memory-Management muss man sich mal anschauen. Wird ja sicherlich über einen RAM-Controller gehen usw usw.

Dann wirste auch keine HDD usw haben. Du musst also über Netzwerk booten usw. Kurz um, was ich sagen will ist, nVidia muss da trotzdem noch Hand anlegen, wobei Sie sicherlich aus Tegra einiges übernehmen können. Aber gerade CUDA müssen Sie halt trotzdem noch nach ARM portieren.

[Ailuros]

Jaein.

Also an sich ja, weil das Grundkonzept soweit ich das überblicken kann unverändert bleibt. Andererseits aber auch NEIN! weil man so manche Pferdefuß mit dem neuen CPU-Core umgeht.

KNC unterstützt z.B. kein sfence und noch einige andere Sachen sind nicht wirklich soo cool. Zudem schmerzt der fehlende SSE-Support aktuell noch ziemlich heftig.

Das wird mit dem Umstieg auf AVX schon sehr viel angenehmer.

Ganz abgesehen davon ist der nearMemory ne sehr coole Sache. Aber an sich eigentlich auch "nur" ein logischer Schritt. Es war an sich absehbar.

Intel geht halt konsequent den Weg weiter, den ich schon vor einiger Zeit aufgezeigt habe. Zumindest im HPC-Bereich werden Knoten nicht mehr so aussehen wie wir das heute kennen. Also als quasi klassische Workstation PCs.

Man kann sich einfach nicht mehr leisten auf nur irgendwas unnützes mit rum zu schleppen.

Schau dir mal KNL an. Wenn du das konsequent durchziehst, dann ist eine Karte ein kompletter Knoten.

Kommt natuerlich drauf an was man genau unter "fetter Schminke" versteht. ndrs hat schon verstanden was ich meinte.

Sonst fuer den restlichen Kaese der leichteren Programmierbarkeit wurde das Thema so oder so schon etliche Male durchgeknetet in der Vergangenheit; wenn aber Intel nicht ihren Arsch geruehrt hat fuer bessere DP FLOPs/Watt hilft es alles nicht besonders viel, denn fuer NV duerfte es kein besonderes Problem sein zumindest 3TFLOPs bei 225W TDP zu erreichen wenn nicht sogar mehr zu dem Zeitpunkt.

[Hugo78]

Achso, CUDA ist auf ARM schon portiert?

CUDA for ARM
http://devblogs.nvidia.com/parallelforall/cuda-arm-platforms-now-available/

[Skysnake]

Durchaus, nur musst du auf einen Knoten als Ganzes schauen. nVidia wird es da schwer haben, mit KNL zu konkurrieren. Ein KNL-Knoten besteht einfach aus fast nichts mehr, und Intels Fähigkeiten und Kenntnisse bzgl Compiler sollte man nicht unterschätzen.

Bereits heute ist es ein einziger simpler Parameter bei compileraufruf um für KNC zu compilieren. Bringt einem halt nur nich sooo viel, weil das Ding halt kein SSE, sfence usw kann. Wenn normale CPU und KNL aber die gleiche AVX Version beherrschen, bzw. KNL halt einfach nur mehr, dann wirds halt echt übel.

Intel zeigt da einen ziemlich harten Weg auf. Wenn man konsequent alles umsetzt, was Sie im Prinzip anfangen, kommen die nächsten Cluster zu 100% von Intel. Die integrieren einfach alles. Interconnect, RAM usw. Dazu noch die überlegene Fertigung. Da wird es echt schwer mit zu konkurrieren.

Und ja, die Aussicht macht mir ziemliche Bauchschmerzen...

@Hugo:
Ach ja stimmt, an das Ding hatte ich gar nicht mehr gedacht :up:

Ja, dann siehts besser aus. Bleiben aber noch immer genug Baustellen über. Die "0815" CPU-Libs für HPC sind halt x86 LIBs. Die müsste nVidia erstmal für ARM/CUDA portieren. Das wird alles noch ein haufen Arbeit.

[Ailuros]

Ach ja stimmt, an das Ding hatte ich gar nicht mehr gedacht :up:

Ja, dann siehts besser aus. Bleiben aber noch immer genug Baustellen über. Die "0815" CPU-Libs für HPC sind halt x86 LIBs. Die müsste nVidia erstmal für ARM/CUDA portieren. Das wird alles noch ein haufen Arbeit.

Ist doch eine absolute Notwendigkeit; wie sonst sollen sie ab Tegra5/Logan CUDA genau benutzen? Obwohl eine anstaendigere OCL Unterstuetzung eine um zich Mal bessere Idee waere, ist aber OT zum Thema hier.

[AnarchX]

Knights Landing: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10009485#post10009485

[=Floi=]

http://www.computerbase.de/2015-01/intel-xeon-phi-31s1p-fuer-125-statt-1.991-us-dollar/

gibt es dafür irgendwelche nütliche software für consumer?
wollen die mit dieser preisaktion marktanteile vergrößern?

[Nightspider]

Würde es Software zum encodieren geben für 4K und h.265 würde ich mir so ein Teil in meinen gamingrechner stecken. ;D

[Ailuros]

http://www.computerbase.de/2015-01/intel-xeon-phi-31s1p-fuer-125-statt-1.991-us-dollar/

gibt es dafür irgendwelche nütliche software für consumer?
wollen die mit dieser preisaktion marktanteile vergrößern?

Ja zum letzten.

[Loeschzwerg]

Kann ja jemand als Hobbyprojekt Outcast 1.1 darauf portieren :D

[Naitsabes]

Marktanteil vergrößern, Marketing, Lagerbestände abbauen.

Das werden wohl die Hauptgründe sein.


edit. habe nicht gesehen, dass es bereits eine Seite weiter ging -.-

[Coda]

Kann ja jemand als Hobbyprojekt Outcast 1.1 darauf portieren :D
Da müsste erst mal jemand das Multithreading überhaupt halbwegs gut skalierbar machen. Im Moment macht es fast nichts.

[Sunrise]

Würde es Software zum encodieren geben für 4K und h.265 würde ich mir so ein Teil in meinen gamingrechner stecken. ;D
Laut Dark Shikari ist das Ding zumindest für x264 und speziell angepasstem SIMD-Code dafür nicht zu gebrauchen. Das war damals für Core 2 ein Vergleich. Und schon damals stank das Teil ab.

Hatte mich ehrlich gesagt auch etwas überrascht.