[Klaatsch]

Ungewohnt, dass da wieder Morrich steht. Bleib am Ball

[Morrich]

Das Ka ist halt ein Rad...

[Juli Karen]

Hey Morrich, weist du zufällig, welche WLP beim Brocken 3 beiliegt (hab ich mir auch geholt deshalb die Frage)?

Ist das die Alpenföhn Glatteis oder eine andere?

Denn die Glatteis hat eine Wärmeleitfähigkeit von 5W, die MX-4 aber 8,4W, weshalb ich zu deren Nutzung tendiere - ausgehend davon, dass mehr = besser ist?


Und wie hast du die WLP verteilt? Die Rillen zwischen den Heatpipes (Bild 5) würden mich ja eher dazu verleiten, die WLP auf dem Kühler zu verteilen, damit sie ordentlich ausgefüllt sind.

[Zankro]

Elex ist draußen und ich lade den scheiß über Steam mit 400 kb/s runter, trotz 120k Leitung.
Ach wie mich das freut, Steam kann manchmal echt scheiße sein.


Wobei ich mich immer noch frage wieso es kein scheiß Pre Load gab ?

[Multithread]

Weil der Publisher anscheinen keinen Preload wollte.
Steam bietet die Möglichkeit dies einzustellen.


Ist aber insbesondere für Leute mit Mässigen Inet schlecht. Selbst 12 Stunden Preload hätten den meisten wohl gereicht.

[Juli Karen]

Ich hab kurz nach 19 Uhr begonnen zu ziehen (Gog); dauerte ~80 Minuten bei ~5,5 -6Mb/s (50K Leitung)

Und im Anschluss gleich die erste 7h Spielesitzung, ist mir seit seit FO4 nicht mehr passiert

Und ich weis schon nicht, wie ich mich entscheiden soll

[jabu]

Plötzlich bemerke ich, dass die Ressourcen meines PCs ausgelastet sind:
Der CPU-Lüfter braust auf, das HDD rattert, die Kiste ist kaum noch bedienbar. Das ist beim Kompilieren dieses Projektes doch noch nie vorgekommen, zumal ich vorhin nur wenig verändert habe. Ist irgendwas kaputt? Ich fürchte Schlimmes...

Doch es offenbart sich der Knieschuss des Tages (vereinfacht dargestellt):

Spoiler:(zum lesen bitte Text markieren)

__forceinline void RecursiveFunc()
{
    //...
    RecursiveFunc();
}

Auaaaaa!
Der Schmerz weicht allmählich wohltuender Erleichterung, puh.
Was gut ist: Der Compiler tut wirklich, was man ihm sagt.
Es darf sich über mein Vorgehen amüsiert werden, ich halte das aus.

[Morrich]

Da ich NULL Ahnung von Programmierung habe, lese ich da leider gar nichts raus und kann nicht mitlachen...

[foobar]

Da ich NULL Ahnung von Programmierung habe, lese ich da leider gar nichts raus und kann nicht mitlachen...

Um Rekursion zu verstehen, muss man halt erst mal verstehen, was Rekursion ist.

[Lookbehind]

Um Rekursion zu verstehen, muss man halt erst mal verstehen, was Rekursion ist.

Ey! Das ist mein Spruch!

Da ich NULL Ahnung von Programmierung habe, lese ich da leider gar nichts raus und kann nicht mitlachen...

jabu hat eine Funktion geschrieben, mit dem Namen "RecursiveFunc", und das erste was diese Funktion tut, ist eine Funktion namens "RecursiveFunc" auf zu rufen. ... dem geneigten Leser könnte auffallen, dass die Funktion die aufgerufen wird, den gleichen Namen trägt, wie die Funktion, die diese aufruft. ... Die Funktion ruft sich also selbst auf, und da die erste Aufgabe dieser Funktion ist, sich selbst auf zu rufen, wird sie das auch wieder tun, und die darin aufgerufene Funktion wird sich wieder selbst aufrufen, und ... das nimmt kein Ende. Jedenfalls kein gutes

Schlage in einem Lexikon den Begriff Rekursion nach, wenn es ein gutes Lexikon ist, wirst du dort finden "siehe Rekursion"

