Video 6-2: Laufzeitexperimente

0:02 Wir hatten über Wissenschaft gesprochen und Naturwissenschaft braucht immer Experimente. Experimente in der Informatik, in der Algorithmik zumindest sind in der Regel Laufzeitexperimente, in der wir messen, wie lange was braucht oder messen, wie viel Speicher was braucht. Und das möchte ich noch mal konkret machen, auch mit Live Experimenten. Was kann da schon schiefgehen? Ähm, das Beispiel, was ich noch mal aufwärmen möchte, ist dieses Freum Problem, das Sie schon kennen. Zur Erinnerung, das war ein als Eingabe eine Menge von Zahlen und ein ein Array von Zahlen äh n Stück ähm ganze Zahlen sonst nicht weiter eingeschränkt und die die Aufgabe war, die Anzahl Tripel von Indizes zu finden, wo sich diese drei Zahlen zu null summieren.

0:49 Jetzt hatten wir ja letztes Mal lang über Modelle gesprochen, das heißt, wir sollten das jetzt auch anwenden. Eine Frage bei einem Problem war die Modellierung der Daten und hier sagen wir die Größe der Eingabe. Der Parameter, der uns da interessiert, ist die Anzahl Zahlen nahliegend.

1:07 Und als Datenmodell, wenn nichts da steht, ist immer worst Case gemeint. In dem Code, den wir da verwendet haben, macht auch gar keinen Unterschied. Der braucht immer gleich lang. Also Best Case und Worst Case und Average Case ist in diesem Fall alles das gleiche. Wir hatten uns auch schon einen Algorithmus für dieses algorithmische Problem überlegt. Das war ein ganz einfacher und das ist auch nicht der ähm den man am Ende verwenden möchte. Ich bleibe aber bei dem, um jetzt diese Laufzeitexperimente zu illustrieren. Und sobald wir dann die Grund die die Bausteine zurecht haben, werden wir das Problem dann auch ein drittes Mal noch mal besuchen. Sehnen sich an die vier Template Punkte. Nur noch mal so ein bisschen äh im Unterbewusstsein halten.

1:50 Ähm Kern hier war die Idee, dass wir einfach alle alle Tripel von Indizs durchprobieren und zählen, wie viele summieren sich zu null. Worauf ich ihren Fokus lenken möchte, hier ist die Laufzeitanalyse. Die theoretische Analyse, die wir da gemacht hatten. Da hatten wir als Modell gewählt, wie oft werden die Zeilen 5 bis sechs ausgeführt. Das wäre natürlich hilfreich, wenn man den Code noch mal vor Augen hätte. Äh, deswegen ist hier noch mal der Code dazu. Ähm, und hier eine Java Implementierung, die sehr nah da dran bleibt. Kann man gleich zurück. Ähm, die Anzahl Ausführung dieser Zeilen 5 bis 6 ist exakt dieser Term Abhängigkeit von n oder als Tildenation, das hatten wir damals noch nicht, aber mittlerweile kennen wir es ja, äh ist es ein n hoch 3 und ich kann es natürlich auch noch weiter ungenauer angeben als von n hoch 3.

