News Xeon Phi „Knights Landing“ mit 72 Kernen und On-Package DRAM

[Krautmaster]

Ich glaube Intel kann das besser bewerten als du ob das Sinn macht oder nicht.

da wäre ich mir nicht so sicher, SMT4 bei so schwachen kernen wird nicht viel bewirken, wenn es kaum ressourcen gibt bringt auch ein lückenfüller nix!

da bin ich mir sogar ziemlich sicher, ziemlich also quasi ganz sicher, ja doch, relativ sicher

Bei dem Intel Monster geht es ja weniger um maximale DP Leistung, viel eher darum diese auch wirtschaftlich und vergleichsweise einfach abrufen zu können. Wer spezielle, sehr spezielle Szenarien hochoptimieren kann ist mit ner reinen klassischen GPU meist besser beraten. Schau dir 5D bei der HD5850 an, die haut heute noch was Crunchen und Mining angeht Hawaii in die Pfanne, gerade auch bei / Transistor Leistung. Weils eben perfekt auf die Architektur gepasst hat...

Nai hat das super erklärt. Viele Szenarien passen auf PHI weit besser als auf eine GPU die ebenfalls zunehmend breiter aufgestellt wird. Es ist immer Frage der Anwendung... die Systeme als solche nur schwer vergleichbar.

Auf dem PHI sollte man vergleichsweise einfach Windows / Linux booten können... versuch das mal auf Hawaii. Geht sicher... nur mit welchem Aufwand.

 

[Fred_der_Finger]

Mal entgegen der ganzen Konversation auf hohem Niveau, was Kostet denn eigentlich so ein Ding!?

 

[Simon]

Die aktuellen Phis gehen für 1.700 bis 4.300 US-Dollar (bei Abnahme von 1.000 Stück) über die Ladentheke.

http://files.shareholder.com/downlo...ne_02_14_Recommended_Customer_Price_List_.pdf

Da viele Phis jedoch in Großprojekten (Super Computer) zum Einsatz kommen, dürfte der reale Verkaufspreis i.d.R. deutlich darunter liegen.

 

[Volker]

Artikel-Update: Gegenüber EETimes bestätigte Micron die Nutzung von Hybrid Memory Cube für Intels „Knights Landing“. Der Speicher wird laut Micron dabei so schnell und für Programmierer dennoch einfach zu adressieren sein, dass er quasi als bis zu 16 GByte großer L3-Cache gesehen werden kann.

 

[yummycandy]

Mal eine Laienfrage, ist der Phi so einfach zu programmieren wie eine ultraparallele x86 SMT-Umgebung? Oder hat die Architektur damit nicht mehr viel zu tun?

 

[Nai]

da wäre ich mir nicht so sicher, SMT4 bei so schwachen kernen wird nicht viel bewirken, wenn es kaum ressourcen gibt bringt auch ein lückenfüller nix!

Ich glaube eher anders herum wird ein Schuh draus:
Eben weil sie so einfach sind, brauchen sie es

Zwei Probleme die einem den Tag versauen und einem von der Peak-Performance abbringen können sind die inhomogene Auslastung der Hardware und Latenzen. Latenzen entstehen nicht nur durch Speicherzugriffe, sondern auch durch arithmetische Operationen, da es ne Zeitlang dauert, bis das Rechenergebnis wieder zur Verfügung steht. Während aritmetische Latenzen afaik <=30 Takte benötigen, so benötigt ein Speicherzugriff auf dem DRAM 600-1000 Takte. Wenn man nun auf einen kompletten Speicherzugriff warten muss, so könnte man in dieser Zeit ebenfalls 600 bis 1000 Rechenoperationen durchführen! Die inhomogene Auslastung entsteht dadurch, dass ein Prozessor viel Spezialhardware wie eine FPU oder eine ALU enthält. Ein Thread führt aber mal ne FPU mal ne ALU Instruktion aus, wodurch jeweils die FPU oder die ALU untätig ist und die Auslastung erniedrigt wird. Deshalb ist es wichtig diese Latenzen irgendwie zu überbrücken und die inhomogene Auslastung zu vermeiden. Moderne Prozessoren verwenden dafür hauptsächlich Ansätze, welche ihre Single-Threaded-Leistung erhöhen, wie eine komplexe Out-Of-Order Pipeline oder Sprungvorhersagen. Diese gesamte Kontrolllogik kostet jedoch relativ viel Chip-Fläche. Deshalb verwendet man bei Parallelrechnern wie dem PHI primär den Ansatz des breiteren Hardware-Multithreadings um die Latenzen zu überbrücken, da dies weniger Chip-Fläche benötigt. So hat laut http://www.cac.cornell.edu/education/training/StampedeJune2013/mic-130618.pdf PHI weder Out of Order noch Sprungvorhersage.

