WEBVTT 00:03.102 --> 00:07.029 [SPEAKER_02]: Willkommen zu einer neuen Episode vom Engineering Kiosk Podcast. 00:07.049 --> 00:09.393 [SPEAKER_02]: Heute wird es schnell, richtig schnell. 00:09.453 --> 00:14.802 [SPEAKER_02]: Wir sprechen über eine Challenge, die auf den ersten Blick fast harmlos klingt und dann völlig eskaliert. 00:14.823 --> 00:17.367 [SPEAKER_02]: Die 1-Billion Road Challenge. 00:17.387 --> 00:24.800 [SPEAKER_02]: Eine Milliardezeilen Wetterdaten einlesen, Prostation, Minimum, Mittelwert und Maximum berechnen und das Ganze so schnell wie möglich. 00:24.840 --> 00:26.403 [SPEAKER_02]: Klingt nach einer Simplenfeisarbeit? 00:26.423 --> 00:28.266 [SPEAKER_02]: Ja, genau hier wird's spannend. 00:28.246 --> 00:36.902 [SPEAKER_02]: Denn wir schauen uns auch an, wie es an einer Ebenjava Implementierung mit fast fünf Minuten aufzeit plötzlich Lösungen mit rund ½ Sekunden werden. 00:36.922 --> 00:44.736 [SPEAKER_02]: Und dabei geht es nicht nur um Java, DJVM und Grail VM, sondern auch um die Frage, was Performance-Optimierung eigentlich wirklich bedeutet. 00:44.716 --> 00:59.685 [SPEAKER_02]: Lokale Hashmaps, Memory Mapping, integer statt float, Single Instructions Multi-Bedata kurz Zimdi, Branchless Coating, Unsafe, Cashlines und warum plötzlich sogar das Paasen eines Temperaturwärts zu wissenschaft werden. 00:59.725 --> 01:03.332 [SPEAKER_02]: Außerdem sprechen wir darüber, warum diese Challenge so viral gegangen ist, 01:03.312 --> 01:15.455 [SPEAKER_02]: Welche Kritik ist daran gab und was andere Sprachen wie sie, Go, PHP, SQL oder sogar Avika daraus gemacht haben und warum eine GPU hier nicht automatisch der entgegen heißt. 01:15.495 --> 01:22.688 [SPEAKER_02]: Wenn du wissen willst, ob ja aber wirklich langsam ist oder ob wir diese Müters heute endgültig den Schäker ziehen, dann bleibt dran, los geht's. 01:27.427 --> 01:44.102 [SPEAKER_02]: Lieber Wolfgang, die Größe gehen raus, anders wunderschön zu Land mit dem leckesten Kaiser Schmaan, ohne Rosin und heute haben wir mal ein Thema, aber es ist schon lange auf der Urhab, aber wir starten mit einer einfachen Frage für dich, was war die letzte Performance Optimierung, die du geschrieben hast oder gecomptes hast? 01:44.082 --> 01:45.525 [SPEAKER_01]: Moment, die wir kurz abgelenkt. 01:45.545 --> 01:47.068 [SPEAKER_01]: Bei Kaiserschmarn haben wir schon abgeschalten. 01:47.088 --> 01:54.022 [SPEAKER_01]: Weil du das von dem Land gesprochen, wo es Kaiserschmarn ohne Russine gibt und der dabeiste ist, in welchem Land ist es das, sollen Österreich gibt es sowas nicht. 01:54.042 --> 01:55.464 [SPEAKER_01]: In Österreich gibt es sowas von mehr. 01:55.484 --> 01:57.709 [SPEAKER_01]: Wer gibt's nur mit Russinen? 01:57.729 --> 01:58.711 [SPEAKER_01]: Glaubens Krieg. 01:58.731 --> 02:01.516 [SPEAKER_01]: Bin er nicht religiös, deswegen halte ich mich von durch den Kriegen fern. 02:01.556 --> 02:04.943 [SPEAKER_01]: Du wörtest jetzt Einleitung machen im religiöse Kriege. 02:04.923 --> 02:10.231 [SPEAKER_01]: in der Entwicklerwelt, wo es darum geht, ob man Micro optimisation machen soll oder nicht. 02:10.251 --> 02:22.952 [SPEAKER_02]: So, jetzt veroff die Frage wegzuschmeißen, so wie der Berater es macht, kommen raus aus deinem Beruf und kommen wieder rein in den Podcast, worum er essenziellen Wert liefern solls und unter anderem Fragen beantworten soll sie dir gestellt werden. 02:23.012 --> 02:26.998 [SPEAKER_02]: Was war die letzte Performance optimierung, die geschrieben oder gebromptet aus? 02:26.978 --> 02:30.748 [SPEAKER_01]: Ich glaube, meine Optimierungen bewegen sich eigentlich immer auf der SQL Ebene. 02:30.768 --> 02:37.987 [SPEAKER_01]: Also, wenn ich so zurück denke, in den letzten Monaten weißt, dass ich sich einmal mindestens 20 SQL queries optimiert habe. 02:38.027 --> 02:42.017 [SPEAKER_01]: Weil im Code habe ich eigentlich sehr selten, optimierungen, muss ich sagen. 02:41.997 --> 02:45.282 [SPEAKER_01]: Im Kot hast du selten um die Miehrung oder im Kot hast du selten die Bottlenex. 02:45.302 --> 02:45.823 [SPEAKER_01]: Beides. 02:45.843 --> 02:49.268 [SPEAKER_01]: Also Bottlenex und dadurch habe ich auch keine Optimierungen. 02:49.308 --> 02:56.238 [SPEAKER_01]: Weil ich selten unterwegs bin, wo man mit wirklich sehr großen Daten handtiert und oft geht's ja um große Datenmengen. 02:56.258 --> 03:01.366 [SPEAKER_01]: Und wenn ich große Datenmengen habe, dann liegen die meisten in irgendeiner Datenbank und dann sind wir wieder beim Eskoll dem. 03:01.406 --> 03:06.874 [SPEAKER_02]: Das fühlt mich aber auch zu der Anlage, dass du in letzter Zeit auch keine computerintensiven Applikation geschrieben. 03:06.854 --> 03:10.081 [SPEAKER_01]: Mein normal von dem Comput in SQL-Kür ist abschist, ja. 03:10.101 --> 03:11.023 [SPEAKER_02]: Ja, ja, genau, klar. 03:11.103 --> 03:15.493 [SPEAKER_01]: Also so zumindest ist nicht, dass ich jetzt an extreme Bottlenächstrang gekommen wäre. 03:15.513 --> 03:21.286 [SPEAKER_01]: Wo ich mir gedacht habe, ja, okay, dann ist die ZBU-Lote halt ein bisschen höher, statt drei Prozent ist die vier Prozent. 03:21.306 --> 03:21.526 [SPEAKER_01]: Das ist so. 03:21.546 --> 03:21.927 [SPEAKER_02]: Verstehe, verstehe. 03:21.907 --> 03:26.494 [SPEAKER_02]: Und die nächste Frage, da möchte ich eine Antwort, die aus der Hüfte geschossen kommt. 03:26.514 --> 03:28.317 [SPEAKER_02]: Ja, richtig Bauchgefühl. 03:28.357 --> 03:35.267 [SPEAKER_02]: Jetzt nicht 30 Kunden, vier Sekunden, fünf Sekunden überlegen, weil wir schneiden im Podcast und alle Leute, aber Audi-Grid kriegen das nie mit, wenn du so lange überlegt. 03:35.287 --> 03:37.631 [SPEAKER_02]: Ja, Trump, wenn du immer super schnell bist, ja, genial. 03:37.651 --> 03:40.515 [SPEAKER_02]: Ja, ja, nee, nee, deswegen geht's mal, Float Float, ja, Bauchgefühl. 03:40.535 --> 03:43.780 [SPEAKER_02]: Was ist dein erster Gedanke, wenn du ja war und performenst hast? 03:43.760 --> 03:46.063 [SPEAKER_02]: Und Gott, das will. 03:46.083 --> 03:50.208 [SPEAKER_02]: Nur die Zugehmens, jetzt war ohne Kathe, ohne das Audio gestütten zu haben. 03:50.248 --> 03:53.872 [SPEAKER_02]: Die kamen sogar relativ schnell, die wir sagen, so eine anderthalb Sekunden. 03:53.912 --> 03:56.976 [SPEAKER_02]: Interessant, was fühlt sich zu diesem Bauchgefühl, zu diesem ersten Gedanken? 03:57.296 --> 04:03.824 [SPEAKER_01]: Ja, grundsätzlich mal, dass Klischee, aber ihr hat in den Kollegen an der Uni, der an hoch optimierten Indextrukturen gearbeitet hat. 04:03.844 --> 04:06.747 [SPEAKER_01]: Und der hat mit Java angefangen, weil der große Java-Fan war. 04:06.727 --> 04:14.464 [SPEAKER_01]: Und auf allen Konferenzen wurde es eingereicht hat, obwohl sein Index sehr, sehr schnell war, hat es geheißen, warum machst du es in Chava, warum kommst du mit Chava um die Erkehung? 04:14.484 --> 04:15.366 [SPEAKER_01]: Gott, es will. 04:15.386 --> 04:23.183 [SPEAKER_01]: Geweckt mit einem Chava und am Ende hat das dann in C implementiert, damit alle Leute glücklich waren und man muss zu geben, er war dann auch schneller in C. 04:23.163 --> 04:25.830 [SPEAKER_01]: aber gar nicht so viel schneller wie immer vielleicht den Kind. 04:25.871 --> 04:38.185 [SPEAKER_02]: Ich glaub auch, dass immer nur Leute sagen, ja war es langsam oder ja war unperformen, das sind so zwei gegen leufige Begriff in einem Satz, dass das von Leuten kommt, die wenig Ja war schreiben. 04:38.165 --> 04:42.573 [SPEAKER_01]: Man muss schon ehrlich schon sagen, dass die JVM irgendwo da dazwischen liegt. 04:42.633 --> 04:48.784 [SPEAKER_01]: Das heißt, wenn du natürlich jetzt Hardcore-Optimierungen machen willst, dann musst du immer diese JVM mitdenken. 04:48.824 --> 04:50.647 [SPEAKER_01]: Was macht denn die JVM deinem Hintergrund? 04:50.687 --> 04:52.350 [SPEAKER_01]: Was macht die vier Optimierungen? 04:52.391 --> 04:57.299 [SPEAKER_01]: Und in C-Kanzool da einfach da gibt's niemand, der dich irgendwo da unterstützt bei der Note-Optimierungen. 04:57.379 --> 04:58.421 [SPEAKER_01]: Du musst halt alles selber machen. 04:58.461 --> 05:00.104 [SPEAKER_01]: Du kannst du auch alles selber machen. 05:00.525 --> 05:01.607 [SPEAKER_01]: Das sehe ja so als... 05:01.587 --> 05:19.022 [SPEAKER_01]: größten Unterschied wobei die JVM natürlich auch wenn man jetzt zurückblickt auf die letzten 20 Jahre, in denen scharversicht natürlich sehr stark weitentwickelt hat, hat sich die JVM weitentwickelt und ist auch wesentlich optimierte geworden und hat auch mehr Möglichkeiten und werden wir heute auch Dinge besprechen. 05:19.002 --> 05:40.740 [SPEAKER_02]: Ja, ob ich bin mir dann nicht sicher, ob ich da 100 Prozent mitgehe, dass man immer darüber nachdenkt, muss macht, was macht die JVM dafür, Optimierung, denn dann würde den ja das gleiche Argument gelten, okay, bei C, was macht der Compiler für Optimierung, weil der Compiler, optimiert ja auch Sachen weg und schreibt ja auch ins Geheim mehr oder weniger, dein Code um, wo er denkt, ist, er wäre smart, hauen Co. Also, ja, das muss du auch machen. 05:40.720 --> 05:49.611 [SPEAKER_01]: Weil ich kann mir selber rennen in den ganzen Optimierungsbeispielen und so, die wir gemacht haben, auch Barallelles rechnen und zu weiter damals an der Uni noch. 05:49.631 --> 05:56.100 [SPEAKER_01]: Ich hatte das sehr oft, am Ende war das Programm super schnell und da bist du draufgekommen, der hat ja einfach eine komplette Loop wegoptimiert. 05:56.160 --> 06:02.328 [SPEAKER_01]: Und du wollte es das eigentlich zeigen, dass du es irgendwie schneller machen kannst, er kommt bei einer O3-Fleck, hat einfach gecheckt. 06:02.348 --> 06:05.191 [SPEAKER_01]: Oh, da gibt's nie einen Output, der wird nie verwendet. 06:05.231 --> 06:07.234 [SPEAKER_01]: Ich kick mal die ganze Loop einfach raus. 06:07.214 --> 06:20.327 [SPEAKER_02]: Ich meine meine ganzen Kompiler optimierung gab es natürlich auch ätliche Bucks in der in der ganzen Historie aber darum geht es heute mal etwas darum, ob ich dich davon überzeugen kann, dass Java und Performance doch vielleicht in einem Satz genannt werden könnte. 06:20.628 --> 06:34.622 [SPEAKER_02]: Denn die heutige Episode dreht sich um ein Thema, was ich schon länger im Kopf habe, schon eigentlich fast zwei Jahre, aber ich kam noch nie dazu und zwar sprechen wir heute über die 1-Billion-Row-Challenge also oft zu Deutsch, weil 06:34.602 --> 06:48.140 [SPEAKER_02]: Es gibt auch das Wort Billionen in Deutsch, aber eine Billjen in Englisch ist nicht eine Billionen in Deutsch, eine Billjen in Englisch ist eine Milliarde in Deutsch, also reden wir heute über die eine Milliarde Zeilen Challenge. 06:48.160 --> 06:49.624 [SPEAKER_02]: Hast du davon schon mal gehört? 06:49.604 --> 06:53.728 [SPEAKER_02]: Von dir monastakt, das ist schön, dass du dich an unsere Kommunikation erinnerst. 06:53.748 --> 06:55.530 [SPEAKER_02]: Wir nimmst uns etwas positives hier. 06:55.570 --> 06:56.211 [SPEAKER_02]: Fangen wir an. 06:56.231 --> 06:58.454 [SPEAKER_02]: Und zwar gibt es einen Software-Engineer. 06:58.474 --> 07:00.215 [SPEAKER_02]: Wer heißt Gunner Molling? 07:00.276 --> 07:03.819 [SPEAKER_02]: Gunner Molling hat früher für Rettet gearbeitet. 07:03.839 --> 07:09.826 [SPEAKER_02]: Zum Zeitpunkt dieser 1-Billion Road-Challenge von der Wegleiche Zielen hat er bei decode Bill gearbeitet. 07:09.846 --> 07:12.709 [SPEAKER_02]: Das ist ein Apache Flink Software-Sys Service. 07:12.689 --> 07:22.517 [SPEAKER_02]: Start, wenn man so möchte, ein Patchy Flink ist so stream-Processing, und jetzt zwischen ist er auch so verängene bei Konflulen, dass es die Firma hinter Kafka für die Leute nicht kennen. 07:23.098 --> 07:27.711 [SPEAKER_02]: Und Gunner hatte eine Idee, lassen uns doch mal einen Performance-Kontest starten. 07:27.691 --> 07:33.297 [SPEAKER_02]: Da hat er sich gedacht, ich setze sich mal hin, tüfteln mal ein bisschen und schreibt er auf dem Blockpost. 07:33.317 --> 07:39.603 [SPEAKER_02]: Den hat er dann im ersten Jahr nur 2024 veröffentlicht und die Challenge hat er gesagt okay, die ich jetzt gleich beschreibe, rumsteiget. 07:39.623 --> 07:45.249 [SPEAKER_02]: So, wir starten jetzt am ersten 24 und die geht jetzt uns genau ein Monat bis zum 31. 07:45.289 --> 07:48.833 [SPEAKER_02]: Jahr nur bis miternacht und dann schauen wir mal was passiert. 07:48.893 --> 07:53.057 [SPEAKER_02]: Wo mit er nicht gerechnet hätte, der Performance-Kontest ging ein wenig wie rein. 07:53.037 --> 07:56.821 [SPEAKER_02]: Und hat immer ein wenig mehr Arbeit gemacht, als er eigentlich wollte. 07:56.861 --> 07:59.264 [SPEAKER_02]: Aber was hat er eigentlich in diesem Blockpost beschrieben? 07:59.304 --> 08:01.807 [SPEAKER_02]: Und zwar sagt er, lasst man Performance-Kontest machen? 08:01.847 --> 08:09.295 [SPEAKER_02]: Lass doch mal gucken, wie weit sich modernes Java verformes technisch eigentlich treiben ist. 08:09.315 --> 08:13.660 [SPEAKER_02]: Und vielleicht kommen da Lösungen bei rum, von dem man auch noch etwas Neues lernen kann. 08:13.820 --> 08:16.664 [SPEAKER_02]: Das war die Motivation, und da hat er sich eine Aufgabe ausgedacht. 08:16.684 --> 08:19.787 [SPEAKER_02]: Die Aufgabe, und das fand ich so schön, so hat er sein Blockpost begonnen. 08:19.767 --> 08:24.715 [SPEAKER_02]: Deine Aufgabe, komm mal, solltest du sie annehmen, ist trügerisch einfach. 08:24.735 --> 08:35.311 [SPEAKER_02]: Schreibe ein Jahr war Programm, das Temperaturmesswerte aus einer Texterteile ausließt und die minimal Mittel und maximal Temperatur pro Wetterstation berechnet. 08:35.351 --> 08:39.698 [SPEAKER_02]: Es gibt nur ein Haken, die Datei hat eine Milliarde Zeilen. 08:39.738 --> 08:45.928 [SPEAKER_02]: Und ich weiß, du guckst ja nicht so viele Hollywood-Actionen-Filme, aber Deine Aufgabe, solltest du sie annehmen. 08:45.968 --> 08:46.669 [SPEAKER_02]: Woher kommt das? 08:46.649 --> 08:53.998 [SPEAKER_02]: Ehem, Matrix, Mission Impossible, oder eigentlich Deine Aufgabe im Falle, dass du sie an nehmst. 08:54.018 --> 08:54.598 [SPEAKER_02]: Klar, klar, klar, klar. 08:54.618 --> 08:56.540 [SPEAKER_02]: Und da nachzerstört sich dann dieses Memo selbst. 08:57.321 --> 09:00.385 [SPEAKER_02]: Dieses Blockpost hat sich nicht von selbsterstört, aber es tottet schon. 09:00.405 --> 09:06.953 [SPEAKER_02]: Also, diese Textertei hat auch eine relativ einfache Struktur und zwar Hamburg, sie Mikolon, Temperaturwelt, also 12,0. 09:07.553 --> 09:11.678 [SPEAKER_02]: Krakau, sie Mikolon, 12,6 und so weiter und so vor. 09:11.658 --> 09:21.677 [SPEAKER_02]: Das Programm was du schreiben sollst, soll halt den minimalen Mittelwert und den maximalwert pro Messstation also Hamburg, Krakau und so weiter in alphabetischer Reihenfolge ausgeben. 09:21.697 --> 09:31.516 [SPEAKER_02]: Also Hamburg, gleich 5 Grad ist der niedrigste Wert 18 Grad ist der Mittelwert 27,4 ist der maximalwert Komma, Krakau und so weiter. 09:31.557 --> 09:32.839 [SPEAKER_02]: In alphabetischer Reihenfolge. 09:32.819 --> 09:35.543 [SPEAKER_02]: Ziel der ganzen Challenge, wer kriegt am schnellsten hin. 09:35.603 --> 09:45.196 [SPEAKER_02]: Und die Regeln, weil wir könnten jetzt hier an einer hier machen, keine Regeln haben, aber guter sagte, was man ein paar Regeln festlegen und die fand ich auch ganz interessant. 09:45.216 --> 09:47.720 [SPEAKER_02]: Du darfst keine Exzellen abhängigkeiten nutzen. 09:47.740 --> 09:50.563 [SPEAKER_02]: Das bedeutet also eigentlich, wenn du so möchtest du nur Ständertlip. 09:50.604 --> 09:57.453 [SPEAKER_02]: Ja war ohne Lee, also auch keine der Riewarte irgendwie wie Kotlin und auch kein Java native interface. 09:57.473 --> 10:01.138 [SPEAKER_02]: Also, dass du mit Ja war was anderes, andere Sprache callst oder so. 10:01.118 --> 10:09.788 [SPEAKER_02]: Dann hast du ja schon über die JVM gesprochen und bei Jahr war gibt es ja auch Alternative Run Times, Open JDK, Grail VM und so weiter und so fort. 10:09.808 --> 10:15.515 [SPEAKER_02]: Die wurden erlaubt, aber nur wenn sie in einem spezifischen Package Manager verfügbar waren. 10:15.575 --> 10:20.561 [SPEAKER_02]: Also das nennt man SDK-Man, das sind Software Development Kit Manager. 10:20.581 --> 10:24.105 [SPEAKER_02]: Kannst ihr vorstellen, ob ihr irgendwie so ein Paket Manager für Java Run Times gekriegt. 10:24.085 --> 10:28.090 [SPEAKER_02]: Dann fand ich sehr gut die Regel, kann mich auch in die Zahl gar nicht rauf. 10:28.110 --> 10:34.478 [SPEAKER_02]: Die Berechnung der Ergebnisse muss zur Laufzeit der Anwendung erfolgen und nicht so komplett sheim. 10:34.498 --> 10:40.725 [SPEAKER_02]: Da gibt es ja ganz dreckige Elemente, die man da fahren kann und noch mal ein bisschen Parme Informationen zu den Daten selbst. 10:40.765 --> 10:44.770 [SPEAKER_02]: Ich habe gerade Hangmburg und Krakau als Wetterstation bei Spirinand. 10:44.830 --> 10:49.536 [SPEAKER_02]: Es gibt nur maximal 10.000 Eindeutige Wetterstationsnahmen. 10:49.617 --> 10:54.688 [SPEAKER_02]: Das ist erstmal deine Meinung zu dem, zu der Aufgabe, zu dem Datenset und zu den Regeln. 10:54.728 --> 11:04.289 [SPEAKER_02]: Du als Alter Universitätsprofessor und auch Dozent, das ist aber so eine klassische Aufgabe, die man auch den Studenten geben kann, um die jene antreten zu lassen oder hat es du noch eine andere Regeln reingeführt. 11:04.309 --> 11:07.356 [SPEAKER_01]: Mein Initial geht, danke, was sofort, wie wir dir das in Notche es machen. 11:07.336 --> 11:24.957 [SPEAKER_01]: mit JavaScript an die für dich kann ich schneller sein als JavaScript, aber gut, das ist noch ein nebenbaustelle, sonst ist es natürlich eigentlich sehr cool, das Beispiel, weil es super einfach ist, also auch die Daten, es gibt nur zwei Werte, die Station und die Temperatur, weil ganz aufziehen der so test datensets und wie ganz groß, sondern da geht es halt wirklich darum, 11:24.937 --> 11:30.626 [SPEAKER_01]: Ganz einfaches Problem, viele Daten, wie kann ich das wirklich ein bisschen kleinste optimieren? 11:31.026 --> 11:40.241 [SPEAKER_01]: Also hast du wenig Möglichkeiten, als mit den Daten irgendwas zu machen oder mehr Rebaustellen und es geht halt wirklich darum, wie kannst du das schnell einlesen, wie kannst du Strings verarbeiten? 11:40.261 --> 11:45.188 [SPEAKER_01]: Klassisch, so eine Datei hat halt ganz viele Strings, text und wie kannst du das optimiert? 11:45.208 --> 11:49.695 [SPEAKER_01]: Machen, also superkleinen, nehmen wir jetzt gerade wieder überlegt, wie du es vorgelesen hast. 11:49.675 --> 11:53.021 [SPEAKER_01]: Wir sehen jetzt schon wieder fünf Ideen gekommen, das könnte man eigentlich mit Studierern der so machen. 11:53.041 --> 11:59.291 [SPEAKER_01]: Da könnte man bei der Challenge mitmachen, die eine machen der Datenbank, die anderen machen, JavaScript und so weiter eigentlich eine geniale Challenge. 11:59.311 --> 12:01.214 [SPEAKER_01]: Also ich bin voll überzeugt von der. 12:01.234 --> 12:02.356 [SPEAKER_02]: Ja, dann machen wir weiter. 12:02.376 --> 12:11.852 [SPEAKER_02]: Denn wenn du diese Challenge auch dein Studenten gibst, so wie Gunner ist, dem Internet gegeben haben, muss man natürlich auch eine Methode auswählen, wie man die ganze Sache den Test hat. 12:11.832 --> 12:16.298 [SPEAKER_02]: Gunner hat sich gedacht, okay, ich teste das alles, also nicht, ich an die Sommel, ich Gunner. 12:16.358 --> 12:21.384 [SPEAKER_02]: Und zwar, hat er gesagt alle Lösungen werden bitte als Pulby Quest Submitted, bei Gitter. 12:21.404 --> 12:23.587 [SPEAKER_02]: Und irgendwann nachdem einen 30. 12:23.627 --> 12:32.338 [SPEAKER_02]: Januar, so im Februar, schnappt sich Gunner die Lösungen und testet das Zentral auf einem Hetznersterbar, mit acht DDZierten CPUs und 32 GB RAM. 12:32.318 --> 12:48.105 [SPEAKER_02]: Er hat dann auch ganz genau geschrieben, wie er getestet hat, das bedeutet er, dass Linux Time Command zur Zeitmessung genommen, er hat jedes Fatmischen fünf mal laufen gelassen, er hat das schnell zu und das langsamster Ergebnis verworfen und den Durchschnitt aussehen drei mittleren übergebliebenen ermittelt. 12:48.546 --> 12:51.471 [SPEAKER_02]: Willi sagen es eine fähre, fähre runtime, oder? 12:51.491 --> 12:57.381 [SPEAKER_02]: Also eine fähre Zeitmessung, um halt irgendwie so neu sie neighbor und co, alles mal irgendwie auszustießen. 12:57.361 --> 13:19.960 [SPEAKER_01]: Und natürlich das klassische Käschenproblem, weil wenn du die Daten natürlich vom Operating System schon im Käschligen hast, im Rahmenlegen hast, dann hast du natürlich auch ein Vorteil und das ist eigentlich ab den zweiten Run, hast du die Daten irgendwo im Käschligen und erst ab den zweiten Run hast du richtige Zeitmessungen und darum, dass das größte wegzuwerfen, den größten Messwert macht, absolut sein. 13:20.142 --> 13:25.810 [SPEAKER_02]: Aber man merkt schon, du gehst schon in die richtige Ecke, weil was Caching und Ramon Kuh angeht. 13:25.830 --> 13:29.274 [SPEAKER_02]: Da kommen wir gleich ja noch mal ein bisschen zu der Kritik, weil es ist das Internet. 13:29.815 --> 13:33.620 [SPEAKER_02]: Du kannst ja nicht einfach ein Blockpost rauspacken und eine perfekte Lösung, die gibt es ja gar nicht. 13:33.660 --> 13:36.284 [SPEAKER_02]: Es findet sich immer irgendwer, der was zu mir packen hat. 13:36.324 --> 13:42.332 [SPEAKER_02]: Aber wenn du das jetzt mal so hörst, was würdest du denn so schätzen, wo liegen wir denn tatsächlich bei den Ergebnissen? 13:42.352 --> 13:48.360 [SPEAKER_02]: Wie sind immer noch bei Ja aber, was würdest du sagen, wie schnell kann man so ein Ja war, Programm? 13:48.340 --> 13:51.185 [SPEAKER_02]: laufen lassen, damit man die zu erwartenden Nägel gibt. 13:51.205 --> 13:53.188 [SPEAKER_01]: Ja, es sind ja mal 13 GB an Daten. 13:53.268 --> 13:58.117 [SPEAKER_01]: Das heißt man braucht ja eigentlich alleine schon 13 GB Transfer der Daten. 13:58.137 --> 14:05.269 [SPEAKER_01]: Also wenn du jetzt davon ausgesternst, dass die CPU schneller ist, da ist der Daten Transfer, dann hast du zumindest das die 13 GB Daten. 14:05.289 --> 14:13.082 [SPEAKER_01]: Und das sind wir da schon im Bereich, ich würde es keine aktuellen Zahlen, so im Kopf, was aktuell eine moderne Hardware hinbekommt. 14:13.062 --> 14:19.134 [SPEAKER_01]: Aber ich würde mal sagen, 13 GB von einer klassischen Festplatte braucht sich ja mehrere Sekunden. 14:19.154 --> 14:25.106 [SPEAKER_01]: Von einer SSD-Platte bist du wahrscheinlich irgendwo bei einer Sekunde vor Modimal, oder bei einen halb Sekunden. 14:25.126 --> 14:26.970 [SPEAKER_01]: Ist so eine Gruppe schätzung von mir. 14:26.990 --> 14:30.717 [SPEAKER_01]: Aber auf jeden Fall, der Datentransfer an sich ist schon durchaus sportlich. 14:30.697 --> 14:35.462 [SPEAKER_02]: Ich muss zugehen, ich bin beeindruckt, ich bin beeindruckt, also du bist wirklich auf einen richtigen Track, ja? 14:35.482 --> 14:41.107 [SPEAKER_02]: Ich greif mal ganz kurz vor, weil nämlich auch diese Zahlen habe ich natürlich vorbereitet. 14:41.127 --> 14:48.014 [SPEAKER_02]: Nur moderne NVM-ESSD, schafft 6-Wenzielziger 5-Besieben, die wir weitestern, ja? 14:48.034 --> 14:50.176 [SPEAKER_02]: Und eine klassische Server SSD, so ca. 14:50.196 --> 14:52.419 [SPEAKER_02]: 2 bis 3 Gigabyte pro Sekunde. 14:52.459 --> 14:55.962 [SPEAKER_01]: Also meistens 2 bis 3 Gigabyte für eine Spinning disk, Server Platte. 14:56.043 --> 15:10.729 [SPEAKER_02]: Nee, für für so eine sogenannte SATA SSD, also der Unterschied zwischen NVMe, SSDs und SATA SSDs ist in der Regel das Interface über das die kommunizieren, da NVMe SSDs oft über das PCIe Interface kommunizieren. 15:11.230 --> 15:15.958 [SPEAKER_01]: Das heißt, der Spending disk ist wahrscheinlich gleich langsam, weil das Interface bottleneck ist. 15:15.938 --> 15:19.443 [SPEAKER_01]: Ja, da bin ich jetzt zu weit von der wirklichen Hardware entfernt. 15:19.763 --> 15:25.651 [SPEAKER_01]: Ihr habt gerade noch mal nachschatt, so klassische Spinningsdysks waren ja eher so bei 300 Megabyte die Sekunde. 15:25.671 --> 15:28.435 [SPEAKER_01]: Ich habe es auch wieder so im Kopf und frühe die guten alten Zeiten. 15:28.455 --> 15:31.319 [SPEAKER_01]: Aber kommen wir zurück zu dem richtigen Track auf dem Lobas. 15:31.359 --> 15:37.067 [SPEAKER_02]: Also bei 13 gear bei der Rodeaten ist allein der AIO auf realistischer Hardware 2.6 Sekunden. 15:37.127 --> 15:41.633 [SPEAKER_02]: Und das bedeutet natürlich, dass allein das Programm deine Daten hat 2.6 Sekunden. 15:41.693 --> 15:43.836 [SPEAKER_02]: Warum dem aber nicht so ist, kommen wir gleich drauf. 15:43.816 --> 15:46.805 [SPEAKER_02]: Jetzt weiß ich gar nicht, dass du mir jetzt schon Zeit genannt hast, nicht, hast du nur nicht, ne? 15:46.825 --> 15:48.289 [SPEAKER_02]: Du bist sofort auf das Ero gegangen. 15:48.309 --> 15:59.040 [SPEAKER_01]: Und hast du es ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja, ja 15:59.020 --> 16:06.328 [SPEAKER_01]: Man kommt dann wahrscheinlich zu irgendwo bei den Eben 2, 3 Sekunden raus, wenn man das jetzt normal implementiert. 16:06.348 --> 16:12.014 [SPEAKER_02]: Okay, also, Gunner selbst hat als er die Performance Challenge gelondest, hat eine naive Implementierung gebaut. 16:12.054 --> 16:18.081 [SPEAKER_02]: Also wirklich hier Open, File und Gedurch die Zeilen und packt die alle in so ein R.A. und so weiter und so fort. 16:18.101 --> 16:21.945 [SPEAKER_02]: Und da hat es vier Minuten und 49 Sekunden gebraucht, ja? 16:22.065 --> 16:24.708 [SPEAKER_02]: Ohne, aber wirklich so einfach völlig dumm runtergeschrieben. 16:24.748 --> 16:27.171 [SPEAKER_01]: Es lebe die Objektorientiertheit im Chavar. 16:27.151 --> 16:33.357 [SPEAKER_02]: Ja, also ich meine, Megid Work, Megid Beautiful, Megid Fasten, Megid Fasten und dann Bühltefoll. 16:33.397 --> 16:35.779 [SPEAKER_02]: Ist ja aber auch egal, er hat Megid Work gemacht. 16:35.799 --> 16:40.623 [SPEAKER_02]: So, jetzt der Gewinner, der ganzen Challenge, hat anderthalbte Kunden gebraucht. 16:40.643 --> 16:56.398 [SPEAKER_02]: Und zwar lief die Gewinnerlösung auf der GraviM, das bedeutet, dass die Gewinnerlösung 188-mal schneller ist, als Gunners native, nicht native, 16:56.378 --> 16:58.502 [SPEAKER_02]: Na Ivelösung, schnell leist. 16:58.542 --> 17:05.093 [SPEAKER_02]: Fun fact, der mich enorm zum Grinseng gebracht muss, ich zugeben, der Gewinner ist Thomas Wötinger. 17:05.133 --> 17:11.545 [SPEAKER_02]: Thomas ist weiß Präsident Software der Belopment bei Oracle und Gründer der Grail wie im. 17:11.565 --> 17:21.542 [SPEAKER_02]: Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha 17:21.590 --> 17:30.245 [SPEAKER_02]: So, jetzt ist es aber so, das war jetzt die Gewinnerstabmischen von 1,5 Sekunden, wenn man Gunners regelwerken im Tag legt. 17:30.665 --> 17:35.013 [SPEAKER_02]: Gunner hat aber während des Monats hier und da ein bisschen Kritik bekommen. 17:35.233 --> 17:39.480 [SPEAKER_02]: Deswegen hat er noch zwei andere Bonus-Ergebnis-Listen gemacht. 17:39.460 --> 17:53.786 [SPEAKER_02]: Und zwar hab ich gerade gesagt, er hat die ganze Sache auf einem Hetzner Server abgefeuert mit acht dedicierten VCPUs und dann wurde die Frage gestellt, ja Moment mal, aber was passiert denn eigentlich, wenn wir einfach mal mehr CPUs zur Verfügung haben. 17:53.806 --> 18:00.658 [SPEAKER_02]: Also, hat man ja auch schon eine Episode zu, dass ab und zu höhere Parallelisierung nicht unbedingt immer ein schnelleres Ergebnis ist. 18:00.638 --> 18:05.943 [SPEAKER_01]: Episode 188, hab ich natürlich gerade Nachgeschatt, Skalierung, um jeden Preis. 18:05.963 --> 18:11.869 [SPEAKER_01]: Da haben wir genau besprochen, ab wann rentiert sich's denn überhaupt in die Parallele Welt einzudauchen, weil da ja auch ein gewisse Ober hätte. 18:11.929 --> 18:27.203 [SPEAKER_02]: Hier in diesem Fall lohnt es sich und zwar wurde sehr betest man mit 32 Kurs durchgeführt, also die Selbstfamissions und dann ging es auf 300.000 Sekunden runter, ebenfalls mit der Graal VM, weil jetzt nicht die Lösung von Thomas, dem VIP von Oracle. 18:27.183 --> 18:33.411 [SPEAKER_02]: Das bedeutet, dass dann die Lösung mit den 32-Kurs fünfmal so schnell ist. 18:33.471 --> 18:38.017 [SPEAKER_01]: Das heißt, sie ist dann fünfmal so schnell ungefähr, es sehen aber nur viermal so viele Kurs. 18:38.057 --> 18:39.459 [SPEAKER_01]: Genau, interessant. 18:39.519 --> 18:47.149 [SPEAKER_01]: Das wäre auch mal interessant, herastzufinden, warum es sein kann, aber wahrscheinlich gibt es ja auch noch mal irgendwelche Optimierung entkästest, die da genutzt waren können. 18:47.129 --> 18:53.175 [SPEAKER_02]: Ja, normalerweise würde ich sagen, das übersteigt meine Gehaltsklasse, weil das tut es jetzt in den Fall auch, weil das weiß ich nicht warum. 18:53.516 --> 18:59.963 [SPEAKER_02]: Und dann gibt es auch eine bonus Wiste in den Regeln stand, ja, dass es maximal 10.000 einzigartige Wetterstationen gibt. 19:00.003 --> 19:07.931 [SPEAKER_02]: Jetzt ist es aber nur so, dass er testdaten, Satz nur 413 verschiedene Wetterstationen hat. 19:07.971 --> 19:14.638 [SPEAKER_02]: Leute, die sich ein bisschen mit Competitive coding auseinandersetzt und Algorithmenoptimierung wissen, 19:14.618 --> 19:24.797 [SPEAKER_02]: Da gibt es aber potential, wenn du nämlich umso mehr Informationen über die Daten hast, die für den Performance test genutzt werden, desto eher kannst du natürlich auf diese Daten optimieren. 19:24.818 --> 19:33.454 [SPEAKER_02]: Und deswegen wurde mal ein neues Datensätterstellt, wo wirklich 10.000 verschiedene einzigartige Wetterstationen erzeugt wurden. 19:33.434 --> 19:36.900 [SPEAKER_02]: Und jetzt könnte man sagen, wie an die war, um ist das eine relevante. 19:36.920 --> 19:44.614 [SPEAKER_02]: Ja, also auf der einen Seite, wenn du natürlich andere Strings das beeinflusst, das natürlich die Entscheidungen, wie du das Fall passt. 19:44.634 --> 19:48.641 [SPEAKER_02]: Wenn du kleinere Strings das zum Beispiel kannst du andere Hechfunktionen nutzen. 19:48.661 --> 19:53.730 [SPEAKER_02]: Und wie gesagt, du kannst halt nicht deiner Algorithmen auf die speziellen Datensetze anpassen. 19:53.750 --> 19:55.854 [SPEAKER_02]: Data Setover fitting nennt man so was. 19:55.874 --> 19:58.058 [SPEAKER_02]: Dann kannst du nämlich alles relativ gut handt tunen. 19:58.038 --> 20:01.384 [SPEAKER_02]: Ja, und das hat die Top 10-Lisse dann auch noch mal ein bisschen durchgemixed. 20:01.404 --> 20:12.402 [SPEAKER_02]: Also kann man sagen, nur weil die Lösung, die bei dem originalen Regelsett gewonnen hat, das ist nicht automatisch der Gewinner dann, wenn die Testzenarien minimal geändert werden. 20:12.943 --> 20:21.598 [SPEAKER_02]: Ein Fanfekt gibt es jedoch und zwar gab es einen Teilnehmer, der bei allen drei Tests, das bedeutet bei dem originalen Regelwerk. 20:21.578 --> 20:29.972 [SPEAKER_02]: Bei dem Regelwerk mit den 32 CPUs und mit den 10.000 einzigartigen Wetterstationen in den Top 3 war eine einzige Satmischen. 20:29.992 --> 20:36.122 [SPEAKER_02]: Und da könnte man schon darüber sprechen, okay, das ist ja so die beste, würde ich sagen, well-rounded Blöse oder? 20:36.142 --> 20:39.788 [SPEAKER_01]: Außer du hast nur einen Datensetz, wo du 400 Städtionen in Trinken hast. 20:39.908 --> 20:42.152 [SPEAKER_01]: Es ist komplett immer drauf an, was du vier Daten hast am Ende. 20:42.132 --> 20:46.056 [SPEAKER_01]: Weil vielleicht hat die Lösung dann eine Problem mit 20.000 Stationen. 20:46.076 --> 20:49.320 [SPEAKER_01]: Also man, es ist immer die Frage, wie weit ist das Ganze optimiert. 20:49.340 --> 20:54.386 [SPEAKER_01]: Vielleicht darf noch jetzt nach der Licht zur Klärung, weil du jetzt gesagt hast, okay, die Strings sind ein länger geworden bei den Stationen. 20:54.426 --> 20:58.550 [SPEAKER_01]: Das würde ja auch heißen, die Transferzeit von Disk wird länger. 20:58.570 --> 21:01.093 [SPEAKER_01]: Und eigentlich werde es ja alles Disk bauen. 21:01.133 --> 21:06.199 [SPEAKER_01]: Wenn man das wirklich von Disk laden würde, wie du ja Initial schon gesagt hast, erstens, 21:06.179 --> 21:31.326 [SPEAKER_01]: wird das Ganze öfters ausgeführt, das heißt, diese ganzen Informationen von der Platte wandern mal zuerst in den Ram, entweder über ein Betriebssystem Cash und dem Ram sprechen wir dann von 40 bis 60 GB pro Sekunde, das heißt, wir laden des gesamte Fall unter einer Sekunde eigentlich in Richtung CPU, wenn das schon im Ram liegt und dadurch kann man erst solche Micro-Optimierungen machen, weil sonst bin ich mal ziemlich sicher, dass eigentlich das Bottlenack die Festplatte werden. 21:31.390 --> 21:38.300 [SPEAKER_02]: Ja, also jetzt greif ich mal ein bisschen vor, bevor wir zu der offizellen Kritik an der Challenge kommen, denn du sprichst es ja schon an. 21:38.320 --> 21:44.108 [SPEAKER_02]: Also auch die auch im Test hat Gunner anscheinend die der Teibereiz auf eine Ramm des Gelegt. 21:44.148 --> 21:47.613 [SPEAKER_02]: Das bedeutet auch im ersten Rahn lag die schon im Ramm. 21:47.633 --> 21:52.039 [SPEAKER_02]: Die lag gar nicht also, die der Teilt des Test hat halt lag gar nicht auf einer realen Festplatte. 21:52.059 --> 21:56.385 [SPEAKER_02]: Das bedeutet natürlich dann genau das, was du gesagt hast, dass der Disk 21:56.365 --> 21:57.567 [SPEAKER_02]: I.O. 21:57.607 --> 22:02.576 [SPEAKER_02]: Eigentlich ja maskiert ist, was in der realen Welt ja den dominante bottleneck ist. 22:02.596 --> 22:11.792 [SPEAKER_02]: Also du misst ja eigentlich hier den reinen CPU und memory-band beiden durchsatz und nicht den bottleneck von festplanen I.O. 22:11.812 --> 22:18.323 [SPEAKER_02]: der eigentlich bei realen Big Data Work-Lots der bottleneck ist und somit hat das mit der realen Welt relativ wenig zu tun. 22:18.303 --> 22:29.016 [SPEAKER_01]: Aber die Challenge wäre sonst relativ langweilig, weil wenn der Limitieren der Faktor die Fassplatte wäre oder der Speicher, also SSD Speicher, dann hätte es nicht zum Optimieren. 22:29.056 --> 22:34.243 [SPEAKER_01]: Dann könnte es auf der CPU eben noch so viel Optimieren, wenn das Limit die SSD ist, dann kann es so richtig machen. 22:34.263 --> 22:38.488 [SPEAKER_01]: Also es wäre eine langweilige Challenge, insofern ist das ja wohl sinnvoll, das so aufzusetzt. 22:38.468 --> 22:44.435 [SPEAKER_02]: Das ist nicht ganz, ganz, ganz richtig, denn einige Optimierungen werden jetzt besonders belohnt. 22:44.455 --> 22:48.259 [SPEAKER_02]: So, so handgeschrieben, CPU-Instructions und so weiter. 22:48.279 --> 22:52.404 [SPEAKER_02]: Andere Optimierungen, wenn du die der Teil von der Festpartelle lesen würdest, könntest du trotzdem machen. 22:52.424 --> 23:06.079 [SPEAKER_02]: Wie zum Beispiel, du könntest den Page Cash umgehen, du könntest also in Corona's Prefetching machen, du könntest vorher die ganze Sache komprämieren, könntest vielleicht sogar eine spaltenorientierte Formate transfereieren und ähnliches, also solche ganzen Tricks, 23:06.059 --> 23:07.682 [SPEAKER_02]: Lässt du komplett aus und vor? 23:07.702 --> 23:20.385 [SPEAKER_02]: Und ja, du hast recht, man kriegt das Ergebnis an mit hoher Wahrscheinlichkeit nicht auf eine Sekunde, aber du kannst eine ganze Menge optimierungen bezüglich ein hoh machen Betriebssystem und co, die jetzt komplett aus und vorglassen werden. 23:20.565 --> 23:21.928 [SPEAKER_01]: Ist ein Fairpoint? 23:21.948 --> 23:28.219 [SPEAKER_01]: Man muss sozusagen da musst du die Daten wieder umschreiben und das ist halt auch nicht realistisch, weil wenn die Daten umschreibt, kann ich sie gleich zusammenfassen. 23:28.199 --> 23:36.168 [SPEAKER_01]: Aber wie dem auch sei, es ist die Challenge so definiert, dass es eben um den Kode optimierungen geht, die du beim Processing im CPU leiert wird. 23:36.188 --> 23:42.355 [SPEAKER_01]: Und das finde ich auch schön an dieser Challenge, dass es eben so ein kleines Fenster ist, dass es genau um diese Dinge eben auch geht. 23:42.736 --> 23:52.367 [SPEAKER_02]: Jetzt ist natürlich die große Frage, wie kreativ ist das Internet geworden oder zumindest die Leute, die eine Submission eingereicht haben, welche Optimierungen haben sie gemacht. 23:52.347 --> 23:56.153 [SPEAKER_02]: Und da waren Paar optimierungen dabei, die wollen wir jetzt mal so ein bisschen durchgehen. 23:56.213 --> 24:03.565 [SPEAKER_02]: Die sind vielleicht hier und da etwas jahrverspezifisch, aber im Endeffekt lassen sie sich glaube ich auch fast alle besprochen übertragen. 24:03.586 --> 24:08.734 [SPEAKER_01]: Genau, aber klappt nämlich immer, dass das irgendwie dann irgendwelche JVM-Sachen sind oder sonstige Dinge. 24:08.774 --> 24:16.026 [SPEAKER_01]: Aber so Grundlegern, ob die Mehrungen kann man so wohl für Chabermachen, die würde man auch in zehn machen, die funktionieren bei BHAB im Prinzip auch... 24:16.006 --> 24:21.816 [SPEAKER_01]: Endlich, weil im Hintergrund trotzdem das Operating System arbeitet, also es sind schon allgemein gültige Optimierung. 24:21.836 --> 24:23.098 [SPEAKER_01]: Die meisten zumindest. 24:23.119 --> 24:33.397 [SPEAKER_02]: Die erste Optimierung, die vielleicht gar nicht so offensichtlich ist, die für mich auch wieder interessant war, ist, dass natürlich eigentlich alle Lösungen parallel gearbeitet haben. 24:33.417 --> 24:36.462 [SPEAKER_02]: Also, die haben wirklich auf 8 CPU-Cos gearbeitet, okay cool. 24:36.442 --> 24:39.806 [SPEAKER_02]: Da natürlich auch später das ganze Resaltzeit auch irgendwie ausgegeben werden muss. 24:39.826 --> 24:43.211 [SPEAKER_02]: Kann man sich denken, ja gut, dann habe ich dann vielleicht jetzt eine Hechmap. 24:43.231 --> 24:47.336 [SPEAKER_02]: Da schreibe ich die ganzen Daten rein, Wetterstation, irgendwie als Kie und der Drunter. 24:47.356 --> 24:53.104 [SPEAKER_02]: Vielleicht noch mal eine Hechmap oder einfach nur in Aire mit dem Min-Mittel und Max Temperaturwert. 24:53.124 --> 24:54.566 [SPEAKER_02]: Und dann schreibe ich die einfach da rein. 24:54.666 --> 24:58.651 [SPEAKER_02]: Das Problem ist natürlich, wenn auf 8 Kurs arbeiten, dann hast du natürlich parallelisierung. 24:58.671 --> 25:05.200 [SPEAKER_02]: Dann je nachdem, welche Hechmap du dann dann nutzt, kannst du vielleicht parallel schreiben oder die Witthalt global gelockt. 25:05.180 --> 25:23.678 [SPEAKER_02]: In einem Performance-Context locking, nach ihr merkt schon alles ein bisschen unverternhaft, einer der Optimierung, die eigentlich jeder genutzt hat, lokale Hashmaps, damit jeder das rett halt eigentlich eigenständig arbeiten kann, weil sonst würde viel zu viel Zeit zu Synchronisationen und zum Locking halt verbraucht werden und dann halt am Ende einfach gemürtcht und rausgeschrieben. 25:23.658 --> 25:42.428 [SPEAKER_01]: Wobei auch da wieder du musst du durch die Mörtschzeit mitrechnen, also wenn du im ganz allgemeinen das optimierst kann und durchaus sein, dass das Mörtschenn am Ende wieder sehr dauer ist, aber üblicherweise würde jetzt auch mal sagen, das ist meistens der schnelleres Schritt vor allem, wir sprechen daher von 400 Wetterstationen, das hast du nur 400 Wetterstationen im Mörtschenn. 25:42.448 --> 25:48.518 [SPEAKER_01]: Wenn du jetzt 400.000 Wetterstationen hat, das sieht die Sache vielleicht schon wieder ganz anders aus, so wie 4 Millionen Wetterstationen. 25:48.498 --> 25:54.906 [SPEAKER_02]: Das ist, das ist korrekt, aber ich glaube, das ist ja eine Sache, die man sehr schnell durchmessen kann. 25:54.926 --> 25:59.853 [SPEAKER_02]: Also hast du jetzt eine globale Hechmeppe oder hast du eine Hechmeppe Post-Ret, das ist ja relativ schnell umgeschrieben. 25:59.893 --> 26:04.359 [SPEAKER_01]: Was auch noch ganz interessant war, war bei dieser parallelisierung wie die Daten aufgeteilt wurden. 26:04.379 --> 26:07.182 [SPEAKER_01]: Weil du hast ja eine große Datei, die du lesen musst. 26:07.503 --> 26:14.792 [SPEAKER_01]: Jetzt ist es Problem, du weißt ja nicht, wenn das Drinks sind, wo ist denn ein sauberer Cut bei diesem Datei? 26:14.772 --> 26:31.751 [SPEAKER_01]: Und was da gemacht wurde, ist, dass man grundsätzlich einfach mal die Datei aufsblitet, man zieht irgendwo die Grenze und dann sagt man aber jeder einzelner Threat, fängt nicht am Start an, bei der Position, die mitgeteilt wurde, sondern dieser Threat Schautmal, wo ist denn die nächste neue Teile? 26:31.771 --> 26:36.356 [SPEAKER_01]: Und als die nächste neue Teile wird dann genommen und von da aus wird gelesen. 26:36.836 --> 26:44.104 [SPEAKER_01]: Das heißt, wenn du in der Mitte von einer Teile bist, dann ist es kein Problem, das heißt, du suchst dir die nächste Teile und ab da fangst du arbeiten an. 26:44.084 --> 26:49.629 [SPEAKER_01]: Jetzt hast du noch ein Problem, wenn du jetzt als die zweite Teile nimmst, wer werbertet die erste Zeile. 26:49.649 --> 26:59.158 [SPEAKER_01]: Und das ist dann einfach so gelöst worden, dass da Fred am Ende, wenn das Ende erreicht ist von seiner Position, der trotzdem noch mal weiterließt bis zu nächsten neuen Teile. 26:59.198 --> 27:07.526 [SPEAKER_01]: Das heißt, diese verloreneteile wird vom Fred, der vor übernommen, das also wirklich jede einzelne Teile prozess wird und keine Teile verloren wird. 27:07.546 --> 27:12.471 [SPEAKER_01]: Und so kann man einfach mal stuhre, diese dabei, in der Mitte durchschneiden und des Server verteilen. 27:12.451 --> 27:18.978 [SPEAKER_01]: Also, es sind so kleine Kleiden, die man einfach beachten muss, in der Erechnung, weil wir uns vielleicht weglassen oder einfach das sinnvoll durchzählen. 27:18.998 --> 27:25.805 [SPEAKER_01]: Aber wenn man halt diese Zeit nicht hat und nicht weiß, wo eine Zeit der Aufhalt, wo eine Zahl der Beginn muss man dann mit solchen Taktikungen arbeiten. 27:25.865 --> 27:37.277 [SPEAKER_01]: Aber wenn wir mal von dieser kleinen Optimierung und Anfüchseichen oder sehr naifen Implementierung von parallelisierungen auf mehreren Threats, auf eine Optimierung gehen, die wirklich extrem ein Impact hat. 27:37.297 --> 27:41.682 [SPEAKER_01]: Und das ist eigentlich so die Grundlegens der wichtigste Optimierung meiner Meinung nach, 27:41.729 --> 28:07.602 [SPEAKER_01]: ist natürlich dieses Problem, wenn du in Chava einfach mal eine große Datein einleist, dann gehst du der Zeile für die Zeile durch, stößt objekte, für jede Zeile gibts ein Objekt, für jede Wetterstation, für jeden Namen, gibts eine neuen String, alles wird schön am heb angelegt, zuerst haste objekte objekte objekte objekte und danach kommt hin und wieder der Gabelschcollector vorbei und fängt dann an einem Milliarde von Zeilen und Objekten 28:07.582 --> 28:09.404 [SPEAKER_01]: Und das wird dir einfach dünnen. 28:09.424 --> 28:12.928 [SPEAKER_01]: Also, da war das dürfen Gabelschcollector keine Ahnung. 28:12.948 --> 28:18.173 [SPEAKER_01]: Wahrscheinlich 99% deiner Zeit ist nur mehr der Gabelschcollector am Weg irgendwie deine Objekte zu entfernen. 28:18.193 --> 28:20.556 [SPEAKER_01]: Und objekte generieren natürlich kostet auch viel Zeit. 28:20.876 --> 28:26.162 [SPEAKER_01]: Das heißt, wenn man mit großen Datenmengen arbeitet, ist das eigentlich die schlechteste Idee, die man machen kann. 28:26.202 --> 28:30.687 [SPEAKER_01]: Und diese nicht nur Charvert, was objekte erzeugt, machen ja andere Sprachen genauso. 28:30.667 --> 28:39.720 [SPEAKER_01]: Und was ich da eigentlich so durchgesetzt hat, ist, dass man einfach M-Map verwendet, das ist eine Möglichkeit vom Betriebssystem auf sehr große Datein zuzugreifen. 28:39.760 --> 28:41.483 [SPEAKER_01]: Das wird in der Datenbankwelt verwendet. 28:41.503 --> 28:45.248 [SPEAKER_01]: Das wird überall verwendet, wo man eigentlich mit sehr großen Datenmengen handiert. 28:45.288 --> 28:47.652 [SPEAKER_01]: Das ist nichts anderes, dass ich sagen kann. 28:47.692 --> 28:53.701 [SPEAKER_01]: Map mir doch eine große Datei in meinem Falsystem in einen virtuellen Speicherbereich. 28:53.721 --> 28:56.725 [SPEAKER_01]: Und dann greifst du nur mehr auf diesen virtuellen Speicherbereich zu. 28:56.705 --> 28:59.670 [SPEAKER_01]: Und des Betriebssystemen im Hintergrund meinescht alles wirdig. 28:59.730 --> 29:03.116 [SPEAKER_01]: Das heißt, wann werden die Daten wirklich geladen von der Festplatte? 29:03.136 --> 29:04.899 [SPEAKER_01]: Wo waren die Zwischen gespeichert? 29:04.919 --> 29:14.275 [SPEAKER_01]: Wenn du was endast, wann die wieder zurückgeschrieben, das heißt, dieses ganze Management im Hintergrund, wann werden welche Teile von der Festplatte geladen und geschrieben? 29:14.255 --> 29:20.865 [SPEAKER_01]: Es wird vom Betriebssystem übernommen und du kannst eigentlich auf die Daten zugreifen, als hätte es tun, riesengroßen Speicherbereich. 29:20.905 --> 29:23.128 [SPEAKER_01]: Der kann auch größer als der Ram an sich sein. 29:23.168 --> 29:32.922 [SPEAKER_01]: Weil das dann automatisch im Hintergrund gemäbt wird, die Batches werden geladen durch diese ganzen Käsche ist durchgereicht und dann am Ende von deinem Programm überhaupt verarbeitet. 29:32.902 --> 29:36.808 [SPEAKER_01]: Und das ist natürlich super optimiert, weil das Betriebssystem, das im Hintergrund macht. 29:36.828 --> 29:46.864 [SPEAKER_01]: Und wie gesagt, auch große Datenbanksysteme, wenn du da irgendetwas eine zeile Endes-Dinertatenbank, dann wird deinem Hintergrund wieder dieses Map-Tfall zurückgespreichert auf die Versplatte. 29:46.884 --> 29:50.430 [SPEAKER_01]: Und genau dieses Vorgehen haben die natürlich auch alle verwendet. 29:50.450 --> 29:59.685 [SPEAKER_01]: Das heißt, man mapt einmal diese 13 GB in einen virtuellen Speicher und geht dann schrittweise durch diese Datei durch und liest die Daten. 29:59.665 --> 30:07.896 [SPEAKER_01]: Und der große Unterschied ist, dass dann du in Chava keine Objekte hast, die du immer zeigen musst, sondern du greifst direkt auf den Speicher zu. 30:08.317 --> 30:10.680 [SPEAKER_01]: Früher war das nur möglich mit Ansäff. 30:10.700 --> 30:23.057 [SPEAKER_01]: Ansäff ist in der Chava Welt eigentlich so ein Begriff, der auf den gewissen Sprachumfang Funktionen hinweist, die eben Ansäff sind, nicht sicher sind im Sinne von Speichermanagement. 30:23.037 --> 30:44.860 [SPEAKER_01]: Und wenn man zum Beispiel so ein MAPT-Beitbarverwendet, der eben auf so ein MAPT vom Betriebssystem zugreift, auf so ein virtuelles Speichersystem von Naturteil, dann wird da eben direkt auf den Puffer zugegriffen und nicht mehr auf irgendwelche Objekte im Heb und dann verlieren natürlich auch gewisse Sicherheitschecks, die dem Hintergrund von Chavern natürlich, wenn es um normale Objekte geht, immer gemacht werden. 30:44.840 --> 30:49.605 [SPEAKER_01]: Und daher ist es natürlich für ein produktiven Betrieb, eigentlich eher nicht zu empfehlen. 30:49.625 --> 30:59.214 [SPEAKER_01]: Beziehungsweise viele sagen dann halt auch, wenn ich schon anselferwende, warum verwende ich dann überhaupt Java, weil dann kann ich gleich zehn verwenden, da ist alles anself sozusagen. 30:59.234 --> 31:02.117 [SPEAKER_01]: Also, bringt mir dann Java überhaupt noch ein gewissen Vorteil. 31:02.638 --> 31:06.862 [SPEAKER_01]: Seit Java 2020 gibt es da auch dann memory segments, bzw. 31:06.882 --> 31:11.286 [SPEAKER_01]: seit 2022 sind die eigentlich stabil und können auch verwendet werden, um 31:11.266 --> 31:15.572 [SPEAKER_01]: Etwas sicherer in Zugriff zu haben auf Matt Memory. 31:15.612 --> 31:21.259 [SPEAKER_01]: Das große Problem ist aber auch, dass da gewisse Jackson hintergrund noch immer gemacht werden, die das ganze Langsamer machen. 31:21.279 --> 31:25.204 [SPEAKER_01]: Schauer Team selber sagt da wird auch sehr viel gemacht. 31:25.224 --> 31:27.727 [SPEAKER_01]: 25, 25 kamen Sie das mal in dem Talk. 31:27.747 --> 31:31.091 [SPEAKER_01]: Auch wirklich angesprochen, was wir optimieren und sie machen. 31:31.111 --> 31:34.636 [SPEAKER_01]: Und dass das Memory segment dann noch wesentlich schneller werden sollte. 31:34.656 --> 31:36.278 [SPEAKER_01]: Und in Richtung Anseif. 31:36.258 --> 31:54.942 [SPEAKER_01]: von der Performance gehen sollte, Anseif ist garantiert immer der schnellste, weil da hast du einfach null checks und darum wurde das bei der Challenge eigentlich auch immer verwendet gegenüber Obwohl's memory segment schon gegeben hätte, ist man dann am Ende trotzdem wieder auf die Anseif Funktionen gegangen, weil man da einfach noch mal mehr Speedraus holen kann. 31:54.922 --> 32:09.397 [SPEAKER_02]: Jetzt ist es natürlich so, weil Ansafe mehr oder weniger debriketet wurde und das ja, weil ekosystem sich natürlich auch weiterentwickelt wurde, haben wir mal nachgeschaut in einem JDK 26 was aktuell veröffentlicht wurde, wird Ansafe, die vollmäßig exception schmeißen. 32:09.517 --> 32:23.612 [SPEAKER_02]: Das bedeutet, wenn du jetzt eigentlich dieselbe Performance-Challenge nochmal laufen lassen würdest, mit Ansafe, wird dann exceptionfliegen und wenn du die Abfangen würdest, dann wird das natürlich auch negativen Impact auf deine zeitliche Performance geben, weil exception schmeißen immer relativ teuer ist. 32:23.592 --> 32:34.138 [SPEAKER_01]: Vielleicht noch als Informationen, was das wirklich in Zahlen bedeutet hat damals, also von so einem normalen Proach auf einen Anselfer Proach, da haben wir einen Speedup von ungefähr vier. 32:34.178 --> 32:37.546 [SPEAKER_01]: Das heißt auf ein Viertel der Zeit, die es vorgebraucht hat. 32:37.626 --> 32:41.736 [SPEAKER_01]: Also das sind schon riesengrösen Ordnungen, wenn man da in den Anselfbereich hineingeht. 32:41.716 --> 32:47.584 [SPEAKER_02]: Aber wie der Name schon sagt, Anzef ist leider auch in normalen Fällen Anzef. 32:47.624 --> 32:51.590 [SPEAKER_02]: Also wenn nicht ganz genau weiß, was du da tußt, sollte du das glaube ich nicht verwenden. 32:51.630 --> 32:54.895 [SPEAKER_02]: Für so ein paar Formen ist es schön, ich sage ich, gibt Kette, ja, nutze es bitte. 32:55.315 --> 33:06.892 [SPEAKER_01]: Auf jeden Fall, wenn man mir großenfalls arbeitet, M-Map, Superding funktioniert eigentlich in jeder Sprache und lagert viel Anzbetriebssystem aus, was einfach meistens beattechnisch, eine gute Sache ist. 33:06.912 --> 33:09.816 [SPEAKER_01]: Aber auch da muss man sagen, es gibt trotzdem noch diese, 33:09.796 --> 33:14.923 [SPEAKER_01]: Einteilung von Bages von Cashlines, das spielt alles da natürlich genauso eine Rolle. 33:14.943 --> 33:20.011 [SPEAKER_01]: Das heißt, wenn man jetzt war, los in dem virtuellen Memory herumspringt, ist es natürlich trotzdem langsam. 33:20.031 --> 33:26.881 [SPEAKER_01]: Weil im Hintergrund muss dann als Betriebsstem ständig irgendwie auf der Platte herumspringen und sich wieder andere Bages von der Platte holen. 33:26.921 --> 33:28.483 [SPEAKER_01]: Das heißt, das dauert dann immer lang. 33:28.503 --> 33:32.088 [SPEAKER_01]: Also man ist jetzt nicht irgendwie automatisch super schnell immer. 33:32.108 --> 33:37.015 [SPEAKER_01]: Wenn man schlecht programmiert und irgendwie weil das Random herumspringt, wird es langsam bleiben. 33:37.035 --> 33:38.858 [SPEAKER_01]: Egal ob es jetzt memory mapped ist oder nicht. 33:38.838 --> 33:48.349 [SPEAKER_02]: Aber ich komme jetzt einfach mal mit zwei Optimierungen, die auch von jedem genutzt wurden, die deutlich einfacher zu ermöglichen sind und deutlich einfacher auch zu verstehen. 33:48.369 --> 33:52.373 [SPEAKER_02]: Jetzt nicht immer dieser N-Map und ich brauchen Informatikstudio-Marongas zu finden. 33:52.393 --> 33:54.296 [SPEAKER_02]: Und zwar, kümmere ich mich mal wieder um Hashmaps. 33:54.316 --> 33:58.440 [SPEAKER_02]: Ich habe gerade schon von lokalen Hashmaps gesprochen, die dann übersetzen nicht geteilt werden müssen oder bzw. 33:58.460 --> 34:00.402 [SPEAKER_02]: nicht synchronisiert werden müssen wegen den Locking. 34:00.422 --> 34:06.229 [SPEAKER_02]: Jetzt spreche ich mal über Custom Hashmaps. 34:06.209 --> 34:08.252 [SPEAKER_02]: auch immer die Standard-Hasch-Map ersetzt. 34:08.312 --> 34:35.811 [SPEAKER_02]: Die Standard-Hasch-Map, wenn du da Sachen reinpackst, bürgen von, weil die Standard-Hasch-Map weiß von vorne rein, nicht wie viel Entwiese reinkommen, wenn du irgendwann dauerhaft der reinschreibst, kommst du an ein Punkt, da muss die Grease-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch-Hasch 34:35.791 --> 34:54.390 [SPEAKER_02]: Und dann wird's natürlich interessant, da kannst du natürlich die ganze Sache sogar so weit treiben, dass du Kasst und Hash mit implementierst und um die Größe deiner Einträge ganz genau kennst in diesem Fall waren die Einträge dann alle 64-Bite groß, was dann ganz genau eine Cash-Line ist und somit könnte das ganze Working Set wirklich in den L1 Cash von der CPU passen. 34:54.370 --> 34:58.016 [SPEAKER_02]: Und das hat sich wahnsinn, also dann brauchst du eigentlich gar nicht mehr. 34:58.036 --> 35:00.560 [SPEAKER_02]: Würgend wie Memorie rumspringe ist, und dann hast du das Ganze da. 35:00.580 --> 35:04.486 [SPEAKER_02]: Das ist direkt in der CPO, und das bringt ihn natürlich ein schön boost. 35:04.506 --> 35:06.429 [SPEAKER_02]: Wenn du aber weißt, wie viel da du hast. 35:06.490 --> 35:10.656 [SPEAKER_01]: Er merzen genauer angeschaut, was die Implementierung von den Kastem-Herschmaps waren. 35:10.676 --> 35:15.484 [SPEAKER_01]: Aber die einfachste Hashmap Implementierung, die es hier an sich gibt, ist, du machst ne Modolo. 35:15.464 --> 35:26.141 [SPEAKER_01]: Du nimmst die Stringwerte den Intergerberd von dem String in irgendeiner Form, konntet dir es den zu einem Interger und machst ein Modulu und bekommst dann die Position von dem jeweiligen Eintrag. 35:26.401 --> 35:37.539 [SPEAKER_01]: Das ist ja so was man so ganz passigstechnisch mal lernt und wenn man nur 400 Einträge hat zu keine Koalitionen, hast du keine Probleme, dann hast du da im Prinzip Modulu 400 und bist schon glücklich. 35:37.579 --> 35:40.223 [SPEAKER_01]: Ob jetzt Modulu die schnellste Variante ist, 35:40.203 --> 35:44.350 [SPEAKER_01]: Keine Ahnung gibt es wahrscheinlich noch optimiertere Dinge, aber das wäre so die Naive. 35:44.370 --> 35:50.740 [SPEAKER_01]: Herangehensweise du machst immer einmal eine Modulo-Opiration, die auch sehr schnell ist und hast schon die Position in der Hashemannie. 35:50.761 --> 35:59.595 [SPEAKER_02]: Eine andere noch einfache Optimierung, die sogar ich wirklich schon mal angewendet habe, ist in Tager stattflot. 35:59.615 --> 36:06.126 [SPEAKER_02]: Ich habe gedacht, die Temperaturwäte sind zum Beispiel 12,4,12,4 Grad Celsius. 36:06.106 --> 36:18.588 [SPEAKER_02]: Und ich glaube, man kann davon ausgehen, dass Temperaturen in der Regel von minus 99,9 Grad bis plus 99,9 Grad von Wetterstationen in Welt sind. 36:18.648 --> 36:25.420 [SPEAKER_02]: Oder kennt so ein Ort, ohne Wetterstation steht, was über oder gleich minus 100 Grad oder plus 100 Grad. 36:25.440 --> 36:29.768 [SPEAKER_01]: Sollte bei Celsius selten vorkommen, wenn wir bei veranhalten sind, strategisch und wieder anders sind. 36:29.815 --> 36:37.393 [SPEAKER_02]: Nee, aber wir kennen die Daten, wir sind in einem ordentlichen metrischen System und nicht in irgendwas amerikanisch unterwegs. 36:37.413 --> 36:41.783 [SPEAKER_02]: Jetzt gibt's einen Simplentrick, der wird auch oft bei finanziellen Werten angewendet. 36:41.803 --> 36:45.732 [SPEAKER_02]: Und zwar, dass man die ganze Sache einfach nicht als Float speichert, sondern als Integer. 36:45.712 --> 37:02.404 [SPEAKER_02]: Denn wenn wir davon ausgehen können, dass wir immer nur eine Nachkommage schneller hat, dann multipliziert man den Temperaturwelt einfach mit 10, dann werden einfach aus 12,4 Grad, einfach 1224 und Intel-Geradmetik-Operation sind 2 bis 3 Mal schneller auf klassische CPUs als Floor-Operation. 37:02.384 --> 37:11.132 [SPEAKER_02]: Und wenn man dann somit mit ganz zahlen arbeitet, brachte das in dieser Messung allein dieser Schritt plus 40 Prozent Speed. 37:11.152 --> 37:21.061 [SPEAKER_02]: Also Minus, 40 Prozent oder bis um 40 Prozent schneller, nur weil man die Temperaturberechnung von Float auf Integerung gerechnet hat, mit dem man einfach mal zähne rechnen. 37:21.101 --> 37:30.990 [SPEAKER_02]: Solche kleinen Tweeks finde ich unglaublich schön, weil die sind super einfach zu verstehen, sie sind super schnell zu implementieren und sie sind einfach nicht kompliziert. 37:31.021 --> 37:37.691 [SPEAKER_01]: Was du jetzt halt einfach weg verschwiegen hast, ist wie komm ich denn von dem Stringbad zu dem Integer. 37:37.731 --> 37:41.898 [SPEAKER_01]: Weil das ist ja die eigentlich Schwierigkeit, das Ganze liegt als String in der Dadei. 37:41.918 --> 37:58.564 [SPEAKER_01]: Stringbalsen ist immer super teuer und auch da hat ein Teilnehmer und zwar ein wird einer messischer Student sein Handel ist Mary Kitty hat dann er optimierung geschafft, dass er wirklich auf Bid-Ebene diese ganze Umformung macht. 37:58.544 --> 38:13.123 [SPEAKER_01]: Das heißt er sieht diesen String wieder als Bittreinfolge an, macht dann sehr schlaue Bitt-Operation, eine Multiplikation eigentlich auf CPU-Ebene und nimmt sich die einzelne Deile so heraus von dieser Float-Tahl, dass er die 100. 38:13.284 --> 38:15.186 [SPEAKER_01]: Stelle, die Zähne-Stelle und die 1. 38:15.226 --> 38:16.368 [SPEAKER_01]: Stelle jeweils 1. 38:16.388 --> 38:23.337 [SPEAKER_01]: Betrachtet dann eine Multiplikation-Traft macht. 38:23.317 --> 38:32.190 [SPEAKER_01]: 18-Alu-Operationen, also das sind so die Grundoperationen auf der CPU super wenig, schafft das diesen kompletten String umzuwandeln in einen integer. 38:32.210 --> 38:42.625 [SPEAKER_01]: In demals so die einzelnen Stellen einzeln behandelt und diese einzelnen Behandlungen werden, aber über eine multiplikation parallel auf der CPU quasi durchgeführt. 38:42.605 --> 38:45.593 [SPEAKER_01]: Und so kann man jetzt umformen, wenn man natürlich die Daten genau kennt. 38:45.614 --> 38:49.846 [SPEAKER_01]: Also es geht natürlich nur mit diesem Muster, mit diesem Format. 38:49.866 --> 38:56.344 [SPEAKER_01]: Und sonst, wenn man sich denkt, wie kompliziert sonst ist, irgendein Strings zu baßen, das sind natürlich in Welten, was man sich da einsparen kann. 38:56.543 --> 39:06.208 [SPEAKER_02]: Der WD-Mesisch, der hat sich die ganze Challenge angesehen und hat relativ schnell festgestellt, nach den ersten Optimierungen, die wir gleich besprochen haben, hier mit M-Map und Intel-Jahr und all so was. 39:06.228 --> 39:09.196 [SPEAKER_02]: Wahrheit irgendwann, das passen der Temperatur der Bottleneck. 39:09.296 --> 39:13.607 [SPEAKER_02]: Und mit diesen Anruhe-Operationen, die hat er irgendwie, glaube ich, auch Twitter oder so veröffentlicht. 39:13.587 --> 39:18.014 [SPEAKER_02]: Da sind die ganzen Leuten, die die Kinder darunter gefallen, weil er niemand drauf kam. 39:18.035 --> 39:22.081 [SPEAKER_02]: Und wenn der Wolfgang von ALU-Appearationen spricht, das hat so so weg gemacht. 39:22.101 --> 39:24.846 [SPEAKER_02]: Das sind diese grundlegenden Rechnung- und Login-Operationen. 39:24.886 --> 39:29.354 [SPEAKER_02]: Also hier zum Beispiel at Substract-Inkrimant-Dekrimant, so was. 39:29.394 --> 39:31.377 [SPEAKER_02]: All das, was so eine CPU-World super schnell kann. 39:31.357 --> 39:34.922 [SPEAKER_02]: Und das wird eigentlich zum Standardteil für jede Lösung. 39:34.942 --> 39:38.006 [SPEAKER_02]: Und jetzt da gibt es noch eine Seidenstory zu der ganzen Thematik. 39:38.046 --> 39:41.951 [SPEAKER_02]: Und zwar hat er wie in der messische Studenti-Lösung wohl veröffentlicht. 39:41.971 --> 39:46.136 [SPEAKER_02]: Dann hat er weiß Präsident von Oracle, der er auch die Gewinnerlösung gemacht hat. 39:46.176 --> 39:48.399 [SPEAKER_02]: In offiziell ins Gewinnertym aufgenommen. 39:48.419 --> 39:50.462 [SPEAKER_02]: Und laut Gerüchten. 39:50.442 --> 40:00.065 [SPEAKER_02]: Ich konnte es nicht wäre ich fizieren, ich habe wirklich hart gesucht und fünf Air-Eist aufgeschmissen und so weiter und so was alles etwas zeitlich etwas unscharf. 40:00.105 --> 40:05.498 [SPEAKER_02]: Was aber auf jeden Fall der Fall jetzt ist dieser Vietnameseische Studentarbeit in den Zwischen vor Oracle. 40:05.478 --> 40:16.528 [SPEAKER_02]: Also der Thomas, der VP war Oracle und der Grail VM Project liebt, hat den Kollegen anscheinend durch diese Lösung ins Grail VM geholt. 40:16.548 --> 40:21.072 [SPEAKER_02]: Und das muss man natürlich schon sagen, ist schon ein hartestorik so fern, diese den stimmt. 40:21.213 --> 40:23.475 [SPEAKER_02]: Ich konnte sie nicht 100% werifieren. 40:23.495 --> 40:28.780 [SPEAKER_01]: Ich bin jetzt schon ein bisschen entdeucht an die von deinem investigativen Journalismus Fähigkeiten. 40:28.800 --> 40:34.725 [SPEAKER_01]: Du könntest ja dem Thomas einfach nicht lenkt den Messidsschreiben. 40:34.705 --> 40:47.498 [SPEAKER_02]: Ja, was jetzt gerade läuft und jetzt gucken wir mal, ob das so funktioniert und nicht der Thomas hat nie jemand von mir bekommen, ob weil nicht mein Interview wird zum Thema Gravi machen, weil ich habe nämlich festgestellt, dass der Thomas in der Schweiz lebt und in Österreich studiert hat. 40:47.538 --> 40:52.384 [SPEAKER_02]: Deswegen habe ich die Hoffnung, dass der Thomas auch Deutsch spricht und wie ihn mal zum Interview kriegen. 40:52.424 --> 40:58.470 [SPEAKER_02]: Und dann werde ich eben glaube ich diese Frage mal stellen, so fern, dass es denn auch was wird. 40:58.510 --> 41:03.295 [SPEAKER_02]: Ich möchte jetzt nichts versprechen, Talk ist cheap, wir haben noch nicht geliefert, ist das du mich aber dazu gedrängt? 41:03.275 --> 41:08.648 [SPEAKER_01]: Aber wenn jetzt vielleicht gerade eine Kollegin vom Domus zu hat, vielleicht könnt ihr in Jahr mal anstoßen. 41:08.688 --> 41:18.651 [SPEAKER_01]: Wasser war da Mary Kitty auf der TPU, wenn ihr gemacht hat, ist natürlich ja ganz allgemeines Vorgehen und alle Lösungen arbeiten eigentlich sehr tief unten. 41:18.631 --> 41:25.403 [SPEAKER_01]: Und man kann natürlich auf der CPU Ebene sehr viel optimieren, wenn man nur die richtigen Instructions gibt. 41:25.423 --> 41:38.547 [SPEAKER_01]: Und ganz allgemein, vielleicht 7D hast du vielleicht auch schon mal gehört, an die Single Instruction, mal die Beldäter, das heißt, du gibst eine Instruction an und kannst dann aber auf einem breiteren Feld auf mehrere 41:38.527 --> 41:44.593 [SPEAKER_01]: Beiz 23 Beiz zum Beispiel die selbe Operation durchführen, die selbe Binäre Operation, die selbe Adition. 41:45.033 --> 41:57.664 [SPEAKER_01]: Das heißt, wenn man mehrere Daten schon in die Registerin leht und dann die eine Instruction anwendet, dann kann die CPU das wesentlich bei Formante durchführen, parallel eigentlich durchführen und man hat natürlich im Extremensbiet ab. 41:57.704 --> 41:59.927 [SPEAKER_01]: Jetzt haben wir sehr viel Ähnliche der Daten. 41:59.987 --> 42:05.952 [SPEAKER_01]: Und wenn man natürlich schafft mit CMD Dinge durchzuführen, dann erhält man da Dementsprechend ein Speed ab. 42:05.932 --> 42:12.999 [SPEAKER_01]: Jetzt gibt es auch noch zwar, nennt sich das, wird auch gerne so genannt Tepur-Sman CMD. 42:13.039 --> 42:20.787 [SPEAKER_01]: Das heißt, ich mache eine parallelle Operation auf einem Register, zum Beispiel auf einem 64-Bitre-Gister. 42:20.807 --> 42:28.254 [SPEAKER_01]: Ich sehe aber die einzelnen Werte in diesem Register als einzelne Werte an und macht dann wieder eine matematische Operation. 42:28.815 --> 42:34.420 [SPEAKER_01]: Und genau das ist bei der Challenge genauso gemacht worden. 42:34.400 --> 42:42.212 [SPEAKER_01]: oder in Teil einer Teile in ein Register und Prüfer, wo ist, es muss ich aufpassen, dass du mir ja verstehst, Andy. 42:42.252 --> 42:42.913 [SPEAKER_01]: Wie hast du es? 42:42.933 --> 42:45.477 [SPEAKER_01]: Sehmi Kollern, bei uns heißt Streichpunkt. 42:45.517 --> 42:52.307 [SPEAKER_01]: Das heißt, in der CSV, ich muss ja wissen, wo ist der Trainer zwischen meiner Wettestation und meiner Temperatur? 42:52.287 --> 42:55.914 [SPEAKER_01]: Und die Kosten für einen String vergleichen, wo ist denn dieses Zeichen? 42:55.934 --> 42:57.156 [SPEAKER_01]: Die sind eigentlich sehr hoch. 42:57.176 --> 43:02.767 [SPEAKER_01]: Wenn ihr das jetzt aber über Swarmach, also Sinn David in Ratchester, ist heißt es ausgeschrieben. 43:02.807 --> 43:09.660 [SPEAKER_01]: Dann kann ich mit einem Bitmuster überprüfen, wo ist denn dieses Semi-Collon in meinem String? 43:09.680 --> 43:14.650 [SPEAKER_01]: Gibt's da irgendwo ein Semi-Collon, weil das muss ich mal erstes finden, damit ihr überhaupt weiterarbeiten kann. 43:14.630 --> 43:35.085 [SPEAKER_01]: Und wenn ihr das dann gefunden habt, dann gibt es auch noch mal so einen speziellen Instrukturbefehle für die CBO, das im Instructors hat mit dabei, nennt sich TZCNT im Prinzip nichts anderes als zählen wir die Nullen nach einem Einzer, nach dem binären Einzer, da wo das Seemekoll und drin ist, dann bekommen wir die genaue Position. 43:35.065 --> 43:50.570 [SPEAKER_01]: Und das sind super wenig Allooperationen, das heißt auch da kann ich wieder super viel Zeit rausholen und kann Stringoperationen auf matematische Allogrundoperationen runterbrechen, um möglichst schnell meinen Strichpunkt, mein Semikoll und in dem String zu finden. 43:50.590 --> 43:54.677 [SPEAKER_01]: Und dann kann ich weiterarbeiten mit dem Restlichen optimierungen, die man auch schon erwähnt haben. 43:54.657 --> 44:12.121 [SPEAKER_01]: Aber auch da ist wieder natürlich wichtig, umso mehr, ich sekwenziell durch meine Daten durchgehen kann, umso mehr kann ich natürlich auch die Hardware, auch die Mährung ausnützen, weil am Ende kommt hier alles vom Ram, oder von dieser Ram-Disk, geht doch meinen L3, Cash, L2, Cash, L1, Cash, bis es dann irgendwo im Registe landet. 44:12.141 --> 44:19.872 [SPEAKER_01]: Und umso mehr, da sekwenziell durchwandern kann, also 64-bit, 64-bit, können meine Cash optimierungen. 44:19.852 --> 44:30.582 [SPEAKER_01]: dann auch auf der Hardware Ebene gemacht werden und die bekommen über Pipeline Infact dann sehr zäquenzell, meine Datenreien, CPU können immer die gleichen Instructions eigentlich wieder ausführen. 44:30.602 --> 44:39.451 [SPEAKER_01]: Das heißt, ich bin überall optimiert und kann auf allen Systemen eigentlich meine Caching Funktionen verwenden und toll dann auch wieder viel Speed raus. 44:39.471 --> 44:48.660 [SPEAKER_01]: Also, so klassische Patterns sind eigentlich immer möglichst wenig, ändern in meinen Instructions und möglichst gleiche Patterns anwenden, weil dann kann die Hardware super optimieren. 44:48.640 --> 45:02.663 [SPEAKER_02]: Du hast gerade schon Pipeline in den genannt und vorausschaubarkeit von der CPU und persönliches bei einem Stichwort Branschlist-Coding und das hat auch eine gewisse Relevanz bei den ganzen Performance-Kontes gespielt, denn da geht es mal wieder um eine Performance-Optimierung auf CPU-Ebene. 45:03.103 --> 45:07.490 [SPEAKER_02]: Jetzt mal ganz heilevel beschrieben was Branschlist-Coding eigentlich ist. 45:07.550 --> 45:10.395 [SPEAKER_02]: Du schreibst deinen Code so um, dass 45:10.375 --> 45:16.204 [SPEAKER_02]: ist als Verzweigungen eigentlich durch aritmetisch oder bittweise Operation ersetzt werden können. 45:16.244 --> 45:22.073 [SPEAKER_02]: Weil dann muss die CPU eigentlich nicht mehr raten, welchen Weg sie denn als nächstes nehmen soll. 45:22.093 --> 45:25.077 [SPEAKER_02]: Und so eine CPU, die hat eigentlich drei Ebenen. 45:25.097 --> 45:34.752 [SPEAKER_02]: Auf der einen Seite die Pipeline, hat der Wolfgang Rat schon besprochen, dann gibt es einen Predictedor, einen Branch Predictedor, und dann gibt es sogenannte Branch Misses. 45:34.792 --> 45:38.678 [SPEAKER_02]: Also dann kosten eines Fehler, falls man einen falschen Weg gegangen ist, nimm es mal so. 45:38.658 --> 45:49.639 [SPEAKER_02]: Relativsympel, ja, Leute, die Doktorbeiten über Branches Coating schreiben würde mich es glaube ich aus anderen nehmen, weil ich die Thermologie nicht treffe, aber die meisten Leute von uns würde ich mal sagen, sind nicht auf der Ebene unterwegs. 45:49.679 --> 46:01.982 [SPEAKER_02]: Im Endeffekt kann man die ganze Sache jetzt so optimieren, man kann sein Code so umschreiben, dass er Relativbranche-List ist, also das bedeutet, der Branche-Produktor versucht. 46:01.962 --> 46:08.051 [SPEAKER_02]: Zu raten, welcher der richtige Weg ist, die mit CPU erst nächstes nehmen muss. 46:08.071 --> 46:15.822 [SPEAKER_02]: Da der versucht also die nächsten 15, plus 15, 20 Stufen für die CPU vorzuschreiben und dann in die Pipeline zu legen. 46:16.162 --> 46:20.308 [SPEAKER_02]: Typischerweise liegt so ein Brandspreadler zu 95% richtig. 46:20.288 --> 46:28.179 [SPEAKER_02]: Wenn das der Fall ist, sieht performance fast gratis, weil die CPU einfach nur die Pipeline abarbeiten kann und einfach durchballern kann. 46:28.499 --> 46:31.744 [SPEAKER_02]: Ungefähr so wie ihr fahrt, nur ein ever Porsche neben Freia Autobahn. 46:31.764 --> 46:39.394 [SPEAKER_02]: Wenn er jedoch falsch rät, dann habt ihr einen branch miss und dann muss die gesamte Pipeline gelehrt und neu befüllt werden. 46:39.374 --> 46:47.143 [SPEAKER_02]: Und das könnt ihr euch schon vorstellen, je nach Echtektur, je nach 15, 25 Züglichen, kann das relativ teuer werden. 46:47.163 --> 46:53.350 [SPEAKER_02]: Und in dem Zeitspektrum, in dem wir jetzt hier gerade in dieser Performance Challenge unterwegs sind, ist dies natürlich teuer. 46:53.391 --> 47:05.685 [SPEAKER_02]: Deswegen gab es eine Optimierung vom Thomas dem Gewinner, der hat seinen Kodesohn geschrieben, dass er möglichst wenig Branches hat und hat somit die Institutionen in der Pipeline. 47:05.665 --> 47:09.072 [SPEAKER_02]: zwar erhöht, also die CPU hat er mehr Arbeit. 47:09.112 --> 47:17.249 [SPEAKER_02]: Er hat aber die Branchen misses selbst von 6% auf 0,3% reduziert und ist somit deutlich schneller geworden. 47:17.469 --> 47:20.416 [SPEAKER_02]: Es hat somit auch den Gewinn gekriegt. 47:20.436 --> 47:24.484 [SPEAKER_02]: Also Branchen des Kodings war seine letzte Optimierung der hat zehn Version geschrieben. 47:24.464 --> 47:28.030 [SPEAKER_02]: Alle zehn Versionen sind in seinem Githapp-Repository verfügbar. 47:28.050 --> 47:29.712 [SPEAKER_02]: Die haben wir auch in den Schonots verlinkt. 47:29.732 --> 47:31.956 [SPEAKER_02]: Könnt ihr euch das mal ansehen, wie das funktioniert? 47:31.976 --> 47:35.922 [SPEAKER_02]: Ganz interessante, thematik, auf welcher Ebene man da alles optimieren kann. 47:36.182 --> 47:39.948 [SPEAKER_02]: Ob man das jetzt für Produktionskoll machen muss oder nicht, weiß ich jetzt nicht. 47:41.250 --> 47:46.438 [SPEAKER_02]: Für meine Web Applikation war es nicht nur, wenn ich weil da hatte, die PE alles springt, von daher. 47:46.418 --> 47:52.465 [SPEAKER_01]: Also, ich glaube, dass es grundsätzlich, wenn du Code schreibst und der Code extrem oft ausgeführt wird, dass du es durchaus ein Sinn macht. 47:52.485 --> 48:04.378 [SPEAKER_01]: Und dann solltest du eben in deinem if Statement vielleicht nicht irgendwas drin haben, was einmal so ist, einmal so, also so ein Check auf gerade und ungerade und dann hast du ganz viel darunter mit dem Check gerade ungerade. 48:04.398 --> 48:08.983 [SPEAKER_01]: Wenn du den irgendwie weg optimieren könntest, dass es halt eher so ein Fall ist, wenn ein Fehler 48:08.963 --> 48:23.728 [SPEAKER_01]: Fall, da ist dann gehen in den L2 und sonst ist der klassische I2 immer der richtige, weil dann hast du wieder so ein Pättern, was immer angewandt wird, was immer gleich ist und alles was gleich ist, ist für die CPU und für das ganze System einfach immer von Vorteil. 48:23.748 --> 48:33.064 [SPEAKER_01]: Und drum ist es auch wichtig, dass du wenn du durch einen array durchleufst, halt so durchleufst, wie du sie memory liegt und nicht irgendwie random springst, weil sonst bringst du alles durcheinander und dann 48:33.044 --> 48:39.815 [SPEAKER_01]: Fallen überall aller Käsches raus, du hast wieder irgendwo andere Branches, Branches, Misses und das macht dann einfach alles dauer. 48:39.855 --> 48:48.189 [SPEAKER_01]: Und wenn du auf so einer Ebene bist, dass du da optimieren musst, dann macht so was natürlich, der finde ich, ich finde es mal mitzudenken und vielleicht auch waren Ifs wegzulassen. 48:48.510 --> 48:53.398 [SPEAKER_01]: Das ist ja auch möglich, vielleicht kannst du es irgendwas mit einem Bitschift zum Beispiel machen einen Stadt mit einem Ifs. 48:53.378 --> 49:12.866 [SPEAKER_02]: Jetzt haben wir schon immer ein paar Optimierung gesprochen, relativ einfache, wie zum Beispiel lokale Hashmaps, Custom Hashmaps, Intagestadt Float und so weiter, ein paar komplizierteres, branchless coding, SIMD, dem Registar, allen PIPA pro irgendwelche Bitt Instruktionen, ALU-Operation. 49:12.906 --> 49:17.833 [SPEAKER_02]: Also, da kann einem schon mal der Kopf rauchen, aber auch für die Infrastrukturte ist, was dabei. 49:17.813 --> 49:24.027 [SPEAKER_02]: Und zwar kann man eine ganz einfacher Optimierung machen und zwar acht von zehn Lösungen in den Top 10 haben die sache gemacht. 49:24.067 --> 49:28.798 [SPEAKER_02]: Wir haben einfach die Standard JVM ausgetauscht und zwar haben die einfach mal die Grail wie im genutzt. 49:28.818 --> 49:35.653 [SPEAKER_02]: Und wer jetzt nicht aus dem Java umfeld kommt, ist jetzt dafür die Frage, was ist denn jetzt schon wieder die Grail wie im? 49:35.633 --> 49:44.507 [SPEAKER_02]: gar kein Problem, wir haben euch gekawert und zwar die greil DM ist auch von oracle entwickelt ist eine alternativen Laufzeit umgebung für java bzw. 49:44.547 --> 50:01.573 [SPEAKER_02]: JDK ist voll kompatibel zu mir aber standard, da da ein paar andere Elemente die besonders für diesem performance contest sehr relevant sind auf der einen Seite, macht die greil DM so genanntes erhrt auf time kompillierung das bedeutet die greil DM erzeugt eine ausführbarer Datei und 50:01.553 --> 50:05.260 [SPEAKER_02]: Und braucht bei der Ausführung keine JVM zur Laufzeit mehr. 50:05.461 --> 50:13.657 [SPEAKER_02]: Das wird nicht so wie die JVM auf der Vitro-Maschine ausgeführt, sondern die GraviM kompliert erherd auf Time den ganzen Code in einer Ausführbare Datei. 50:14.098 --> 50:20.511 [SPEAKER_02]: Dann im Gegensatz oder im Drecken vergleicht zur JVM hat die GraviM ein extrem schnellen Staat. 50:20.851 --> 50:22.735 [SPEAKER_02]: Das ist natürlich für ein Performance-Kontest. 50:22.715 --> 50:27.324 [SPEAKER_02]: Da wo es irgendwie um teilweise similesikunden geht, schon hart relevante. 50:27.364 --> 50:32.795 [SPEAKER_02]: Die zeichert sich wohl auch durch geringen Speichenverbrauch aus, zumindest in der Basis-Version. 50:32.855 --> 50:36.442 [SPEAKER_02]: Und was auch ganz interessant ist, die kann auch mit mehreren Sprachen umgehen. 50:36.463 --> 50:42.715 [SPEAKER_02]: Das bedeutet, die greif die M, wenn man da 1,2 Extendionsreinpackt, truffel Framework heißt, dass jetzt in diesem Fall ... 50:42.695 --> 50:48.123 [SPEAKER_02]: Da kann man noch ja was gepeißen und Ruby und COC++ in der selben Randheim ausführen. 50:48.163 --> 50:50.626 [SPEAKER_02]: Also interoperatität zwischen Strachen. 50:51.047 --> 50:55.473 [SPEAKER_02]: Ganz interessant, so dass das globale Bild, was eigentlich die Greil wie im Is. 50:55.494 --> 51:07.170 [SPEAKER_02]: Ich habe gerade gesagt, acht von zehn Lösungen in der Top 10 nutzen die Greil wie M. Ich möchte aber auch positive hervorheben, dass die schnellste JVM implementierung auf Platz 4 nicht. 51:07.210 --> 51:11.757 [SPEAKER_02]: Also das geht alles auch mit der JVM. 51:11.737 --> 51:38.385 [SPEAKER_01]: Eine andere schöne Optimierung, oder ja, also, was die Optimierung nennen kann, wird es eher ein Heck nennen, aber auch das sei ja bei einer Challenge duch außerlaubt, ist, dass dieses Memory Mapping, was wir zuerst erwähnt haben, dass du das Fall in the Memory Mapsst, das musst du dann auch irgendwann aufräumen, das heißt, wenn du das wieder schließt, dann musst du es wieder alles gecheckt werden, das braucht auch wieder Zeit, das muss alles Ordnungsgemäß, 51:38.365 --> 51:42.630 [SPEAKER_01]: abgeschlossen werden und das braucht halt bei 13 GB 100 Milisi-Kunden. 51:43.491 --> 51:46.995 [SPEAKER_01]: Jetzt ist ja das eigentlich unnötig und will mir eigentlich gar nicht machen. 51:47.035 --> 52:04.255 [SPEAKER_01]: Was ich jetzt bei Schlaue ausgedacht habe, ist, ihr können das Ganze hier in den Zugprozess auslagern und wenn wir fertig sind mit unserer Berechnung, dann lassen wir einfach den Parent-Derminieren, also den Parent-Prozess, den eigentlichen Berechnungsprozess, weil wir haben wir deshalb geben die schon ausgegeben, dann derminieren wir das Ganze. 52:04.235 --> 52:17.237 [SPEAKER_01]: Und dann läuft eigentlich dieser Kindprozess, den wir da weggesprochen haben, der läuft im Hintergrund weiter und wird dann vom Betriebssystem, als Zombieprozess irgendwie verarbeitet und dann gekillt bzw. 52:17.578 --> 52:20.843 [SPEAKER_01]: alles geschlossen und verarbeitet und im Hintergrund passiert das alles. 52:20.823 --> 52:40.958 [SPEAKER_01]: Jetzt indem er aber im parent killed, frühzeitig ist man eigentlich noch gar nicht fertig mit dieser ganzen Arbeit, aber nachdem die im Zombeprozess dann vom Betriebssystem im Hintergrund erledigt wird, ist man offiziell schon beendet und hat dieser gemlich schon ausgegeben und die offizelligen Regeln erlaubendes auch, weil die Zeit wird nur gestoppt, bis dieses Endergabennis ausgegeben ist. 52:40.938 --> 52:44.843 [SPEAKER_01]: Wenn da im Hintergrund noch irgendwas besiedert betriebssystem Ebene, dann ist es völlig okay. 52:44.863 --> 52:50.471 [SPEAKER_01]: Und da holst du wieder 100 Medizikunden raus, was hier bei einer 1,5 Sekundenlaufzeit schon einiges an Zeitzen. 52:50.631 --> 52:52.914 [SPEAKER_01]: Also es sind 7% in dem Fall. 52:52.934 --> 52:55.257 [SPEAKER_01]: Und wenn du 7% rausholen kannst, ist es natürlich super. 52:55.277 --> 53:03.889 [SPEAKER_01]: Also, das ist eher ein Heck, weil die eigentliche Berechnung wird jetzt nicht schneller dadurch, aber zumindest die Zeitnehmung wird, wo sie die Fernfluss nennen, was mal so. 53:03.909 --> 53:05.511 [SPEAKER_01]: Hab ich einen sehr netten Heck gefunden. 53:05.491 --> 53:10.839 [SPEAKER_02]: Wenn es so bin, also ich würde sagen, kennst du die Regeln, kennst du die Daten, kennst du optimieren. 53:10.899 --> 53:12.421 [SPEAKER_02]: Und das finde ich immer sehr, sehr lustig. 53:12.441 --> 53:18.009 [SPEAKER_02]: Und deswegen haben wir auch eine ganze Menge dieser Optimierung mal durchgesprochen, weil da ich schon sehr, sehr viel Kreativität bei. 53:18.470 --> 53:22.997 [SPEAKER_02]: Jetzt ist die ganze Challenge aber auf Java ausgelegt worden. 53:23.037 --> 53:28.545 [SPEAKER_02]: Und das Internet hat sich natürlich in dem Lassen einfach mal andere Sprachen auch zu testen. 53:28.525 --> 53:44.682 [SPEAKER_02]: Es gab nie eine offizielle Challenge zu sprachen, wie C, GOP, HP oder Ähnliches, aber es gibt im Gitarpropositorie der Challenge in den Diskussionen ein sogenanntes Show Enttell und da könnt ihr euch ätliche Lösungen zu anderen Sprachen auch ansehen. 53:45.203 --> 53:51.630 [SPEAKER_02]: Zum Beispiel die schnellste Version die recorded wurde, wurde in C geschrieben, die 53:51.610 --> 53:54.975 [SPEAKER_02]: knapp übernach halben Sekunde liegt bei acht Kurs. 53:54.995 --> 53:59.662 [SPEAKER_02]: Also auch noch mal dreimal so schnell wie die schnellste Ja-Wahlösung. 53:59.683 --> 54:10.179 [SPEAKER_02]: Und was es eigentlich ist, es ist eigentlich C mit einer ganzen Menge CPU-Instructionen, sogar mit so einem Befehl, Erweiterungssatz, der nur auf Intel CPUs läuft. 54:10.199 --> 54:12.362 [SPEAKER_02]: Weil da wird dann direkt drauf optimiert. 54:12.382 --> 54:19.373 [SPEAKER_02]: Okay, wir wissen ja auch, ob welcher CPU die Test durchgeführt würden, wurden deswegennehmerdirektionen Erweiterungssatz für die Befehl dazu. 54:19.353 --> 54:32.751 [SPEAKER_02]: Also auch schon ziemlich cool, aber mal recht interessant, dann habe ich immer als Alter GoFan bei euch auch die Go-Lösung mal angesehen und wenn man sich die mal so ansieht, dann hat die eigentlich eine ganze Menge der selben Optimierung drin. 54:32.771 --> 54:43.165 [SPEAKER_02]: Ja, er ist relativ naiv implementiert, danach wurden printer verwendet, danach wird kein Float-Parsing mehr genutzt, sondern es wurden kastem Temperatur-Parser implementiert. 54:43.205 --> 54:48.432 [SPEAKER_02]: Danach hat man eine eigene Hashtabel gebaut, anstatt die aus der Standardlib zu nehmen und 54:48.412 --> 54:52.518 [SPEAKER_02]: also alles ähnliche Optimierung wie bei Java auch. 54:52.538 --> 54:59.847 [SPEAKER_02]: Die schnellste Native PRP-Lösung fand ich auch ganz lustig, die Licht bei 15 Sekunden, also schon ein bisschen was länger. 54:59.888 --> 55:03.212 [SPEAKER_02]: Aber es gab auch eine kreative Lösung, wie man PRP noch schneller machen kann. 55:03.252 --> 55:10.622 [SPEAKER_02]: Die wollte jetzt hier auch nicht ohne Wendlassen und zwar hat jemand das wird glaube ich nicht mehr ins Regelwerk passen, aber einfach eine kreativität haben. 55:10.602 --> 55:17.514 [SPEAKER_02]: Original PAP Standard-Lip-Lösung, wer 15 Sekunden, dann hat noch jemand, dass FFI Interface von PAP genutzt. 55:17.534 --> 55:29.674 [SPEAKER_02]: Das ist eigentlich so wie Jane Eyedas, du Foreign-Funks-Kollen-Kanz und zwar hat jemand, eine PAP-Lösung geschrieben, die dann unten drunter eine andere Rastlösung einfach kollt. 55:29.654 --> 55:31.016 [SPEAKER_02]: Kann man machen? 55:31.037 --> 55:34.443 [SPEAKER_02]: Dadurch kriegt man PRP auf 1,9 Sekunden runter. 55:34.463 --> 55:37.969 [SPEAKER_02]: Also eigentlich wird alles in Russ berechnet, nur die Ausgabe wird über PRP gemacht. 55:38.069 --> 55:43.219 [SPEAKER_02]: Jetzt kümmert über Streiten und Philosophieren, ob das eine PRP-Lösung ist oder eine Rastlösung. 55:43.239 --> 55:45.503 [SPEAKER_02]: So raufgang, deine Meinung ist das PRP oder ist das eine Rastlösung. 55:45.483 --> 55:56.096 [SPEAKER_01]: Der eigentlich hat jetzt gesagt, es ist schon eine Rastlösung, aber dann haben wir überlegt eigentlich, wenn man diese ganzen Sprachen, Beisen, B-H-B, die passieren alle auf irgendwelche Lips, die da runterlegen. 55:56.116 --> 56:02.244 [SPEAKER_01]: Also auch Chava passiert natürlich auf Lips, die da runterlegen, M-Map ist auch vom Bekriebssystem. 56:02.264 --> 56:04.567 [SPEAKER_01]: Also es verschwimt da eigentlich eh schon ziemlich. 56:04.587 --> 56:10.214 [SPEAKER_01]: Also nur zu sagen, wenn man eine Internet-Lip verwendet oder eine Lips, die da runter sitzt, schwirkt zu sagen. 56:10.234 --> 56:13.178 [SPEAKER_01]: Aber am Ende ist dann die Frage, was macht die Lips immer? 56:13.158 --> 56:14.961 [SPEAKER_01]: Und was verwendest du ganz unten? 56:14.982 --> 56:17.466 [SPEAKER_01]: Ja, was du darüber stüpst, ist ja dann eigentlich egal. 56:17.887 --> 56:20.011 [SPEAKER_01]: Und jetzt kommt noch ein bisschen was fürs Grinsen. 56:20.071 --> 56:25.161 [SPEAKER_02]: Es hat sich jemand, die Arbeit gemacht und hat die 1 Billion Road Challenge in Avika gelöst. 56:25.201 --> 56:30.812 [SPEAKER_02]: Die Avika Lösung hat ganze 11 Zeilen, was auch sehr wachlich ist und braucht sogar 6 Minuten. 56:30.792 --> 56:35.279 [SPEAKER_02]: Also ich bin den Kurt angesehen und habe ich gedacht, ich kannte Aweka, nein, ich kannte nicht Aweka. 56:35.299 --> 56:37.142 [SPEAKER_02]: Verlinkt man natürlich auch in den Show-Nots. 56:37.182 --> 56:43.511 [SPEAKER_02]: Und dann für dich Wolfgang Speziell habe ich auch noch zwei One-Billgen Road-Challenges in SQL rausgesucht. 56:43.531 --> 56:46.095 [SPEAKER_02]: Und zwar immer mit Clickhouse und auch mit DuckDB. 56:46.115 --> 56:52.525 [SPEAKER_02]: Da nicht überraschend muss man sagen, hat der Datenbank import schon 27 bis 30 Sekunden gedauert. 56:52.545 --> 56:58.634 [SPEAKER_02]: Und dann die Quillie ging so auf 6 Sekunden und mir richtigen Daten zu machen, weil die ganze Berechnung halten SQL gemacht wurde. 56:58.654 --> 56:59.095 [SPEAKER_02]: Aber ... 56:59.075 --> 57:27.090 [SPEAKER_02]: eine Billion oder eine Milliarde Datenbankzeilen nach Daktivier oder nach Klicausladen, dauert halt schon obwohl ich muss sagen, die Klicauslösung hat sogar noch nichtmals die Daten in die Klicausdaten Bank geladen, weil das hätte länger gedauert, die Klicauslösung hat einfach nur eine Querie gemacht, die dann direkt auf das CSV-Bassfallsystem zugreift und das ist natürlich auch eine interessante Geschichte, das bedeutet da wird nur wirklich die Query Engine genutzt so die Daten wurden gar nicht in die Storage Engine von Klicausgeladen. 57:27.070 --> 57:35.202 [SPEAKER_01]: Mir kommt es ja nur schweren Herzens über meine Lippen, aber ich habe eine Implementierung in Oracle gefunden, die habe ich auch gefunden, ja, mich rausgelassen. 57:35.222 --> 57:36.664 [SPEAKER_01]: Und die braucht nur 80 Kunden. 57:37.305 --> 57:40.670 [SPEAKER_02]: Ja, ich meine, aber gelesen zu haben, dass die den Import rausgerechnet haben. 57:41.731 --> 57:45.337 [SPEAKER_01]: Die Lesen direkt in CSV ein, das ist eine Externinterbälle. 57:45.357 --> 57:51.846 [SPEAKER_01]: Keine Ahnung, ob die jetzt im Vorhinanz schon irgendwie in Memory und Dubschnitten gemäbt wird, das weiß ich jetzt nicht, aber... 57:51.826 --> 57:55.712 [SPEAKER_01]: Ja, scheinbar ist Oracle in manchen Bereichen zumindest recht schnell. 57:55.752 --> 58:00.739 [SPEAKER_01]: Weil es gibt, glaube ich, auch noch eine Postgres Variante, die irgendwie acht Minuten braucht oder so. 58:00.759 --> 58:10.533 [SPEAKER_01]: Aber die Dinge sind halt einfach nicht fürs Basin gedacht und die machen halt dann wirklich ganz klassisches String Basin und damit man halt dann, dass das einfach sehr, sehr teuer ist. 58:10.573 --> 58:20.787 [SPEAKER_01]: Wenn du halt diese Zeichen für Zeichen wirklich Stringmäßig beachtest und nicht dieses Format, was eigentlich dahinter steckt, dann hast du einfach einen schweren Stand mit solche Techniken. 58:20.767 --> 58:23.675 [SPEAKER_02]: Und jetzt höre ich manche Leute, den Podcasts-Grass schon hören. 58:23.715 --> 58:25.981 [SPEAKER_02]: Jungs, schmeißt du mal eine GPU drauf. 58:26.021 --> 58:27.305 [SPEAKER_02]: Was ist alles für schneller? 58:27.365 --> 58:29.150 [SPEAKER_02]: Ja, hat der Jakob gemacht. 58:29.190 --> 58:34.986 [SPEAKER_02]: Der Jakob ist sogar Senior Software-Engine bei Nvidia, der hat sich die One-Billian Road-Challenge machen genommen. 58:35.046 --> 58:36.109 [SPEAKER_02]: Und er... 58:36.089 --> 58:41.537 [SPEAKER_02]: hat mit Dask, dass es eine Paisenbibiotik für Paralleles und Verteiltes rechnen. 58:41.577 --> 58:49.589 [SPEAKER_02]: Und mit QDF, was eine Paisen GPU-Data-Frame-Bibiotik ist, wo er beides auch maintainer von ist. 58:49.629 --> 58:56.920 [SPEAKER_02]: Hat die ganze Sache auf echt heftigen Grafikarten auf 2 RTX-8000 ausgeführt, und siehe da Satfieren halb sie Kunden gedauert. 58:56.940 --> 59:05.472 [SPEAKER_02]: Also, da sieht man auch, dass mit P-Kartwer und etwas Abzeugzotsoberhett doch langsamer wird 59:05.452 --> 59:20.507 [SPEAKER_02]: Aber da wird auch gesagt, okay, die ganze Challenge ist einfach nicht für GPUs, für sogenannte FPGA's, viel Programme Regate-Arris geeignet, weil die Berechnung halt sehr trivial ist und die Red-Patternshalte sehr sequenziell sind. 59:20.487 --> 59:29.721 [SPEAKER_01]: Und du hast dann auch noch dieser Sluckab-Hashmaps, die du irgendwie umformen musst, das geht ja auch nicht, alles was random ist, ist mit GPUs und durchs Erböse. 59:29.761 --> 59:35.049 [SPEAKER_01]: Zusätzlich glaube ich jetzt, dass es auch ein Problem ist, wie du mit Strings umgest. 59:35.069 --> 59:39.215 [SPEAKER_01]: Und wenn du das davor umrechnest, wie dein Intelligerwert, dirst du, wie du das selber Problem. 59:39.235 --> 59:49.110 [SPEAKER_01]: Also, es ist die Frage, könntest du solche Lösungen, wie sie in den Challenge, Lösungen vorgekommen sind, wo du dann das ganze Binär betrachtest oder so vielleicht könntest du es dann auf GPUs umformen. 59:49.090 --> 59:55.419 [SPEAKER_01]: vielleicht würde es dann auch schneller werden, aber sie ist halt einfach am Ende gar nicht so ein großes Datenzett für eine GPU. 59:55.439 --> 01:00:04.791 [SPEAKER_01]: Muss man auch sagen, wenn man das jetzt als Intetje sieht, ist schon keine 13 GB mehr und viele Strings, da ist GPU auch nicht gut, keine Mathematischen Berechnungen. 01:00:04.831 --> 01:00:14.084 [SPEAKER_02]: Genau, es ist halt, es ist halt keine klassische Matrix oder Wektorberichnungen, es ist halt min max und den Mittelwert, also von daher aber auch mal interessant. 01:00:14.124 --> 01:00:17.308 [SPEAKER_01]: Aber hätte ich mir auch gedacht, dass es schneller ist, als vier Sekunden ehrlich gesagt. 01:00:17.288 --> 01:00:28.726 [SPEAKER_02]: Ja, wahrscheinlich, wenn es grisse vielleicht wahrscheinlich auch noch ein bisschen runter ist, auch Paisen noch dabei und Piper pro, aber ich glaube jetzt auch nicht, dass das Hienius auf der Engineier von der Videos so viel zerrengestickt hat. 01:00:28.766 --> 01:00:33.653 [SPEAKER_01]: Ja, wobei erkennt es dafür sehr gut und kennt alle Basistrix zumindest. 01:00:33.693 --> 01:00:40.504 [SPEAKER_01]: Also wenn er selber maintainer ist, würde ich mir schon vorstellen, dass er der ganz guten Ansatz wählen könnte, dem entsprechen. 01:00:40.564 --> 01:00:41.786 [SPEAKER_01]: Aber es ist schon interessant, ja. 01:00:41.806 --> 01:00:44.730 [SPEAKER_01]: Für manche Challenges ist halt GPU, auch nicht das Warwick. 01:00:44.710 --> 01:01:04.710 [SPEAKER_02]: Na ja, aber an so einer Performance Challenge, besonders wenn es um Performance geht, da fühlen sich manche Leute ja immer geknickt, Kritikpunkte hatten wir schon während der Episode ein bisschen angesprochen, zwar das Datastet Overfitting, das bedeutet, dass du dann ein Gerup mit ganz genau auf das Datastet auf dem getestet wird optimiert, dann hatten wir so ein bisschen über das Cash Problem gesprochen, dass 01:01:04.690 --> 01:01:32.419 [SPEAKER_02]: Die Daten auf einer Ramdeskliegen und somit mancher Optimierung, die auf das Lesen von der Festbarte sind halt nicht relevant sind, es gab aber noch eine dritte Kritik und zwar zur Echtektur der CPU und zwar wurde eine Send 2CPU genutzt und die Send 2CPU ist von der Send-Blitelücke betroffen, ja das ist eine CPU-Lücke aus 2003, die es möglich macht, denn die will Daten abzufangen. 01:01:32.399 --> 01:01:37.810 [SPEAKER_02]: Und diese Lücke wurde auf der CPU mit einem Micro-Code Update gepächt. 01:01:37.830 --> 01:01:42.860 [SPEAKER_02]: Und dieser Micro-Code Update verändert die Performance MESPA. 01:01:42.920 --> 01:01:54.323 [SPEAKER_02]: Und die Teilnehmer, die das dann auf einer gepächten CPU ausgeführt haben, haben 5 bis 10% Abweichungen von den jeweiligen Lösungen gefunden. 01:01:54.303 --> 01:01:59.052 [SPEAKER_02]: Und wie irrelevant das jetzt ist, weiß ich nicht, weil da ging es jetzt nicht um viel Geld. 01:01:59.072 --> 01:02:04.742 [SPEAKER_02]: Ich glaube, Gunde hat am Ende ein T-Shirt und zwei Tassen rausgehauen, oder so. 01:02:04.762 --> 01:02:07.026 [SPEAKER_02]: Also, dass da da wird jetzt keine wirklichen Preise vergeben. 01:02:07.066 --> 01:02:10.813 [SPEAKER_02]: Von daher würde ich sagen, liebe es Internet, finde ich mal wieder spannend. 01:02:10.833 --> 01:02:13.999 [SPEAKER_02]: Wie tief eigentlich auch solche Diskussionen und Kritikpunkte gehen können. 01:02:13.979 --> 01:02:21.810 [SPEAKER_01]: Wenn du jetzt zurückblickst, auf diese ganzen Optimierungen und was du da jetzt alles gelesen hast, was bringt dir das im Alltag? 01:02:21.830 --> 01:02:28.239 [SPEAKER_02]: Nur eins, ich hab hoffentlich mal den Müttersterstört, dass ja aber langsam ist, obwohl ich kein JVM- und Java-Fan bin. 01:02:28.299 --> 01:02:33.827 [SPEAKER_02]: Ich oute mich, aber die, na so hinzahlen kann man wo sagen die JVM ist kein Performance-Volierer mehr. 01:02:33.807 --> 01:02:42.367 [SPEAKER_02]: Ja, sie ist zwei bis drei Faktoren langsamer als Handgeschriebenes C. Okay, es ist auch schwer zu zubeitreffen. 01:02:42.407 --> 01:02:49.423 [SPEAKER_02]: Aber der generelle Mütter, das ja, weil langsam ist, würde ich erst mal wieder lehigt und ich glaube auch die letzten haben soll. 01:02:49.443 --> 01:02:50.365 [SPEAKER_02]: Hoffentlich jetzt verstanden. 01:02:50.345 --> 01:02:56.412 [SPEAKER_02]: Ich sage aber auch, dass der ganze Korre, die wir da besprochen haben, vielleicht kein realer Produktionscode ist. 01:02:56.432 --> 01:03:02.980 [SPEAKER_02]: Denn in Großteil der Leistungsteigerung ist halt darauf zurückzuführen, dass halt irgendwie alle bestprecktes ist über Boskowoffen wurden. 01:03:03.000 --> 01:03:09.247 [SPEAKER_02]: Ja, also irgendwelche Validierungen, Boundchecks, Hashtabelrisseysing und so weiter und so fort. 01:03:09.287 --> 01:03:10.549 [SPEAKER_02]: Wird ich so nicht schippen? 01:03:10.589 --> 01:03:13.272 [SPEAKER_02]: Und ein Teilnehmer hat auch in dem Github istiu geschrieben. 01:03:13.292 --> 01:03:19.980 [SPEAKER_02]: Der Code, der schnellsten Beiträge unterscheidet sich stark von dem, was meine Kollegen und ich in unserem täglichen Arbeit. 01:03:19.960 --> 01:03:23.284 [SPEAKER_02]: schreiben, oder für dich sagen, das stimmt, das stimmt. 01:03:23.304 --> 01:03:38.460 [SPEAKER_02]: Also es hat eigentlich hier nichts mit Produktionskoll zu tun, sondern ist eher eigentlich so eine schöne Spielewiese, aber, und jetzt kommen wir mit zum positiven Punkt dieser ganze Thema, die gute Performance und gute Lesbarkeit ist gleichzeitig machbar. 01:03:38.480 --> 01:03:45.748 [SPEAKER_02]: Denn viele Sachen, die wir besprochen haben, sind eigentlich Basisfehler und einfach nur gute Arbeit. 01:03:45.728 --> 01:03:50.632 [SPEAKER_02]: Diese Bitteroperation mit diesem Temperaturpasser von diesem widnermäßischen Studenten. 01:03:50.652 --> 01:03:53.615 [SPEAKER_02]: Wahnsinn, das ist einfach nur gute Arbeit. 01:03:53.655 --> 01:04:00.621 [SPEAKER_02]: Und die ganze Performance-Güne versteckt keine Magie drin, sondern Teilweise würde ich sagen, auch die Formatung von Anfänger fehlen. 01:04:00.641 --> 01:04:06.646 [SPEAKER_02]: Also gut, die Bitterinstruktion mit den Halleoperations von dem widnermäßischen Studenten würde ich jetzt nicht als Anfänger Fehler bezeichnen. 01:04:06.686 --> 01:04:14.993 [SPEAKER_02]: Aber das man jetzt zum Beispiel die Float mal zehn multipliziert damit man einen ganzen Intelliger hat, das ist für jeden einfach erlehrenbar würde ich mal sagen, oder? 01:04:14.973 --> 01:04:17.578 [SPEAKER_01]: Und du spasst ja auf die ganzen Rundungsfehler, die du hast. 01:04:17.598 --> 01:04:25.311 [SPEAKER_01]: Also was du bei den Carrencies, bei den Bärungen ja üblicherweise genauso machst, dass du in der Chewelte hast, der sind dann wirklich Fehler, die man macht. 01:04:25.331 --> 01:04:28.938 [SPEAKER_01]: Zu deinem Argument, schön lesbar, ja, das ist die Frage. 01:04:28.978 --> 01:04:32.965 [SPEAKER_01]: Und da bin ich auch eher auf der Seite, wenn mein Code 01:04:32.945 --> 01:04:36.469 [SPEAKER_01]: 20 Sekunden dauert an statt 30 Sekunden. 01:04:36.489 --> 01:04:49.884 [SPEAKER_01]: Wenn der beim Import einmal am Tag ausgeführt wird, dann bevor zu wie die Läsbarkeit an statt irgendwas kutiert ist, auf BIT-Operationsebene, was dann nur 50 Prozent von meinem Team verstehen. 01:04:49.904 --> 01:04:58.193 [SPEAKER_01]: Also ja, ich glaube da ist Läsbarkeit dann schon auch wichtiger als die eigentliche Performance, aber es kommt immer darauf an, wo man in was für ein Bereich man wirklich arbeitet. 01:04:58.173 --> 01:05:03.921 [SPEAKER_01]: Und vielleicht können wir da ja mal eine Episode machen, mit jemand der wirklich Performance orientiert, ganz unten arbeitet. 01:05:03.941 --> 01:05:07.606 [SPEAKER_01]: Gut, der würde wahrscheinlich sagen, unser Kort ist auch schön. 01:05:07.626 --> 01:05:09.229 [SPEAKER_01]: Das müssen wir dann wahrscheinlich beurteilen. 01:05:09.269 --> 01:05:17.380 [SPEAKER_01]: Aber wird mir mal interessieren, so Leute, die wirklich keine Ernährung an Datenbank, Indexdrukturen, irgendwas Memory, Oblivierte, Indexdrukturen, wirklich arbeiten. 01:05:17.360 --> 01:05:24.932 [SPEAKER_01]: Schaut dieser Code noch schön aus, oder ist er einfach auch unlesbar und du musst er irgendwie zwei Jahre dort arbeiten, wenn wir nur annehmen, irgendwas verstehst. 01:05:25.373 --> 01:05:31.723 [SPEAKER_02]: Ja, ich kann jetzt auch sagen, es gab auch eine Submission und zwar von einer Person Alexei. 01:05:31.743 --> 01:05:36.451 [SPEAKER_02]: Nach einer man kann ich hier ausbrechen, er gilt in der OpenGDP-K Welt, wohl als Performance Guru. 01:05:36.471 --> 01:05:41.038 [SPEAKER_02]: Er hat eine Submission hingelegt, die allein 190 Zeilen Kommentare hat. 01:05:41.018 --> 01:05:45.584 [SPEAKER_02]: wo dann erklärt wird, warum ja alles macht, also das ist vielleicht auch ein Gegenbeispiele zu gut. 01:05:45.604 --> 01:05:49.810 [SPEAKER_02]: Liesbarkeit, aber es ist interessant, dass zu lesen, weil da kann es in der ganze Menge lernen. 01:05:49.870 --> 01:05:56.198 [SPEAKER_02]: Wasserbar auch ein Learning ist ist, dass eine gute Community Challenge. 01:05:56.218 --> 01:06:00.184 [SPEAKER_02]: Eine schön organisierte und gut Design der Community Challenge. 01:06:00.204 --> 01:06:04.790 [SPEAKER_02]: Eine klassische Konferenz im Punkt der Bildung auf jeden Fall schlagen kann. 01:06:05.030 --> 01:06:10.317 [SPEAKER_02]: Denn so viel wissen, wie in diesem Gitterpräository von dieser One-Bill-Yen Road Challenge steckt. 01:06:10.297 --> 01:06:12.959 [SPEAKER_02]: Ich glaube, das krieße nicht auf der Konferenzreihe mit. 01:06:12.979 --> 01:06:21.948 [SPEAKER_02]: Also, da, wer wirklich mal so einen Nördspielplatz haben möchte, der geht mal da rein, ließ sich ein bisschen Kuellkode durch, ein bisschen die Diskussion, das ist schon spannend. 01:06:22.308 --> 01:06:26.972 [SPEAKER_02]: Es gab ein paar Leute, die haben versucht, die ganze Sache auf andere Sprachen zu übertragen. 01:06:27.012 --> 01:06:33.958 [SPEAKER_02]: Es gab auch eine GitHub-Organisation, One-Billgen Road-Chillenge, aber die wird inzwischen archiviert und das ist nie wirklich für die Rage gegangen. 01:06:33.978 --> 01:06:36.000 [SPEAKER_02]: Aber sie haben es versucht, dann auch in die Haberskopf zu machen. 01:06:36.020 --> 01:06:40.084 [SPEAKER_02]: Und wie du Initiales auch in der Tippsgruppe machen wollte, 01:06:40.064 --> 01:06:46.734 [SPEAKER_02]: und ist aber nie wirklich viragegang und jemand hat einen Nachfolger gemacht. 01:06:46.774 --> 01:06:49.879 [SPEAKER_02]: Eine sogenannte One Trillion Road Challenge. 01:06:49.899 --> 01:06:57.109 [SPEAKER_02]: Das ist ein 2,5 Großes Terrorbit, Paketfall auf S3, ist auch nie wirklich viragegang. 01:06:57.170 --> 01:07:02.157 [SPEAKER_02]: Also diese ganzen Spin-Offs nette Idee, aber ich glaube der halbe ich jetzt vorbei. 01:07:02.137 --> 01:07:14.100 [SPEAKER_01]: Find ich aber eigentlich schade, wer eigentlich schon cool zu sehen ist, gibt ja auch andere Challengees, auch so im Universitäten umfällt oder so im Hybriden umfällt, wo es bei einer Konferenz jedes Jahr irgendwelche Challengees gibt. 01:07:14.120 --> 01:07:17.607 [SPEAKER_01]: Ich kennst nur das ein Rekomender Bereich bei der Raxies, gibt es immer eine Challenge. 01:07:17.627 --> 01:07:21.715 [SPEAKER_01]: Haben wir damals mit Trivago auch mitgemacht und einen Datenset zu fühen gestellt. 01:07:21.695 --> 01:07:27.622 [SPEAKER_01]: Vielleicht hinter die Probleme komplexer, dass es interessant bleibt, das ist einfach ein zu einfaches Problem ist. 01:07:27.682 --> 01:07:49.828 [SPEAKER_01]: Aber grundsätzlich ist der Gechallenge, es finde ich schon super spannend und vielleicht auch im kleinen Bereich, wie ihr Wendt habt, somit studierenden oder mal selber was ausprobieren, eben mir juckts nicht auch schon unter den Fingernägelen, irgendwie das ausprobieren, ob ihr mit SQL schneller sein kann, als die anderen, die das mit SQL gemacht haben oder JavaScript wird, 01:07:49.808 --> 01:08:04.027 [SPEAKER_02]: Ja, eine Kritik muss man schon sagen, also diese ganzen Zeiten, die wir hier während der Episode genannt haben für für Go, für C, für SQL und so weiter sind natürlich jetzt nicht vergleichbar mit den originalen Werten, weil das natürlich nicht die gleiche Testausführung war. 01:08:04.047 --> 01:08:09.014 [SPEAKER_02]: Also da hat jetzt irgendjemand diese 1-Billion Road Challenge genommen, hat die in SQL gemacht, hat ihr v.a. 01:08:09.054 --> 01:08:11.277 [SPEAKER_02]: Cloud Not gepackt und hat dann diese Zeiten gepostet. 01:08:11.257 --> 01:08:16.164 [SPEAKER_02]: Also, das sind jetzt nicht diese Zeiten, die von Gunner dem Organisator selbst ausgeführt wurden. 01:08:16.224 --> 01:08:24.275 [SPEAKER_02]: Der hat das nur für Java gemacht und nur in diesem Zeitraum und alle anderen Zeiten danach sind halt immer selbst reportet und selbst ausgeführt. 01:08:24.295 --> 01:08:28.841 [SPEAKER_02]: Da hast du eine grösste Varianz von eigentlichen Hardwaretchips und allen Drummutern. 01:08:28.881 --> 01:08:30.463 [SPEAKER_02]: Was natürlich ganz nache komplizierter macht. 01:08:30.443 --> 01:08:48.975 [SPEAKER_02]: Wenn du jetzt natürlich jetzt diese Challenge machen würdest, replizieren würdest, zu bei der Entschudenden, dann würdest du natürlich isoliert diese Test ausführen, dann während die Zeit wieder vergleichbar, könnte natürlich auch eine schöne Übung für einen kleinen Heckerton sein oder vielleicht für einen Freitagabend, Freitagabend, für einen Freitag nachmittag oder vielleicht mal für einen ganzen Freitag, wenn ihr 01:08:48.955 --> 01:08:52.159 [SPEAKER_02]: mal mit eurem Team lustige Sachen machen wollt. 01:08:52.179 --> 01:08:55.283 [SPEAKER_02]: Warum setzt sie euch nicht einfach mal einen Freitag in Mietingraum? 01:08:55.343 --> 01:09:00.709 [SPEAKER_02]: Frachtreund Chef auf der kleines Frühstück springen lässt, geht jeder zum Bäcker irgendwie ein bisschen hei und so weiter holen. 01:09:00.749 --> 01:09:12.263 [SPEAKER_02]: Und ja, dann bereitet eine Challenge vor und baut das einfach mal nach und dann Freitag 14 Uhr, macht eine Präsentation, jeder präsentiert seine 01:09:12.243 --> 01:09:14.227 [SPEAKER_02]: Lösung, wie oder was er gemacht hat. 01:09:14.267 --> 01:09:17.655 [SPEAKER_02]: Ich glaube, das ist eine ganz spannende T-Materk jetzt, wo er im Spiel ist. 01:09:17.695 --> 01:09:22.225 [SPEAKER_02]: Hier hat die gleichen Tools und dann kommt's auf die bessere Schärche an und allen drunter. 01:09:22.285 --> 01:09:24.390 [SPEAKER_02]: Ich glaube, das könnte rechtland relativ lustig werden. 01:09:24.410 --> 01:09:25.973 [SPEAKER_02]: Komm mal, jetzt habe ich doch eher erwähnt. 01:09:25.993 --> 01:09:27.897 [SPEAKER_02]: Obwohl ich gar nicht geplant hatte. 01:09:27.937 --> 01:09:29.661 [SPEAKER_02]: Aber hey, du hast mich darauf gebracht. 01:09:29.641 --> 01:09:32.044 [SPEAKER_01]: Ja, wäre wahrscheinlich spannend, was die Eiterraß machen. 01:09:32.084 --> 01:09:39.392 [SPEAKER_01]: Wenn man den ganzen Input mal nach Eifüttet und sagt, jetzt macht es noch schneller, wäre interessant, was dabei rauskommen würde. 01:09:39.432 --> 01:09:41.134 [SPEAKER_01]: Wer vielleicht dann eine eigene Challenge? 01:09:41.154 --> 01:09:47.382 [SPEAKER_01]: Auf jeden Fall lasst uns mal wissen, was ihr dazu denkt vor allem, alle Charberheter wird mich natürlich am meisten interessieren. 01:09:47.402 --> 01:09:51.987 [SPEAKER_01]: Was ihr dazu sagt oder wenn ihr andere Verbesserungsvorschläge habt, wie man das noch schneller machen kann. 01:09:51.967 --> 01:10:07.647 [SPEAKER_01]: Schaut mal bei uns in der Discord-Community vorbei, oder wenn ihr euch auch wundert zu wie ich, worum da an die zu einem Backer geht, um ein Ei zu kaufen, bei uns gibt es der Port, aber gut, was weiß ich schon in Österreich, es an der Sache kommt vorbei, bei uns in der Discord wie freuen und sie mir überhaupt ein bisschen Diskussion. 01:10:07.711 --> 01:10:26.534 [SPEAKER_02]: Wege sagt, wer ein bisschen rumnürden möchte, schaut mal in die Show Not Links, da findet ja auch die Avikalisungen Elfzeilen und die ganzen Java Implementierung und ätliche Blockposts, die die Topge binner einfach mal auseinander genommen haben, teilweise echt hat zu lesen, aber super leerreich. 01:10:26.574 --> 01:10:31.980 [SPEAKER_02]: Kann ich nur empfehlen, weil es ihr heute Abend noch nicht kopftechnisch ausglasselt seid, macht das mal. 01:10:31.960 --> 01:10:39.171 [SPEAKER_02]: Wie immer gilt für Performance Freaks, kommt mein Indiscord, korrigiert mich mal oder auch den Wolfgang, falls Sie etwas falsches gesagt haben. 01:10:39.191 --> 01:10:44.920 [SPEAKER_02]: Und jetzt wird mich mal interessieren, was war die beste Performance optimierung, die ihr gemacht habt. 01:10:44.940 --> 01:10:45.962 [SPEAKER_02]: Lasst es uns mal wissen. 01:10:46.002 --> 01:10:48.987 [SPEAKER_02]: Ich glaube, dass wir sehr, sehr viele Leute in den Discord-Community interessieren. 01:10:49.007 --> 01:10:51.170 [SPEAKER_02]: Da haben wir ungefähr 500 Leute inzwischen drin. 01:10:51.230 --> 01:10:53.774 [SPEAKER_02]: Und bei so was sind sehr viele im Raum statt. 01:10:53.814 --> 01:10:55.937 [SPEAKER_02]: Ich freue mich auf eure Submissions bis bald. 01:10:55.957 --> 01:10:57.580 [SPEAKER_01]: Bye bye.