[Morrich]

Hm, also quasi ein programmiertechnisches Perpetuum Mobile.

Ich erinnere mich dunkel daran, dass ich den Begriff "rekursiv" mal in der Ausbildung gehört habe.

Aber aus mir ist halt letztlich eben kein Informatiker geworden, weil mir der ganze Java und C++ Kram zu hoch war bzw. ich zu faul war, mein Hirn anzustregen

[Lookbehind]

Hm, also quasi ein programmiertechnisches Perpetuum Mobile.

... nur das es keine Rechenleistung generiert, sondern diese eher aufsaugt, wie ein schwarzes Loch.

[Morrich]

... nur das es keine Rechenleistung generiert, sondern diese eher aufsaugt, wie ein schwarzes Loch.

Ja, aber es läuft dennoch immer weiter und weiter. Eine Schleife halt.

[Lookbehind]

Ja, aber es läuft dennoch immer weiter und weiter. Eine Schleife halt.

Naja, nicht ganz. Jeder Funktions-Aufruf kostet ein bisschen Ressourcen. RAM und CPU-Zeit. ... Wenn du das Programm lange genug laufen lässt, ist von deinem RAM und freier CPU-Zeit nicht mehr viel übrig. Wenn du es zu weit treibst, reißt es das ganze System mit in den Abgrund.
... und "lange genug" sind durchaus nur ein paar Minuten, denn je schneller der Rechner, desto schneller kann er mehr Funktionen aufrufen, die abermals Funktionen aufrufen. Das ganze wird also exponentiell schlimmer, je länger es läuft.

Auf Betriebssystem-Ebene gibts sowas als Forkbomb. ... da kann man im Terminal immer lustige Smilies malen


Ach ja, Rekursion ist nicht nur schlecht! Richtig angewendet kann Rekursion manchmal auch sinnvoll sein. Wichtig ist aber, dass man eine Abbruch-Bedingung definiert, und diese auch auf jeden Fall irgendwann erreicht wird.
Generell versucht man Rekursion aber zu vermeiden, weil es einfach unperformant ist.

[Morrich]

Ich hab das schon verstanden, keine weiteren Ausführungen nötig. Danke trotzdem.

[jabu]

Da ich NULL Ahnung von Programmierung habe, lese ich da leider gar nichts raus und kann nicht mitlachen...

Du hast natürlich Recht, etwas Hintergrundinformation braucht man wohl. Dann versuche ich mal, es allgemeinverständlich darzulegen (es geht nicht um ein Problem zur Laufzeit, und die Abbruchbedingung fehlt im ursprünglichen Code auch nicht):

Zur Einordnung:
Es geht um ein Freizeitprojekt. Der gezeigte Abschnitt enthält auf das Wesentliche reduzierten Quelltext (folgend nur noch als Code bezeichnet). Als Programmiersprache wurde C++ verwendet, wobei das in C exakt genauso aussieht. Man muss die Sprache nicht sonderlich gut kennen, da es zugleich als eine Art Pseudocode durchgehen kann. Es geht also darum, die (hier ziemlich simple) Struktur nachvollziehen zu können. Die eigentliche Aufgabe der Funktion ist egal.

Wobei es passiert ist:
Nach Änderungen am (für Menschen lesbaren) Code muss dieser erneut in Maschinencode übersetzt werden, damit ihn die CPU versteht. Den Übersetzungsvorgang nennt man Kompilierung, das Werkzeug dafür Compiler. Also habe ich den Compiler angewiesen, das Projekt, in dem besagter Code enthalten ist, zu kompilieren. Dabei sind dem PC die Ressourcen ausgegangen, was mich erschreckt hat, da es unerwartet passiert ist.

