MIC vs. GPGPU/HSA/OpenCL/CUDA [split] [Archiv]

Skysnake

2013-12-29, 15:07:05

Das meiste Zeug ist eben nicht datenparallel und schon gar nicht SSE optimiert. Und wenn doch ist ein CUDA-Port genauso trivial.

Von dem Code, von dem ich ausgehe, also HPC, ist Datenparallelität vorhanden und SSE/AVX wird eh schon genutzt. Threading ist mit OpenMP/PThreads und MPI auch bereits vorhanden.

Und ansonsten willste wohl nicht die Entwicklung mit CUDA/OpenCL mit der Entwicklung auf GPUs vergleichen mit nem vollen VS, GDB, Valgrind usw usw. Das ist schon SEHR viel komfortabler zu debuggen.

Die Anforderungen an die Datenorganisation und die Algorithmen ist bei Xeon Phi und GPGPU fast exakt die selben. Und da versenkt man die Zeit.

Nicht ganz, du hast kein preemption auf GPUs. Das macht die Sache schon schwieriger.

Deshalb halte ich die angebliche bessere Portierbarkeit bei Xeon Phi für maßlos überbewertet. Wenn man darauf normalen x86 Code dem nachträglich Threads irgendwie reingefummelt wurden draufpackt läuft es zwar, aber kacklahm.
Es ist aber das Hauptargument. Es gibt doch eh zu wenig Leute die wirklich vernünftigen, also performanten, parallelen Code für ne CPU schreiben können. MPI+Pthread/OpenMP ist schon einiges an Aufwand. Mit GPUs musste dann aber auch noch Leute haben, die das können und dann eben noch CUDA/OpenCL beherrschen und das richtige Näschen dafür haben, wo es klemmt und wie man die Sachen gescheit optimiert. Das ist ja alles nur nicht trivial.

Was bringt dir tolle GPU-Performance, wenn du keine Leute hast, die dir die Software dafür schreiben, oder schlicht zu wenige. Eben gar nichts. Dann doch lieber X mal mehr Software portieren, die zwar einzeln nicht ganz so viel schneller wird wie bei nem GPU Port, aber unterm Strich über die gesamte Softwareumgebung dann halt doch mehr raus holt.

Ich hab das auch so lange klein geredet, bis ich angefangen hab mit dem Ding was zu machen, und der Unterschied im Overhead ist halt einfach abartig. Vor nem XeonPhi kannste halt jeden setzen der schonmal MPI/OpenMP programmiert hat. GPUs sind da nochmal was ganz anderes im Vergleich dazu. Das "lustige" ist ja, setz jemand vor nen XeonPhi, sag ihm nicht, das es einer ist, sondern gib schlicht die Randbedingungen vor und er arbeitet darauf wie auf nem stink normalen PC und wird auch den richtigen Weg zum Erfolg einschlagen.

Deswegen versteh ich auch nicht, warum nVidia nicht bei HSA mit macht... Die stehen am Ende allein da. Auf der einen Seite Intel auf der anderen HSA mit AMD, Samsung, Qualcomm usw usw.

Total behämmert in meinen Augen, dass die nicht nach dem Motto verfahren: "Der Feind meines Feindes ist mein Freund..."

EDIT:
@Intrinsics:
Ne, sowas will ich auch nicht nutzen. Wenn schon denn schon gleich OpenMP usw. Seh ich aber auch nicht als wirkliches Problem an. Intel ist groß. Die haben die Manpower und einfach das Volumen um die ganzen Standard-Bibs zu portieren und zu optimieren. Gut, das landet dann im Zweifel im ICC, aber den willste eh nutzen, wenn du ein etwas größeres System auf dieser Basis hast.

ICC vs GCC auf KNC ist eh eines der nächsten Dinge, die ich mir anschauen will/muss. Mal schauen ob ich in den nächsten 6 Monaten dazu komme :ugly:

Btw. irgendwie ist das auch schon wieder so total OT -.-

Coda

2013-12-29, 15:18:51

Das "lustige" ist ja, setz jemand vor nen XeonPhi, sag ihm nicht, das es einer ist, sondern gib schlicht die Randbedingungen vor und er arbeitet darauf wie auf nem stink normalen PC und wird auch den richtigen Weg zum Erfolg einschlagen.
Das ist so naiv das es schon fast süß ist. Das funktioniert ja noch nicht einmal am echten PC.

Die große Meute entwickelt immer noch als hätten sie einen 486 vor sich wo Arithmetik und Logik teuer sind und Speicherzugriffe kein Problem.

Ich bleib dabei, ordentlicher Code für Phi und GPGPU liegt in der gleichen Komplexitätsklasse.

Und OT ist doch egal, niemand der was weiß sagt was und der Rest pöbelt rum. Können wir es auch produktiv nutzen.

Du hast mal gefragt wie das mit Drawcalls und so funktioniert: Bei AMD gibt es PM4-Pakete die der Treiber in nen Buffer schreibt. Die sind gar nicht so weit von der API entfernt, sowas wie DRAW_INDEX etc. Ist alles dokumentiert. Die Hardware liest das Zeug dann und erzeugt selber die nötigen Wavefronts und organisiert den Datenfluss. Auch Zustandsänderungen gehen in die Paket-Queue.

Skysnake

2013-12-29, 15:41:38

Da haste auch wieder Recht ;)

Dann mal zum Thema.

Dann haste aber ne andere Vorstellung von Programmierern als ich. Die Java, Python und schlag mich tot Leuts berücksichtige ich da gar nicht. Ich geh da bei meiner Betrachtung halt schon davon aus, das jemand quasi OpenMP, PThreads, MPI und eventuell auch Fortran quasi mit der Muttermilch aufgesaugt hat. C/C++ verstehen sich da dann eh von selbst.

Das ist halt das, von dem ich ausgehe, wenn ich darüber nachdenke, wer überhaupt darüber nach denkt sich nen MIC/GPU System zu holen. Wenn das nicht da ist, sollte man das meiner Meinung nach eh komplett lassen. Kommt dann eh nichts bei rum außer Kosten.

So ein echter 0815 Programmierer, wie du ihn dir grad vorstellst, der wird es eh mit ner GPU nicht schaffen schneller zu sein als mit ner CPU. Die Leute sollte man aber finde ich gar nicht erst in die Betrachtung mit einbeziehen.

Und genau das ist halt der springende Punkt, wo ich dann verstehen kann, warum MIC so interessant wird für die Leute. Wirklich gute parallele Programmierer sind schon rar, aber wirklich gute GPGPU-Programmierer suchste halt quasi wie die Stecknadel im Heuhaufen. Vor allem wenns darum geht, bereits BEVOR! man hunderte von Arbeitsstunden in ein Projekt gesteckt hat, entscheiden zu können, ob man überhaupt nen Speedup im Vergleich zur CPU-Variante schafft oder nicht. Das findeste nochmals viel seltener, einfach weil du dafür richtig tief drin stecken musst und fast nichts anders machen darfst, um einfach genug Überblick zu haben. In dem ganzen Markt ist so viel Dynamik drin das geht auf fast keine Kuhhaut mehr. Was man heute programmiert kannste morgen schon wieder in die Tonne kloppen weil sich die GPUs grundlegend weiterentwickelt haben.

Schauen wir doch nur mal OpenCL2.0 an. Da kommt jetzt globale Syncs. RIESEN Ding.
CUDA 5 mit Dynamic Parallelism war nen RIESEN Ding
Genauso GPU-Direct 2.0
Wenn nVidia wirklich ARM-Cores mit rein setzt in die GPUs wird sich nochmal verdammt viel ändern, und so gehts grad weiter. Preemption ist dann das nächste große Ding, was AMD bei HSA bringt. Also wieder alles überarbeiten.

Was ist bei MIC? K, KNL bringt nen größeren Sprung bei der ISA, aber da gleicht man sich eigentlich "nur" den normalen Xeons an. Xeons und MIC gehen da also eher nochmals nen deutlichen Schritt aufeinander zu, als auseinander, was die Sache noch einfacher macht.

Gerade KNL wird in meinen Augen echt hart. Das Ding wird wohl echt einfach alles auch können, was nen normaler Xeon kann. Was willste mehr?

Coda

2013-12-29, 15:47:43

Was man mehr will? Performance und Performance/Watt und da sind GPUs selbst mit veraltetem Prozess gegenüber von Intel massiv besser.

Wenn ich sowas wie OOO bei KNL schon les lang ich mir an den Kopf. Son Scheiß kann sich Intel nur erlauben weil sie mit der Fertigung zwei, drei Jahre voraus sind. Wird nur nicht ewig halten und dann schauen sie dumm. Das man da überhaupt sowas wie "decoder" auf dem Schaltplan hat ist bei einer durchsatzoptimierten Architektur schon ein Witz.

Und ich wiederhole mich: Dein Nicht-0815-Entwickler hat keinen großen Vorteil bei einem Phi weil er ordentlich datenparallelen Code schreibt und das dauert auf GPU und CPU vergleichbar lang. Oft genug gemacht.

=Floi=

2013-12-29, 16:01:43

Ja, wobei das "winzige" Problem daran ist, dass Sie sich mit dem blockieren von offenen Standards und openSource selbst den Ast vollends absägen, auf dem sie sitzen.

HSA und schlicht x86 Booster wie MIC/XeonPhi sind da einfach VIEL attraktiver, da sie eine viel einfachere Softwareentwicklung erlauben.

warum soll man sich jetzt schon öffnen, wenn es auch später geht? Vor allem, weil NV sicherlich mit der nächsten generation und danch nochmal richtig extrem an der SP/DP-Leistung drehen wird! Wenn man mal durchweg schneller wie AMD in der gleichen preisklasse ist, kann man sich viel problemloser öffnen.
Jetzt verdient man auch gutes geld damit und bindet die leute an die karten.

Skysnake

2013-12-29, 16:02:57

Dann gehörste halt einfach zu den wenigen, dies halt einfach wirklich drauf haben. Da kannste dich drüber freuen.

Schau doch aber mal raus in die Welt. Die meisten wollen doch Java, C# und son Mist haben. Wie was? Der Compiler macht das nicht? Wat ich muss mich um die Daten selbst kümmern? Raceconditions? Syncronisation?

Das sind doch für ganz ganz ganz ganz viele böhmische Dörfer... Die schauen dich entweder mit großen Augen an oder winken ab und wollen vom dem ganzen Zeug nichts wissen. Und bei den paar, die voll drauf abfahren und das interessant finden, und sogar verstehen, worums geht, verlierste nochmal über die Hälfte, wenns dann zu GPUs geht. Da steigen die Leute dann einfach aus, weil Ihnen das Verständnis dafür fehlt, oder Sie schlicht kein Bock drauf haben.