Abschließend noch ein Vergleich mit der GPU Welt. GPUs haben ebenfalls keine Sprungvorhersage oder kein Out-Of-Order. Ein Warp wird angehalten, sobald ein Befehl einen Operranden benötigt, der noch nicht verfügbar ist. Deshalb ist ihr Multithreading ebenfalls breit:

Titan: Maximal 64 Warps bei 32 Registern/Thread für 6 SP-FP Issue Slots pro Kern ~(1/6)
Haiti: Maximal 40 Warps bei für 1 SP-FP Issue Slot pro Kern ~(1/40)


Im Vergleich dazu der PHI:
Phi: Maximal 4 Threads für 2(?) SP-FP Issue Slots pro Kern ~ (1/2)

Man erkennt deutlich, dass die GPUs auf ein wesentlich "breiteres" Hardwaremultithreading setzen. Dennoch krapselt man meiner Erfahrung nach bei der GPU-Programmierung (zumindest bei NVIDIA-Karten) oft an den Latenzen herum.

 

[yummycandy]

Abschließend noch ein Vergleich mit der GPU Welt. GPUs haben ebenfalls keine Sprungvorhersage oder kein Out-Of-Order. Ein Warp wird angehalten, sobald ein Befehl einen Operranden benötigt, der noch nicht verfügbar ist. Deshalb ist ihr Multithreading ebenfalls breit:

Erstmal vielen Dank für den tollen Beitrag, aber:
Bedeutet ja, daß man eine extrem intelligente Threadverwaltung braucht, bzw. ein sehr durchoptimierte Programmierung. Oder übernimmt der Compiler teile dieser Aufgaben?

 

[strex]

Kommen um die 500GB/s am EDRAM an. Das wird wieder nett

 

[QDOS]

Mal eine Laienfrage, ist der Phi so einfach zu programmieren wie eine ultraparallele x86 SMT-Umgebung? Oder hat die Architektur damit nicht mehr viel zu tun?

Die PHI kannst du wie einen normale CPU programmieren, zB in C++ oder Fortran - man merkt eigentlich (bis auf low-level Optimierungen) überhaupt keinen Unterschied zur normalen CPU-Programmierung…

Du kannst Programme entweder lokal auf der PHI ausführen (SSH) oder "Offloading" betreiben, dann lagerst du aus einer auf der CPU laufenden Anwendung Berechnungen auf die PHI aus.

 

[yummycandy]

Die PHI kannst du wie einen normale CPU programmieren, zB in C++ oder Fortran - man merkt eigentlich (bis auf low-level Optimierungen) überhaupt keinen Unterschied zur normalen CPU-Programmierung…

Du kannst Programme entweder lokal auf der PHI ausführen (SSH) oder "Offloading" betreiben, dann lagerst du aus einer auf der CPU laufenden Anwendung Berechnungen auf die PHI aus.

Klingt ziemlich gut. Die Frage ist aber auch, welche Scheduler das ordentlich verteilen kann, darauf lief auch meine Frage hinaus. Oder ob man Probleme bei der Programmierung bekommt, die Latenzen zu reduzieren. Threads erzeugen kann jeder, aber sinnvoll verteilen ist ziemlich schwer. Gerade bei Multicoresystemen. (also mehr als 10 Cores meinte ich)

Aber witzig, daß er wie eine Art CoProzessor agiert. :-)

 

