Aufgabenaufteilung

this-*gt*that

X.DarkForce.X schrieb:

Hi nette Community

Ich habe eine komplizierte 3D-Anwendung und möchte das ganze in Theards aufteilen.
Ich habe es mir so vorgestellt:
Einen Theard für Grafikrendering
Einen Theard für Laden(Texturen/Vertexdaten/...)
Einen Theard für Dinge wie Morphing
Einen Theard für mathematische Kalkulationen
Zwei Theards für Physik
Einen Theard für die Logik(Input/WinAPI-Aufgaben/KI/...)

Ist das gut ausbalanciert?

Meiner Meinung nach ist das ziemlicher Bullshit (was ist überhaupt ein Theard?). Einen Thread für Rendering und einen für Ressourcen-Laden macht ja noch Sinn. Einen für Input/Netzwerk EVENTUELL auch noch. Aber wozu bitte ein Thread für Mathezeugs/Morphing? Weißt du überhaupt, dass jeder Threadwechsel auch Zeit kostet? Und das dein System auf Single-Core CPUs LANGSAMER laufen wird?
Mir kommts eher so vor, als wolltest du einfach auf Biegen und Brechen Threads benutzen, weil dir das "cool" und professionell vorkommt. Praktisch betrittst du einfach nur ein Reich voller Schmerzen und Sychnronisationsprobleme. Und wenn du dich nicht WIRKLICH auskennst, wird dein System sogar noch langsamer.

X.DarkForce.X

Mir ist das Problem mit Syncronisation bekannt! Und ich werden natürlich abhängig der Anzahl logischer Kerne meine Anzahl Theards setzen!

Und dann dein Kommentar:

this->that schrieb:

...weil dir das "cool" und professionell vorkommt.

Was soll das? Meinst du wirklich ich hab um halb fünf keine besseren Dinge zu tun als in ein Forum zu gehen und dort etwas zu Posten was mir "cool und professionell" vorkommt?

zeusosc

X.DarkForce.X schrieb:

Einen Thread für mathematische Kalkulationen
Zwei Threads für Physik

Erkläre mal genauer bitte den unterschied für Dich bei diesen beiden Dingen.
(Für mich wär das ein und das selbe...)

Sei gegrüßt,..

X.DarkForce.X

Physik für Kollisionserkennung, einwirkende Kräfte, Widerstandskalkulationen, ...

Mathematik eben explizit nur für direkte Mathematik. Zum Beispiel für sich ändernden Bézier-Kurven.

zeusosc

Wie sieht bei dir das memory management aus? (bzgl. der snyc)

Greetz

X.DarkForce.X

Wahrscheinlich im Heap...

zeusosc

Du bist drollig,...

weißt du was passiert wenn du n block allocierst und in dem einem thread diesen noch verwendest während du in einem anderen diesen wieder freigibst??

Gerade asyncrone Schreib- und Lese-prozesse führen häufig zu den diversesten Fehlern.

Ist der aus dem Heap reservierte Block dann alligned oder unalligned??
Arbeitest Du dann für deine mathe fkt's dann mit SSE? Oder nimmst du OpenCL? Oder std fkt's ? Kompilierst Du diese dann mit /arch:SSE2 ??

Erzeugst Du kopien deiner Speicherbereiche bei der übergabe oder referenzierst Du die nur?

(Windoof:) Reservierst Du einen private heap oder allocierst Du frei aus dem Prozess Heap?

Hast Du an Abbruchbedingungen gedacht? Werden innerhalb der Threads auf events geprüft und wird dann alles aufgeräumt und wieder freigegeben?

Wie speicherst Du Objecte ab? Nur die Vertices der Graphiken? Oder auch andere Parameter wie z.b. Zentrum, Radius, Brechungsindex, Transmission-Reflexionsgrad einer Glaskugel??

Welche daten brauchst Du für welche Berechnungen?? Müssen diese A-sequenciell sein?

Grüüße

nurf

sdfdhehreherh schrieb:

X.DarkForce.X schrieb:

Ist das gut ausbalanciert? Hab ich was vergessen?

Ja. Dass die Synchronisierung kein Spaß wird.

Wenn man überhaupt synchronisieren muss.

Wenn man die Aufgaben in einem entsprechenden Job-System kapselt, ist die ganze Software relativ lock-frei.
Dann kann man auch zur Laufzeit die Anzahl der benutzten Threads variieren und auch die Aufgaben von Thread zu Thread verschieben.
Locks braucht man eigentlich nur, wenn man nicht weiß was reentrant bedeutet.
Für den Rest reicht meistens auch das Reactor-Pattern.

rapso

X.DarkForce.X schrieb:

this->that schrieb:

...weil dir das "cool" und professionell vorkommt.

Was soll das? Meinst du wirklich ich hab um halb fünf keine besseren Dinge zu tun als in ein Forum zu gehen und dort etwas zu Posten was mir "cool und professionell" vorkommt?

so klingt das leider.
du sagst nicht, dass du ein problem loesen musst, z.b. dass etwas zu langsam wird, lediglich dass du ein komplexes system noch viel komplexer machen willst.
deine aufteilung in threads klingt sehr willkuerlich als ob du 50% mal irgendwo gelesen haettest und 50% hast du dir so dazu gedacht, aber nochmals: man sieht nicht dass es irgend ein problem loesen soll.
entsprechend klingt