Woher sollen also die Massen an Leuten kommen, die gescheiten Code entwickeln können?

Wie siehts denn bei euch aus? Wenn ihr jemanden sucht als Unterstützung, wird euch dann die Tür eingerannt, oder müsst ihr ewig suchen um überhaupt jemanden zu finden, und wenn jemand da ist, wie lang bleibt er da, bevor er wo anders hin geht, weils mehr Kohle gibt...

Als GPGPU-Mensch biste doch so ziemlich allein auf weiter Flur, oder siehst du das anders? Von "den Unis" kannste da meiner Meinung nach nicht viel erwarten. Paar Hansel im Jahr, aber das wars auch. Zumindest wenns an anderen Unis so aussieht wie bei uns, und ich kann mir nicht so wirklich vorstellen, das wo anders die Leute en GPGPU-Vorlesungen usw die Türen einrennen. Und wer am malochen ist, wird wohl eher nicht die ZEit für solche Späße haben. Ist ja nicht so, als ob man sich da nen Wochenende hinsetzt und dann der Vollprofi wäre.

Coda

2013-12-29, 16:41:13

Die Schnittmenge der Leute die es schaffen Code zu schreiben der Auf Phi schneller läuft als auf einem normalem Xeon mit gleicher Verlustleistung (Amdahl!) und es aber nicht raffen CUDA zu benutzen geht meiner Meinung nach gegen Null.

Und für diese schmale Gruppe baut Intel jetzt einen Chip der doppelt oder dreifach so viele Transistoren für den gleichen Durchsatz verballert als GCN.

Meine Prognose: Sie werden auf die Fresse fliegen langfristig. Kurzfristig glauben die Leute das vielleicht mit der "einfachen" x86-Architektur, aber es ist einfach eine Lüge.

Skysnake

2013-12-29, 19:31:45

@skysnake: An welcher Uni bist du doch gleich? Ich vermute mal dass du und Coda einfach zu unterschiedliche Aufgabengebiete abdeckt als dass sich eure Vorstellungen decken würden. Etwa so als ob ein Ralley-Fahrer und Formel-1-Pilot über Fahrzeugentwicklung reden.

Gruß Hübie
Ja, das kann durchaus sein ;D

Ich seh halt auf der einen Seite die Leute die C/C++ schon als low-lvl betrachten, und es verabscheuen, sich dann aber über miese Performance wundern, bzw noch schlimmer denken Sie wären schnell, aber teils >50% langsamer als mit ner C Implementierung :freak: (Phyton vs C single Thread!).

und auf der anderen Seite dann Leute die so abartig tief in C/C++ & MPI+Pthreads drin stecken, aber schlicht noch nie was mit GPUs gemacht haben, und daher null Ahnung haben. Klar lernen die das "schnell", aber nen paar Wochen biste trotzdem damit beschäftigt, und dafür haben die Leute einfach keine Zeit. Die wissen ja oft eh nicht, wo Sie anfangen sollen und stecken bis über beide Ohren in Arbeit, und da oft halt nicht garantiert werden kann, das man mit ner GPU-Implementierung wesentlich schneller ist, lässt man es halt gleich bleiben und sucht sich zur Not jemanden, der halt schon Erfahrung hat, aber die sind halt wie gesagt eher selten und schnell wieder in der Wirtschaft, weils da halt teils besser Kohle gibt.

Die GCC/ICC Frage wurde ja schon beantwortet ;)

Der GCC ist halt der Wald und Wiesen Compiler. Der ist nicht schlecht, aber reicht halt nicht an den ICC heran was Performance anbelangt durch automatische Optimierung für Intel CPUs. Den GCC brauchste aber eigentlich immer, um Linux zu compilieren. Hab mich dieses Jahr mal kurz damit beschäftigt, den ICC dafür zu verwenden, aber ganz schnell wieder die Idee begraben. Es gibt dafür einfach nichts fertiges, oder zumindest habe ich nichts gefunden, und alle Kommentare dazu waren ziemlich einhellig. LASS ES SEIN! Der Linux-Buildprozess ist halt nicht wirklich der einfachste -.- Das ist nen riesiges gewachsenes System. Da steigt man nicht mal eben durch.

-/\-CruNcher-/\-

2013-12-29, 19:40:17

Skysnake

2013-12-29, 20:52:06

Ehh sind aber nicht alles parallele probleme und viele sachen sind noch nicht parallelisiert machbar oder nicht effizient so wie unsere veralteten Video Encoding ansätze das musste selbst Nvidia einsehen ;)
Natürlich wird das in der Zukunft anders aussehen da geb ich dir recht Coda aber bis dahin hat MIC noch eine gute basis und wie Skysnake schon angesprochen hat für viele ist GPGPU neuland da ist es einfach für Intel MIC z.b am Cern zu promoten :)
Das liegt aber nicht an der "mangelnden" Parallelität, sondern einfach den Einschränkungen, denen GPUs unterworfen sind... Die wollen halt einfach schön einfachen geradlinigen Code ohne viele Branches und verdammt hoher Datenlokalität.

Und was einem oft das Genick bricht ist halt das elendige rumkopieren von Daten und irgendwelche Branches und die Syncronisation über Workgroups hinweg. Deswegen ist ja z.B. OpenCL 2.0 auch so verdammt interessant! DAs geht da dann nämlicherstmals. Es muss sich "nur" noch zeigen wie performant das dann auch ist. Zumindest AMD lässt aber dank extra Hardware genau für solche Sachen auf gute Ergebnisse hoffen.

@samm:
Das geht doch noch, sind ja nur 49 Seiten. Schau dir mal die Intel64 IA32 Doku an. Das sind >1400 Seiten :ugly:

Coda

2013-12-29, 23:19:59

Das liegt aber nicht an der "mangelnden" Parallelität, sondern einfach den Einschränkungen, denen GPUs unterworfen sind... Die wollen halt einfach schön einfachen geradlinigen Code ohne viele Branches und verdammt hoher Datenlokalität.
Genau das selbe bei MIC. Sonst läuft's scheiße, weil du entweder die Vektoreinheiten nicht richtig verwendest (SOA mit einem "Thread" per Lane und Maskierung wie bei GPUs auch) oder du dauernd L1$ misses hast und/oder dich der snooping traffic killt.

Coda

2013-12-29, 23:45:06

An welcher Uni bist du doch gleich? Ich vermute mal dass du und Coda einfach zu unterschiedliche Aufgabengebiete abdeckt als dass sich eure Vorstellungen decken würden. Etwa so als ob ein Ralley-Fahrer und Formel-1-Pilot über Fahrzeugentwicklung reden.
Nein. HPC ist HPC. Performanter Code folgt überall den gleichen Regeln.

Skysnake

2013-12-30, 00:36:11

Genau das selbe bei MIC. Sonst läuft's scheiße, weil du entweder die Vektoreinheiten nicht richtig verwendest (SOA mit einem "Thread" per Lane und Maskierung wie bei GPUs auch) oder du dauernd L1$ misses hast und/oder dich der snooping traffic killt.
Klar, wobei es eben nur ne 8er Granulariät für die Maskierung gibt bei DP. Bei Kepler sollte das 192 und bei GCN 64 sein.

Das ist schon nochmal nen Unterschied. Zudem spart man sich eben das hin und her kopiere übern PCI-E. Den "Offload-Modus", bei dem MIC wie ne GPU verwendet wird halte ich für Schwachsinnig. Da nutzt man die Vorteile des Systems gar nicht aus.

Und ansonsten haste halt die die Integerpipe noch. Das haste so bei nVidia gar nicht und bei GCN so lala. Im Prinzip sieht GCN sogar da gar nicht wirklich viel schlechter aus als MIC, aber ohne Softwaresupport der Hardware kann man sich damit halt den Arsch abwischen... Das ist überhaupt DAS Problem von GCN. Das Ding ist richtig cool, aber die API dazu fehlt bisher. Mal schauen was OpenCL 2.0 da bringt. Das könnte meine Sicht wieder pro GPGPU ausschlagen lassen.

Dazu kommen dann halt noch so Sachen wie Startup time usw. für Berechnungen. Auch das direkte Ansprechen von nem NFS ist schon ziemliche nice in meinen Augen. Kein Umweg über den Host, sondern direkt druff uf die Mutter. MIC ist nicht die Killerhardware, aber in Verbindung mit der Software halt schon nicht. Wenn ich aktuell die Wahl hätte zwischen CUDA/OpenCL und MIC, würde ich mich für MIC entscheiden. CUDA 6 hört sich nach gähn an, dafür ist OpenCL 2.0 mit einigen sehr interessanten Sachen gespickt. Wobei wirklich interessant eigentlich HSA ist. Die Programmierparkeit von MIC zusammen mit der Perf/W von klassischem GPGPU hört sich zu verlockend an! Nur kommen die nicht in die Pushen...

Coda

2013-12-30, 00:50:42

Die Granularität bei allen NVIDIA-GPUs seit G80 ist 32. Und nein, das macht keine Unterschied, der Aufwand ist der selbe.

Skysnake

2013-12-30, 00:56:45

Klar die Wavefronts sind immer 32 "Threads". Haben die 3 parallelen Wavefronts aber nicht den gleichen Instructioncounter?

Coda

2013-12-30, 01:31:05

Nein, haben sie nicht.

mksn7

2013-12-30, 14:58:15

Die MIC vs GPU ist wirklich interessant.

Ich dachte mir auch immer, dass das große Intel versprechen vom einfach neu kompilieren quatsch ist. Andrerseits sind Applications, die hinterher halb so schnell laufen wie auf auf den Host CPUs halt immer noch meilenweit mehr als auf den GPUs, wo sie halt einfach gar nicht laufen. Von dem Halb-so-schnell punkt kann man sich dann immer noch voranarbeiten und einzelnen Code teilen ein bisschen mehr Aufmerksamkeit schnenken. Und die typische HPC software ist schon einigermaßen OpenMP parallel, wovon der MIC dann tatsächlich sofort profitiert.

Ein kompletter Port auf GPUs ist für die meisten Applications halt einfach ein rießiger Aufwand. Gerade weil HPC applications dazu neigen, rießige packages zu sein, die über die Jahre anwachsen und eben oft nicht von Informatikern geschreiben werden, sondern von Physikern. Und für ein vernünftiges Buildsystem kriegt man bei denen keinen Dr.

Für neuen Code macht der Cuda/OpenCL Stil viel mehr Spaß, weil der Programmierer mit Restriktionen wie SIMD alignedness usw. bei weitem nicht so belästigt wird.

Dass man sich auf den Karten mit ssh einloggen kann ist für den Entwickler ziemlich cool. Die sysadmins sind aber überhaupt nicht begeistert, weil sie jetzt plötzlich noch ein zweites sehr spezielles System aufsetzen und pflegen müssen.

