Buchempfehlung
Visual Basic 6 Kochbuch
Visual Basic 6 Kochbuch
Viele praktische Tipps zum Programmieren mit Visual Basic 6, die sich oft auch auf FB übertragen lassen. [Mehr Infos...]
FreeBASIC-Chat
Es sind Benutzer im FreeBASIC-Chat online.
(Stand:  )
FreeBASIC bei Twitter
Twitter FreeBASIC-Nachrichten jetzt auch über Twitter erhalten. Follow us!

Tutorial

Threading-Optimierung - Teil 2

von MitgliedThePuppetMasterSeite 3 von 5

Lösungsansatz

Das zuvor beschriebene Komplexe Problem zu lösen ist nicht ganz einfach.
Es muss eine strikte Trennung von 2 Threads vorgenommen werden, deren wechselseitiger Einfluss keine Auswirkungen auf deren Partner-Threads hat.

Mal am Rande: Dieses Problem ist nicht weit her geholt. Aktuelle CPU Entwickler und Programmierer schlagen sich schon länger mit diesem Thema herum, denn die CPU Taktraten lassen sich eigentlich kaum noch Steigern. Daher geht der Trend schon längst auf Multicore CPU's.
Vorteil hier ist die einfache Auslagerung und Parallelität von Programmen. Irgend wann (gar nicht so weit weg), hat die CPU so viele Kerne, das jedes Programm seinen eigenen bekommt.
Aber dies reicht natürlich auch irgend wann nicht mehr aus, um den Leistungshunger eines Programms zu decken. Knapp 4 GHz Taktrate pro Programm ist zwar enorm, aber eine Simulation ist da schnell an einem Mangel.
Daher werden CPUs immer größer und erhalten Kerne in einer Größenordnung von 128 Kerne und mehr (Wurde mir vor ca. einem Halben Jahr von Intel zugetragen).

Jetzt lassen sich natürlich auch einzelne Funktionen problemlos priorisiert und im Single-Prozess auf einen Kern auslagern.
Und hier ist schon wieder das Problem des Wechselseitgen Zugriffs. Eine Funktion auf einem Kern wird nur dann ausgeführt, wenn sie den Auftrag bekommt, bzw. kann nur dann weiter arbeiten, wenn eine andere Funktion ein Ergebnis liefert.
Hier muss also eine Parallelität in die Funktion untergebracht werden, die dafür sorgt, das die Störungen im Ablauf so gering wie möglich gehalten werden.


Diesen Ansatz werden wir in diesem Kapitel ebenfalls verfolgen.

Es gilt also die Reduktion von Störquellen in der Berechnung der Naniten, sowie der Partikel zu minimieren.

Ein Radikaler Ansatz wäre einfach die Trennung der Wechselseiten Beeinflussung. Aber wozu dann noch das Programm weiter entwickeln? (*lach*) .. Nein! Scherz beiseite.

Wobei das an sich schon ein richtiger Ansatz ist, denn genau dies ist es ja, was die Bremsung im Ablauf hervorruft.

Im Threading Optimierung's Tutorial habe ich auf den letzten Seiten schon einen möglichen Ansatz aufgeführt. Es wäre möglich einfach eine Speicherkopie der nötigen Daten zu erzeugen, und mit diesen Zu Rechnen.

Aber, kurz zum Berechnungsmodell an sich, um das Verständnis hier der Kollisionsberechnung zu erleichtern.

Zuerst durchläuft man jedes Partikel, und Prüft, ob es eine Kollision (Satz des Pythagoras) mit einer Nanite gibt. Ist dies der Fall, wird das Partikel aus der Linked List entfernt, und der Nanite ein Schaden hinzu gerechnet.
Das Ganze wird für jedes Partikel wiederholt, bis keine Partikel mehr übrig sind, oder die Partikel sich selbst gelöscht bzw. Umgesetzt haben (Wiki: Alpha- / Beta- / Gamma-Zerfall).


Wie zu erkennen ist, muss ein ziemlicher Aufwand stattfinden, um die Kollision zu Prüfen. Viele Spieleentwickler Nutzen hier eine Art Rasterrung des Spielfelds, um eine Vorrechnung einer Kollisionswahrscheinlichkeit zu ermitteln, bevor Komplexe Kollisionsberechnungen stattfinden, welche mehr Rechenzeit benötigen.

Hiermit lässt sich ein Großteil der Berechnungszeit einsparen. Da meine Simulation jedoch, relativ betrachtet, ziemlich Engmaschig ist, wäre dieser Schritt eher eine Belastung als eine Hilfe. Außerdem wäre es nicht sonderlich hilfreich für dieses Tutorial. :)

Aus diesem Grunde gehen wir das Problem wieder am Kern an. Dem Wechselseitigem Zugriff.

Ziel ist es immer noch, die Beiden Prozesse so voneinander zu Trennen, das nur noch minimalste Zugriffe auf den Partner nötig sind.

Dazu muss man sich den Prozess im Detail ansehen, und genau Untersuchen warum eben dieser so viel Zeit in Anspruch nimmt. In meinem Fall ist es der Herr Pythagoras mit seinem Satz.
Bevor die Partikelberechnung beginnt wird das Mutex auf die Naniten gesperrt, um deren Veränderung zu verhindern und so ein Wechselseitigen Zugriff zu verhindern. Anschließend entspert die Funktion das Mutex auf die Naniten wieder.





 

Gehe zu Seite Gehe zu Seite  1  2  3  4  5  
Zusätzliche Informationen und Funktionen
  • Das Tutorial wurde am 05.05.2010 von MitgliedThePuppetMaster angelegt.
  • Die aktuellste Version wurde am 27.05.2010 von Mitgliedfrebas gespeichert.
  Bearbeiten Bearbeiten  

  Versionen Versionen