Vorträge der Meeting C++ 2014

[Xin]

Moin,

Alle Videos der Meeting C++ 2014 sind nun bei Youtube verfügbar.

Wer mal reinschauen mag: Playliste der Meeting C++

[Onraku]

In Bezug auf "Plain Threads are the GOTO of todays computing - Hartmut Kaiser - Keynote Meeting C++ 2014:

Zum meinem Verständnis: Kern A unterbricht nach Erreichen eines "Futures" von Kern B seinen Thread A0 und beginnt mit Thread A1, und wenn diese Zukunft, oder Abhängigkeit dann eintritt, folgt Kern A wieder Thread A0. Damit "der Faden nicht verloren geht", übernimmt Kern B dann A1.
So werden sequenzielle Bindungen unterbrochen, und alle Kerne müssen nicht warten und arbeiten wirklich parallel.Es entsteht ein Dependency-tree der Threads.

Was ist mit Fällen, in denen A1 kurz vor Ende ist, und an einen anderen Kern weitergegeben wird? Könnte man hier Overhead streichen in dem man die kurze Wartezeiten zur Rückgabe von B nach A akzeptiert? Dadurch wird Thread A1, der ja auch irgendwo herkommt nicht so lange hin und her geschoben. Kann man Threadlaufzeiten gewichten und gezielt zur passenden Idletime vergeben? Oder lineare, wenig verzweigte Threads als Idletime-füller genutzt werden?

Mein Programmierniveau ist ja längst nicht da um mitzureden, aber so wie der Kaiser höhere Abstahierung fordert und ja auch liefert, und sogar seinen Vortrag für mich zugänglich hält, klingt die weitere Optimierung - und ein apokalyptisches Pferdebein zu brechen - auch 'nur' nach einem "Rucksack-Problem". Was ist mir da "wegabstrahiert"?

[Xin]

In Bezug auf "Plain Threads are the GOTO of todays computing - Hartmut Kaiser - Keynote Meeting C++ 2014:

Zum meinem Verständnis: Kern A unterbricht nach Erreichen eines "Futures" von Kern B seinen Thread A0

Ein Future ist ein Wert, der in der Zukunft verfügbar sein wird, aber im Moment der Zuweisung noch nicht zwangsläufig vorliegen muss. Man kann erstmal die Funktion rufen, die den Wert berechnet, wenn man weiß, dass man den Wert später noch brauchen wird. Dann kann man sich mit anderen Dingen beschäftigen.

Irgendwann kommt man zu dem Punkt, ab den man den Future-Wert nun tatsächlich braucht. Mit etwas Glück ist die Funktion um den Wert zu bestimmen bereits gelaufen und der Wert ist eingetroffen. Falls nicht, muss man warten, bis der erwartete Wert eintrifft.
Falls man Warten muss, kann der CPU-Kern eine andere Aufgabe lösen.

Was ist mit Fällen, in denen A1 kurz vor Ende ist, und an einen anderen Kern weitergegeben wird? Könnte man hier Overhead streichen in dem man die kurze Wartezeiten zur Rückgabe von B nach A akzeptiert? Dadurch wird Thread A1, der ja auch irgendwo herkommt nicht so lange hin und her geschoben. Kann man Threadlaufzeiten gewichten und gezielt zur passenden Idletime vergeben? Oder lineare, wenig verzweigte Threads als Idletime-füller genutzt werden?

Das Hauptproblem ist erstmal nicht, dass Threads hin- und hergereicht werden, sondern dass Kerne überhaupt belastet werden. Eine moderne CPU hat 8 Kerne. Ein einfacher Thread kann also maximal 12,5% Rechenleistung aus der CPU rausholen und 87,5% bleiben idle. Nehmen wir an, dass 50% der Leistung der CPU alleine für das Verschieben von Threads verbraten würden, so hätte man die Ausführgeschwindigkeit des Programms bereits vervierfacht.
Zukünftige Rechner werden eher mehr Kerne als mehr Geschwindigkeit pro Kern bieten. So wird sich irgendwann nicht mehr die Frage stellen, auf welchen Kern wir welchen Task schicken, sondern wie wir möglichst viele Kerne einer CPU überhaupt beschäftigt bekommt. Wenn eine CPU irgendwann 65536 Kerne hat (2^16), bedeutet der einfache Task, dass nur nur 0,0015 % der CPU ausnutzbar sind.