2:46 Okay. Ähm, bevor wir das einmal auch laufen lassen, vielleicht ganz kurz noch mal ähm auf den Code geschaut. Den Pseudcode kennen Sie schon. Ich habe ein I, das ist mal mein meine Tripel sind diese Indizik jk und die sind in sortierter Reihenfolge. Also I ist immer kleiner als J und J ist immer kleiner als K. In den Schleifen sehen Sie das darin wieder gespiegelt, dass die die innere Schleife immer bei dem Wert der Variable der ein äußerliegenden Schleife beginnt. Das heißt, ich äh habe dann immer nur Werte für k größer als J. Ähm, die Umsetzung in Java ist im wesentlichen genau das äh Widerspiegel vom Pseudo Code. Ich habe halt hier die Vorschleifen, wie sie in Java üblich sind. Ansonsten ist es das gleiche. Ähm, was Sie hier auch sehen, ist man kann mit diesen schönen Bibliotheksklassen aus dieser äh Algorithmenbibliothek relativ kompakt eine kleine Main Methode schreiben, mit der man das testen kann. Sie könnten natürlich immer hier auch jetzt Daten generieren, wie auch immer, zufällige Zahlen oder sonst was. Äh, sie werden aber gleich sehen, es ist deutlich angenehmer, das einzulesen über die ähm über die Standardeingabe oder aus einer Datei. In diesem Fall ähm wollte ich vielleicht kurz kurz was zu sagen. Hatten wir in Kapitel 2 auch schon mal angeschaut. Es gibt in diese Klassen Standard in und in sind fast gleich, außer dass in eine objektorientierte Version ist, der man im Konstruktor übergibt, wo sie rauslesen soll.

4:40 Und äh hier übergeben wir das erste Kommandozeilenargument. Das heißt, das sollte ein Dateinamen sein. Für inn kann es auch eine URL sein, dann lädt er die automatisch runter, wenn man das äh direkt übergibt. Das heißt, In liest danach die Eingabe ähm oder die den Text aus dieser Datei aus, deren Namen wir übergeben als Kommandozahlenparameter und dann gibt's dieses read alls. Le solange ganze Zahlen bis die Datei zu Ende ist und dann geben wir den Count aus. Ich werde es gleich mal laufen lassen, aber wie immer, Sie sollen ja Hypothesen formulieren, bevor Sie Experimente machen. Versuchen Sie mal eine Hypothese zu raten. Also Szenario ist, wir lassen genau den Code von der vorherigen Folie laufen und wie lange dauert es, wenn die Eingabedatei 1000 Zahlen enthält?

5:44 Frage und Antwortmöglichkeiten ähm haben Sie ja auf Ihren Bildschirm. Das heißt, ich gehe mal zurück hier zum Code bzw. zu Code und Laufzeitanalyse. Ziel ist natürlich, dass Sie das ähm irgendwie in Verbindung bringen. Und ich bereite mal das Experiment vor.

6:23 So, sie kennen ja hier schon den Aufbau. Einmal zur Demonstration ähm ist hier der Code genau wie auf der Folie. Und dann habe ich hier eine Datei, die auch auf äh von Crick in Way auf der Website zu finden ist. Das ist eine Datei mit ganzen Zahlen drin und der Name 1K ins suggeriert ja schon, dass das 1000 Stück sind und das können wir überprüfen mit Line Count 1000 Zahlen.

7:35 Und als Parameter sollte ich jetzt den Dateinamen übergeben, dann können wir das laufen lassen. Bevor das machen, sollen Sie aber Ihre Hypothese abschicken. Jemand noch am Denken oder am ausfüllen oder soll ich mal hier die Codes offenbaren?

8:03 Also, gibt so eine gewisse Bandbreite. Ähm, mal schauen, ob wir es wieder abbrechen müssen. Mag jemand seine Rechnung erklären, wenn Sie mögen? Haben Sie aus dem Bauchgefühl geraten oder haben Sie was gerechnet?

8:24 Sie müssen jetzt nicht noch ähm sozusagen, es ist keine Demokratie. Wir werden gleich die Zahlen für sich sprechen lassen. Äh nur weil die Mehrheit hier für 130 Millisekunden stimmt, muss es ja nicht nicht richtig sein.

8:42 Also lassen Sie mich noch mal zu den Folien gehen, wo ich schreiben kann. Ähm, was wäre meine Überschlagsrechnung dazu? Wir hatten irgendwann mal gesagt, wir brauchen etwa 10 noch- 19 Sekunden für eine Rechenoperation, was auch immer das im Detail heißt, dann ist es so ein bisschen schwammig, aber äh um und bei so ein paar kleine Sachen wie hier drin im Vergleich und das inkrementieren und so, das zählt wahrscheinlich als im wesentlichen einen Schritt. Davon kann ich [schnauben] eine Milliarde pro Sekunde machen. Wie viele Schritte brauche ich? Na ja, äh etwa so viele. Ja, 1/ mal n, was 1000 ist hoch 3, das ist eben gerade ein 6 mal 10 hoch 9 und das kürzt sich wunderbar mit den Sekunden weg. Das heißt, eine Sechstel Sekunde wäre eine gute Schätzung.

