Knights Landing MIC - 72 Kerne, 3 TFLOPs DP, 8-16GiB On-Package, 384GiB DDR4 - 2015

[gravitationsfeld]

x86-Kerne fuer HPC zu verwenden ist einfach Irrsinn. Das hat auch Intel eingesehen. Hast du 72 mal den Decode-Overhead und Legacy-Kram runter bis 16-Bit-Real-Mode.

Xeon Phi ist auch keine wirkliche CPU. Wenn du wirklich Performance aus dem Ding holen willst musst du ISPC benutzen und dann ist es das gleiche Programmiermodell wie CUDA nur in schlechter.

Jajaja, es laufen alle x86-Programme darauf, yadayada. Nur halt extrem bescheiden.

[Skysnake]

Du kannst aber einiges mit OpenMP und Compilerdirektiven etc. reisen.

Ich sage nicht das KNL gut ist, aber vom generellen Konzept her, hat es schon entscheidende Vorteile. Und Intel hatte auf der SC vor 2-3 Jahren mal eine Aufstellung, wieviel für die Decoder, bzw den x86 legacy Kram draufgeht. Das war unter 1% wenn ich mich recht erinnere.

Auf jeden Fall war es vernachlässigbar laut Intel.

Und "läuft" ist schon wichtig. Wenn du anfängst deine Applikation auf CUDA zu portieren, dann ist sie erstmal kaputt. Bei XeonPhi läuft Sie immer, und wenn das Ding oder ein NAchfolger doch scheise ist, dann ist der Code nicht fürn Arsch, denn normale x86 CPUs profitieren in der Regel ebenso von den Optimierungen.

Wenn du aber CUDA oder OpenCL schreibst, ist das im Zweifel toter Code.

Bei Codes mit millionen von Zeilen ist das schon schwierig.

Ich habe ja beruflich mit Codes angeschaut und Empfehlungen abgegeben, wie man diese verbessern kann, und in der Regel wurde auf Portierung hin zu GPUs nicht eingegangen, weil der Aufwand nicht im Verhältnis steht zum Nutzen.

Vor allem fehlt aber auch das KnowHow, um das dann auch dauerhaft zu pflegen. Bringt ja nichts, wenn du einen GPU Code implementierst, und dann am Ende der total scheise ist und langsamer als ein vernünftiger CPU code.

Was ich btw. mal hatte in einem Code den ich reviewed habe. Da war am Anfang der GPU code faktor 5 oder so schneller als der CPU Code, aber ich habe gesehen, dass das auf Grundlage vom Algorithmus/Problem eigentlich nicht sein kann. Nach meiner Arbeit war der CPU Code um einen Faktor 3 schneller als der ebenfalls von mir weiter optimierte GPU Code.

Ich glaub Faktor 20 bis 30 war es am Ende im Vergleich zum orginalen GPU Code...

[=Floi=]

OpenCL wird sicherlich noch eine weile unterstützung finden.

Ich will mal anders fragen. Ist denn heutiger code wirklich noch 10 jahre und mehr unangetastet (sinnvoll) lauffähig?
Es geht immer mehr auf spezialisierungen und gerade im HPC bereich ist es doch usus mehrperformance durch mischkonfigurationen nicht mitzunehmen. Wenn der rechner zig mio kostet und der stromverbrauch erheblich gesenkt werden kann, dann muss eben auch das programm angepasst oder neu geschrieben werden. Irgendwann steht man dann sowieso mit der softwarebasis an. Ich denke multithreaded anwendungen müssen auch auf heutige und zukünftige prozessoren optimiert werden, damit nicht zu viel rechenleistung brach liegt.

[Skysnake]

Multithreading gibt es aber schon ewig. Da ist die codebasis da und die ohne geht es nicht.

Wenn du dir so nen Großrechner anschaust danngibt es natürlich Anwendungen die portiert werden. Aber das sind in der Regel nur eine Hand voll. Für mehr reicht das Geld nicht bzw gibt es auch gar nicht die Leute die das können in dem Umfang. GPUS effizient zu programmieren ist nicht einfach und man kann leicht viel Entwicklungszeit ohne Nutzen versenken.

Ich habe ja selbst schon Lehre gemacht für CUDA, und muss einfach sagen das nur die wenigsten begreifen worauf es ankommt. Das liegt zum Teil aber auch an der Grottigen Doku von nvidia....


Ich hatte mal Slides von einem Vortrag zur Nutzung von Titan gesehen, wo man sich gefreut hat 50% der Zeit die GPUS genutzt zu haben...

Wenn du nicht eine Hand voll von Applikationen hast die mindestens 50% der Rechenzeit benötigen dann machen GPU Systeme schnell keinen Sinn mehr.


Und bezüglich Auslastung. Das sind oft nur Parameter oder gar nur ein recompile.

Domain decomposition ist auch so ein Ding, was aber oft keine Änderung am Code an sich erfordert weil das eh parametrisiert ist.

Das ist halt der Punkt bei CPUS. Die haben halt Caches, Latenzen, Vektoren etc aber das haben an sich schon zich Jahre alle Architekturen. Daher profitieren auch alle von weiteren Optimierungen.

GPUS etc so sind halt immer extra

[gravitationsfeld]