Von der Architektur her fühlt sich Knights Corner manchmal ein bisschen seltsam an. Sie benutzen manche der typischen latenz/durchsatz tradeoff strategien, aber letztendlich ist es eben doch eine cache architektur.

Gipsel

2013-12-30, 15:55:39

Klar die Wavefronts sind immer 32 "Threads". Haben die 3 parallelen Wavefronts aber nicht den gleichen Instructioncounter?
Nein, haben sie nicht.
Oder um das mal etwas ausführlicher darzulegen, ein Kepler SMx hat 4 Scheduler, setzt also jeden Takt Instruktionen von bis zu vier unterschiedlichen Warps (Größe 32) ab. Von jedem Warp können dabei maximal 2 aufeinanderfolgende Instruktionen pro Takt zum Issue kommen (wenn unabhängig, entsprechende Ausführungseinheiten frei und keine Registerbankkonflikte). Jeder Scheduler kann aus bis zu 16 Warps einen auswählen, der zur Ausführung bereit ist. Dabei können maximal 16 workgroups pro SMx laufen, bei einer Größe von 64 für die Workgroup (2 Warps) limitiert man das also auf 32 Warps für den ganzen SMx.
Ein SMx wählt pro Takt aus bis zu 64 Instructioncountern bis zu 4 aus (jeweils einen aus 16 parallel in jedem Scheduler), von denen bis zu 8 Instruktionen (6 ALU + 1 SFU + 1 MEM) ausgeführt werden.

Zum Vergleich, GCN hat logisch gesehen für seine nur 64 ALUs (ein Drittel eines Kepler SMx) auch 4 Scheduler (die aber jeweils nur jeden vierten Takt drankommen, also immer nur einer pro Takt). Jeder dieser Scheduler nimmt immer nur eine Instruktion pro Wavefront (64er Größe), allerdings von bis zu 5 der 10 Wavefronts, die von jedem der Scheduler maximal vorgehalten werden (wenn es unterschiedliche Instruktionsklassen sind, die also an unterschiedliche Einheiten gehen, das ist eine Peakangabe und kann nicht durchgehalten werden, sustained Maximum liegt wohl bei 3 [1 vALU + 1 sALU + 1/2 LDS + 1/4 vMEM + 1/4 Export/GDS/message] plus vielleicht noch die vom Scheduler selber ausgeführten Instruktionen [wie sleep, das Warten auf die dependency counter usw.]). Eine CU kann übrigens genau wie ein SMx ebenfalls maximal 16 workgroups verwalten, wobei dieses Limit lediglich für workgroup-Größen über 64 gilt (bei workgroup-Größe <= 1 Wave gehen die vollen 40 Waves), bei einer Workgroup-Größe von 2 Waves (128 workitems) limitiert man eine CU also auf maximal 32 Waves.
Eine CU wählt pro Takt aus maximal 10 Instruktionscountern (über 4 Takte verteilt kommen jeden Takt jeweils 10 Andere dran, also insgesamt aus bis zu 40) bis zu 5 (sustained 3) aus, von der 5 (3) Instruktionen pro Takt ausgeführt werden.

transstilben

2013-12-30, 19:24:33

...
Meine Prognose: Sie werden auf die Fresse fliegen langfristig. Kurzfristig glauben die Leute das vielleicht mit der "einfachen" x86-Architektur, aber es ist einfach eine Lüge.
Meine Prognose: Intel wird langfristig nicht auf die Fresse fliegen. Mittelfristig werden wir sehen, dass sich ein "stand alone" bootender knight's Landing in 14 nm wie geschnitten Brot verkaufen wird ( vergleiche auch Nachfrage nach KNC ).

Coda

2013-12-31, 04:14:44

Das ist kurzfristig. Selbst ich erwarte auch, dass sie erstmal viel davon verkaufen.

Wenn NVIDIA oder AMD die gleiche Fertigung hätten sähe das aber völlig anders aus.

Ailuros

2013-12-31, 08:25:05

Meine Prognose: Intel wird langfristig nicht auf die Fresse fliegen. Mittelfristig werden wir sehen, dass sich ein "stand alone" bootender knight's Landing in 14 nm wie geschnitten Brot verkaufen wird ( vergleiche auch Nachfrage nach KNC ).

Dafuer muesste Intel's Konkurrenz aber auf Stillstand kommen fuer HPC. Es ist ja sooooooo verdammt schwer etwas "standalone self booting" herzustellen dass es nur Intel schaffen koennte. Damit es mittelfristig (und um zich Male langfristig) zur irgenwelchen "Wundern" kommt muss Intel erstmal ihr perf/W Problem loesen und hier haben sie schon noch einige Strecken zu decken; wenn's nicht so weit kommt wird der standalone Kaese auch nicht den Tag retten koennen.

Wenn NVIDIA oder AMD die gleiche Fertigung hätten sähe das aber völlig anders aus.

Wenn man so einen Prozess-Vorteil hat wie Intel wuerde ich aber auch eine ganz andere bisherige perf/W Situation erwarten. Die Frage ist nun ob sich hier etwas geaendert hat.

***edit: OT ich dachte Knights Corner hatte keine TMUs mehr, jetzt lese ich gerade dass es sie doch noch gab. Nun wenn sie die losgeworden sind in KNL ist es schon ein guter Schritt in eine andere Richtung.

Kriton

2013-12-31, 15:25:27

Das ist kurzfristig. Selbst ich erwarte auch, dass sie erstmal viel davon verkaufen.

Wenn NVIDIA oder AMD die gleiche Fertigung hätten sähe das aber völlig anders aus.

Aber die werden sie erst einmal ja nicht haben. Ist es sinnvoll die Fertigung gedanklich zu trennen wenn sie in der Praxis einen entsprechenden Einfluss hat?
Interessant wird es wenn das Gesetz des abnehmenden Ertragszuwachses ausreichend relevant wird.

Skysnake

2013-12-31, 16:45:08

...
Ok danke, dann war das doch deutlich komplexer, als ich das in Erinnerung hatte. Bei Fermi wars doch aber noch so, das ein SM/CU eben 32 ALUs hatte. Da wurde dann doch immer genau eine Instruction gesheduld.

Bei Kepler ist das ja aber offensichtlich doch nicht mehr so wie ich mir das gedacht hatte. Wäre nett, wenn du mir einige Fragen beantworten würdest.

1. Die 192 ALUs/SMX können also Instrucionen aus vier 32er Warps abgesetzt werden. Das macht doch aber nur Instructionen für die Auslastung von 128ALUs. Woher bekommen denn die restlichen 64 ALUs ihre Instructionen bei nur 4 Shedulern?

So wie ich das verstanden hatte bei den Erklärungen zu GF104 wars ja so ein Ähliches Problem mit den 48 ALUs/SM.

Ich hatte das eben immer so verstanden, dass es zwar mehrere Shedulern gibt, aber immer nur einer Instructionen absetzen kann für eben maximal x Warps, die aber alle den gleichen Instructioncounter haben.

Also das für alle ALUs immer der gleiche Befehl ausgeführt wird, nur halt maskiert wird.

WEnn ich dich aber nun richtig verstehe, können eben direkt pro Pipelinestufe gleich aus mehreren Warps die Instruktionen kommen, und zwar mit unterschiedlichen Programmcountern. Das würde ja aber bedeuten, dass ein Branch nur dann eine Durchsatzverminderung erzeugt, wenn innerhalb eines 32er Warps es eine Divergenz gibt. Wenn aber ein 32er Warps die eine Richtung nimmt und der andere die andere, dann nicht. ODER???

Ganz ehrliche Frage! Ich bin da etwas verwirrt. Das würde ja alles nochmals VIEL! komplizierter machen, als es eh schon ist, und vor allem nochmals deutlich schwieriger zu optimieren fürs Layouten, wie man wo Threads zusammenpackt. :freak: Vor allem kann man das ja gar nicht wirklich richtig wissen wie das aufgeteilt wird.

Das ist kurzfristig. Selbst ich erwarte auch, dass sie erstmal viel davon verkaufen.

Wenn NVIDIA oder AMD die gleiche Fertigung hätten sähe das aber völlig anders aus.
Naja, aber das interessiert doch keinen. Ist halt das gleiche Problem das AMD auch! hat. Intel erschlägt halt so einiges im Moment noch durch seinen Fertigungsvorteil. Ob da in 5 Jahren dann nVidia/AMD doch wieder besser sind interessiert ja erstmal nicht. Bis dahin bricht das schonmal CUDA UND OpenCL kräftig den Hals. AMD ist ja mit HSA ja auch in meinen Augen auf dem Weg weg von OpenCL, bzw halt nochmals als zusätzliches Feature/API, wo man dann sich schlicht anschaut, was sich letztenendes durchsetzt. Halte ich auch für richtig. Die Industrie soll da entscheiden, was Sinn macht, auch wenn es natürlich Ressourcen frisst alles zu unterstützen...