9:41 Mal schauen. Ähm, ich mache mal hier den Performance Modus an. Vielleicht ähm wird es dann ein bisschen reproduzierbar und dann starten wir das mal. Und das war ziemlich schnell. Und jetzt haben wir hier natürlich verschiedene Zeiten angegeben, die sind so unter einer Sekunde auf jeden Fall, wenn man es mehrmals laufen lässt. äh pendelt sich so ein bisschen ein m auf vielleicht eine Drittel Sekunde statt eine Sechstel Sekunde. Das ist aber in der Größenordnung korrekt mit dieser groben Methode, dass man da mal einfach ansetzt, ich kriege eine Milliarde Operation pro Sekunde, das wird nie perfekt passen. Ein bisschen schade, als ich es zu Hause gemacht hatte, ohne Livestream war es perfekt. 0,13 ziemlich witzig. Okay. Ähm, also korrekte Antwort um und bei 130 Millisekunden plus minus Faktor 2 hoch oder runter. Das ist was man hier erwarten darf und was wir auch ungefähr sehen. Also das ist eine ein Faktor 2 weg mit so einer ganz groben Rechnung. Da darf man nicht beleidigt sein. Das ist noch kein Grund, die Hypothese zu verwerfen.

11:02 Ein Punkt, wir hatten über Methodik gesprochen zum Messen. Was ich jetzt getan hatte, war im Wesentlichen das hier in ein bisschen schlauer. Ich habe mich nicht manuell mit der Stoppur hingesetzt und geschaut, wann kommt die Ausgabe und dann drücke ich auf Stopp. das natürlich noch ungenauer, aber ich habe dieses eingebaute Unix Tool verwendet Time, was die komplette Startzeit mit einbezieht, die die Java Virtual Machine braucht. Und bei Java ist das nicht ganz von der Hand zu weisen. Das ist durchaus auch so um den Dreh. Vielleicht ist in diesem Fall tatsächlich die Hälfte der Zeit ähm darauf drauf gegangen, die Virtual Machine zu starten. Wenn man das besser machen will, dann muss man aus dem Programm raus selbst die Zeit stoppen. Dafür gibt's Aufrufe in der Java API, die sind nicht besonders kompliziert, aber wir können auch ähm bei diesem Convenience Rapper an der Stelle bleiben. Ähm da gibt's also eine eine Stopwatch Klasse. Die kann man einmal anlegen und dann kann man, wenn man mit der Rechnung, die man stoppen will, fertig ist, fragen, wie viel Zeit ist denn jetzt vergangen?

12:06 Machen wir auch einmal. Ähm, dafür habe ich eine Klasse Time Free Sum vorbereitet, die im Wesentlichen sowas macht. Da haben Sie ähm den gleichen Aufruf wie in der Main Methode vorhin mit wir lesen und standard in diese ins aus einer Datei und dann mache ich aber erst danach meine Stoppuhr scharf, ruf dann das Count auf, was dann die Trippel zählt und dann gebe ich aus, wie viel Zeit vergangen ist. Das heißt, ich habe hier tatsächlich auch zwei Effekte noch vorher jetzt mitgestoppt mit meinem Time. Äh sowohl das Starten der JVM als auch das Einlesen der Datei. Letztes ist wahrscheinlich Peanuts vernachlässigbar hier, aber na gut, das ist auf jeden Fall präziser, das so zu messen.

13:12 Und wieder als Eingabe unsere 1000 Ins. Auch hier kein großer. Ich mache wieder den anderen Performance Modus an. Mal schauen, ob es ein Unterschied macht.