[QDOS]

Klingt ziemlich gut. Die Frage ist aber auch, welche Scheduler das ordentlich verteilen kann, darauf lief auch meine Frage hinaus.

Welcher Scheduler da genau verwendet wird, war mir bisher immer relativ wurscht. Da verlass ich mich dann auf uOS (Sprich Linux) und OpenMP^^

Aber witzig, daß er wie eine Art CoProzessor agiert. :-)

Theoretisch könntest du die PHI auch als "Cluster" (MPI geht auch…) betrachten, denn du sendest deine Daten über TCP/IP-over-PCIe an die PHI^^

 

[22428216]

Wird bestimmt ein Schnäppchen ;-)

 

[Daedal]

Abschließend noch ein Vergleich mit der GPU Welt. GPUs haben ebenfalls keine Sprungvorhersage oder kein Out-Of-Order. Ein Warp wird angehalten, sobald ein Befehl einen Operranden benötigt, der noch nicht verfügbar ist.

Dem ist seit GCN bei AMD nicht so:

Each GCN Compute Unit (CU) can be described as a processor with a scalar and four vector units (each of which has 16 processing element) that are built on a non-VLIW (Very Long Instruction Word) instruction-set architecture. According to AMD, the GCN CU is able to execute instructions with dependencies efficiently as its own hardware scheduler is able to assign instructions according to the various available computation units within the CU to avoid dependency bottlenecks. This allows the GPU as a whole to handle more instruction-sets per clock cycle.

Dies ist auch der Grund für die Entwicklung von HSA.

 

[Krautmaster]

macht das GCN wirklich zu ner Out of Order Architektur? Wohl kaum.

Anandtech schreibt:

Now GCN is not an out-of-order architecture; within a wavefront the instructions must still be executed in order, so you can’t jump through a pixel shader program for example and execute different parts of it at once. However the CU and SIMDs can select a different wavefront to work on; this can be another wavefront spawned by the same task (e.g. a different group of pixels/values) or it can be a wavefront from a different task entirely.

http://www.anandtech.com/show/4455/amds-graphics-core-next-preview-amd-architects-for-compute/4

Ergänzung (24. Juni 2014)

Dies ist auch der Grund für die Entwicklung von HSA.

HSA is Marketinggeblubber. Quasi alle, Intel AMD Nvidia gehen zunehmend den Weg ihre GPU um salopp "Computing Features" aufzubohren, mag mit HSA selbst noch nichts direkt zu tun haben, ist aber Wegbereiter. Nvidia fängt nun ja auch an wie bei Tegra ARM Kerne mit auf die DIE zu packen, Treibersachen dann direkt an die Hardware auszulagern oder auf niedrigeren Schichten auszuführen umm Overhead zu sparen. Auch bei CUDA ist gemeinsamer Speicherzugriffe möglich was bei AMD HUMA genannt wird...

Wenn man so will wenden sich GPUs zunehmend von ihrer einstigen Spezialisierung ab, werden träger und schwergewichtiger aber dafür flexibler was die Aufgaben angeht.

Bei PHI kommt man von der X86 (CPU) Schiene und geht eher in Richtung Spezialisierung und Massive Parallelisierung / Computing
Bei den GPUs von der reinen Grafik Vektor Ecke in Richtung Flexibilität und Computing

Es geht im Prinzip darum für Computing Szenarien viele Produkte anbieten zu können, vom ARM/X86 Server mit klassischen, vielen CPU Kernen bis hin zum speziellen auf GPU Code optimierten GPU/Tesla Szenario. Und selbst da geht es noch weiter mit FPGA-Chips bis hin zu festverdrahteten Chips die eben nur eine Aufgabe können, diese aber hocheffizient erledigen.

Ähnlich wie bei den CPU Befehlsätzen wie AVX ist HSA ja nicht viel anderes, wo eben ein Teil der APU (der GPU Teil wenn man so will) transparenter integriert wird und sich der Programmierer nicht viel oder garkein Hirn drüber machen muss wo sein Code wie ausgeführt wird.

 

[Nai]