Den Code verstehen:
Um den Code zu strukturieren, verwendet man u. a. Funktionen, welche Code zu kleineren Einheiten zusammenfassen, wodurch einmal geschriebener Code wiederverwendbar, zentral wartbar und leichter lesbar wird.
Funktionen haben, um sie unterscheiden und leicht verwenden zu können, Namen. Der Name der hier definierten Funktion ist, speziell für das Forum, deskriptiv gewählt worden und lautet RecursiveFunc.
Die runden Klammern begrenzen die Parameterliste, welche hier leer ist, weil keine Übergabe von Parametern an die Funktion vorgesehen ist. Also wird RecursiveFunc() hingeschrieben.
Nun steht noch der unbedingt mit anzugebende Rückgabetyp void davor, was bedeutet, dass die Funktion keinen Wert, also nichts (eben void), an ihren Aufrufer zurückgibt, also beispielsweise nicht das Ergebnis einer Berechnung. Also erhalten wir void RecursiveFunc(). Beim Aufruf der Funktion wird der Rückgabetyp nicht angegeben.
Zwischen den beiden geschweiften Klammern stehen die Anweisungen, welche die Funktion beinhaltet und üblicherweise ab ihrem Aufruf auszuführen hat (dann natürlich als Maschinencode). Eine Anweisung wird mit einem Semikolon abgeschlossen. Also lautet die einzige Anweisung, dass die Funktion sich selbst aufruft: RecursiveFunc();
Funktionen, die sich selbst aufrufen, nennt man rekursive Funktionen, weshalb ich diese dementsprechend benannt habe. Natürlich hat sie in ihrer tatsächlichen Version einen anderen Namen, welcher ihre Aufgabe kennzeichnet, und selbstverständlich beinhaltet sie eine Abbruchbedingung, damit sie sich nicht endlos selbst aufruft, was hier ausgelassen wurde.
Die beiden Schrägstriche leiten einen einzeiligen Kommentar ein, ab dem der Compiler den Rest der Zeile verwirft, was einem ermöglicht, Erläuterungen einzufügen. Mit den Punkten soll angedeutet werden, dass dort normalerweise noch etwas steht, was zum Verständnis unnötig ist, aber der Funktion ihren Sinn verleiht. Man hätte die Auskommentierung der Punkte weglassen können, aber dann wäre der Code fehlerhaft und nicht mehr kompilierbar. Beides hat also Vor- und Nachteile, wenn man etwas zeigen will.

Der Zwischenstand:
Wir halten fest, dass die Funktion rekursiv ist, was heißt, dass sie sich selbst aufruft. Das ist ihr bis hierhin erklärter Stand - was schon gültiger und problemlos kompilierbarer Code ist, der aber nichts weiter macht, als sich endlos selbst aufzurufen (nachdem man die Funktion an anderer Stelle einmal aufgerufen hat):

void RecursiveFunc()
{
    //...
    RecursiveFunc();
}

Der Knieschuss:
Rekursive Funktionen sind zwar eher nicht wünschenswert, aber trotzdem nicht verboten, und sie stellen bei manchen Algorithmen einen zugleich überschaubaren und effizienten Ansatz dar.
Funktionen, also auch ganz normale, sind aber schon grundsätzlich eine Medaille mit zwei Seiten: Einerseits wird der Code durch Funktionen kompakter, wenn man ihn sonst mehrfach hinschreiben müsste, andererseits muss die CPU immer wieder an die betreffende Stelle hinspringen, was bedeutet, dass sie den Code vielleicht nicht mehr im Cache hat, was dann wegen der Ladevorgänge arg auf die Performance gehen kann. Auch wenn der Code im Cache liegt, kosten Aufruf und Rücksprung noch einige Takte, was zwar normalerweise verschmerzbar ist, aber nicht immer an besonders performancekritischen Stellen.
Um das Problem zu lösen, sodass der Compiler den Code an Ort und Stelle einfügt (mit dem Nachteil, dass er insgesamt größer wird, was ab einem gewissen Punkt, der sich schwer vorhersagen lässt, auch nicht gut für das Caching ist) gibt es bei C und bei C++ ein Keyword mit dem Namen inline, womit die Funktionsdefinition folgendermaßen aussieht:

inline void RecursiveFunc()
{
    //...
    RecursiveFunc();
}