13:28 Ah, witzig. Faktor 2 schneller, indem ich Okay, na gut. Also, sie sehen, Laufzeiten muss man meistens ein paar mal wiederholen, bevor es so richtig reproduzierbar ist. Äh, das hier war jetzt eher einmal glücklich schneller gelaufen, als dass das jetzt systematisch so wäre. Schade, hat daheim besser geklappt.

13:48 Äh nichtsdestotrotz reduziert natürlich diese Art aus dem Programm die Laufzeit zu messen, ähm den den Fehler, den wir machen. Vorher haben wir systematischen Fehler gehabt, indem wir mitmessen, wie lange den die Startzeit der JVM ist und so weiter. Das haben wir jetzt eliminiert. Also in aller Regel, will man aus dem Programm heraus die Laufzeit messen, wie hier, dann kann man dafür sorgen, dass man nur das misst, was man wirklich messen möchte.

14:21 Gut, lass uns nämlich den kleinen empirischen Teil noch abschließen, dann machen wir eine Pause. Ähm, jetzt habe ich einmal gemessen, was ich eigentlich als Hypothese hatte, war aber diese Asymptotik, ne? Ich hatte eigentlich dieses Modell aus meinem abstrakten Kostenmaß her geleitet, um und bei so viel Operationen oder als Sekunden umgerechnet mit dieser groben Schätzung das hier mal 10 noch - 9 Sekunden. Die Hypothese kann ich mit einer einzigen Messung nicht so richtig ähm klar bestätigen oder widerlegen. Was wir also machen ist mehrmals messen und zwar mit verschieden großen Eingaben. Äh, wenn Sie mögen, können wir da auch ein zwei Beispiele mal noch äh dazu machen. Also neben dem 1K Int gibt's auch ein 2K ins und dann läuft das ein bisschen länger. 2 Sekunden auch noch mal so nur so zu zum das Gefühl bekommen, wie sehr das vinander abweicht. Ma er jetzt noch mal die 1K. Na gut, immer noch ziemlich schwankend. Dann kann ich es noch für vier machen.

15:38 Können sie natürlich mal reproduzieren und das sind immer Dinge, die sich dann je nach Maschine so ein bisschen unterscheiden können. Na komm. Wow. Okay. Äh diese Laufzeitexperimente mit dem Livestream äh gehen doch deutlich anders aus.

16:03 Äh muss mir mal noch was ausdenken. Also, das hier sind Messungen, wie sie von äh den Autoren vom Buch gemacht wurden auf ihrer Maschine. Als ich das daheim gemacht habe, war das ziemlich nah dran. Das hat ziemlich gut gepasst. Äh wir hatten hier gesehen, unsere Schätzung war 0,13, nicht? Ja, und das hatten wir etwa bei 2 Sekunden. Hier hatten wir jetzt schon 20. Ähm ist eben unter Last ein bisschen anders. Was machen wir jetzt mit diesen Messungen? Die sind immer noch aus denen äh könnte ich jetzt für jede prüfen, wie gut passt die zu meinem 1/6 n hoch 3* 10 hoch -9. Aber es ist ein bisschen mühsam, da äh klar zu sehen. Es gibt eine schönere grafische Methode, um das zu machen. Und auch da ähm ich zeige Ihnen erstmal die polierte Variante auf den Folien. Äh ich kann einfach einen einen 2D Plot machen, indem auf der einen Achse die Eingabegröße gemalt ist, N und auf der anderen Dimension die Laufzeit. Und dann bekomme ich hier so eine wachsende Funktion.

