Moin,
Alle Videos der Meeting C++ 2014 sind nun bei Youtube verfügbar.
Wer mal reinschauen mag: Playliste der Meeting C++
Vorträge der Meeting C++ 2014
- Xin
- nur zu Besuch hier
- Beiträge: 8862
- Registriert: Fr Jul 04, 2008 11:10 pm
- Wohnort: /home/xin
- Kontaktdaten:
Vorträge der Meeting C++ 2014
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Re: Vorträge der Meeting C++ 2014
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"?
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
![Twisted Evil :twisted:](./images/smilies/icon_twisted.gif)
![Rolling Eyes :roll:](./images/smilies/icon_rolleyes.gif)
- Xin
- nur zu Besuch hier
- Beiträge: 8862
- Registriert: Fr Jul 04, 2008 11:10 pm
- Wohnort: /home/xin
- Kontaktdaten:
Re: Vorträge der Meeting C++ 2014
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.Onraku hat geschrieben: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
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.
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.Onraku hat geschrieben: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?
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.
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.Onraku hat geschrieben:Was ist mir da "wegabstrahiert"?
Es gibt also keine Chance, dass sich die Threads gegenseitig ein Bein stellen könnten.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Re: Vorträge der Meeting C++ 2014
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.
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.
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...
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.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 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.
...die nicht nicht unbedingt fertig wird. -> Hin und HerschiebereiFalls man Warten muss, kann der CPU-Kern eine andere Aufgabe lösen.
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
- nur zu Besuch hier
- Beiträge: 8862
- Registriert: Fr Jul 04, 2008 11:10 pm
- Wohnort: /home/xin
- Kontaktdaten:
Re: Vorträge der Meeting C++ 2014
Soweit ich weiß, hat sich Moore auf die Rechnergeschwindigkeit festgelegt, nicht auf die Art und Weise, wie dies umzusetzen ist.Onraku hat geschrieben: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.
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.
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.Onraku hat geschrieben: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.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 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".
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.
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.Onraku hat geschrieben:Vorraussetzung scheint mir aber zu sein, zu wissen wie lange ein Thread läuft, bzw zu wissen wann ein Future-Wert eintrifft....die nicht nicht unbedingt fertig wird. -> Hin und HerschiebereiFalls man Warten muss, kann der CPU-Kern eine andere Aufgabe lösen.
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.Onraku hat geschrieben: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.
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ß.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.