Da macht nVidia ja aber auch nicht mit... leider ... :(

nVidia finde ich lebt ja auch teils von der CodeBasis, die aufgebaut wurde. Die hält ein Jahr, die hält zwei Jahre, aber dann bröckelt Sie, und Sie bröckelt bereits jetzt. Das hält nicht nochmal 3-5 Jahre.

Mit Maxwell und CUDA6 kommt ja auch kein Killerfeature. Ganz im Gegenteil. CUDA 5 mit GPU-Direct2 und HyperQ und DynamicParallelism waren an sich die Killerfeatures. Was ich von den Leuten die auf der SC waren und sich das nVidia Zeug angeschaut haben, hielt sich die Begeisterung bzgl CUDA5 unterm STrich aber ziemlich in Grenzen. Was soll dann erst bei CUDA 6 passieren, wo derartige "Killer"-Features wie es aussieht ja fehlen. :confused:

Dafuer muesste Intel's Konkurrenz aber auf Stillstand kommen fuer HPC. Es ist ja sooooooo verdammt schwer etwas "standalone self booting" herzustellen dass es nur Intel schaffen koennte.

Ähm...

So ganz trivial ist das auch gar nicht :freak:

Also zumindest für KNC ist es nen ziemlicher act....

Mit KNL dürfte es einfach werden. Deutlich einfacher sogar, aber "einfach" würde ich es dennoch noch nicht ganz nennen, wenn auch kein Vergleich mehr zu aktuell!

Damit es mittelfristig (und um zich Male langfristig) zur irgenwelchen "Wundern" kommt muss Intel erstmal ihr perf/W Problem loesen und hier haben sie schon noch einige Strecken zu decken; wenn's nicht so weit kommt wird der standalone Kaese auch nicht den Tag retten koennen.

Naja, Perf/W ist bei KNC auch "schwierig". So wirklich gute Vergleiche gibt es ja nicht. Es ist immer ein bischen Äpfel mit Birnen... Das GANZE! KNF Zeug und auch das frühe KNC Zeug muss man dazu auch noch raus lassen, sonst vergleicht man Äpfel mit Apfelblüten und wundert sich, warum Apfelblüten so komisch schmecken und so staubtrocken sind...

Das machts halt nicht gerade einfacher, da überhaupt den Überblick zu haben, wie man welche Daten überhaupt interpretieren kann bzgl. Perf/W. Letztenendes muss man sich wohl son Ding einfach holen und anschauen, wies für einen selbst passt. Die Daten so in der "Öffentlichkeit" kannste in die Tonne treten, zumindest das was ich gesehen habe, einfach weil man zu viele Randbedingungen nicht kennt....

Wenn man so einen Prozess-Vorteil hat wie Intel wuerde ich aber auch eine ganz andere bisherige perf/W Situation erwarten. Die Frage ist nun ob sich hier etwas geaendert hat.

Naja, schau dir doch mal KNC, oder gar KNF an....

Welche Basis hat denn das Ding?
Wie sind denn manche Sachen gelöst?

Also der Weisheit letzter Schluss ist da so manches nicht. Da gibt es son paar Stellen, wo man sich denkt. WARUM?

Intel hat da noch einiges an Optimierunspotenzial in meinen Augen. Irgendwie erinnert mit das an nen BD-Clon aus nem Paralleluniversum :tongue:

Die Frage ist halt, was Intel jetzt daraus macht, und wie sich das Gesamtkonzept entwickelt. KNC und schon gar nicht KNF kann man so wirklich mit KNL vergleichen. Da ändert sich einfach nochmals gewaltig viel. Meint ihr ein VLIW5->VLIW4->GCN Vergleich würde es treffen? Kam mir gerade sehr bildlich in die Gedanken.

***edit: OT ich dachte Knights Corner hatte keine TMUs mehr, jetzt lese ich gerade dass es sie doch noch gab. Nun wenn sie die losgeworden sind in KNL ist es schon ein guter Schritt in eine andere Richtung.
TMUs usw sollte er noch haben.

Ansonsten sollte man sich eben auch nochmal überlegen, aus was denn nen DEEP-KNx Boosternode besteht, oder auch später nen KNL Node, und im Vergleich dazu mal nen nVidia Tesla oder auch AMD FirePro Node nehmen... Die Unterschiede sind schon eklatant.

Und bei nVidia seh ich nicht wirklich im kommenden Jahr standalone GPUs für den HPC-Bereich. Vielleicht 2015, eher 2016, und selbst dann würde ich es nicht mit nem KNL vergleichen wollen.

Bei AMD geht die Sache eher in Richtung APU meiner Meinung nach, an die halt ne nochmals dickere dGPU noch rangeflanscht werden kann bei Bedarf, aber die iGPU schon nen guten Grundstock bildet. DAs wird spannend vor allem mit HSA, wie sich das jetzt genau entwickelt in 2014 und 2015.

Ich seh da eigentlich nen Machtkampf zwischen Intel mit Xeon+XeonPhi auf der einen Seite und HSA auf der anderen Seite. nVidia wird da schlicht dazwischen zerrieben. Das ist zumindest meine Aussicht auf die Dinge.

Und ja ich schreib bewusst HSA und nicht AMD. AMD hat allein gar keine Chance... Deswegen ärgert es mich um so mehr, das nVidia nicht doch noch auf den HSA Zug aufspringt... Das schwächt HSA vs. Intel nur unnötig... Denn das Letzte was wir gebrauchen können wäre ein Intel das nVidia auch noch schluckt...

Dann lieber nViida bei HSA, die ihre (i)GPUs als Konkurrenz zu ARM usw anbieten für Qualcomm, Samsung, TI und sogar AMD, in freudiger Mischung der jeweiligen ARM und x86 CPUs. So könnte sich nämlich nViida eventuell sogar nen x86 SOC besorgen... Wäre zumindestens wünschenswert!

Gipsel

2013-12-31, 19:35:16

Ok danke, dann war das doch deutlich komplexer, als ich das in Erinnerung hatte. Bei Fermi wars doch aber noch so, das ein SM/CU eben 32 ALUs hatte. Da wurde dann doch immer genau eine Instruction gesheduld.Nein, da war das auch schon komplizierter. Bei Fermi gab es zwei parallele Scheduler, die jeweils eine (GF100 SMs) bzw. zwei (GF104 SMs) Instruktionen über zwei Takte verteilt absetzen konnten. Im Prinzip geht Kepler in die Breite (doppelt so viele Scheduler) und streicht die hot clock (deswegen dort jeden Takt eine neue Instruktion und nicht alle zwei [hot clocks; betrachtet man den Grundtakt, ist es auch bei Fermi jeden Takt]). Fermi hatte 16er SIMD-Einheiten (zwei oder drei davon in jedem SM), die G80/GT200-Serie hatte 8er SIMDs (auch zwei [G80] oder drei [GT200] davon, damals hießen sie noch die einzelnen SIMDs SMs).

Coda

2014-01-01, 03:04:33

Bei Kepler kann jeder der vier Scheduler zwei unabhängige Instructions aus einem Warp issuen pro Takt. Im Prinzip ist ein SM ein superskalarer vierfach SMT Core mit 6 dicken SIMD-Einheiten.

Die Warps laufen unabhängig, es gibt keinen gemeinsamen Instruction-Counter.

Mir gefällt was AMD bei GCN macht aber besser. Simpler und eleganter. Die haben es aber auch etwas einfacher, weil sie seit jeher 64er thread groups haben, brauchen also halb so viel scheduling logik.

Skysnake

2014-01-01, 11:45:23

K, das bedeutet, wenn ich bei Kepler nicht zwei Warps habe, die die gleiche instruction aus nem Codepfad ausführen wie zwei andere, dann hab ich schonmal verloren und kann den SMX nicht auslasten.

hm.. das ist ja an sich gar nicht sooo schlimm wie eigentlich gedacht. Wenn ich beide Zweige eines branches wirklich gleichzeitig ausführen kann selbst innerhalb eines SMX.

Coda

2014-01-01, 12:15:21

?

Jeder der Warp-Scheduler pickt jeden Takt aus dem Pool an Warps die auf dem SMX laufen (maximal 64 Warps, wenn zu viele Register gebraucht werden entsprechend weniger). Dabei müssen natürlich die Hazards berücksichtigt werden.

Dann werden aus diesem ausgesuchten Warp entweder eine Instruction oder ein Paar an die Ports geissued (da hilft wohl der Compiler auch).

Ich versteh nicht was du meinst mit "beiden Branches". Von einem Warp läuft immer nur ein Pfad gleichzeitig. Aus diesem einen Pfad aber eben bis zu zwei Instructions.

Die 192 ALUs können nur ausgelastet werden wenn mindestens zwei Warps zwei unabhängige Instructions haben jeden Takt. Es gibt da bei Kepler aber wohl noch mehr Einschränkungen wegen Registerbankkonflikten.

Skysnake

2014-01-01, 12:33:10

Ja wat denn nun?

Kann ich jetzt innerhalb eines Taktes von nur einem Sheduler Warps in die SMX packen, oder von mehreren. Ich hab ja in der Regel mehrere Warps in einem Block. Und soweit ich das verstehe müssen/sollten wohl die Warps eines Blocks auf einem SMX/CU laufen bisher, um die Sync innerhalb eines Blocks zu gewährleisten. Zwischen SMX gibt/sollte es ja keine Syncs (geben).

Gipsel schreibt ja:

ein Kepler SMx hat 4 Scheduler, setzt also jeden Takt Instruktionen von bis zu vier unterschiedlichen Warps (Größe 32) ab.
Das widerspricht eigentlich dem, was du gerade sagst.

Ich kann also innerhalb eines Blocks einen Warp den einen Zweig eines Branches nehmen lassen, und einen anderen Warp eben den anderen. Das dürfte nach Gipsels Aussge einem eigentlich nicht weh tun, da beides ausgeführt werden kann. Erst wenn innerhalb eines Warps ein unterschiedlicher Verlauf genommen wird tuts weh, oder wenn man so stark zwischen den Warps verzweigt, das man eben mit den 4 Shedulern die 6 Warp-Slots gefüllt bekommt.

Was mir jetzt auch nicht ganz klar ist, ist wie weit die Warps eines Blocks dann auseinander liegen dürfen bzgl Instructioncount....

Wir hatten das in der Vorlesung als deutlich weniger komplex behandelt. Da hatte man quasi nur einen Instructioncounter pro Block und nicht pro Warp und bei Branches wuder halt über Maskierung gearbeitet und gut war. Es wurden aber demnach immer alle Warps eines Blocks durch beide Zweige komplett durchgeschickt. Dem ist ja aber offenbar nicht so.

Macht aber natürlich das ganze Sheduling deutlich komplizierter.

Coda

2014-01-01, 12:38:12

Es gibt vier Warp-Scheduler pro SMX, nicht nur einen.

Und klar können unterschiedliche Warps unterschiedliche Pfade nehmen, aber nicht einer mehrere gleichzeitig.

Der State pro Warp ist halt Register-Offset ins Register-File + Instruction-Counter und das Scoreboard.

Bei einem local group sync werden halt alle Warps die bis zu diesem Punkt gelaufen sind schlafen gelegt bis alle angekommen sind.

Skysnake

2014-01-01, 16:14:42

AH jetzt...

Du bezogst dich in deiner Aussage nur auf EINEN Sheduler. Ok, so macht dein Text oben natürlich sinn. Den Bezug auf EINEN Sheduler hatte ich nicht verstanden.

Dann passt ja alles.

Ailuros

2014-01-02, 12:07:37

Ähm...

So ganz trivial ist das auch gar nicht :freak:

Also zumindest für KNC ist es nen ziemlicher act....

Mit KNL dürfte es einfach werden. Deutlich einfacher sogar, aber "einfach" würde ich es dennoch noch nicht ganz nennen, wenn auch kein Vergleich mehr zu aktuell!

Wenn men etwas zeitlich vorgesehen hat sehr frueh im design ist es durchaus trivial. AMD/NVIDIA enginners werden wohl nicht so naiv sein dass es keine der beiden Seiten je erwartet haette. Wenn man das ganze tuten und blasen Marketing von LRB von Anfang an verfolgt hat, ist es wirklich keine Ueberraschung mehr; nur kommt es eben mit 3-4 "LRB Generationen" Verspaetung.

Naja, Perf/W ist bei KNC auch "schwierig". So wirklich gute Vergleiche gibt es ja nicht. Es ist immer ein bischen Äpfel mit Birnen... Das GANZE! KNF Zeug und auch das frühe KNC Zeug muss man dazu auch noch raus lassen, sonst vergleicht man Äpfel mit Apfelblüten und wundert sich, warum Apfelblüten so komisch schmecken und so staubtrocken sind...

Das machts halt nicht gerade einfacher, da überhaupt den Überblick zu haben, wie man welche Daten überhaupt interpretieren kann bzgl. Perf/W. Letztenendes muss man sich wohl son Ding einfach holen und anschauen, wies für einen selbst passt. Die Daten so in der "Öffentlichkeit" kannste in die Tonne treten, zumindest das was ich gesehen habe, einfach weil man zu viele Randbedingungen nicht kennt....

Ich trete gar nichts in die Muelltonne. Intel's eigener Marketing-scheiss behauptet 14-16 GFLOPs/Watt (wo hab ich den exact gleichen Wert nochmal gehoert?) und insgesamt bis zu 200W pro SKU fuer KNL. Die Vorbehalte ist jetzt lediglich ob etwas von diesem ueberhaupt annaehernd stimmt. Da aber die direkte Konkurrenz vergleichbare Werte bis jetzt durch marketing vermittelt hat (welch Zufall!) wundere ich mich immer noch wo zum Henker der Prozess-Vorteil nochmal genau ist.

Naja, schau dir doch mal KNC, oder gar KNF an....

Welche Basis hat denn das Ding?
Wie sind denn manche Sachen gelöst?

Also der Weisheit letzter Schluss ist da so manches nicht. Da gibt es son paar Stellen, wo man sich denkt. WARUM?

Intel hat da noch einiges an Optimierunspotenzial in meinen Augen. Irgendwie erinnert mit das an nen BD-Clon aus nem Paralleluniversum :tongue:

Die Frage ist halt, was Intel jetzt daraus macht, und wie sich das Gesamtkonzept entwickelt. KNC und schon gar nicht KNF kann man so wirklich mit KNL vergleichen. Da ändert sich einfach nochmals gewaltig viel. Meint ihr ein VLIW5->VLIW4->GCN Vergleich würde es treffen? Kam mir gerade sehr bildlich in die Gedanken.

Siehe oben. Kommen Intel's HPC Loesungen frueher als die der Konkurrenz bis jetzt? Nein. Haben sie irgend einen sehenswerten perf/W Vorteil bis jetzt? Nein eher das Gegenteil. Aus irgend etwas muss der Prozess-Vorteil fuer Intel bestehen und komischerweise kann ich ihn immer noch nicht selbst fuer KNL deutlich identifizieren. Entweder fliegt mir ueber die vergangenen Jahre wichtiges ueber den Kopf vorbei oder wir koennen dass Prozess-Maerchen beruhigt begraben bis Intel wirklich einen sehenswerten Unterschied liefern kann. Mag sein dass es mit KNL schon so weit ist, aber ich will mich dann erstmal mit realen Daten ueberreden lassen.

TMUs usw sollte er noch haben.

Ansonsten sollte man sich eben auch nochmal überlegen, aus was denn nen DEEP-KNx Boosternode besteht, oder auch später nen KNL Node, und im Vergleich dazu mal nen nVidia Tesla oder auch AMD FirePro Node nehmen... Die Unterschiede sind schon eklatant.

Und bei nVidia seh ich nicht wirklich im kommenden Jahr standalone GPUs für den HPC-Bereich. Vielleicht 2015, eher 2016, und selbst dann würde ich es nicht mit nem KNL vergleichen wollen.

Bei AMD geht die Sache eher in Richtung APU meiner Meinung nach, an die halt ne nochmals dickere dGPU noch rangeflanscht werden kann bei Bedarf, aber die iGPU schon nen guten Grundstock bildet. DAs wird spannend vor allem mit HSA, wie sich das jetzt genau entwickelt in 2014 und 2015.

Hast Du schon einen festen Lieferungs-termin fuer KNL? Wenn dieser eigenhalten wird schoen und gut, aber davor gilt wie ueberall "wenn alles nach Plan laeuft".

Ich seh da eigentlich nen Machtkampf zwischen Intel mit Xeon+XeonPhi auf der einen Seite und HSA auf der anderen Seite. nVidia wird da schlicht dazwischen zerrieben. Das ist zumindest meine Aussicht auf die Dinge.

Und ja ich schreib bewusst HSA und nicht AMD. AMD hat allein gar keine Chance... Deswegen ärgert es mich um so mehr, das nVidia nicht doch noch auf den HSA Zug aufspringt... Das schwächt HSA vs. Intel nur unnötig... Denn das Letzte was wir gebrauchen können wäre ein Intel das nVidia auch noch schluckt...

Dann lieber nViida bei HSA, die ihre (i)GPUs als Konkurrenz zu ARM usw anbieten für Qualcomm, Samsung, TI und sogar AMD, in freudiger Mischung der jeweiligen ARM und x86 CPUs. So könnte sich nämlich nViida eventuell sogar nen x86 SOC besorgen... Wäre zumindestens wünschenswert!

Wenn ich mir die founding members von HSA und ihr eigentliches Kerngeschaeft so ansehe, bezieht sich die eigentliche Interesse eher auf die Maerkte wo das eigentliche Volumen liegt: ULP SoCs und mainstream consumer products. Was soll den Samsung, Mediatek oder Qualcomm genau besonderes mit servers bzw. x86 genau am Hut haben?

Nebenbei:

http://www.xbitlabs.com/news/cpu/display/20131230135420_AMD_Will_Reduce_Focus_on_High_Performance_Multi_Core_Chips_for_Se rvers.html

Sonst braucht nach der obrigen Logik NVIDIA fuer die Zukunft nicht besonders viel von HSA so lange ARM ein Mitglied ist und sie custom CPU cores (Duke Denver Forever) endlich aufs Laufbahn bringen.

Insgesamt wuerde ich eher sagen dass je mehr diverse IHVs Erfahrungen im ULP SoC Markt sammeln koennen desto besser werden ihre ultra high end Produkte fuer perf/W. Hier sind eben Intel und NVIDIA noch lange kein Apple oder Qualcomm, ausser natuerlich dem ueblichen fetten Batzen an nutzloser heisser Luft durch PR/marketing auch fuer diese Maerkte.

Coda

2014-01-02, 13:29:52

Intel hat einen Prozessvorteil, sonst könnten sie nicht aus so einer ineffzizienten Architektur vergleichbare Leistung rausholen.

Und das mein ich nicht mal vollständig negativ, es gibt ja auch durchaus Vorteile wie globale Cache-Kohärenz und freies Thread-Scheduling ohne blocks/warps.

Ich halte das halt nicht für wichtig genug um diesen Weg zu gehen. Gerade die Cache-Kohärenz führt mit Sicherheit zu mehr Latenz bei der LSU. Und 70 x86-Decoder und der ganze Legacy-Scheiß sind dann auch nicht umsonst, vor allem wenn sowas wie GCN da praktisch null Overhead hat.

Skysnake

2014-01-02, 13:48:14

Den "Legacy-Scheis" würde ich jetzt nicht mal als so schlimm ansehen. Da gabs von Intel auch mal ne Folie zu, auf dem Sie meinten, dass das gesamt sich im niedrigen einstelligen Prozentbereich abspielt, und das kann ich mir durchaus vorstellen. Man kann ja extrem viel einfach wiederverwenden, das man eh für anderes Zeug braucht.

Ich seh da die Cache-Kohärenz und auch son paar andere Sachen an sich eher als Problematisch an, die halt daher kommen, dass das noch auf nem asbach Pentium aufbaut. Interrupts sehen z.B. etwas "seltsam" aus.

Bei der Art und Weise, wie das µLinux drauf läuft, wird man wohl auch noch einiges zu optimieren haben. Die Corenummerierung sieht stellenweise seltsam aus, und auch sonst gibt es paar Sachen, die einen am Kopf kratzen lassen.

Überhaupt das Prozessmapping auf das Ding ist nicht ganz uninteressant. Man hat halt den ollen Ringbus, und das sind schon so manche Hops auf KNC. Die Crossbars auf den GPUs sind da schon etwas, über das man sich von der Softwareseite her weniger Gedanken machen muss.

Wenn ich irgendwann mal Zeit habe, will ich mir eigentlich das Prozessmapping mal anschauen und wieviel man da noch rausholen kann, aber ich befürchte ich werde nicht wirklich in 2014 Zeit finden -.-

Und mit KNL ist das Zeug dann ja auch eh wieder recht uninteressant, wegen den vielen Änderungen... Da muss man sich schon überlegen, ob es Sinn macht, da zich Stunden/Tage an Arbeit rein zu stecken.

Coda

2014-01-02, 13:57:28

Den "Legacy-Scheis" würde ich jetzt nicht mal als so schlimm ansehen. Da gabs von Intel auch mal ne Folie zu, auf dem Sie meinten, dass das gesamt sich im niedrigen einstelligen Prozentbereich abspielt
Marketing-Bla. Selbst Forsyth hat sich darüber beschwert und der war direkt an LRB beteiligt.

Die ganze x87-Geschichte mit dem Register-Stack, 1-15 byte instruction length, 16, 32 und 64 Bit Modus inkl. aller komischen Modi (virtual 16 bit, pae, etc.) können nicht umsonst sein. Selbst wenn es nur 3% wären gibt's da die eine oder andere Pipeline-Stage die Strom verbraucht um das zu behandeln.

Bei dicken Cores ist das egal, die haben eh schon out of order execution etc. aber eben nicht bei einer durchsatzorientierten Architektur. Da will man das die Instruction möglichst direkt die richtigen Status-Leitungen setzt und weiter geht's.

Skysnake

2014-01-02, 14:37:23

Naja, bei so nem Ding wie KNC mit den 61 Cores sind Caches und Interconnect meiner Meinung nach schon deutlich wichtiger als die ALUs an sich.

Das bischen Legacy Zeug würde mir da wirklich keine Kopfschmerzen machen. Der Softwaresupport dankts dir. Zumal man am Pentium Core auch nicht so viel hat rumschrauben müssen. Da gibts meiner Meinung nach ganz andere Baustellen als das. Allein das man für die 512 Bit Register Maskierungen braucht, aber z.B. nicht wie seit Nehalem schon POPCNT. Da fasste dir schon an den Kopf, wenn du das siehst. Sowas ist durchaus ganz nützlich. Aber Pustekuchen. Das wird halt nicht unterstützt.

Für mich fällt KNC zu nem guten Grad noch unter die Quick&Dirty Kategorie, weil LRB halt son krasser Reinfall war.

Mit KNL werden die nen riesen Sprung nach vorne machen. Dann kann man auch richtig mit dem Finger auf Sie zeigen, wenn Perf/W nicht gut sind usw. Davor würde ich mich nicht in trügerischer Sicherheit wiegen.

Zumal das Ding eigentlich relativ straight forward laufen sollte, wenn man die 512 Bit Register benutzt.

PS:
Noch was zu Perf/W. Powermanagement sollte man bei nem Ding wie MIC nicht unterschätzen. In der "frühen" Entwicklungsphase ist das aber nicht unbedingt mit hoher Priorität bei den Samples geschlagen... Das sollte man im Hinterkopf behalten, wenn man irgendwelches Material raus sucht.

Alle Perf/W Aussagen, die nicht mit dem "finalen" XeonPhi Softwarestack gemacht wurden, würde ich mit SEHR viel Salz geniesen, oder direkt in die Tonne treten...

Da stimmt zwar das eine oder andere, ist aber oft nur die halbe Wahrheit... Wobei ich mir nicht anmaßen will, zu unterscheiden, ob die Leute das wissen und schlicht klicks generieren wollen, oder es einfach nicht besser wissen.

Coda

2014-01-02, 14:51:33

We agree to disagree :)