17:09 dass die jetzt hier zwischendrin so eine geklättete Kurve gemacht haben, finde ich was schon bisschen äh schade, weil natürlich wissen wir hier gar nicht, was passiert. Ja, wir wissen ja nur die roten Punkte. Ähm das können wir auf verschiedene Weise reproduzieren, aber lass sie mich ganz kurz zeigen, wie man das vielleicht heutzutage am eh ersten machen will. Sie haben nicht viel Python im Studium als Zwangsveranstaltung, vielleicht in Data Science mehr als in Informatik, aber das ist auch so wenig, was sie davon brauchen. Äh was ich hier aufgemacht habe, ist ein Jupiter Notebook, in dem Fall Google Colab, wo man das in der Cloud laufen lassen kann. Da gibt's einen Befehl, um eine Bibliothek zu laden, um Sachen zu plotten. Und dann gibt's im Wesentlichen hier einen Aufruf. Das hier ist ja nur ein bisschen Kosmetik und dann mache ich Show und dann malt mir das ein Bild, was keinen Schönheitspreis gewinnt, aber reicht, um mal kurz was zu sehen. Die Zahlen, die ich hier eingegeben habe, das waren die Zahlen aus der Tabelle bzw. die Zahlen, wie ich sie zu Hause auf meinem Laptop gestoppt hatte.

18:24 Also, das ist die Eingabegröße und das hier ist die Zeit in Sekunden. Und ähm für die Python Experten, ich habe hier eine Liste. Diese äh eckigen Klammern sind eine Liste und jeder Eintrag ist aber ein Tuppel, ein Paar. Muss man nicht so machen, aber kann man so machen. Äh um das zu plotten, brauche ich die X und Y Werte als zwei Arrays. Könnte man auch gleich direkt so eingeben, wenn man mag. Ähm, ich habe mich hier entschlossen, ich will die lieber zusammenhalten, dass ich die Eingabegröße und die Zeit direkt als ein Paar habe. Die kann man dann in Python mit diesem schönen Konstrukt List Comprehension aus dieser Liste auslesen. Also X ist jetzt die Liste von dem ersten Eintrag aller Tuppel namens Time, wobei Time aus da aus diesem Data aus dieser Data Liste kommt. All diesen Teil brauchen Sie nicht verstehen. Sie können das im Wesentlichen ähm blind kopieren oder sich KI generieren lassen. Ähm darum geht's jetzt hier nicht. Mit einem Aufrufblot können Sie die malen und wenn wir das ausführen, dann kriegen sie das Bild unten, sobald die eine Virtual Machine für mich frei haben. Und dann sehen Sie hier dieses Bild.

19:41 Ähm, man kann d mit den Parametern spielen. Dieses O und Minus bedeutet, ich mag sowohl die dicken fetten Bobbel hier haben an den Messwerten, als auch einen eine gerade Linie dazwischen.

19:53 Okay, also der Punkt ist, es kostet 3 Minuten so ein Bildchen zu malen. Es gibt überhaupt keinen Grund, das nicht zu tun, wenn sie irgendwelche Messungen machen. Grafiken sind immer intuitiver, um zu sehen, welche Zusammenhänge da sind.

20:14 Dieser Plot hat aber ein Problem in sofern als dass er nicht so richtig explizit zeigt, was dieses kubische N hoch3 Wachstum ist. Man sieht zwar, dass diese Punkte hier wachsen, aber ist es jetzt n hoch 3 oder n hoch 4 oder n hoch 2,7? Das erkennt man da nicht so richtig gut. Oder ist es vielleicht sogar was noch schlimmeres? Vielleicht ist ja exponentiell oder sowas. Es gibt einen einfachen Trick, der das viel schöner zeigt, nämlich einen Log Plot, auf dem beide Achsen logarithmische Skalen haben und dann passiert, was was mathematisch offensichtliches, aber was unfassbar praktisches aus so einem polynomiellen Wachstum wird eine Gerade. Und zwar egal, welcher Exponent da ist, das kann auch n hoch 17 sein, dann ist die gerade steiler, aber es ist immer noch eine gerade Linie. Und ob etwas eine gerade Linie ist oder nicht, erkennt man optisch halt sehr viel schneller. Auch da wieder ähm das einzige, was Sie ändern müssen, ist hier stand plot, hier oben stand plot XY. sagen sie jetzt lock log und der Rest ist halt in der Bibliothek schon eingebaut, weil alle die Data Science betreiben so Kram ständig brauchen.