Hartmut Kaiser führt an, dass aktuelle Supercomputer 3'200'000 Kerne haben und die Rechenleistung von Supercomputern von vor 20 Jahren heute in einem iPhone 6 stecken. Das bedeutet, dass wir damit Rechnen müssen, dass in 20 Jahren ein iPhone 20 3,2 Millionen CPU-Kerne haben könnte und wir mit einem einfachen Task, das Händi zu Tode langweilen würden, weil die 3199999 anderen Kerne den Akku leer idlen würden.

Was ist mir da "wegabstrahiert"?

Nichts. Vielleicht die Erkenntnis, dass im Single Task der Stackframe eine Liste von Funktionsaufrufen ist und bei Futures ein Baum. In jedem Fall findet jeder den Ort wieder wo es weitergeht, nämlich die eigene Wurzel und die Wurzel stoppt dann, wenn das Ergebnis für die Wurzel erforderlich ist.
Es gibt also keine Chance, dass sich die Threads gegenseitig ein Bein stellen könnten.

[Onraku]

Naja, die Geschwindigkeit/Kern stagniert ja jetzt schon, Moore's Law gilt immer weniger (zumindest nicht als v/core, als v/cpu schon), und bis es Quantencomputer gibt steigt eben die Azahl der Kerne.

Das bedeutet, dass wir damit Rechnen müssen, dass in 20 Jahren ein iPhone 20 3,2 Millionen CPU-Kerne haben könnte und wir mit einem einfachen Task, das Händi zu Tode langweilen würden, weil die 3199999 anderen Kerne den Akku leer idlen würden.

Genau das wird doch passieren, zumindest im Meer von Amateurapps (die haben aber Rechtfertigung durch den eigenen Lerneffekt beim coden) und Billigapps. Was fehlt ist dann mal wieder der nächste Schritt auf der "High-Level-Leiter": das Coremanagement muss der Next-Generation-Compiler mit dem OS im Hintergrund ausmachen.
Was dort passiert, darauf wollte ich mit mit meiner Frage eigentlich hin: Optimierung durch weniger Verschieben von Threads. Wenn mehr verwaltet, als gerechnet wird - hier nennst Du 50% - liegt das näher an meinem Vorurteil eines Vorstadt-Rathauses als an meiner Vorstellung einer modernen CPU. Daher mein Gedanke an weniger "Bürokratie".
Vorraussetzung scheint mir aber zu sein, zu wissen wie lange ein Thread läuft, bzw zu wissen wann ein Future-Wert eintrifft.

Falls man Warten muss, kann der CPU-Kern eine andere Aufgabe lösen.

...die nicht nicht unbedingt fertig wird. -> Hin und Herschieberei

OK, wenn das Hauptproblem ist, überhaupt alle Kerne mit Arbeit zu versorgen fällt das erstmal auf den Programmierer zurück. Hartmut Kaiser führt aber auch an, das Menschen eben nicht gerade geübt sind viele Dinge gleichzeitig zu tun, und auch in 20 Jahren will niemand 2^16 Tasks manuell verwalten, geschweige denn 3,2*10^6 Tasks oder vielleicht 2^24 wenn das bis dahin der Fall sein wird. Vielleicht währen Bienen- und Ameisenköniginnen die besseren Programmierer für sowas. Vielleicht liegt aber auch gerade in diesen "Hive-Minds" (ob nun wie bei Star-Treks Borg mehr oder weniger telepathisch, oder bei Staatenbildenden Insekten durch Pheromone, oder der CPU durch die Schltung von Transistoren) der Schlüssel darin, einen Überblick über das ganze Chaos zu finden. Unser Hirn lässt ja auch noch jede Menge Fragen offen, und es wäre ja nicht das erste Mal, das Ingenieure das Beste rauskitzeln, in dem sie auf Entwicklungsarbeit von 6 Milliarden Jahren zurück greifen...

[Xin]

Naja, die Geschwindigkeit/Kern stagniert ja jetzt schon, Moore's Law gilt immer weniger (zumindest nicht als v/core, als v/cpu schon), und bis es Quantencomputer gibt steigt eben die Azahl der Kerne.

Soweit ich weiß, hat sich Moore auf die Rechnergeschwindigkeit festgelegt, nicht auf die Art und Weise, wie dies umzusetzen ist.
Quantencomputer lösen andere Computer nicht ab, Quantencomputer lösen Probleme, die mit Quantencomputern lösbar sind. Ein "Hello World" ist nicht unbedingt ein Problem, welches mit Quantencomputern optimal zu lösen ist, aber eins, was im Alltag häufiger vorkommt.

