Nachdem ich neulich die dreidimensionale Generierung von Spielwelten durch eine Mercatorprojektion auch in der zweiten Dimension abgebildet hatte, machte ich mir einige Gedanken zur Performance der Generierung...
Die Mercatorprojektion lief wie folgt ab: zu jedem Pixel bestimmte ich Longitude und Latitude der Richtung des Strahls, der ausgehend aus dem Koordinatenursprung den Planeten durchstoßen müsste, um den korrekten Ort für die Einfärbung des Punktes in der Projektion zu bestimmen. Anschließend wurden alle Dreiecke, die den Planeten als Gesamtheit darstellen daraufhin untersucht, ob der Strahl sie traf. sobald eines gefunden wurde, wurde die Suche abgebrochen und der Pixel mit der Farbe dieses Dreieckes eingefärbt.
Zunächst einige Randbedingungen: Die Erzeugung der Benchmark-Planeten lief bis in die 6. Rekursionsebene. Daraus resultieren 81920 Dreiecke. Die Mercatorprojektion wurde als Bild mit einer Auflösung von 800 Pixel * 600 Pixel erzeugt. In einem Single-Thread Durchlauf ohne irgendwelche Optimierungen wurde eine Generierung in rund 28 Sekunden absolviert.
ray tracing took 00:28:32.358739
Da hierbei der Computer nur zu 25% ausgelastet war, war die nächste Optimierung klar: Alle Kerne wurden genutzt. Die Tests ergaben, dass bereits 4 Threads (einer pro Kern) für die Rückprojektion ausreichten, die Auslastung des Rechners auf 99% zu heben. Wir ich bereits im Hauptseminar lernte, macht es keinen Sinn, Raytracing mit General-Purpose-CPUs auf Pixelebene zu parallelisieren. Daher wurden Worker erstellt, die jeweils eine Zeile der Projektion zu berechnen hatten und vier Threads, die diese insgesamt 600 Worker abarbeiten mussten. Dadurch wurde eine Beschleunigung erreicht, die jedoch nur marginal ausfiel: nunmehr brauchte die Erzeugung der Projektion nur noch rund 20 Sekunden:
ray tracing took 00:20:14.845007
Das reichte mir noch nicht. Da die Suche bisher in einem großen unsortierten Heuhaufen von Dreiecken operierte, versuchte ich vor dem eigentlichen Check auf Durchdringung eines Dreiecks durch den Strahl - eine Aufgabe, die mit vielen komplexen Operationen (Trigonometrie, Quadratwurzeln,...) verbunden ist - die Anzahl der zu testenden Dreiecke zuu reduzieren. Ich teilte dazu den Raum in Oktanten ein und testete vor jedem Durchdringungstest zunächst, ob der Strahl in den Oktanten zeigte, in dem das fragliche Dreieck lag. Diese Optimierung lieferte drastisch bessere Ergebnisse - die Berechnung wurde nun in erwas mehr als 11 Sekunden erledigt:
ray tracing took 00:11:23.174519
Die Berechnung des Oktanten für die Dreiecke wurde aus dem Code für den Durchdringungscheck ausgelagert - jetzt berechnete ich den Oktanten für jedes Dreieck vor Beginn der Projektion. Dadurch erreichte ich eine nochmalige Verbesserung auf rund 10 Sekunden:
ray tracing took 00:10:14.295899
Bis zu diesem Zeitpunkt mussten sich die einzelnen Worker beim Übertragen der Farben in das Zielbild immer noch synchronisieren - Daher erzeugte ich nun ein Zielbild für jeden Worker, deren Inhalte ich nach Abschluss der Berechnung "übereinanderkopierte", woraus erst das eigentliche Zielbild entstand. Das machte den Prozess der Erzeugung nochmals geringfügig schneller und ich erreichte das erste Mal eine Zeit von unter 10 Sekunden:
ray tracing took 00:09:44.255353
An diesem Punkt bemerkte ich einen fatalen Fehler in der Bestimmung der Oktanten der dazu führte, dass ich bisher die Dreiecke nicht in 8, sondern nur in zwei Untermengen aufgeteilt hatte. Dieser Fehler wurde beseitigt und die Separierung der Dreiecke nochmals erweitert: Nunmehr benutzte ich statt 8 Oktanten 16 Bereiche (wie nennt man das eigentlich?) und dadurch wurde der vorerst letzte Quantensprung in der Performance erreicht:
ray tracing took 00:02:56.765160
Docker auf Raspberry Pi Model 3B+
07.06.2020
Nachdem ich neulich über neues in meinem Docker-Zoo berichtete und überneulich eine Idee zur Aufwertung und Beschleunigung meines Raspberry erfolgreich in die Tat umsetzte, war der nächste Schritt klar...
WeiterlesenAndroid Basteln C und C++ Chaos Datenbanken Docker dWb+ ESP Wifi Garten Geo Go GUI Gui Hardware Java Java. Komponenten Jupyter JupyterBinder Komponenten Links Linux Markdown Markup Music Numerik OpenSource PKI-X.509-CA Präsentationen Python QBrowser Rants Raspi Revisited Security Software-Test sQLshell TeleGrafana Verschiedenes Video Virtualisierung Windows Upcoming...
Nach der letzten losen Zusammenstellung (für mich) interessanter Links aus den Tiefen des Internet von 2025 folgt hier gleich die nächste:
WeiterlesenEs gibt ein neues Plugin für die sQLshell, das die Erstellung von Pivot-Tabellen enorm vereinfacht - alles, was dazu benötigt wird ist eine bereits erfolgte Abfrage.
WeiterlesenIch wurde wieder einmal durch einen Trööt auf Mastodon inspiriert...
WeiterlesenManche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.
Wer daran teilhaben und eventuell sogar davon profitieren möchte, muss damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.
Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...
PS: Meine öffentlichen Codeberg-Repositories findet man hier.