Du kannst aber einiges mit OpenMP und Compilerdirektiven etc. reisen.
Nein kannst du nicht. OpenMP hat nichts mit Autovektorisierung zu tun. Und wenn du nicht vektorisieren kannst, dann willst du Xeons kaufen und keine Xeon Phis.

Ich glaube Intel kein Wort was sie ueber die Decoder sagen.

Dieses "mimimimi, Leute sind zu dumm zu programmieren" wird auch langsam echt alt von dir. Vielleicht Projektion?

[Skysnake]

Openmp hat einige Anleihen bei OpenACC genommen. Da geht in Zukunft schon einiges. Zumal man eben mit den compiler Direktiven oder auch openmp pragmas überhaupt erst den compiler dazu daß der Code vektorisiert.

Compiler haben nämlich sehr oft ziemliche Schwierigkeiten vektorisierten Code zu generieren, weil eben die Programmiersprachen oft gar nicht so klar sind wie man denkt. Wer liest schon den C++ standard mal wirklich selbst?

Und sorry, ich habe nicht gesagt, dass die Leute zu dumm dafür sind! Lernen könnten die das schon wenn sie wollten und dafür Zeit hätten. Aber genau das haben sie nicht. Du kannst halt Doktoranden nicht nen halbes jahr bis Jahr nur lernen lassen effizienten Code für GPUs zu schreiben. Das sind halt keine Informatiker im großen und die ganzen. Da kannste froh sein wenn es vernünftiger CPU Code ist.

Falls gehört halt viel Erfahrung dazu und viele Griffe ins Klo die man machen muss,bis man das richtige Gespür hat.

Und zu dem persönlichen Seitenhieb.
Denk was du willst. Ich verdiene damit meinen Lebensunterhalt und bin ganz zufrieden mit dem was am Ende vom Monat überwiesen wird. Und ich kann nächsten Monat wo anders anfangen wenn ich will. Sooo falsch kann ich also wohl nicht arbeiten.

Zumal ich in den letzten zwei Jahren mit vielen Leuten reden konnte und so auch andere Sichtweisen sehen konnte,die nicht so aussehen wie meine, aber eben da sind.

Wenns nach mir gehen würde.würden z.b. Viel mehr FPGAS genutzt werden, aber das kannste eben nicht machen, weil es zu teuer wäre und auch eh die Leute dazu fehlen.

Manchmal muss man halt leider mit den echten Gegebenheiten leben, aich wenn sie einem nicht passen.

[danarcho]

Will ich mal auch meinen Senf dazugeben, was die Programmierbarkeit von Intel MIC angeht:
Intel hat relativ früh und stark auf OpenMP gesetzt, und das ist tatsächlich ein relativ einfacher Weg, um die vielen Kerne effektiv auszulasten. Der Vorteil der Architektur ist, dass sie anders als GPUs auch vernünftiges thread-level parallelism beherrscht. Dazu kommen noch die Vektor-Einheiten für data parallelism. OpenMP ist für beides geeignet: Man kann threads kreieren (parallel) und verschiedene tasks zuweisen (z.B sections), aber auch loop iterations verteilen (for) und sogar vektorisieren (simd). Da der Programmierer durch die #pragmas praktisch bestätigt, dass der code so korrekt ist, brauch der compiler z.B. für die vectorization keine aliasing prüfung durchführen.
Durch die Offloading capabilities, die tatsächlich OpenACC entliehen sind, ist es auch möglich den code auf accelerator karten zu schieben. Es gibt dafür leider nur back-ends für die Xeon Phi Karten und für CUDA. Ich arbeite selbst daran das zu ändern, aber die OpenMP spec ist halt ein ziemlicher batzen.
OpenCL ging auch für Xeon Phi, aber ich glaube, dass da der Support schon eingestellt wurde.

[Skysnake]

Wobei der offloading Ansatz meiner Meinung nach ein Schuss in den Ofen war, was sie ja inzwischen wohl auch so sehen.

Auf nextplatform.com gibt es auf jeden Fall ein Interview mit Intel zum Nachfolger und da wurde gesagt das man kein offloading machen wird. Zumindest habe ich das so verstanden.

[danarcho]

Wobei der offloading Ansatz meiner Meinung nach ein Schuss in den Ofen war, was sie ja inzwischen wohl auch so sehen.

Auf nextplatform.com gibt es auf jeden Fall ein Interview mit Intel zum Nachfolger und da wurde gesagt das man kein offloading machen wird. Zumindest habe ich das so verstanden.
Ich werde mir das Interview mal durchlesen. Die neuen Xeon Phi sind ja auch gesockelt und keine accelerator mehr im eigentlichen Sinn. Daher ergibt das schon Sinn. Für GPUs sehe ich aber trotzdem noch Potenzial.

[transstilben]

Neue Produkt-Familie x205:

https://ark.intel.com/products/series/132784/Intel-Xeon-Phi-Processor-x205-Product-Family

Man beachte die Bepreisung. Wäre schön, wenn die mal in einem Supermicro Dual 3647 Board laufen würden ... :freak:

[Skysnake]

Da steht nur N/A :ugly:

[transstilben]

Da steht nur N/A :ugly:

dann hat mir google wohl was gezeigt, was man noch nicht hätte sehen sollen. ;D

http://preisvergleich.pcgameshardware.de/1411003346

[Skysnake]

Das wäre glaube ich schon ziemlich günstig