Das bedeutet, dass wir damit Rechnen müssen, dass in 20 Jahren ein iPhone 20 3,2 Millionen CPU-Kerne haben könnte und wir mit einem einfachen Task, das Händi zu Tode langweilen würden, weil die 3199999 anderen Kerne den Akku leer idlen würden.

Genau das wird doch passieren, zumindest im Meer von Amateurapps (die haben aber Rechtfertigung durch den eigenen Lerneffekt beim coden) und Billigapps. Was fehlt ist dann mal wieder der nächste Schritt auf der "High-Level-Leiter": das Coremanagement muss der Next-Generation-Compiler mit dem OS im Hintergrund ausmachen.
Was dort passiert, darauf wollte ich mit mit meiner Frage eigentlich hin: Optimierung durch weniger Verschieben von Threads. Wenn mehr verwaltet, als gerechnet wird - hier nennst Du 50% - liegt das näher an meinem Vorurteil eines Vorstadt-Rathauses als an meiner Vorstellung einer modernen CPU. Daher mein Gedanke an weniger "Bürokratie".

Bei einem Computer, der mehr Kerne als Aufgaben hat, wird es keine Verschieberei geben. Es stellt sich die Frage, ob es sich lohnt ein temporäres Problem zu lösen. Und die Zahl, die ich nannte war exorbitant hoch angesetzt, damit sie nicht in Zweifel gezogen wird. Und selbst dann habe ich Vorteile.

Amateur-Apps werden amateurhaft programmiert. Darum darf man sich Gedanken machen, ob man als professioneller noch Goto verwendet, obwohl viele Amateure das früher getan haben.

Vorraussetzung scheint mir aber zu sein, zu wissen wie lange ein Thread läuft, bzw zu wissen wann ein Future-Wert eintrifft.

Falls man Warten muss, kann der CPU-Kern eine andere Aufgabe lösen.

...die nicht nicht unbedingt fertig wird. -> Hin und Herschieberei

Nein, wenn ein Future nicht zeitig fertig wird, muss der das Future nutzende Thread warten. Es wird nichts geschoben. Es wird gewartet. Man kann einen Wert nur ausrechnen und solange das dauert, muss man halt warten. Aber alles andere hat man in der Zwischenzeit bereits gleichzeitig erledigen können - darauf muss man nachfolgend nicht mehr warten.

OK, wenn das Hauptproblem ist, überhaupt alle Kerne mit Arbeit zu versorgen fällt das erstmal auf den Programmierer zurück. Hartmut Kaiser führt aber auch an, das Menschen eben nicht gerade geübt sind viele Dinge gleichzeitig zu tun, und auch in 20 Jahren will niemand 2^16 Tasks manuell verwalten, geschweige denn 3,2*10^6 Tasks oder vielleicht 2^24 wenn das bis dahin der Fall sein wird.

Ich vermute, dass sich die Frage anders stellen wird. Man wird einfach alles gleichzeitig anwerfen. 1+2 rechne ich jetzt nicht aus, ich deligiere das. Anschließend delegiere ich, dass das Ergebnis *5 genommen wird. Bis der zweite Delingierte das Ergebnis braucht, hat der erste das Ergebnis geliefert.
Das bringt Overhead. Das macht CPUs erstmal langsamer. Aber CPUs werden das optimieren. Und dann ist eine Rechnung wie ein Baum. Nehmen wir an, jeder Knoten deligiert 2 Subknoten und dafür braucht man pro Knoten die hundertfache Leistung für die ganze Bürokratie, als würde man es seriell bearbeiten, dann muss die CPU auch hundertfach soviel Rechenzeit investieren.
Nehmen wir nun an, die Berechnung braucht 40'000'000 Recheneinheiten, dann braucht die parallelisierte 4'000'000'000 Milliarden Recheneinheiten. Verteilt auf 65536 Cores bleiben rund 700000 Recheneinheiten, die gewartet werden muss gegenüber 40 Millionen.
Die CPU muss deutlich mehr arbeiten, aber sie ist bedeutend schneller fertig.
Und man muss auch nicht überlegen, was man tut, man parallelisiert einfach jeden Scheiß.