Erstmal vielen Dank für den tollen Beitrag, aber:
Bedeutet ja, daß man eine extrem intelligente Threadverwaltung braucht, bzw. ein sehr durchoptimierte Programmierung. Oder übernimmt der Compiler teile dieser Aufgaben?

Das gesamte Scheduling auf der GPU wird von der Hardware übernommen, da kann man als Programmierer oder als Compiler nichts dran ändern. Man kann als Programmierer oder als Compiler lediglich versuchen die Instruktionen im Programm so anzuordnen, dass es besser funktioniert.

According to AMD, the GCN CU is able to execute instructions with dependencies efficiently as its own hardware scheduler is able to assign instructions according to the various available computation units within the CU to avoid dependency bottlenecks.

Mir erschließt sich leider nicht, worauf genau sich der Nebensatz nach dem as bezieht, deshalb kann ich dazu leider nichts sagen. Da die Quelle lediglich eine Hardwareseite zu sein scheint, ist es auch möglich, dass der Autor etwas falsch verstanden hat. Deshalb sollte man sich bei solchen Fragen besser auf die Dokumentation vom Hersteller selbst beziehen, falls auffindbar. So steht im GCN Whitepaper folgendes:

The CU front-end can decode and issue seven different types of instructions: branches, scalar ALU or memory, vector ALU, vector memory, local data share, global data share or export, and special instructions. Only issue one instruction of each type can be issued at a time per SIMD, to avoid oversubscribing the execution pipelines. To preserve in-order execution, each instruction must also come from a different wavefront; with 10 wavefronts for each SIMD, there are typically many available to choose from. Beyond these two restrictions, any mix is allowed, giving the compiler plenty of freedom to issue instructions for execution.

Oder alternativ kürzer:

Global memory reads generate a reference to the off-chip memory and
experience a latency of 300 to 600 cycles. The wavefront that generates the
global memory access is made idle until the memory request completes. During
this time, the compute unit can process other independent wavefronts, if they are
available.

 

[Luke S.]

Ich wäre ja für Kings Landing ;D

War auch mein erster Gedanke

 

[Krethi & Plethi]

Mal entgegen der ganzen Konversation auf hohem Niveau, was Kostet denn eigentlich so ein Ding!?

geizhals.at?

ums gleiche geld bekomtm man bei AMD/Nvidia jedenfalls deutlich emrh Gflops und deutlich weniger verbrauch.

 

[Krautmaster]

genau, vorallem weil die Käufer solcher Karten auf auf die Flops achten die der Hersteller angibt

Da gibts sicher 100 wichtigere Argumente als eine Flop Leistung die im Benchmarkfall auftritt. Aber das wurde ja bereits gesagt. Die "Flops" sind erstmal 0 vergleichbar, weil es im Rahmen des jeweiligen Kontextes beachtet werden muss der bei PHI vs AMD/Nvidia himmelweit auseinander geht.

 

[Krethi & Plethi]

Auch bei CUDA ist gemeinsamer Speicherzugriffe möglich was bei AMD HUMA genannt wird.

nein, da hast du wohl etwas falsch verstanden...

 

[Krautmaster]

Was sind genau die Unterschiede zwischen Unified Memory und HUMA?

Nvidia mit CUDA 6:
http://www.heise.de/developer/meldung/Nvidias-CUDA-6-fuehrt-Unified-Memory-Konzept-ein-2047232.html

Unter dem Schlagwort Unified Memory führt Nvidia ein an das hUMA-Konzept (heterogeneous Uniform Memory Access) der Heterogeneous System Architecture (HSA) erinnerndes Programmiermodell ein, über das Applikationen via CUDA-Direktiven Zugriff auf den Speicher von CPU und GPU erhalten, ohne dass Entwickler manuell Daten jeweils hin und her kopieren müssen.

AMD mit HUMA:
http://www.heise.de/newsticker/meld...rgieeffizienz-fuer-Kaveri-und-Co-1850975.html

...CPU und GPU auf einen gemeinsamen Speicherbereich zugreifen können. AMD nennt diese Technik heterogeneous Uniform Memory Access, kurz hUMA.