Skysnake

2014-01-02, 15:11:49

Ist ja auch nicht schlimm in diesem Fall ;) Zumindest für mich :ugly:

Ich kann deine Sichtweise ja durchaus nachvollziehen. Ich seh halt nur den Schritt von KNF zu KNC, der schon groß war und blicke dann noch auf KNL.

In 2 Jahren wissen wir ja wies läuft, und wer eher richtig lag :up:

Coda

2014-01-02, 15:28:35

Wie gesagt wegen dem Fertigungsvorteil glaube ich trotz dieser verschwenderischen Taktik, dass sie Erfolg haben können.

Nur bin ich eben nicht der Meinung, dass die Programmierung wesentlich einfacher ist und glaube dass es der falsche Weg ist was die Hardware angeht.

Gipsel

2014-01-02, 15:32:34

Ich trete gar nichts in die Muelltonne. Intel's eigener Marketing-scheiss behauptet 14-16 GFLOPs/Watt (wo hab ich den exact gleichen Wert nochmal gehoert?) und insgesamt bis zu 200W pro SKU fuer KNL. Die Vorbehalte ist jetzt lediglich ob etwas von diesem ueberhaupt annaehernd stimmt. Da aber die direkte Konkurrenz vergleichbare Werte bis jetzt durch marketing vermittelt hat (welch Zufall!) wundere ich mich immer noch wo zum Henker der Prozess-Vorteil nochmal genau ist.Man sollte da nicht aus dem Auge verlieren, daß KNL in intels 14nm FinFET Prozeß kommt. Und das sind im Gegensatz zu GFs 14XM oder TSMCs 16FF echte 14nm (also nicht 20nm mit FinFETs). Die haben schon einen riesigen Vorsprung in der Fertigung.
KNL verringert den Overhead gegenüber KNC vermutlich schon deutlich, auch weil dann einfach 2 Vektoreinheiten pro Kern werkeln. Aber auch das Design der Vektoreinheiten selber ist noch relativ gesehen näher an dem von CPUs (nur eben breiter und mit dem Maskierungkram, aber immer noch verdammt wenige Register, weswegen sehr leistungsfähige L/S-Einheiten und gute Anbindung an den L1 dringend nötig ist; das kostet mehr Strom als physisch näher liegende und direkt adressierte Register). Außerdem sitzt zwischen den Registerfiles und den Vektoreinheiten noch eine Shuffle-Unit, wo jeder Operand durch muß. Das ist für horizontale Operationen zwar ganz nett, aber sowas Stromfressendes kann sich nur intel erlauben (das ist ein Overhead für alle Operationen, der nicht nur anfällt, wenn es benutzt wird wie bei GPUs mit dem local memory oder den expliziten shuffle-Instruktionen, die die Datenleitungen des local memory nutzen).