21:29 Und dann sehen Sie hier das Bild und das ist wirklich nah einer geraden Linie auch mit den Messungen auf meiner Maschine. So ein ganz kleines bisschen ist es nach oben geneigt, so ein bisschen konvex, aber nah genug dran, damit wir das glauben können. Hier bei den Messungen ist es äh der Traum jedes Physikers, dass man so präzise zu dem Modell passt. Und dann kann man natürlich von so einem äh von so einer Gerade auch Regressionsäh Geraden berechnen. Das heißt, man kriegt so eine Schätzung für die Steigung und aus der Steigung kann man den Exponenten berechnen. Das ist hier in den Folien noch mal ausgeführt. Ähm wenn wenn wir wenn Sie tatsächlich aus rein aus den Messdaten schätzen wollen, welcher Exponent in n passt am besten zu den Daten, dann können Sie dieses dieses Vorgehen hier nehmen. Wir messen den die Steigung dieser Geraden und berechnen je nach Basis vom Logarithmus, was dann der Exponentiell was der dann der Exponent ist.

22:37 Also in Anbetracht der Zeit lassen Sie mich ähm das ein bisschen kürzer machen. Wir können aus den Daten also eine Hypothese ableiten und diese Hypothese, die gibt uns jetzt für jede Eingabegröße eine eine sehr viel genauere Schätzung als meine grobe ähm Überschlagsrechnung von vorhin, insbesondere für etwas größere Eingaben. Und was besonders ähm besonders oft bequem ist, sich anzuschauen, ist was passiert, wenn ich die Eingabegröße verdopple. Und ähm wenn ich das hier die zweimal mache, ich lasse das jetzt nicht laufen 400 Sekunden lang, da habe ich keine Geduld für, da das ja auch noch ein Faktor 4 langsamer ist während dem Livestream. Ähm, aber man kann die Messung machen und sieht dann, dass eben die Vorhersagen von diesem Modell, dass wir aus den kleinen Größen berechnet haben, sehr gut auch für die nächst größeren Größen passt. Und in dem Sinne kann man dann sagen, wir wir haben unsere Hypothese validiert durch die nächst größeren Daten.

23:38 Ein bisschen einfacher kann man ähm auch ohne, dass man jetzt explizit so eine so eine Hypothese ausrechnet, kann man diese Verdopplungshypothese aufstellen. Wenn ich den Exponenten von meinem N kenne, dann kann ich ausrechnen, was passieren muss, wenn ich die Eingabegröße verdopple. Das steht hier in Formeln, aber lassen es uns für unsere für unsere konkrete ähm Hypothese auch noch mal nachrechnen. Was sollte passieren, wenn ich von n zu 2 gehe, wenn ich davon ausgehe, dass mein t von n sowas ist wie eine Konstante mal n hoch 3. Ja, dann setze ich das hier ein. a* 2n hoch 3 gee dur a mal n hoch. Da kürzt sich schon mal das A weg. Das ist also gar nicht relevant für diese für diese Faktor. Und hier kann ich natürlich ausmultiplizieren. Das heißt, da habe ich 8n hoch 3 und unten habe ich nur n hoch 3. Das kürzt sich natürlich auch. Das heißt, ich bekomme einen Faktor 8. Wann immer ich die Eingabe verdopple, habe ich bei einem kubischen Wachstum die Laufzeit verachtfacht.

24:46 Das ist was sich hier hinter dieser Doubling Hypothesis verbirgt und das kann ich dann auch mit meinen Messungen machen. Ähm kann man natürlich hier von Hand machen. Man kann auch Python das ausrechnen lassen. In unserem Fall, wie man in dem Bild auch schon sieht, sind diese ähm Quotienten zwischen dem nächsten und dem vorherigen Punkt leicht steigen. ist nicht ganz konstant, aber es sind um und bei acht. Also noch mal eine andere Art, wie man sich plausibel machen kann, dass das Modell hier ganz gut passt.