Also haben wir es schon mit einer einfachen Performanceoptimierung zu tun. Üblicherweise versteht man unter Optimierung noch etwas anderes, weil Inlining übliches Handwerkszeug ist. Aber wie ich bereits sagte, ist es doch nicht so trivial, darüber zu entscheiden, wann Inlining (Einfügen des Maschinencodes als Kopie) sinnvoller als ein echter Funktionsaufruf (Sprung zur Funktion mit dem Maschinencode und Rücksprung) ist. Die richtigen Entscheidungen zu treffen, kann manchmal viel ausmachen.
Zu inline sollte man noch wissen, dass der Compiler (neben Anforderungen, die die Sprachstandards stellen bzw. nicht stellen sollen, auch weil der Compiler meistens besser als ein Mensch entscheidet) selber entscheiden darf, ob er ein Inlining vornimmt oder nicht, weswegen inline ein Hinweis an den Compiler ist und kein Zwang.
Um ein Optimum herauszuholen, muss der Mensch manchmal doch besser wissen, wo Inling sinnvoll ist und wo nicht. Aber weder C noch C++ sieht so einen Zwang vor. Um den Compiler trotzdem zum Inlining zu zwingen, haben deren Hersteller Erweiterungen eingeführt. Beim C++-Compiler von Microsoft lautet das entsprechende Keyword __forceinline, womit die (vereinfachte) Funktion komplett ist:

__forceinline void RecursiveFunc()
{
    //...
    RecursiveFunc();
}

Also soll der Compiler gezwungen werden, den Maschinencode dieser Funktion dort einzufügen, wo sie aufgerufen wird, aber ihr Aufruf beinhaltet einen Aufruf und der einen Aufruf und der einen Aufruf und... , was ewiges Kopieren von Maschinencode bedeutet, um das Programm zu erstellen, weshalb die Ressourcen ausgehen.

Das ist zur Laufzeit ganz anders, wo das Abbruchkriterium den Ausweg weist, weswegen man schon mal übersehen kann, dass der Code nicht endlos eingefügt werden kann. Ein weiterer Grund ist, dass ich das Keyword __forceinline nicht direkt verwende, sondern stattdessen ein kürzeres, und damit unauffälligeres, Präprozessor-Makro hinschreibe, welches dann vom Präprozessor automatisch durch __forceinline ersetzt wird.

Zum Hintergrund:
Natürlich wusste ich das, weswegen die Aktion wohl auf partielle Geistesabwesenheit oder Ablenkung zurückzuführen ist. Passiert ist es, weil ich eine bestimmte Kategorie an ziemlich kurzen und besonders oft aufgerufenen Funktionen in der endgültigen Version aus Performancegründen unbedingt als Inline-Funktionen vorliegen haben muss. Dazu muss die Rekursion natürlich verschwinden, was hier zum Glück durch Ersetzen mit einer Schleife möglich ist, aber bei einem kurzen Versuch, wo es zunächst auch um die Korrektheit insgesamt ging, noch nicht erfolgt ist.

Hm, also quasi ein programmiertechnisches Perpetuum Mobile.

Ich erinnere mich dunkel daran, dass ich den Begriff "rekursiv" mal in der Ausbildung gehört habe.

Aber aus mir ist halt letztlich eben kein Informatiker geworden, weil mir der ganze Java und C++ Kram zu hoch war bzw. ich zu faul war, mein Hirn anzustregen

Es wird nicht immer gut gelehrt.

[Morrich]

AMDs Umsatz und vor allem Gewinn hat sich sehr positiv entwickelt in den letzten Monaten.
Man schreibt tatsächlich aus eigener Kraft mal wieder schwarze Zahlen!

Hoffen wir, dass das noch eine ganze Weile so weiter geht und sich besonders am CPU Markt wieder eine stabile Konkurrenzsituation einstellt.
Dieser technische Stillstand über die letzten Jahre war ja einfach nur erbärmlich.

[Juli Karen]

Hätten mir ruhig Danken können, die AMDler, dass ich vor zwei Wochen aus der roten eine schwarze Null gemacht habe

[Morrich]

[Juli Karen]

Also doch AMDler oder deren Fanboy

PS: Hast du auf die Schnelle ein Freeware Tool zur Hand, mit dem ich im Gaming die Temps beobachten kann, oder das im Hintergrund mitläuft?

HWMonitor zeigt mir keinen einzigen Kern mehr an