Ist das gut ausbalanciert?

total void. du fragst uns, ob du etwas gut loest ohne ein problem zu nennen. woher sollen wir wissen ob das gut ist? woher willst du das wissen? wie ist denn laut deinem profiling die lastverteilung der einzelnen bereiche die du schlussendlich auf threads verteilen willst? waere das nicht eine nennenwerte information wenn du fragst ob die aufteilung gut ist?
wuerde die frage sich nicht von selbst beantworten wenn du siehst dass die verteilung gleichmaessig ist?

ich hoffe das beantwortet deine "Was soll das?" frage.

X.DarkForce.X

Also OK!
Ich habe eine 3D-Anwendung die zuerst mit 0,... Bilder in der Sekunde lief. Nach Occlusion-, Frustum- und Detailcullling lief das ganze mit 50 bis 150 Bildern in der Sekunde. Das Ergebnis ist gut, ich habe aber einen schnellen Vierkerner und habs mal auf 'nem langsamen Zweikerner getesten. Fatal! Nach langen Ladezeiten liefs nur sehr ruckelig.
Da fiel mir ein, dass ich bis jetzt nur einen Prozess und nur einen Thread hatte!

PS: Mein Prozessor hat Turboboost, heisst er übertaktet sich bei Anwendungen, welche nur einen Kern ansprechen. Heisst, ich hatte fast 4 GHz auf einem Kern...

inter2k3

X.DarkForce.X schrieb:

Mir ist das Problem mit Syncronisation bekannt! Und ich werden natürlich abhängig der Anzahl logischer Kerne meine Anzahl Theards setzen!

Und dann dein Kommentar:

this->that schrieb:

...weil dir das "cool" und professionell vorkommt.

Was soll das? Meinst du wirklich ich hab um halb fünf keine besseren Dinge zu tun als in ein Forum zu gehen und dort etwas zu Posten was mir "cool und professionell" vorkommt?

Ich weiss auch nicht was das soll. Auf mich machst du einen sehr amüsanten Eindruck und ich freu mich jedesmal, wenn ich sehe dass du eine neue Frage gestellt hat. Muss ich jedesmal schmunzeln.

Auf der einen Seite fragst du vor noch garnicht allzulanger Zeit nach einem OpenGL SDK, was der unterschied zw. template <class T> .. und template <typename T> .. ist, ob man nen Winkel in rad oder deg angiebt, wie man zwei Texturen pixelweise vergleicht etc. etc., und auf der anderen Seite willst du Vertexkoordinaten von Rotationsellipsoiden (lustigerweise als Geosphäre von dir bezeichnet) berechnen, multithreading realisieren...

Du verstehst grösstenteils die klarsten Antworten nicht oder ignorierst sie schlichtweg und antwortest auf Fragen wie:

rapso schrieb:

wie ist denn laut deinem profiling die lastverteilung der einzelnen bereiche die du schlussendlich auf threads verteilen willst?

mit Aussagen, die inhaltlich gleichwertig sind mit: Ich esse gerne Wurstbrot.

Vlt. sollte "cool und professionell wirken" heissen, dass du gerne Themen ansprichst, von denen du nicht die geringste Ahnung hast. Dir fehlen ganz offensichtlich eine Menge Grundkenntnisse, aber das scheint dich nicht zu stören, da es dank copy&paste und google trotzdem irgendwie klappt - und zur Not gibts ja noch das Forum.

Nichts für ungut. Wie gesagt, ich freu mich jedesmal

Powerpaule

X.DarkForce.X schrieb:

Also OK!
Ich habe eine 3D-Anwendung die zuerst mit 0,... Bilder in der Sekunde lief. Nach Occlusion-, Frustum- und Detailcullling lief das ganze mit 50 bis 150 Bildern in der Sekunde. Das Ergebnis ist gut, ich habe aber einen schnellen Vierkerner und habs mal auf 'nem langsamen Zweikerner getesten. Fatal! Nach langen Ladezeiten liefs nur sehr ruckelig.

Das klingt (trotz Culling, aber das ist ja auch nicht alles) eher danach, als ob die Anwendung insgesamt einfach noch ineffizient programmiert etc ist. Langsame oder falsch benutzte Algorithmen, überflüssige oder zu häufige Berechnungen, zu detaillierte Objekte, etc.
Dass mein Prozessor mehr Leistung hat, ist kein Grund dazu mit Leistung verschwenderischer umzugehen. Was ist denn ein "langsamer Zweikerner"?
Da jetzt mit Threads mühsam versuchen, irgendwas rauszuholen, obwohl das Problem erstmal woanders liegt, macht mir keinen Sinn. Und wenn doch Threads, dann sollte man, wie schon erwähnt wurde, erstmal herausfinden, was eigentlich die größten Leistungsfresser sind. Und dann kann man überlegen, wie sich das überhaupt gut in Threads aufteilen lässt. Wenn der eine Thread dauernd auf einen anderen warten muss, weil beide in irgendwelche selben Objekte schreiben, dann ist der Sinn auch fraglich.
Das Einzige, was sich fast immer relativ problemlos und sinnvoll in einen Tread auslagern lässt, ist das bloße Laden von Objekten, Texturen und sonstigen Informationen..