Alles zusammen würde ich vermuten, daß AMD und nV in planaren 20nm bei den GFlops/W nicht weit hinten liegen werden gegenüber KNL mit FinFETs in 14nm (was prinzipiell eine doppelte Dichte ermöglicht und transistortechnisch locker 1,5 Generationen weiter ist). Wo intel ohne Fertigungsvorsprung wäre, könnte man vielleicht ganz grob am Vergleich von KNC mit 22nm FinFETs mit den kommenden 20nm Designs (planar) von AMD und nV ablesen ;). Aber intel hat nunmal diesen Vorsprung, also wäre es etwas akademisch.

Coda

2014-01-02, 15:34:37

Gipsel was ist eigentlich deine Meinung bezüglich der einfacheren Programmierbarkeit?

Skysnake

2014-01-02, 15:48:24

Nicht nur das Gipsel.

Denk auch an den Near-Memory. Das wird die Perf/W auch deutlich anheben.

Und der Interconnect direkt mit im Chip/Package wird auch nochmal was reisen.

An sich ist der Interconnect so nah ja auch verständlich, aber Intel drückt da meiner Meinung nach auch massiv ihre Marktstellung und Größe durch... Mir schmeckt das gar nicht...

Wenn man sich mal son minimalen KNL Knoten anschaut, bleibt da nicht mehr viel. KNL mit Package, nen Mini-PCB von der Größe ner PCI-E Karte mit Stromversorgung und Anschlüssen und das wars auch schon :wow: Wenn man den RAM noch dazu nehmen will halt noch 4/8 RAM-Riegel und das wars dann auch schon.

Ach btw. ich bin mir da grad auch nicht mehr sicher. Soll die Spannungsregelung nicht auch in den Chip mit KNL?

Und genau hier bekommt doch AMD und vor allem nVidia richtig Probleme. Intel verschließt sich immer weiter. Teils aus Zwang zu Integration, aber natürlich auch sehr bewusst. Die haben halt wirklich ALLES! im eigenen Haus. Die können ohne Problem die Integration weiter treiben als jeder andere. Und genau da kann man halt wieder die Perf/W verbessern. Man sieht doch gut an der Green500 wie viel man durch derartige Anpassungen raus holen kann.

@Coda:
Im Prinzip stimme ich dir sogar zu. An sich ist das Modell das Intel verfolgt nicht das "richtige" für maximale Perf/W. Ich würde mir da deutlich mehr im Bereich der Speicherverwaltung wie bei OpenCL wünschen, wobei mir das nicht weit genug geht. Schlicht deutlich mehr Kontrolle WENN! ich es denn will, und halt wirklich allumfassende Doku, damit man wirklich versteht und weiß, was die Hardware denn nun am Ende wirklich genau macht, und vor allem warum.

Aber da treffen Wunsch und Realität aufeindener. Man hätte wohl viel zu wenige Leute, die das dann am Ende auch wirklich effizient nutzen können :(

Coda

2014-01-02, 15:54:22

Der Punkt ist selbst mit Intels Trade-Offs könnte man den Chip wesentlich effizienter designen wenn man nicht an x86 gekettet wäre.

Es ist nicht ausgeschlossen, dass AMD oder NVIDIA umdenken und doch L1-Cache-Coherency einbauen und die einzelnen Kerne für ein OS sichtbar machen. Wobei ich eher glaube, dass beide auf HSA setzen werrden.

Gipsel

2014-01-02, 15:54:48

Gipsel was ist eigentlich deine Meinung bezüglich der einfacheren Programmierbarkeit?
Ich denke Skysnake hat insofern recht (das hat er doch gesagt, oder?), als daß Leute aus der HPC-Ecke, die bisher auf CPU-Clustern gearbeitet haben, sich recht schnell mit MIC anfreunden können. Ein paar Regeln ändern sich zwar, aber sie bleiben in ihrem vertrauten Umfeld. Es gibt ein beträchtliches Beharrungsvermögen, was man nicht unterschätzen sollte. Vom Prinzip her muß man für optimale Performance auf MIC und GPUs zwar in etwa das Gleiche machen (high level Optimierungen, Design des Algo, generelles Datenlayout usw.), aber die Einstiegshürde für HPC-Leute könnte bei GPUs höher sein und diese zudem empfindlicher mit Performanceeinbrüchen reagieren (weil stärker auf Durchsatz getrimmt), wodurch Einige MIC präferieren könnten. Weiterhin ist am Ende des Tages MIC tatsächlich etwas flexibler, man kann also allen Scheiß darauf loslassen, auch wenn es mies performed und das für optimierten ("guten") Code nur eine recht kleine Rolle spielen sollte.

Coda

2014-01-02, 15:57:29

Nun gut, ich komm halt eher aus der anderen Richtung.

Übrigens sehr geiler Thread - war lange nicht mehr so nerdig ;)

Skysnake

2014-01-02, 16:23:56

/sign Kann ich mich NUR anschließen :up:

@Topic:
Coda, es wäre ein TRAUM! wenn nVidia zu HSA dazustoßen würde! Das wäre dann nämlich wirklich ein ernst zu nehmender Gegner für Intel. Also auch abseits vom Ultra-Mobile Bereich.

Aber so recht dran glauben kann ich das nicht. Das Argument mit ARM kann ich da auch nicht ganz teilen. Warum sollten dann Samsung, Qualcomm und TI bei HSA extra dabei sein? Klar, der CPU-Part von ARM wird wohl HSA-Kompatibel sein, aber nVidia wird wohl nicht ohne Mitgliedschaft ihren GPU-Part HSA konform auslegen können/dürfen.

@L1 Cache-Cohärenz.
Da bin ich anderer Meinung. Da verschenkt man unnötig viel. Ich finde es gerade interessant, das ich eben KEINE Cache-Cohärenz habe. Klar muss ich dann Syncs einbauen, aber eben auch nur wirklich da wo ich es auch wirklich brauche. So lange die also selten genug und performant genug vorkommen, ist das kein Problem.

Ich hatte lustigerweise ne ähnliche Frage bzgl Cache-Cohärenz in meiner Dipl-Prüfung :ugly: Da gings darum, wo man den L2 am geschicktesten hin packt. Da hat mir der Prüfer dann auch erst was von Cachecohärenz und bla blub erzählt, aber halt auch in dem Moment nicht bedacht, dass das Programmiermodell das ja gar nicht vor sieht!

Klar kann man das Modell wieder ändern, aber den Grundgedanken hinter OpenCL mit den explizieten Syncs halte ich für absolut richtig für den Code, der auch auf sowas läuft.

So muss man sich z.B. ja gar keine großen Gedanken um Cachetrashing durch andere Prozesse/Threads machen. Also zumindest nicht so wirklich.

Das empfinde ich teils als sehr angenehm.

