ZFX + Developia

Hallo zusammen, ZFX ist wieder online \o/ Der Webserver war abgestürzt/heruntergefahren. Ursache unbekannt. Demnächst will Steffen die Webseite aber auf einen normalen Hoster umziehen, damit er solche Sachen nicht mehr machen muss. Ich habe jetzt auch wieder Handy-Kontakt, so dass ich schneller Alarm schlagen kann :)

Juchuu! Ich hatte mir echt Sorgen gemacht.

Nice, danke für euren Einsatz.

Schön dass das Forum wieder da ist :)

Cool, super. Hatte mir auch schon sorgen gemacht, immerhin haben wir hier so eine schnuckelige Community, eigentlich müsste man das unter Denkmalschutz stellen :D
Wie ist denn die aktuelle Lage? Ich meine, es kann ja immer mal irgendwas passieren, ggf. wäre es gut ein wenig Redundanz zu haben? Vlt. einen zweiten Admin oder so? Wenn sowas wie Hosting-Kosten jemals ein Thema wird, könnte man das ja sicherlich auch innerhalb von weniger als einer Woche mit einem kleinen Aufruf hier in den Griff bekommen, Hauptsache die Seite bleibt online :D

Jonathan hat geschrieben: ↑27.07.2022, 12:06 Cool, super. Hatte mir auch schon sorgen gemacht, immerhin haben wir hier so eine schnuckelige Community, eigentlich müsste man das unter Denkmalschutz stellen :D
Wie ist denn die aktuelle Lage? Ich meine, es kann ja immer mal irgendwas passieren, ggf. wäre es gut ein wenig Redundanz zu haben? Vlt. einen zweiten Admin oder so? Wenn sowas wie Hosting-Kosten jemals ein Thema wird, könnte man das ja sicherlich auch innerhalb von weniger als einer Woche mit einem kleinen Aufruf hier in den Griff bekommen, Hauptsache die Seite bleibt online :D

Volle Zustimmung. Ich bin zu allen "Schandtaten" bereit, wie sicherlich die meisten Regulars hier.

So ist es.

Ich habe übrigens gemerkt, dass die fehlende HTTP-zu-HTTPS-Umleitung nicht nur sehr nervig für einmalige Besucher ist, sondern auch ganz praktische Implikationen hat: Das Internet Archive findet das Forum nicht mehr; zeichnet in 90 % der Crawlings nur die HTTP-Fehlerseite auf. Das ist sicher auch der Grund, warum unser Google-Rating ruiniert ist.

Freut mich (:

Auch von mir ein grosses und herzliches Dankeschön. :-) Wüsste nicht, was ich ohne zfx machen würde. Für mich persönlich eine der aller wichtigsten Community/Seiten!

Danke an allen die dieses Forum ermöglichen.!

Das ist eigentlich alles Steffen. Ich habe ihm nur geschrieben... wir müssen gelegentlich Zeug in phpbb machen. Aber eher alle x Jahre.

Wow. Jemand hat 20+ Jahre nach Geschehen unser altes Amiga-Projekt wiederentdeckt. 20 Jahre! Amiga! Ich find's so absurd. Und fühle mich gebauchmiezelt. https://www.gamesthatwerent.com/2022/08 ... the-lines/

Ich muss echt mal wieder irgendwas Produktives tun. Kann ja nicht ewig von altem Ruhm leben.

Was für eine geile Seite :-O Glückwunsch!

Ich hab in letzter Zeit zu viel im Jammer-Thread geschrieben, höchste Zeit sich mal der anderen Seite zuzukehren.

Internet ist heutzutage echt schnell! Ich habe gerade ein Spiel mit 60 MB/s runtergeladen, das war in ein paar Minuten fertig. Soweit ich weiß ist 50 MB/s schon eine ganz ordentliche Geschwindigkeit für eine externe Festplatte mit USB 3 (USB 3.1 oder was auch immer gerade aktuell ist, ist vermutlich noch was schneller), und auch wenn das natürlich nicht mit SSDs mithalten kann, ist es schon irgendwie erstaunlich, dass die Internetgeschwindkeit von heute die Festplattengeschwindigkeit von gestern ist. Ein paar Dinge werden eben doch mit der Zeit besser :)

