05:33:52 Hannes joined the channel
07:15:25 Schrompf joined the channel
07:19:15 Hannes: Hi Schrompf
07:20:05 Hannes: Morgen kann ich ausschlafen. Die Lehrer meines Sohnes haben Weiterbildungstag.
07:24:56 Schrompf: moin Hannes! gut schlaf
07:25:26 Schrompf: ich durfte heute. so ein bissl jedenfalls. frau hatte doch normalen dienst - am montag macht sie normalerweise 12 bis 18, aber nicht heute
07:25:42 Schrompf: und da hat sie sich bereit erklärt, dem flock in die schule zu schaffe und durfte liegen bleiben
07:45:19 Hannes: hab ein interessantes strategie spiel gefunden: https://store.steampowered.com/app/1465460/Infection_Free_Zone/
07:45:39 Hannes: es benutz als level map daten aus der echten welt
07:46:01 Hannes: man kann zuhause spielen
07:46:40 Hannes: google-maps mit zombieinvasion
07:53:04 Schrompf: hab den trailer gesehen, der algo meinte wohl, das interessiert mich. tut es nicht
08:02:44 Schrompf: Das Video über die Physik-Engine im ZFX ist der Hammer
08:03:02 Schrompf: also nicht das Video, das labert die ganze Zeit nur und macht nur aller paar minuten was bemerkenswertes
08:03:08 Schrompf: aber die physik-engine... wow
08:03:30 Schrompf: wie der ritter sein schwert frei nach mauszug bewegt und dabei an den tisch stößt
08:09:42 Hannes: ja, sieht gut aus
14:34:31 Schrompf joined the channel
15:13:59 Hannes joined the channel
17:59:42 Magister joined the channel
18:53:44 Schrompf joined the channel
19:51:40 starcow joined the channel
19:51:55 starcow: Abend zusammen :-)
19:55:14 Hannes: hi starcow
19:55:25 starcow: hi Hannes! :-)
19:55:36 Hannes: wie siehts aus?
19:56:00 starcow: Es geht langsam voran ^^
19:56:36 starcow: Sozusagen von der einen Frage zur nächsten :-)
19:58:31 starcow: Hast du schonmal malloc selbst implementiert auf Windows?
19:59:09 Hannes: warum?
19:59:20 Hannes: hab ich nicht
19:59:56 Hannes: ich hab in c++ mal new überladen und speicherallocationen protokolliert
20:00:20 starcow: Ich möchte die stdlib nicht mitlinken - also später dann...
20:01:09 starcow: Deshalb bin ich dabei die paar wenigen Funktionen selbst zu implementieren.
20:01:21 Hannes: aber warum?
20:02:09 starcow: um keinen Maschinencode in der exe zu haben, der nicht gebraucht wird. Und um des "Lernens Willen" :-)
20:02:36 Hannes: aber malloc braucht man schon
20:02:50 starcow: wieso?
20:03:38 starcow: in der stdlib wird unter Windows ja einfach ein Syscall in die WinAPI gemacht. Denn könntest du ja auch direkt selbst machen.
20:04:56 starcow: Das ist ja eigentlich "plus-minus" nur ein Wrapper.
20:05:12 Hannes: damit? https://learn.microsoft.com/en-us/windows/win32/memory/comparing-memory-allocation-methods
20:05:47 starcow: Ja, genau!
20:06:40 starcow: VirtualAlloc ist - glaube ich - quasi der "Standard" unter Windows für das Heap
20:06:58 Hannes: ich hab erst gedacht du willst ein riesiges array erstellen und dann den speicher verteilen
20:08:32 Hannes: hab bisher keinen grund gehabt WinAPI funktionen dafür zu verwenden
20:08:43 starcow: Du meinst eine Art "Area-Allocator"?
20:10:24 Hannes: keine ahnung
20:11:19 Hannes: char buffer[1000000000];
20:11:50 starcow: das crasht dir aber, wenn du das versuchst auf dem Stack anzulegen ;-)
20:11:52 Hannes: dann gäbe es wohl stack probleme
20:12:04 starcow: ^^
20:13:13 starcow: Wenn ich ein Textfeld habe, indem ich Text einfügen kann (an einer bestimmten Stelle)... Wie würdest du dass dann lösen?
20:13:40 starcow: Gibts da einen "Trick", dass man nicht immer umkopieren muss?
20:13:58 starcow: Wie hast du sowas gelöst?
20:14:03 Hannes: garnicht
20:14:34 starcow: ? :-)
20:14:49 Hannes: aber muss man wohl kopieren
20:15:01 starcow: Geht wohl nicht anders, oder?
20:15:28 Hannes: die str* funktionen hast du wohl auch nicht zur verfügung?
20:16:03 starcow: Du meinst, ob ich die Implementation sehen kann?
20:16:20 starcow: Oder, ob ich sie verwenden kann? :-)
20:16:27 Schrompf: text in der mitte von anderem text einfügen: ja, geht nur mit umkopieren
20:16:43 Schrompf: malloc selbst schreiben: ist ne schöne übung, aber halleluja, hast du dir da was vorgenommen
20:16:48 starcow: Aah, der Herr Schrompf! :-)
20:16:51 Schrompf: kannst natürlich alles zu virtualalloc durchleiten
20:17:06 Schrompf: aber malloc holt sich mit VirtualAlloc nur Megabytes auf einmal
20:17:16 starcow: Ok!
20:17:22 Schrompf: und segmentiert solche blöcke dann clever mit ner art binär heap
20:17:40 Schrompf: und jeder menge kluger beschleunigungsstrukturen, von denen ich nur ansatzweise ne ahnung habe
20:17:57 Schrompf: da steckt ne menge hirn drin, die größten hirne des planeten haben daran gearbeitet
20:18:00 starcow: Eine Art Area-Allocator?
20:18:14 Schrompf: malloc ist ja literally das zentrum jedes C-Codes
20:18:16 Schrompf: nein
20:18:44 Schrompf: Arena-Allocs sind ja nur Bump Allocs, also ein großer Block, aus dem Du von vorne nach hinten rausgreifst, und nach dem ende des zwecks alles auf einmal wegschmeißt
20:18:59 Schrompf: malloc muss free können, also eine beliebige reihenfolge von holen und freigeben
20:19:07 Schrompf: und das führt zu ner menge zusätzlichem spaß
20:19:07 starcow: Das müsste dann ja eigentlich ziemlich schnell sein, oder?
20:19:30 starcow: Also, wenn man sich einfach ein grosses Stück rausschneidet, meine ich
20:19:42 Schrompf: ja, ist nicht schneller möglich, aber geht wie gesagt nur, wenn du als mensch weißt, dass all diese allocs für einen zweck sind und der zweck für alle allocs gemeinsam endet
20:19:49 Schrompf: das ist kein general purpose alloc
20:19:57 Schrompf: malloc muss aber general purpose sein
20:20:48 starcow: Wenn ich nur zwei drei Stellen im Code habe, andem ich mir Speicher hole, könnte ichs aber eifach per Virtual Alloc machen? Wäre das genau so schnell wie malloc?
20:21:58 Schrompf: das weiß ich nicht ausm kopf, aber ich würde spekulieren: nein
20:22:34 Schrompf: sonst könnte ich nicht erklären, warum die standardlib-coder*innen sich die mühe machen, so ein komplexes caching einzubauen
20:23:07 Schrompf: allen voran glaube ich, dass virtual alloc nur pageweise gibt. d.h. du kriegst immer ganze mempages, also 4kb bzw. 64kb je nach OS und Konfig
20:23:27 starcow: Damit könnte ich leben :-)
20:24:22 starcow: Ich lese immerwieder mal, dass bei gewissen Projekten die stdlib "bewusst" nicht mitgelinkt wird. Bei einem solchen Szenario, _muss_ ich ja malloc irgendwie über die Syscalls selbst implementieren, oder?
20:24:33 Schrompf: ja
20:24:51 Schrompf: oder über Hannes' vorschlag mit char buffer[1'000'000] :-)
20:25:00 starcow: Hehehe :-)
20:25:11 Schrompf: mach's global und der wird einfach mit in deine exe gelinkt. dann kriegst du ne riesige exe, aber hast deinen eigenen heap direkt an board
20:25:29 starcow: Du meinst im Data-Segment anlegen?
20:25:57 starcow: Aufm Stack ist bei mir bei 1 bis 2 MB irgendwann schluss (mit crash).
20:26:43 Schrompf: ja, die stackgröße kannst du auch einstellen, per linker-option beim kompilieren oder zur laufzeit
20:26:45 Schrompf: glaube ich
20:26:52 Schrompf: aber default ist 1MB unter Windows, glaube ich
20:27:11 Hannes: eine exe kann doch 1GB oder so groß sein?
20:27:16 starcow: Wäre die Performance denn ähnlich gut (oder besser), wie wenns aufm Heap liegen würde?
20:27:59 starcow: @Hannes Schrompf mein glogal also im Data-Segment - nicht auf dem Stack
20:28:07 starcow: *global
20:31:32 Schrompf: ne exe kann *fast* beliebig groß sein, ja
20:31:40 Schrompf: da kannste auch einen 1GB-Buffer reinkompilieren
20:31:53 Schrompf: aber ich denke, ich muss nicht darauf hinweisen, wie idiotisch das wäre
20:31:54 Hannes: sollte wohl in den ram rein passen
20:32:06 Schrompf: das gilt ja auch für virtualalloc
20:32:22 Schrompf: und komprimiert auch gut, der download wird nicht größer :-)
20:32:38 Schrompf: aber ist halt nachm auspacken ein GB groß auf platte, und lädt auch entsprechend lange beim start
20:32:51 Schrompf: so wie ne Zip Bomb, falls jemand von euch alter sack genug ist, um das noch zu kennen
20:33:00 starcow: Ich kenns noch ;-)
20:33:03 starcow: Haha
20:33:25 Hannes: starcow, wann machst du ein betriebssystem?
20:33:41 starcow: Ist auf nächste Woche datiert :-D
20:34:11 starcow: Der starcow weiss leider noch viel zu wenig :-<
20:35:30 starcow: Wie würdet ihr denn einen primitiven Texteditor realisieren? Einfach einen grossen Buffer holen und dann ständig umkopieren (mit jedem eingefügten Buchstaben)?
20:35:43 Schrompf: jaaaaa, so könnte man es machen
20:35:57 Schrompf: geht sicher bis ein paar kb textgröße
20:36:00 starcow: Irgendwie wahnsinnig diese Kopiererei ^^
20:36:15 starcow: Aber anders geht wohl nicht - prinzipbedingt?
20:36:22 Hannes: ist strcpy schneller wenn man mehrere zeichen kopiert?
20:36:27 Schrompf: aber die "großen" machen das sicher anders. irgendwie zeilenweise buffer, oder ähnliche granularität
20:36:52 Schrompf: so dass du, wenn du oben was einfügst, nicht die GB hintendran alle rückwärts kopieren musst
20:37:12 Schrompf: und wnen du das tust, brauchst du wieder ne clevere beschleunigungsstruktur
20:37:42 Schrompf: so dass du in zeile 2'723'274 noch weißt, dass sie mit zeichen 82'924'384 beginnt
20:37:46 starcow: Achso, ich hänge Zeilen aneinander? Wie ne verkettete Liste?
20:37:51 Schrompf: ja
20:38:02 Schrompf: oder eher wie ein tree, würde ich spontan sagen
20:38:12 Schrompf: ist wirklich nur wild spekuliert, ich hab keine ahnung
20:38:29 starcow: Ein Tree?
20:38:33 Schrompf: aber wir sehen alle, denke ich, dass ein plumper linearer buffer schnell an seine grenzen kommt, wenn du in der ersten zeile was tippst
20:38:41 Hannes: wenn man immer lowleveliger ans c programmieren geht wofür braucht man dann noch ein betriebssystem?
20:38:54 starcow: :-)
20:39:02 Schrompf: also wär mein nächster schritt, den text zu segmentieren, so dass du immer nur ein paar kb hinterkopieren musst, egal wo im file du bist
20:39:18 Schrompf: aber du brauchst für tausend zwecke trotzdem die globale position
20:39:26 Schrompf: jedes abschnitts im gesamtfile
20:39:43 Schrompf: also würd ich mir ne tabelle aufmachen, wo jedes segment beginnt
20:39:54 starcow: Interessant!
20:40:06 Schrompf: und da bist dann wieder bei ner linearen abhängigkeit, nur halt jetzt auf segmenten anstatt auf einzelzeichen
20:40:20 Schrompf: sprich, das fliegt dir wieder im die ohren, wenn dein text eine größenordnung länger ist
20:40:23 starcow: Was aber doch sehr viel besser wäre, oder?
20:40:37 Schrompf: klar, ist ein fortschritt von "durchschnittliche anzahl zeichen pro segment"§
20:41:03 Schrompf: aber wann immer du vor nem skalierungsproblem stehst, wo deine ideen nur die grenze rausschieben, willst du eigentlich ne hierarchie haben
20:41:28 Schrompf: weil du dann vom großen zum kleinen und wieder zurück fließend übergehen kannst
20:41:35 Schrompf: wir haben unseren riesigen text
20:41:40 Schrompf: und den unterteilen wir in zeilen
20:41:47 Schrompf: und die zeilen gruppieren wir in seiten
20:41:56 Hannes: Schrompf, du hast doch große xml dateien geparst, wenn ich mich recht erinnere
20:41:59 Schrompf: und die seiten in bücher oder wasweißich was wir hier als vokabel nehmne
20:42:15 Schrompf: und so gehst du vom kleinen zum großen und wieder zurück
20:42:15 starcow: Klingt vernünftig
20:42:29 Schrompf: und speicherst immer nur die kleinen relativ zu ihrem großen
20:42:50 Schrompf: und wenn du jetzt ganz oben ein zeichen einfügst, verlängerst du nur die erste zeile
20:43:07 starcow: Das ist wirklich gut! :-)
20:43:08 Schrompf: und merkst dir für alle zeilen, dass sie eins später starten, aber nur bis zum ende der seite
20:43:23 Schrompf: und dann merkst du dir für alle seiten, dass sie eins später starten, aber nur bis zum ende des buches
20:43:24 Schrompf: usw
20:43:43 starcow: Schrompf, du hast eben einen Text-Editor im Kopf geschrieben ^^
20:43:45 Schrompf: du musst dich beim gruppieren ja nicht daran festhalten, dass dir ein menschlicher begriff für jede ebene einfällt :-)
20:44:13 Schrompf: ja, mein hirn kann das, jetzt nach 40 jahren in diesem thema
20:44:21 starcow: :-]
20:44:28 starcow: :-D
20:44:49 starcow: So alt bist du doch gar nicht! ;-D
20:44:54 Schrompf: Hannes: ja es gibt geile String-Ops, die deutlich mehr als 1 zeichen pro Operation kopieren können
20:44:56 Schrompf: oder durchsuchen
20:45:07 Schrompf: und ja, ich hab mal riesige XMLs gelesen
20:45:56 Schrompf: und da sind genau solche bäume draus entstanden: jedes tag und jedes attribut als einzelzeichne, aber die struktur von xml liefert dir automatisch schon so nen baum aus großen elementen und kleinen unterelementen
20:46:59 Schrompf: du ballerst da also linear durch, brauchst natürlich für jeden schritt ne geile kleine idee, aber wenn du dich klug anstellst, fällt automatisch so ein baum aus ganz großen teilstücken und deren teilstücken und deren teilstücken raus
20:47:39 Schrompf: ich hab mit 6 angefangen zu coden, und ich bin 45, ich bin also wirklich bald bei 40 jahren
20:47:50 Schrompf: war keine völlige übertreibung, nur ne ganz kleine :-)
20:48:05 Hannes: haben die daten in den ram gepasst oder musstest du dir da was überlegen?
20:48:26 Schrompf: najaa.... ja nein ja
20:48:27 starcow: Ich weiss! :-) Schrompf ist eine Art Säulenheiliger!
20:48:53 Schrompf: also: so ein file lädst du nicht stumpf, indem du nen buffer mallocst und fread() darein machst
20:49:35 Schrompf: stattdessen nimmst du memory mapping, einen skill des betriebssystems / dateisystems, wo du eine riesige allokation mit der datei verknüpft in deinen prozess kriegst und du liest einfach wie in normalem speicher
20:49:57 Schrompf: nur dass wenn du in ne neue gegend kommst, das OS den file content erst von platte lesen muss
20:50:14 Schrompf: aber das ist die (mit abstand, wir reden hier von faktor 3 oder so) schnellste möglichkeit, große dateien zu lesen
20:50:41 Schrompf: und jetzt kann das file beliebig groß werden, viel größer als dein RAM, und du liest da halt so fix durch, wie die platte liefern kann
20:50:56 Schrompf: und wenn du random access machst, isses auch genauso lahm wie wenn du auf ner platte rumspringst
20:51:26 Schrompf: aber wir haben trotzdem dafür gesorgt, dass die maschinen mehr als genug RAM hatten, um auch die größte Datei komplett in den RAM zu kriegen
20:51:42 Schrompf: die dicksten hatten 1,5Terrabyte RAM <3
20:51:53 starcow: Uiii X-)
20:51:58 Hannes: woher weiß man wie die tags zusammengehören, es kann ja beliebig ein
20:52:02 Schrompf: die files kamen als ZIP, weil ne XML halt extrem gut komprimiert
20:52:21 Schrompf: und wir haben einige minuten zeit gespart, indem wir die nicht ausgepackt haben, sondern direkt ausm ZIP gelesen
20:52:38 starcow: Um was ging es da?
20:52:54 Schrompf: Hannes: weißt du vorher nicht, wir haben immer linear durchgelesen, aber diese hierarchie baut sich ja trotzdem auf
20:53:16 Schrompf: und da war noch die oberaffengeile idee, keinen tree im speicher aufzubauen, wie das alle XML-reader so machen
20:53:25 Schrompf: sondern linear einen buffer aus kleinen schnipsel anzulegen
20:53:34 Schrompf: "Tag ABC öffnet"
20:53:39 Schrompf: "Attribut xyz kommt"
20:53:46 Schrompf: "Attribut-Wert 123 kommt"
20:53:50 Schrompf: und so weiter
20:53:56 Schrompf: und dann irgendwann "Tag ABC schließt"
20:54:45 Schrompf: und beim erstellen dieser liste aus "XML-Events" haben wir dann automatisch tabellen erstellt, die uns die speicherposition von allem gemerkt haben, was uns so interessiert
20:55:04 Schrompf: so dass wir fix im file alles gefunden haben, woraus wir tatsächlich random access brauchten
20:55:25 Schrompf: malloc() ist nämlich auch nicht kostenlos, du hast pro speicherblock mindestens zwei Pointer an zusatz-speicherbedarf
20:55:34 Schrompf: und wenn du milliarden kleine allocs machst, merkste das
20:55:50 Schrompf: da kann man enorm sparen, indem man viele kleine schnipsel ohne alloc hintereinander schreibt
20:56:10 Schrompf: und die kleinen schnipsel dann noch optimiert, um anstatt mit 64bit speicher z.b. nur mit 48bit auszukommen
20:56:21 Schrompf: starcow: Pauschalreise-Preisberechnung
20:56:55 Hannes: warum konntet ihr kein binärformat nehmen, das ähnlich aufgebaut ist wie xml? oder bringt das nichts?
20:56:58 Schrompf: die Reiseanbieter (TUI, ITS, Neckermann, usw.) haben zwei drei mal pro tag ihren kompletten Katalog in nem Standard-Dateiformat geliefert
20:57:08 Hannes: ok
20:57:20 Schrompf: das waren dann XML-Files bis zu 150GB größe, wo alle hotels, flüge, preisstrukturen, regeln, verfügbarkeiten usw. drin standen
20:57:25 Schrompf: der standard war gegeben
20:57:33 Schrompf: darauf hatte sich die branche geeinigt
20:57:37 Schrompf: und das war halt XML
20:58:02 Schrompf: macht bei den dimensionen aber jetzt auch nicht mehr viel aus
20:58:14 Schrompf: die Idee beim XML war genial
20:58:35 Schrompf: du hattest so einzel-stückchen wie "Tag öffnet" und "Attribut" und so
20:58:39 Schrompf: aber kein "Tag schließt"
20:59:00 Schrompf: stattdessen hattest Du einfach nur beim nächsten "Tag öffnet" einen kleinen Marker "Hier kommen vorher soundsoviele Schließungen"
20:59:21 Schrompf: dass es die richtigen zum öffnenden
20:59:36 Schrompf: aber dadurch konntest du echt an ner beliebigen stelle im XML anfangen zu parsen
20:59:47 Schrompf: musste nur ein '<' sein, nicht mitten im wort
20:59:58 Schrompf: und dadurch haben wir das XML-parsen parallelisieren können
21:00:28 Schrompf: wir haben halt 256 threads losgeschickt, die einfach das nächste '<' in der nähe von "so um 2GB rum" gesucht haben
21:00:37 Schrompf: und von da aus losgeparsed haben
21:01:04 Schrompf: und nachher konnte man die einzelteil-listen mit diesem trick einfach aneinander hängen und hat einen validen XML-baum rausgekriegt
21:01:45 Schrompf: und das eigentliche parsen bestand dann aus "wörter aus einer liste erkennen" und "whitespace überspringen" und "Wort = "content"" strukturen erkennne
21:02:06 Schrompf: und für jede einzelne aufgabe hatte ich hand-vektorisierte x86-magic geschrieben
21:02:35 Schrompf: glorreiche zeiten
21:02:38 Schrompf: *seufz*
21:03:00 starcow: :-)
21:03:01 Schrompf: meinen vektorparser wollt ich irgendwann fertigstellen, der war noch ncith einsatzbereit, als ich da weg ging
21:03:19 Hannes: hast du so eine datei mal versehentlich mit notepad, vs studio oder nem browser oder so geöffnet?
21:03:21 Schrompf: aber niemand sonst auf der welt braucht halt nen parser, der wörter mit 16byte auf einmal erkennt
21:03:29 Schrompf: klar, war unser täglich brot
21:03:40 Schrompf: sublime und notepad++ haben das hingekriegt
21:03:57 Schrompf: Notepad... puh. Word? Besser gleich nachm TaskManager greifen
21:04:31 Schrompf: und wir hatten dann custom tools geschrieben, die die oben erwähnte x86-vector magic benutzt haben, um teile des XMLs auszuschneiden
21:05:11 Schrompf: gibt ne SSE4-Instruction, die nen Substring in nem 16Byte-Vector finden und erkennen kann
21:06:02 Schrompf: und eine Instruction, die nen Range Check macht, byteweise. Da kannst Du 16byte auf einmal prüfen, ob sie "im Bereich 64..96 liegen, oder im Bereich 32..35, oder im Bereich 10, 13, oder 20"
21:06:26 Schrompf: und du kriegst ein Register zurück, in dem 0xff steht, wenn für das Byte ein Treffer war, oder 0x00 wnen nicht
21:06:47 Schrompf: stellt sich heraus, dass auch die Ingenieur*innen von Intel und AMD keine Trottel sind :-)
21:07:14 starcow: :-)
21:07:21 Hannes: bist du eigentlich froh das du aus dem job gegangen bist?
21:07:41 Schrompf: den string searcher mit dieser SSE4 instruction hab ich im ZFX mal gepostet. Schafft an die 20GB text pro Sekunde, im Gegensatz zur C-Standard strstr()-Funktion, die irgendwo bei 1GB/s ausmaxt
21:08:02 Schrompf: Hannes: najaaaaa
21:08:14 Schrompf: anfangs kam ich in der neuen firma nicht so gut klar, menschlich und von den aufgaben her
21:08:24 Schrompf: da hab ich dem alten team und den alten aufgaben schon nachgetrauert
21:08:40 Schrompf: aber dort ist auch immer mehr DevOps jetzt, so richtig mit Bereitschaft nachts und am Wochenende
21:09:08 Schrompf: und die geilen Aufgaben werden weniger, stattdessen immer mehr Maintenance, und andere Apps in Go oder PHP
21:09:48 Schrompf: und außerdem ist der Team Spirit dort inzwishcen den Bach runter. interne sozialdynamik und neue chefs, die selbstverliebte arschlöcher sind, haben dort inzwischen ein gangklima erzeugt, so dass ich echt froh bin, rauszusein
21:09:51 starcow: Mein Beileid!
21:10:19 starcow: "Gangklima" :-D
21:10:25 Hannes: das letzte meinst du die alte firma?
21:10:31 Schrompf: inzwischen bin ich in der neuen firma angekommen, hab passende aufgaben gefunden, meine nische geformt
21:10:39 Schrompf: ja, Hannes
21:11:18 Schrompf: und die neue firma zahlt halt viel besser, bietet krank-ohne-krankenschein auch für kindkrank an, bezahlt das mittagessen und die limo, den kaffee, das obst, die schoki
21:11:21 Schrompf: ich werd immer fetter
21:11:33 starcow: ^^
21:11:36 starcow: Shit!
21:11:54 Schrompf: und auch wenn sich herausgestellt hat, dass roboter ein viel weniger cooles thema sind, als ich vorher dachte, bin ich dort doch ziemlich zufrieden inzwischen
21:12:08 Schrompf: nur diesen extremen performance-themen und dem damaligen team weine ich noch nach
21:12:28 Schrompf: das waren 4 C++ler*innen, dieses Mal wirklich absichtlich gegendert, weil eine der vier halt ne Frau war
21:12:37 Schrompf: und eine der besten Coder, die ich jemals kennengelernt habe
21:13:08 Schrompf: mit denen geile krasse steile neue Ideen zu entwicklen und zu bauen, um mit diesen absurden Datenmengen umzugehen, war so geil... das will ich nicht in meinem lebenslauf missen
21:15:19 starcow: Wisst ihr wieso ab Windows10 ein Segfault irgendwie nur noch "silent" crasht, wenn man ihn provoziert?
21:16:01 starcow: Bei den älteren Windwos-Versionen kam so ne Meldung "Blablabla muss funktioniert nicht mehr und muss beendet werden"...
21:17:18 Schrompf: keine ahnung
21:17:36 Schrompf: wenn du in der IDE bist, kriegst du ja sofort den Debugger, dann hast du alles, was du brauchst
21:18:00 Schrompf: und wenn das ding alleine läuft, empfehle ich Dir std::stacktrace (ab C++20, glaube ich)
21:18:16 Schrompf: und nen Windows API Exception handler
21:18:30 Schrompf: Windows hat eigene Exceptions, nciht die C++-Exceptions
21:18:36 Schrompf: und da kommen auch Segfaults und so durch
21:18:43 starcow: Kann man nicht irgendwie in Windows einstellen, dass sich das bemerkbar macht, wenn was crasht?
21:18:45 Schrompf: damit kannst du die fangen und nen stacktrace ausgeben
21:19:01 Schrompf: du kannst also quasi code schreiben, der läuft, wenn du nen segfault auslöst
21:19:15 Schrompf: und das hab ich in all meinen spielen drin, um den callstack ins log zu schreiben
21:19:35 Schrompf: damit hab ich ne einfache debug-möglichkeit, wenn das spiel bei ner spielerin auf steam crashed
21:19:49 starcow: ohne core dump!
21:19:53 Schrompf: ja, du kannst auch per Regedit oder so einstellen, dass Windows nen "Minidump" erzeugt
21:19:57 Schrompf: wenn dein spiel crasht
21:20:22 Schrompf: den minidump kannst du dann mit der exakt passenden Exe im VisualStudio laden und kriegst nen Debugger an der CrashStelle
21:20:34 Schrompf: aber das muss man halt auf jedem Rechner einstellen, glaube ich
21:20:39 Schrompf: googel mal nach "Minidump"
21:21:21 starcow: Ich kann nur begrenzt einfluss nehmen auf das System dort. Ist keine ganze IDE installiert.
21:21:45 starcow: Früher war das sofort klar, wenn Windows was abschossen hatte.
21:22:38 Schrompf: wie gesagt, google mal nach "minidump"
21:22:48 Schrompf: du kannst das glaube ich auch ins manifest der exe einkompilieren
21:23:00 Schrompf: und dann entsteht bei nem crash auch auf dem zielsystem ein minidump
21:23:11 Schrompf: und den können die leute dir dann schicken, und du kannst den ins VisualStudio laden
21:23:17 Schrompf: und siehst den Crash live von innen
21:23:48 starcow: Super, danke für den Tipp! :-)
21:32:23 Schrompf: poste mal was, starcow !
21:32:34 Schrompf: ich würd mich echt freuen, mal zu sehen, was du aus all dem machst
21:34:26 starcow: Ich rühre leider immernoch an der Basis rum. :-) Aber ich denke bald sollte es etwas Grafik auf dem Bildschrim geben :-)
21:34:44 Schrompf: naja, "noch immer"... du willst es ja so
21:34:58 Schrompf: es wäre heutzutage echt nicht mehr nötig, ein malloc() selbst zu bauen
21:35:17 Schrompf: aber ich find's auch geil, mit welcher konsequenz und ausdauer du die basics untersuchst
21:35:33 Schrompf: du hast wahrscheinlich jetzt bereits mehr ahnung von den innereien der standardlib als ich
21:35:51 starcow: Hehe, ja, das ist mir bewusst :-). Ja, du hast Recht, ich find das einfach enorm spannend! Kann irgendwie nicht ändern X-)
21:36:12 starcow: Aber malloc selberschreiben -> Das mache ich jetzt erstmal nicht ^^
21:36:49 Schrompf: doch, mach mal!
21:36:58 starcow: Haha :-D
21:37:02 Schrompf: bau dir erstmal ne plumpe liste aus freien blöcken
21:37:13 Schrompf: und denk an die hierarchien
21:37:33 starcow: Ok!
21:37:38 Schrompf: du kannst linear durchgehen und was vom kleinsten freien block abzwacken, der groß genug ist
21:37:47 Schrompf: und dann siehst du, dass das sacklangsam ist
21:38:04 Schrompf: wenn du mal ein paar millionen kleine allocs hattest und die hälfte davon ge-freed hast
21:38:24 Schrompf: und dann wird's lustig, dann denkst du an die weisheit von vorhin mit den "hierarchien"
21:39:01 Schrompf: und teilst zum beispiel jeden free-block in zwei hälften, von denen du jeweils "kleinsten teilbereich" und "größten teilbereich" merkst
21:39:20 Schrompf: und danach kannst du dann uuuultrafix raussuchen, in welchem teilstück du die allokation unterbringst
21:39:38 starcow: Was würde denn passieren, wenn jedes Malloc einfach ein VirtualAlloc aufruf ist? Ich meine... Ist zwar etwas Platz verschwendet, müsste doch aber ziemlich gut laufen (performance-technisch)?
21:39:44 Schrompf: das plus ne irre menge an compiler- und hardware-wissen ist auch das, was in malloc() aus der standardlib waltet
21:39:50 Schrompf: nein
21:40:05 Schrompf: VirtualAlloc ist ein Kernel-Switch, soweit ich weiß
21:40:14 Schrompf: 1000 instructions allein für den kontextwechsel
21:40:21 starcow: Oha...
21:40:29 Schrompf: wo ein malloc im "nicen" pfad auf <100 cycles kommt
21:40:43 Schrompf: außerdem kriegst du nach meinem wissen immer mindestens eine page
21:40:49 Schrompf: also 4kb oder 64kb
21:40:54 starcow: Aber malloc muss ja auch irgendwo den Syscall machen? Anders gehts ja irgendwie nicht, oder?
21:41:03 Schrompf: und die meisten allocs sind irgendwas schräges wie 27byte
21:41:18 Schrompf: doch, malloc macht gelegentlich nen syscall, wenn die buffer alle sind
21:41:27 Schrompf: ansonsten holt es sich 64MB auf einmal oder so
21:41:34 Schrompf: und gibt dir die 27 byte daraus
21:41:40 starcow: Und initial? Also beim ersten aufruf?
21:41:58 Schrompf: beim ersten aufruf wird's nen ersten großen buffer holen, schätze ich
21:42:01 Schrompf: aber jetz spekulier ich
21:42:08 xq: was schrompf sagt
21:42:16 xq: und damit gute nacht
21:42:21 Schrompf: ah, xq ist sa
21:42:30 Schrompf: der hat mehr ahnung von diesen innereien als ich
21:42:33 Schrompf: nein, er ist weg
21:42:34 Schrompf: der penner
21:42:38 starcow: Also quasi Speicher vom Data-Segment? Dort wo die globalen und static wohnen?
21:42:42 Schrompf: nein
21:42:46 xq: mmap/VirtualAlloc ist fucking lahm
21:42:48 Schrompf: speicher vom betriebssystem
21:43:01 Schrompf: das OS redet mit der MMU im Prozessor direkt
21:43:09 Schrompf: und daher geht das auch nur mit ganzen pages
21:43:39 xq: kann morgen sicher mal was dazu schreibem
21:43:47 starcow: Moment... du sprachst von einem Buffer?
21:43:59 starcow: @xq ok! :-)
21:44:04 Schrompf: nein
21:44:11 Schrompf: @starcow: es ist kompliziert
21:44:38 Schrompf: allen voran: die vorstellung davon, dass der hauptspeicher ein riesiges array aus hintereinander liegenden bytes ist
21:44:46 Schrompf: ist nur ne illusion, die die MMU für dich herstellt
21:45:05 Schrompf: in wirklichkeit gibt's pages, die jeweils auf physischen RAM gemappt werden
21:45:11 starcow: Du meinst die Windows Pages?
21:45:21 Schrompf: jede page hat ne reihe transistoren auf einem der speicherriegel
21:45:33 Schrompf: und welche und wo die sind, macht die MMU
21:45:36 Schrompf: im prozessor
21:45:50 starcow: Ok, klar Memory Management Unit?
21:46:08 Schrompf: und dazu hat sie eine reihe caches, darunter den TLB, der rein dazu da ist, adressen (aus pointern in deinem prozess) auf physische pages zu übersetzen
21:46:10 Schrompf: genaz
21:46:20 Schrompf: heiutzutafe in de rCPU eingebaut
21:46:25 Schrompf: oh, ich bin echt durch
21:46:29 Schrompf: egal
21:46:35 Schrompf: ich werde mich morgen früh hassen
21:46:39 Schrompf: (euch auch, btw)
21:46:50 Schrompf: aber jetzt gerade fühl ich mich wohl
21:46:52 starcow: Haha, noch drei Minuten, dann machen wir Schluss! :-)
21:47:32 Schrompf: also: die illusion, dass der speicher eine riesige reihe bytes ist, die hintereinader liegen, wird für jeden prozess eigens erstellt
21:47:45 Schrompf: wenn du nen pointer auf die konsole logs
21:47:51 starcow: Ok, dass verstehe ich.
21:48:03 Schrompf: und die adresse, die da steht, in ner anderen exe als pointer eingibst
21:48:06 Schrompf: kriegst du nen segfaulrt
21:48:07 starcow: Das sind keine echte "Hardware" Adressen, sondern nur vom Prozess
21:48:16 Schrompf: weil die andere exe ihre eigene illusion hat
21:48:41 Schrompf: und das ist absicht, das OS gibt sich viel mühe, dass jeder prozess ganz für sich allein lebt
21:48:48 Schrompf: genau
21:48:53 starcow: Ok, klar!
21:49:13 Schrompf: und wenn du jetzt VirtualAlloc aufrufst, dann kriegst du eine anzahl pages auf eine adresse gemappt
21:49:23 Schrompf: und diese pages werden dann auch in die illusion eingepflegt
21:49:33 Schrompf: so dass die ne echte adresse haben, wo pointer sie finden können
21:49:40 Schrompf: (nur in deinem prozess, wohlgemerkt)
21:49:48 Schrompf: und das kostet rechenzeit
21:50:05 Schrompf: deswegen ist ein VirtualAlloc zwangsweise viel langsamer als ein stdlib-malloc
21:50:05 starcow: Du sagst mir: Wenn ich malloc(1) mache, dann gibts gar keinen Syscall? Weil malloc ne "versteckte Reserve" hat?
21:50:10 Schrompf: genau
21:50:18 Schrompf: malloc hat nen internen buffer
21:50:26 Schrompf: und bedient die allermeisten allocs daraus
21:50:35 Schrompf: weil die allermeisten allocs halt 42 bytes sind, oder 27
21:50:43 starcow: holt er sich das einfach bei Programmstart? Oder wo versteck sich dieser Buffer?
21:50:44 Schrompf: aber die wenigsten sind "256kb"
21:50:51 Schrompf: ne, das holt das nach bedarf
21:51:11 Schrompf: und wahrscheinlich auch eskalierend, damit dein prozess nicht absurd viel verbraucht sofort ab start
21:51:20 Schrompf: die müssen ja an "alle" usecases denken
21:51:38 Schrompf: wenn du ein kleines tool schreibst, dann mit 20kb auskommt, dann müssen die nur 24kb allokieren
21:51:59 Schrompf: wenn du ein tool schriebst, dass 20GB allokiert, dann müssen die 20GB virtual-allocen
21:52:20 Schrompf: aber das internet würde schreien, wenn du ein 20kb-tool hast und das OS 20GB dafür reserviert
21:52:29 Schrompf: daher die eskalations-stufen
21:52:40 Schrompf: hierarchien, erinnerst du dich? sie sind wirklich überall
21:52:55 starcow: Ich dachte, an den Heap kommt nur das OS ran?
21:53:02 Schrompf: ja?
21:53:13 Schrompf: ich hab den eindruck, du hast ein verständnisproblem, aber ich seh's noch nicht
21:53:19 Schrompf: der heap ist ne illusion
21:53:25 Schrompf: die wird für jeden prozess neu gebaut
21:53:33 Schrompf: und die baut man nur pageweise
21:53:39 Schrompf: also mindestens 4kb auf einmal
21:53:43 starcow: Das ist mir klar.
21:54:05 Schrompf: und damit malloc kleine allocs bedienen kann, ohne sinnlos zu eskalieren, holt es sich immer ein paar pages, und managed die dann selbst
21:54:18 Schrompf: und wenn du was riesiges mallocst, holt es halt viele pages auf einmal
21:54:26 starcow: Ich frage mich nur, woher holt sich malloc die Reserve, wenn es kein Syscall macht? Und wenn diese Reserve auch nicht im Data-Segment des Programmes liegt.(?)
21:54:41 Schrompf: doch, es macht nen syscall, aber halt nur einmal am anfang
21:54:47 Schrompf: und dann nach bedarf, wenn die reserve alle ist
21:54:59 starcow: Achso! :-]
21:55:03 Schrompf: und der speicher liegt dann nirgendwo in der exe, sondern kommt halt vom OS
21:55:04 starcow: :-D
21:55:13 Schrompf: und das OS hat alles da, was die maschine zu bieten hat
21:55:50 starcow: Aber diese Initiale Syscall könnte ich ja einfach selbst machen... Und den Speicher "clever" selbst verwalten. Meintest du das?
21:56:06 Schrompf: genau. damit baust du dann malloc() selbst, genau wie du es vor hattest
21:56:26 starcow: Ich glaube ich habs jetzt verstanden! :-) Danke Schrompf
21:56:31 Schrompf: gerne. hoffe ich
21:56:46 starcow: Heisst aber: Initial hab ich diese Performance Einbusse ohnehin.
21:57:12 Schrompf: ja, aber nich überbewerten
21:57:23 Schrompf: die "performance-einbusse" ist immer noch nur ein paar tausend takte
21:57:27 Schrompf: ne mikrosekunde
21:57:38 starcow: Hehehe ok!
21:57:56 starcow: Danke für deine Geduld Schrompf! Das war jetzt sehr erhellend! :-)
21:57:58 Schrompf: deine zwangsweise windows virenschutz sicherung braucht sekunden, eh es entscheidet, dasss deine exe wert ist, ausgeführt zu werden
21:58:16 Schrompf: da kannste die mikrosekunde für VirtualAlloc stressfrei verkraften :-)
21:58:19 starcow: :-x
21:58:28 Hannes: so genau hab ich bisher keinen Einblick gehabt in den Speicher, danke für die Erklärungen Schrompf
21:58:35 Schrompf: gern
21:58:45 Schrompf: bitte bedenke, dass ein großteil davon spekulation ist
21:58:53 Schrompf: hab ich ja klargestewllt, hoffe ich
21:58:58 Hannes: :-)
21:59:17 starcow: Ok, gut zu wissen! Einfach nicht VirtualAlloc am "Laufmeter" aufrufen, richtig?!
21:59:39 Schrompf: naja
21:59:40 Schrompf: doch
21:59:44 Schrompf: for science! :-)
21:59:46 Schrompf: mach das mal
21:59:57 Schrompf: und du wirst herausfinden, warum man das nciht macht :-)
21:59:57 starcow: Hehehe, OK!
22:00:15 Schrompf: du kriegst es nur mit nem echten usecase mit
22:00:25 starcow: Danke dir Schrompf, sehr gut erklärt!
22:00:25 Schrompf: also brauchst du irgendwas, was wirklich einen zweck erfüllt
22:00:50 Schrompf: das ist hier gerade eine version von "make games, not engines"
22:01:02 starcow: Die Prämisse find ich gut!
22:01:11 Schrompf: du hast keine ahnung, warum dein malloc() suckt, solange du kein echtes programm hast, was ordentlich malloct
22:01:42 Schrompf: genauso wie: du hast keine ahnung, warum deine engine kacke ist, solange du kein echtes spiel hast, was du damit bauen willst
22:01:55 starcow: ^^
22:02:31 starcow: Leute, wir sollten ins Bett! :-)
22:02:44 Schrompf: wir haben gerade feedback-runde in der firma
22:03:10 starcow: Danke für die Ausdauer Schrmopf :-)
22:03:11 Schrompf: wo wir uns selbst und unsere kollegen bewerten sollen, was für skills sie haben in diesen und jenen themen
22:03:42 Schrompf: und da hab ich heute gelernt, dass ein kollege in ner berliner games-firma mit dem typen von der Nebula-Engine und von sokol gearbeitet
22:03:44 Schrompf: hat
22:03:49 Schrompf: krasse fäkalie
22:04:18 Schrompf: ein anderer kollege hat für UbiSoft Moskau an Heroes of Might&Magic 5 mitgebaut
22:04:28 Schrompf: was mach ich bei denne?
22:04:41 Schrompf: nur weil ich nen game auf steam hab, was ~50k umsatz gemacht hat
22:04:48 Schrompf: es ist so irre
22:04:54 Schrompf: gute nacht, starcow
22:05:08 Schrompf: danke, dass du meine alte-männer-rants immer so tapfer erträgst
22:05:18 starcow: Du stehst denen bestimmt in nichts nach!
22:05:34 starcow: Da bin ich mir sicher! :-)
22:05:39 Schrompf: abstrakt betrachtet ja, aber es fühlt sich anders an
22:05:41 starcow: Nacht meine Lieben! Bis bald
22:05:53 Schrompf: nachti
22:05:56 Hannes: bis bald
22:06:58 Hannes: ich gehe auch mal eine mütze schlaf hohlen
22:07:05 Hannes: gn8
22:07:07 Schrompf: weise
22:07:09 Schrompf: nacht
22:11:01 Schrompf: dasss die leute immer so tapfer meinen alte-männer-bullshit ertragen
22:11:35 Schrompf: naja, ich freu mich, weisheit spitten zu können, die sonst im äther verpufft