Gipsel

2014-01-02, 16:38:08

Ich hatte lustigerweise ne ähnliche Frage bzgl Cache-Cohärenz in meiner Dipl-Prüfung :ugly: Da gings darum, wo man den L2 am geschicktesten hin packt. Da hat mir der Prüfer dann auch erst was von Cachecohärenz und bla blub erzählt, aber halt auch in dem Moment nicht bedacht, dass das Programmiermodell das ja gar nicht vor sieht!OT:
Erinnert mich irgendwie an meine Nebenfachprüfung für's Diplom (bin ja Physiker mit den Nebenfächern Chemie und Informatik). Kriege es zwar nicht mehr genau zusammen (zu lange [~12 Jahre] her), aber es ging irgendwie um virtual memory, page tables und so'n Kram. Habe mich da um irgendein Implementierungsdetail (TLBs?) mit dem Prüfer gestritten, wo er mir nicht glauben wollte, wie das in modernen CPUs gelöst ist. Marschierte dann mit einer 1,7 raus und dem Gefühl, da mehr zu wissen als der Prüfer :freak:.

Skysnake

2014-01-02, 17:04:35

Ja, war ganz lustig. Waren so die letzten 2-5 Minuten der Prüfung :ugly:

Keine Ahnung, wie wir noch drauf kamen, er dachte wohl es ist ne interessante Frage :biggrin: Hatten uns davor halt darüber unterhalten, das man bei GPUs lieber etwas nochmals berechnet als nen Wert aus dem Speicher/Register zu lesen, einfach weil man im Gegensatz zu CPUs praktisch nie Computebound aber fast immer Memory-Bandwidth-Bound ist.

Voll gut war, dass der Prüfer dann 2/3 Wochen weg war. Mir ist in der Zeit ständig das durch den Kopf gegangen, weil ich nicht verstanden habe, wie er auf seine "Lösung" gekommen ist. Also nach dem Urlaub hin und ihn gefragt, warum das so ist(es ging darum ob der L2 vor oder hinter nem Corssbar zwischen CUs und RAMcontroller liegt).

Ich so:
Wenn ich die auf die SEite der Ram-Controller pack, dann hab ich doch den Cache segmentiert und halt alle Daten nur einmal vor! Wenn ich ihn aber auf die Seite der CUs pack, dann sieht jede CU doch nur noch einen Slice und nicht mehr alles! Also sinkt die Effizienz des Caches, und seine effektive Größe..

Er so:
Ja, aber dann kann man nicht so schön eine Cachecohärenzdomaine implementieren.

Ich:
Und wo soll das was bringen?

Er:
Öhm... also mir fällt grad kein Beispiel ein aber..

Ich ins Wort Fall:
Ne Cachekohärenz bringt mir zwischen den CUs doch eh nichts. Das Ergebnis ist doch da eh NIE definiert, weil das Programmiermodell das gar nicht vorsieht ohne expliziete Syncs...

Er:
Hm... Moment mal.. *denk**denk* Öhm... ja. Hm... Das stimmt wohl, da lag ich dann wohl falsch, daran hab ich gar nicht gedacht. *und geht mit einem lächeln auf dem Gesicht und Kaffee trinkend weg.*

Ich:
:ugly:
WTF? (ja, das hab ich gesagt ;D) *Nich sein ernst? Ist ihm die Frage grad so spontan in der Prüfung eingefallen?*

Bin btw auch mit ner 1,3 oder 1,7 raus. Da hab ich mir dann auch gedacht: Cool. Hätten wir das da direkt geklärt, wäre es sicherlich die 1,0 geworden.

Aber wer fängt schon das Diskutieren in ner Prüfung an? ;D

EDIT noch was onTopic: ;)
Nun gut, ich komm halt eher aus der anderen Richtung.

Übrigens sehr geiler Thread - war lange nicht mehr so nerdig ;)
Das ist hier auch das "Problem". Du bist da einfach zu sehr in GPGPU drin. Für dich ist das alles sonnenklar, aber für viele ausm HPC- oder allgemein wissenschaftlichen Bereich nicht wirklich. Wenn ich mir anschau, wieviel da auf MatLAB usw setzen, dann graust es einem teilweise. Das ist halt deutlich schneller implementiert und man muss sich nicht so viel/keine Gedanken um die numerische Stabilität der Lösungen machen. Dafür ist das Zeug aber wohl teilweise schnarch langsam...

Ich hatte mal nen Praktikum, da hat der Betreuer was von MatLAB nach C/C++ portiert. Nach ~1 Jahr Arbeit waren Sie sowas um den Faktor 30 schneller :ugly: Das "Programm" wurde halt von irgendwelchen Biologen geschrieben, dass die Daten ausgewertet hat. Auf sowas trifft man aber halt an jeder Ecke... Und die Leute dies wirklich drauf haben versinken in Arbeit.

Deswegen gehe ich auch davon aus, dass du nen guten Haufen an Kohle im Jahr nach Hause bringst Coda ;) Wobei ich mich schon frag, ob du nicht wo anders mehr verdienen könntest mit den GPGPU und Multithread usw Kenntnissen.

mksn7

2014-01-02, 17:15:22

Mich wundert manchmal ein bisschen, dass Intel in KC soviel Legacy zeug reinpackt. AMD64 kombatibel ist man ja dann doch nicht, und man wird sowieso alles neu kompilieren was drauf laufen soll.

Aber dann könnte man ja nicht X86-kombatibel!!11 draufschreiben. Und man sieht halt auch, wo es an vielen Stellen wichtiger war, das Produkt fertig zu kriegen.

Mit dem Ansatz, den Intel verfolgt, werden sie nie eine höhere Effizienz als die GPUs herbekommen. Der Effekt der Fertigung dürfte in Zukunft weniger werden; Von einem Intelmenschen hab ich auf einem Vortrag zu Exascale mal die Prognose von einem Faktor 2.5 bis 2020 gehört. Das Argument mit dem Intel die Clusterbetreiber überzeugen will ist die Verwendbarkeit für gängige HPC Anwendungen. Gerade für General Purpose Cluster ist das sehr wichtig.

Edit zu den Kohärenzgeschichten: Der Phi hat interesanterweise die vmovnrngoapd ( move no read no global ordering) instruction, die zumindest das strong memory ordering aufhebt. Weiß nicht, ob es das bei den normalen CPUs auch gibt.

Skysnake

2014-01-02, 17:30:04

Ach KNC hat z.B. auch RAS drin. Das suchste bei normalen GPUs auch vergeblich. Allein damit haben Sie schon wieder ne kleine Marktniesche aufgestoßen.

Intel macht mit MIC so ein bischen das was IBM schon ewig macht. Schlicht alles an Technologie rein packen was man hat und die Konkurrenz damit erschlagen. Wenn man mal in einem Bereich etwas unlegen ist, weil das Ding scheis Komplex ist, ist es auch egal. Im Schnitt ist man einfach interessanter als die Konkurrenz. Wobei Intel das erst mit KNL so wirklich macht. Bei KNC und KNF hat man am CPU-Core an sich zu sehr gespart. Aber was erwartet man auch, wenn das Ding mal Larrabee war... Das sollte man ja auch nie ganz aus den Augen verlieren. KNF und auch KNC waren ja eigentlich mal als was anderes geplant. Dafür performt das Ding gar nicht so schlecht.

Ailuros

2014-01-02, 19:08:31

Man sollte da nicht aus dem Auge verlieren, daß KNL in intels 14nm FinFET Prozeß kommt. Und das sind im Gegensatz zu GFs 14XM oder TSMCs 16FF echte 14nm (also nicht 20nm mit FinFETs). Die haben schon einen riesigen Vorsprung in der Fertigung.
KNL verringert den Overhead gegenüber KNC vermutlich schon deutlich, auch weil dann einfach 2 Vektoreinheiten pro Kern werkeln. Aber auch das Design der Vektoreinheiten selber ist noch relativ gesehen näher an dem von CPUs (nur eben breiter und mit dem Maskierungkram, aber immer noch verdammt wenige Register, weswegen sehr leistungsfähige L/S-Einheiten und gute Anbindung an den L1 dringend nötig ist; das kostet mehr Strom als physisch näher liegende und direkt adressierte Register). Außerdem sitzt zwischen den Registerfiles und den Vektoreinheiten noch eine Shuffle-Unit, wo jeder Operand durch muß. Das ist für horizontale Operationen zwar ganz nett, aber sowas Stromfressendes kann sich nur intel erlauben (das ist ein Overhead für alle Operationen, der nicht nur anfällt, wenn es benutzt wird wie bei GPUs mit dem local memory oder den expliziten shuffle-Instruktionen, die die Datenleitungen des local memory nutzen).

Alles zusammen würde ich vermuten, daß AMD und nV in planaren 20nm bei den GFlops/W nicht weit hinten liegen werden gegenüber KNL mit FinFETs in 14nm (was prinzipiell eine doppelte Dichte ermöglicht und transistortechnisch locker 1,5 Generationen weiter ist). Wo intel ohne Fertigungsvorsprung wäre, könnte man vielleicht ganz grob am Vergleich von KNC mit 22nm FinFETs mit den kommenden 20nm Designs (planar) von AMD und nV ablesen ;). Aber intel hat nunmal diesen Vorsprung, also wäre es etwas akademisch.

Schoen sie sind transistorentechnisch im Vorsprung aber meine Frage bleibt nach wie vor wo der eigentliche "Vorteil" sein sollte wenn ich beispielsweise auf KNL@14nm und Maxwell@20-wasauchimmer genau die gleichen DP GFLOPs/Watt jeweils erreiche?

Ja natuerlich gibt es eine sinnvolle technische Erklaerung warum es moeglicherweise so weit kommt, es interessiert aber mich als Beobachter die Bohne wenn es sich fuer Intel nicht wirklich zum ausgepraegten grossen Unterschied fuehrt dank dem Prozess-Vorteil. Fuer mich als Laie bleibt ein Prozess nach wie vor ein sehr nutzvolles Mittel einen chip aufs Laufband zu bringen; mit den Fundamenten einer Architektur hat dieses verdammt wenig bis gar nichts zu tun.

Skysnake

2014-01-02, 19:40:35

Bei gleichem Perf/W Verhältnis in Linpack usw ist MIC ner normalen GPU vor zu ziehen, einfach weil das Ding nicht ganz so schnell einbricht und halt für viele Leute etwas einfacher zu entwickeln und optimieren ist.

Son GDB ist z.B. schon eine ziemliche Hilfe.