Jammer-Konter: Internet-Durchsatz ist tatsächlich gigantisch; Internet-Latenz ist furchtbar. Home Office hat mir das deutlich vor Augen geführt. (Klar gibt’s eine physikalische Grenze, wie schnell ein Paket in die USA und zurück kann, aber … seit 2000 ist die Latenz eher schlimmer geworden als besser.)

Endlich...
https://www.khronos.org/blog/mesh-shading-for-vulkan

Ich wusste, dass mein Zeug schnell kompiliert, aber … meine Build Instrumentation zeigt:

Das Linken und Optimieren einer Release-Version meines Flugsimulators geht schneller als das Kompilieren dieser Quelldatei.

Das komplette Kompilieren inklusive ca. 100 C++-Quelldateien dauert natürlich länger, aber auch noch nicht so lange wie Ninja mit seinen rund 20 C++-Quelldateien.

Das ist verdammt schnell. Ich Freak

Nach 2 Tagen habe ich jetzt Github actions mit meinem CMake Projekt am laufen.
Clang und MSVC unter Windows und GCC unter Linux laufen.
GCC unter MingGW hat Probleme in einer 3rd Party lib (bin mir aber noch nicht sicher ob ich das überhaupt supporten will)
Clang unter Linux hat noch ein Problem (siehe anderer Thread)

Alles in allem macht das aber ein gutes Gefühl zu sehen dass der Build mit verschiednen Compileren und Platformen läuft :)
Positiver Nebeneffekt: Man finded einige Unsauberkeiten in den CMakeLists die Microsoft einfach durchgehen lässt...

Alles in allem bin ich aber gerade sehr zufrieden mit dem Zwischenstand

Heute gab's auf Arbeit einen Lichtblick, nach Wochen des teilweise selbstverschuldeten Chaos.

Wir haben ein Programm, das Requests annimmt und an einen Workerthread verteilt, der dann losrechnet. Darin geht man dann durch ungelogen 18 ineinander geschachtelte Schleifen und wertet ein komplexes Regelwerk für jede der möglichen Schleifenvar-Kombinationen aus. Wir haben das gut optimiert inzwischen und jede Menge Shortcuts, Mikrooptimierungen und Cleverheiten eingebaut, so dass ein innerster Loop amortisiert 2 bis 200µs rechnet. Aber irgendwie haben alle Optimierungen der letzten Monate, obwohl im Profiling und in den Benchmarks recht erfolgreich, auf Production quasi nichts bewirkt. Warum?

Nuja, wir haben in den Retros besprochen, auch außerhalb der Tickets öfter komischen Sachverhalten auf den Grund zu gehen. In dem Fall war die Partial-Rate für eine bestimmte Sorte Requests z.B. 25%, der selbe Request umgelabelt aber im Promille-Bereich. Forschen, Profilen, Testen, und siehe da: die Requests brauchen unter Last drastisch länger. Wir reden von Faktor 40, nicht von den ~2.5x, die man auf modernen Hyperthreaded CPUs schlimmstenfalls erwarten würde.

Das Profilen zeigte einen std::shared_mutex als Verursacher. Unter Volllast verbrachte die Engine >90% der Zeit im Kernel, der Callstack führt durch den shared_mutex in den Kernel-Futex. Anscheinend implementiert man einen RW-Mutex mit zwei Mutexen. Und der Read-Mutex mag in der Theorie ultrakurz sein, aber dreistellige Threads mit jeweils fast Millionen Locks pro Sekunde killen den vollständig.