25:27 Lassen Sie nämlich das hier noch unterstreichen. Diese Methode, dass man einen Logblock Plot malt und dann die Steigung der Geraden abliest, die gibt einem den Exponent von n. Wenn man genauer hingucken will, dann reicht es manchmal nicht. Also, es ist keine äh sehr präzise Methode. Wenn man genauer wissen will als nur ungefähr der den Exponenten, dann muss man andere Arten der Datenanalyse bemühen.

26:04 aus den Daten, die wir gemessen haben, können wir dann wie gesagt hier aus der Verdoppelungshypothese bekommen wir den Exponenten, aber das A hat sich rausgekürzt. Aus den konkreten Zahlen, die wir gemessen haben, können wir eine Schätzung für das Ausrechnen und dann bekommt man eine Vorhersage in in präzisen Sekunden für diese Maschinen. Da diese Zahlen ja immer anders sind, bei meiner Maschine war es jetzt viermal langsamer unter Livestream, wäre dann das A eben auch viermal größer.

26:39 ein eine Bemerkung, was man dabei immer missst, wenn man solche Experimente macht, sind einerseits Effekte, die wir untersuchen wollen, nämlich welchen Einfluss hat der Algorithmus und die Eingabedaten. Und dann gibt's aber auch jede Menge Effekte, die wir vielleicht gar nicht mitmessen wollten, weil wir die Algorithmen vergleichen wollten oder die uns zwar interessieren, die aber so ein bisschen schwieriger zu kontrollieren sind für uns als Programmierer, nämlich alles, was so die Umgebung angeht. Ähm, beeinfacht gesprochen ist aber das, was den Exponenten beeinflusst, der Algorithmus. Die ganze Umgebung beeinflusst im Wesentlichen den Konstanten Faktor davor.

27:21 Ich habe da so ein bisschen ein Sternchen dran zu machen, weil äh es Fälle gibt, wo das nicht ganz so äh hundertprozentig klappt. ähm Dinge wie Cashing und so die ähm die möchte man auch berücksichtigen. Da müsste man auch im Algorithmus genauer drauf schauen. Aber als erste Nährung ist das der der Punkt. Deswegen ist auch die Eingabe und die Algorithmen ändern das, was den viel dramatischeren Effekt hat.

27:52 Letzter Punkt zu Experimenten. Wie Sie schon gesehen haben, ich lasse den gleichen Code noch mal laufen und kriege eine andere Laufzeit. Das ist einfach so. Es ist ähm, obwohl wir diese Maschinen als Menschen gebaut haben, sind sie zu chaotisch geworden oder zu komplex, zu viele Level von Dingen, die die da reinspielen, als dass man noch perfekt vorhersagen könnte, wie lange was dauert. Es ist einfach zu kompliziert. Auf eine gewisse Genauigkeit kann man es vorher sagen, aber es gibt immer so ein kleines Rauschen in der Messung und es gibt immer Effekte, die sehr schwierig wer zu sagen sind, wenn man ganz ganz genau hinguckt. Äh die gute Nachricht ist, im Vergleich zu all den Naturwissenschaften geht's uns richtig gut. Experimente sind unfassbar billig. Es kostet ein bisschen Strom und ein bisschen Geduld, aber wir können ganz ganz bequem sehr viele Daten gewinnen. Das heißt, man kann mit ähm Durchschnitten bilden und so weiter ganz oft sehr präzise Daten generieren, selbst wenn die einzelne Messung noch nicht so präzise ist und das kostet sehr wenig im Vergleich zu naturwissenschaftlichen Experimenten.

28:53 Das heißt, wir sollten da einfach ähm auch nicht davor zurückschrecken, Dinge ein paar mal zu wiederholen.