Für Leute wie Coda, Gipsel oder auch mich ist es im Prinzip wurscht ob jetzt da ne GPU von AMD/nVidia vor einem ist oder MIC, aber man muss eher davon ausgehen, dass der "0815"-Programmierer, der überhaupt Multithread programmieren kann, und dann sogar noch MPI beherrscht, in der Regel nichts mit GPGPU anfangen kann, weil er sich noch nie damit beschäftigt hat, und auch gar keine Zeit dafür hat.

Skysnake

2014-01-02, 19:41:58

Das Forum hängt :(

mksn7

2014-01-02, 20:09:41

Da bin ich zweimal andrer Meinung:

Wenn ich neuen Code schreiben will, würde ich eine GPU dem MIC vorziehen. Für alten Code andersrum.

Und wer MPI vernünftig programmieren kann, der kriegts auch auf GPUs hin. Da ist vielleicht das kleine Set von Leuten, das vor 15 jahren MPI programmieren gelernt hat und in in den letzten 5 jahren keine Lust gehabt hat was neues zu lernen.

Da gehts weniger um die Techniken die die Leute können, sondern um die Techniken die die Codes verwenden.

Gipsel

2014-01-02, 20:20:42

Wenn ich neuen Code schreiben will, würde ich eine GPU dem MIC vorziehen. Für alten Code andersrum.Weißt Du, wieviele Hunderte Millionen Codezeilen für HPC bereits existieren? Die meisten Bibliotheken haben ihren Ursprung irgendwann in den 70ern des vergangenen Jahrhunderts (weswegen da Unmengen an altem Fortran Code existiert, mit Glück hat es schonmal wer auf Fortran95 portiert). Das willst Du nicht alles von Grund auf neu schreiben, selbst wenn es ab und zu angebracht wäre (dann wird es nämlich oft überall schneller, weil die alten Codes für moderne Architekturen meist suboptimale Datenlayouts bzw. Zugriffsmuster haben). :rolleyes:
Und wer MPI vernünftig programmieren kann, der kriegts auch auf GPUs hin. Da ist vielleicht das kleine Set von Leuten, das vor 15 jahren MPI programmieren gelernt hat und in in den letzten 5 jahren keine Lust gehabt hat was neues zu lernen.Das sind die meisten Leute, kein "kleines Set".
Da gehts weniger um die Techniken die die Leute können, sondern um die Techniken die die Codes verwenden.Siehst Du, und das ist eben oft irgendein dubioser Fortran- oder auch C-Code mit angeflanschtem MPI. MPI ist seit zwei Jahrzehnten der defakto-Standard auf den HPC-Clustern.

del_4901

2014-01-02, 20:33:02

Das sind die meisten Leute, kein "kleines Set".

Alles Noobs: http://www.gamedev.net/blog/355/entry-2250592-become-a-good-programmer-in-six-really-hard-steps/
Commencing Step 5: Writing a functional HLSL dialect.

Skysnake

2014-01-02, 22:33:33

Siehst Du, und das ist eben oft irgendein dubioser Fortran- oder auch C-Code mit angeflanschtem MPI. MPI ist seit zwei Jahrzehnten der defakto-Standard auf den HPC-Clustern.
Und hat durchaus nicht mal ne Integration von PThreads, obwohl das ganz ordentlich Leistung bringen kann, wenn man statt MPI eben PThreads für die Arbeit auf einem Node verwendet. Aber es macht den Code halt gleich nochmal deutlich umfangreicher....

@mksn7:
Der Link von AlphaTier ist sehr gut!

Weist du wie viel die HPC Leuts schon oft können, bevor Sie überhaupt jemals mit GPUs in Berührung kommen?

C/C++, dazu nen bischen Assembler. MPI ist wie Gipsel schon richtig sagte die absolute Pflicht heutzutage, kannste also nicht weglassen, und wenn wir schonmal dabei sind, packste mal noch gleich PThreads und/oder OpenMP mit dazu, damit du nicht so viele MPI-Prozesse mit dir rumschleppen musst. Garnieren wird das Ganze dann noch mit nem bischen Linux, bash und noch irgend ner weiteren Skriptsprache. Ach und Fortran dürfen wir natürlich auch nicht vergessen, weil halt immer mal wieder so oller "alter" Code aufschlägt...

So "lustige" Sachen wie Batchsysteme, Storage usw usw usw lassen wir mal lieber unter den Tisch fallen, das hat man ja immerhin in einigen Wochen/Monaten wirklich drin.

Der ganze Rest beschäftigt dich aber bereits Jahre, wenn nicht gar Jahrzehnte... Ist ja auch nicht so, als ob da nicht immer mal wieder was Neues dazu kommen würde....

Du hast allein schon mit C/C++, Fortran(95), MPI, OpenMP und PThreads nen ARSCH! voll zu tun um das wirklich intus zu haben und "schnell" produktiven Code erstellen zu können... Musst ja auch immerhin all die ganzen anderen Tools wie Make, autotools, GCC/ICC, GDB, Valgrin usw usw beherrschen, um eben schnell und effizient arbeiten zu können. Ist ja nicht so, als ob man beliebig Zeit hätte.

Und da sollte dir dann "mal eben" noch CUDA UND OpenCL aneignen, weil sich die nVidia nicht dazu herab begeben kann, OpenCL voll zu supporten ohne Einschränkung?

Ja ne ist klar... Bist du allein CUDA oder OpenCL wirklich beherrscht, und nen Gefühlt dafür hast, wie du vorgehst, kannste locker Monate wenn nicht Jahre rechnen, um eben wieder Erfahrung zu sammeln. Aber das hilft dir auch wiederum nichts, weil ständig! was Neues kommt bei GPUs. HSA steht z.B. schon vor der Tür, was du dir konsequenterweise auch mal gleich reinziehen solltest...

Merkste was? Das kann niemand wirklich alles gut beherrschen. Vor allem braucht es wirklich viel Zeit, sich auf dem laufenden zu halten. Und das schon ganz ohne Späße wie eben Filesysteme und Grafikausgabe.

Das kommt ja auch noch am Besten in Form von QT oder gar gleich OpenGL dazu.

Ich hatte auch mal den elan noch neben QT und OpenGL mir DX in den Grundzügen anzueignen, aber das hab ich gleich gestrichen. Man hat einfach gar nicht die Zeit dafür, und das sag ich als Student, der deutlich mehr Zeit halt als jemand der berufsmäßig Entwickler ist.

Du stellst dir das glaub ich echt viel zu einfach vor....

Gipsel

2014-01-02, 23:13:54

Ach und Fortran dürfen wir natürlich auch nicht vergessen, weil halt immer mal wieder so oller "alter" Code aufschlägt...Es wird auch immer noch eine Menge neuer Fortran-Code geschrieben ;). Sieht aber inzwischen vermutlich erheblich besser aus als das, was mir mal über den Weg gelaufen ist (war irgendein Quantenmechanik [Dirac-Fock]-Code aus den 70ern, damals wohl für das Äquivalent von HPC, heute auch bequem auf einem PC schnell genug). Habe nie rausbekommen, welche Fortran-Version das genau war (ein F95-Compiler hat es nach ein paar Anpassungen gefressen). Das waren nur ~20kB Code oder so, aber ich habe auch durch intensives Draufschauen nicht wirklich rausbekommen, wie und warum er funktioniert (mußte ich zum Glück auch nicht). Okay, es hat nicht geholfen, daß es eine eingekürzte Version eines noch älteren Codes war, bei dem eventuell hilfreiche Kommentare fehlten (und ich nicht wirklich ein Experte in diesem Theorie-Gebiet bin). Der Prolog des längeren Original-Codes sagte übrigens, daß es wohl mal auf 2804 Lochkarten (für die Jüngeren unter uns, die das noch nie gehört haben, Wikipedia hilft ;)) gepaßt hat ;D.

mksn7

2014-01-02, 23:20:53

Weißt Du, wieviele Hunderte Millionen Codezeilen für HPC bereits existieren? [...]

Hast du meine These falsch vertanden? Genau das war eigentlich meine Aussage: Die ganzen alten Codes auf GPU zu portieren, ist in der Regel nicht praktikabel. Aber für den Phi bekommt man das wohl angeblich in "hours or days" zumindest mal zum kompilieren und zum laufen, wenn auch ohne weitere Arbeit meistens erstmal langsamer.

Die Probleme wie Datenlayout sind dann natürlich auch wieder die gleichen. Ohne ein kontinuierliches SoA Layout kommt man auch auf dem Phi nicht weit.

Ok, ihr hab Recht, es gibt wahrscheinlich einen ganzen Haufen Leute, die sich mit MPI auskennen, aber keine GPU programmierung können. Als jemand der Beides mehr oder weniger gleichzeitig gelernt hat (und natürlich nicht zur Perfektion behersche), finde ich GPU programmierung nicht schwieriger als guten Cluster code zu schreiben.

Edit: Den Fortranprogrammierer der alten Schule erkennt man oft an den kryptischen, kurzen Variablennamen in all caps. Ist doch klar was "ADGDR" bedeutet.

Skysnake

2014-01-02, 23:22:52

LOL ;D

Aber sowas kenne ich. Nen Studienkollege, der vor kurzem fertig geworden ist, hatte nen alten Astrocode, den er anpassen sollte. Er hätte fast seine Dipl-Arbeit verkackt, weil das Ding schlicht nicht funktioniert hat... Er musste sogar für 2 Wochen extra in die USA fliegen, damit er mit einer Doktorantin, die was mit dem Code-Teil gemacht hatte das durcharbeiten konnte. :ugly:

Am Ende hat sich dann rausgestellt, dass es ne Funktion für einige Parameter schon in der Urfassung der Programms gab, irgenwo dann aber statt der parametrisierten Funktion halt fixe Werte übergeben wurden ;D

War halt "doof", dass das bis zu seiner Arbeit halt nie wirklich benutzt/gebraucht wurde und daher NIE aufgefallen ist :ugly: Ist ja nur so 30 Jahre alter Code oder so :ugly:

PS:
ich hatte das "alter" bewusst in Anführungszeichen gesetzt ;)

EDIT:
@mksn7:
Was ist denn für dich "guter Cluster code"?

Ansonsten überleg dir mal, wieviel Software wirklich von Grund auf neu geschrieben wird. Das wird nicht mal 1% aller Softwareprojekte sein. 0,000001% halte ich da für wahrscheinlicher. Der Rest wird an bestehendes ran geflanscht und angepasst. Das was man ja oft bei GPGPU sieht ist, das man eben bestehenden Code nimmt, bei dem man schon weiß, wo die Hot-Spots sind, die eben überhaupt sinn machen, GPUs zu verwenden.

Direkt mit ner GPU-Implementierung beginnt kaum wer. Man muss ja überhaupt erstmal abschätzen können, wie lange etwas überhaupt braucht, und ob man überhaupt GPUs sinnvoll verwenden kann.