Erste Hilfe: Read aus diesem Objekt weiter rein in die Loops geschoben, hinter ein paar kritische Filter, die sonst die meisten Wertekombinationen rauskegeln. BÄM, x40 schneller. Die "richtige" Lösung ist jetzt ein Copy-On-Write - jeder Request holt sich beim Start den shared_ptr des Objekts und liest das unsynchronisiert, bei Änderungen (nur alle paar Sekunden) wird das ganze Ding kopiert und dann atomar der globale shared_ptr geswappt.

Hat uns jetzt spontan 80% unserer Production-Cores überflüssig gemacht und leider auch all die geilen Optimierungstickets rausgekegelt. Stattdessen ist jetzt das Protobuf-Marshalling auf der Go-Seite der Flaschenhals, und das Netzwerk selbst.

Ich hab jetzt nicht bei allem Folgen können, aber es klingt gut :D

Wir haben in der Abteilung endlich eine neue Kaffeemaschine bekommen. Bohnen sollen auch bezahlt werden, d.h. wir müssten jetzt nur noch organisieren, welche Bohnen wo gekauft werden und die Reinigung der Maschine irgendwie sinnvoll organisieren und dann gibt es endlich jeden Tag so viel Kaffe wie man will in vernünftiger Qualität. Einen guten Milchaufschäumer gibts obendrein, so dass ich jetzt immer lecker Cappuccino machen kann :)

Kaffee ist Infrastruktur! Zumindest für die Ü30, hab ich den Eindruck. Bei uns geht eine ziemlich definierte Grenze durch die Firma: Ü30 -> Kaffee. U30 -> Mate, Cola, EnergyDrinks

Omg, wtf, ich hab früher auch hauptsächlich Mate getrunken und jetzt wo du es sagst, ich glaube ich bin mit ca. 30 umgestiegen...

Schrompf hat geschrieben: ↑28.09.2022, 13:42 Anscheinend implementiert man einen RW-Mutex mit zwei Mutexen. Und der Read-Mutex mag in der Theorie ultrakurz sein, aber dreistellige Threads mit jeweils fast Millionen Locks pro Sekunde killen den vollständig.

Kannst du das für einen Multithreading-Laien wie mich nochmal erklären? :)

Ich bin zwar nicht Schrompf, versuchs aber trotzdem mal.

So ein read write lock wird oft so implementiert dass die Reader beim holen eines Locks checken ob der write mutex gelockt ist und wenn nicht einfach einen atomaren Counter hochzählen und beim Release wieder verringern.
Der write mutex checkt dann ob der Counter 0 ist und kann nur dann den Lock hohlen.

Die hohe Anzahl Threads und Locks lassen vermutlich einfach den atomaren Counter langsam werden was dann zu den performanceproblemen führt.

Gibt natürlich noch ein paar Details die ich jetz hier übersprungen habe, aber so ganz grob könnte ich mir das Problem so erklären.

Irgendwie so, ja. Hab jetzt mal fix geschaut, ob ich die echte Implementation des shared_mutex finde, aber ohne Ergebnis. Es braucht im RWMutex irgendein Manöver, um Threads schlafen zu legen, bis sie dran dürfen - das wird wahrscheinlich ein Kernel-Mutex sein. Und Du brauchst nen schlichten Counter, solange alle nur lesen. Das ist das Atomic, von dem Matthias erzählte. Und Atomics klingen verlockend, aber lösen bei echter Contention (das bedeutet flapsig gesagt "Drängelei beim Zugriff") core-übergreifende Cache Invalidation-Events aus, die aus nem kleinen arithmetischen 3-Takte-Pups hunderte Takte Große Bühne machen können.

Hatte ich schonmal, beim AllocTracking damals: ich dachte, einfach CurrentMemSize += Bla wäre ne schnelle Sache auf nem Atomic. Pustekuchen. Der Import hat mit AllocTracking wortwörtlich Tage gedauert, wo er vorher nach ner halben Stunde durch war.

Vielen Dank für die Erklärungen. Das ergibt Sinn.

Es bewegt sich was.

Da werden sich meine Kinder aber freuen 🤩

*Ähem* P16 *Ähem*

@Schrompf: Mega!