Multithreading in Spielen bisher noch nicht verbreitet?

[Murvun]

moin moin,

bin gerade wieder über solch einen satz gestolpert (dual-cpu's von intel gingen ja an die ersten tester), und da irritiert mich diese aussage durchaus! kennt jemand morrowind? ich wunder mich bei diesem spiel immer, wieviel zeit zwischen dem klick auf <ende> und dem tatsächlichen ende vergeht. und ich bin in der ini schon über einen schalter gestolpert, der threads en/disabled...

und es gibt bestimmt noch mehr!

[Plutos]

Morrowind kennen bestimmt viele hier :wink:
Und es gibt bestimmt auch jetzt schon das ein oder andere Spiel, das Multi-Threaded programmiert ist...das ändert aber rein gar nichts an der Tatsache, dass es der überwiegende Großteil der Spiele nicht ist. Somit kann man noch keineswegs von Verbreitung reden - das sind Ausnahmen.

[LOCHFRASS]

UT2k4 ist auch multithreaded, jedenfalls unter Linux.

[redfalcon]

. und ich bin in der ini schon über einen schalter gestolpert, der threads en/disabled...

Und wie heißt dieser Schalter?

[Pappy]

Da Multicores der Ausweg für AMD und Intel aus der Taktratensackgasse sind werden die Programmierer zukünftiger Engines wie z. B: Unreal 3 sicher auf Multithreading setzen. Die Frage dabei ist natürlich wie schnell der Ottonormaluser auf Dual Core umsteigt. Aber ein neues Spiel wäre für mich bereits Grund genug, allerdings nur bei adequaten Taktraten, damit man bei älteren Spielen nicht zu viel Performance verliert.

[InsaneDruid]

UT2k4 ist auch multithreaded, jedenfalls unter Linux.

Das sollte mich aber wundern, da Tim Sweeney immer wieder sagte: solange es keine weitreichende Verbreitung von Dual CPUs / Dual Cores gibt würde man MT als weniger sinnvoll erachten und es NICHT supporten.

@Mac wird zumindest der Sound auf den 2ten Prozz gelegt, evtl ist es auch (nur) das unter Linux?

[GloomY]

Threads werden verwendet, um Nebenläufigkeiten effizient hinzubekommen. Das müssen nicht umbedingt parallele Berechnungen sein, sondern kann z.B. auch I/O sein.
Wenn man sieht, dass ein Spiel aus mehreren Threads besteht, heisst das daher noch lange nicht, dass der Hauptteil der Berechnungen auf diese (beiden) Threads aufgeteilt ist. Es kann z.B. sein, dass der übliche Game-Loop innerhalb des ersten Threads gemanaged wird, ein zweiter Thread die Soundausgabe macht und ein dritter auf Tastatureingaben reagiert.
Die Hauptlast bezüglich Berechnungen liegt hier trotzdem bei einem Thread, obwohl mehr als einer existiert.

[Demirug]

Threads werden verwendet, um Nebenläufigkeiten effizient hinzubekommen. Das müssen nicht umbedingt parallele Berechnungen sein, sondern kann z.B. auch I/O sein.
Wenn man sieht, dass ein Spiel aus mehreren Threads besteht, heisst das daher noch lange nicht, dass der Hauptteil der Berechnungen auf diese (beiden) Threads aufgeteilt ist. Es kann z.B. sein, dass der übliche Game-Loop innerhalb des ersten Threads gemanaged wird, ein zweiter Thread die Soundausgabe macht und ein dritter auf Tastatureingaben reagiert.
Die Hauptlast bezüglich Berechnungen liegt hier trotzdem bei einem Thread, obwohl mehr als einer existiert.

Das hängt vom verwendeten Model ab. Ich gehe aber davon aus diese Model das du hier gerade beschrieben hast in nächster Zeit am häuftigsten zum Einsatz kommen wird. Die Physik ist auch noch ein Kanidat für einen eigenen Thread.

Ich bevorzuge ja bekanntermassen ein anderes Model.

[GloomY]

Das hängt vom verwendeten Model ab. Ich gehe aber davon aus diese Model das du hier gerade beschrieben hast in nächster Zeit am häuftigsten zum Einsatz kommen wird.Die Zukunft gehört den Multi-Cores. Mein "Modell" (besser: Beispiel) lässt sich ziemlich schlecht auf mehreren CPUs parallelisieren, weil die CPU-limitierten Aufgaben trotz Aufteilung immer noch ein Thread alleine abarbeiten muss.
Die Physik ist auch noch ein Kanidat für einen eigenen Thread.Sicher. :)
Ich bevorzuge ja bekanntermassen ein anderes Model.Äh ja? Welches denn?

btw: Wieso "bekanntermaßen"? Vielleicht sollte ich öfters mal ins Graka-Forum reinschauen...

[Demirug]

Äh ja? Welches denn?

btw: Wieso "bekanntermaßen"? Vielleicht sollte ich öfters mal ins Graka-Forum reinschauen...

Das Thema hatten wir hier vor kurzem schonmal. IIRC war es im Programmierung Forum.

Mein Modell baut auf der Idee der abhängigen Microjobs auf. Die Arbeit die normalerweise in einem großen Gameloop abläuft wird in viele kleine Jobs aufgeteilt. Davon könten in der Regel viele gleichzeitig ausgeführt werden. Ein Beispiel sind die KI Berechnungen für einzelne Computergegner. Ebenso kann ich gleichzeitig nach den hörbaren Tonquellen und den sichtbaren Objekte suchen.Allerdings beides erst nachdem die Weltdaten aktualisiert sind. Deswegen auch "abhängige" Jobs.

Um die vorhande Recheneleistung zu nutzen lässt man dann auf jeder CPU genau einen Thread laufen. Diese Threads hollen sich die Jobs aus einer Liste und arbeiten sie ab. Das ganze braucht nur wenig Syncronisation und funktioniert ganz gut.

[Adam D.]

Auch wenn's hier jetzt nicht unbedingt reingehört: Ich würde jetzt gerne (endlich) mal wissen, ob es sich für mich - jemanden, der viel spielt, jedoch auch viel arbeitet - lohnt, Ende des Jahres auf DC umzusteigen? Momentan hab ich 'nen gammeligen XP2800+ drin.

Bitte um Verzeihung für OT :redface:

[mrdigital]

Demirug, meinst Du, dass es wirklich erfizienter ist, das Job Scheduling selbst zu machen?

[Demirug]

Demirug, meinst Du, dass es wirklich erfizienter ist, das Job Scheduling selbst zu machen?

Ich glaube es nicht nur ich weiß es sogar.

Selbst Microsoft rät bei diesem Anwendungsshema zur Verwendung eines Threadpools. Die fertigen Funktionen dafür habe ich nur nicht benutzt weil sie von der Ausrichtung her eher auf Jobs mit I/O Funktionen ausgelegt sind. Der Pool hat also mehr Threads als CPUs vorhanden sind. Für eine Spieleanwendung ist das aber eher schlecht.

Das Scheduling läuft bei der von mir verwendeten Art vollständig im User Bereich ab. Dadurch können Threads ihere Quota immer voll ausnutzen. Da zudem jeder Thread fest an einen Kern gebunden wird vermeide ich auch das sie sich gegenseitig eine CPU wegnehmen. Der einzige Overhead der entsteht ist der das die Jobs aus einer Liste geholt werden müssen. Da auf diese Liste alle Threads zugreifen muss sie natürlich Syncronisiert werden. Dafür kommen aber CriticalSections zum einsatz die ebenfalls vollständig immer User Bereich abgewickelt werden können. Die Abhängigkeiten werden über einfaches Counting erledigt was auch sehr gering im Aufwand ist.

[mrdigital]

Wie bindest du einen Thread fest an eine bestimme CPU? (Huch das sind ja lauter Fragen im Telegrammstil ;))

[Demirug]

Wie bindest du einen Thread fest an eine bestimme CPU? (Huch das sind ja lauter Fragen im Telegrammstil ;))

Mit SetThreadAffinityMask.

[GloomY]

Um die vorhande Recheneleistung zu nutzen lässt man dann auf jeder CPU genau einen Thread laufen.Das Scheduling läuft bei der von mir verwendeten Art vollständig im User Bereich ab.Diese beiden Aussagen stehen imho in einem Widerspruch zueinander.

Entweder es sind Kernel-Level Threads, dann kann man diese auch auf mehreren CPUs parallel bearbeiten lassen, oder es sind reine User-Level Threads, von denen dann aber der Kern selbst nichts weiss.
Ich habe da noch grob in Erinnerung, dass es auch ein hybrides Modell gibt, aber das hat genau die gleichen Eigenschaften: Nur Threads, die auch vom Kern aus sichtbar sind, sind (echt) parallelisierbar und hierbei entscheidet der Kern nach seiner eigenen Scheduling-Strategie und nicht die des Programms. :|

[Demirug]

Diese beiden Aussagen stehen imho in einem Widerspruch zueinander.

Entweder es sind Kernel-Level Threads, dann kann man diese auch auf mehreren CPUs parallel bearbeiten lassen, oder es sind reine User-Level Threads, von denen dann aber der Kern selbst nichts weiss.
Ich habe da noch grob in Erinnerung, dass es auch ein hybrides Modell gibt, aber das hat genau die gleichen Eigenschaften: Nur Threads, die auch vom Kern aus sichtbar sind, sind (echt) parallelisierbar und hierbei entscheidet der Kern nach seiner eigenen Scheduling-Strategie und nicht die des Programms. :|

Ich meinte das Scheduling meiner Jobs. Die Threads welche diese Jobs abarbeiten sind natürlich reguläre Systemthreads und müssen sich die CPUs mit den Threads von anderen Anwendungen teilen. Es gibt aber wie gesagt nur einen solchen Thread pro CPU und dieser ist auch fest an eine CPU gebunden.

Dadurch verhindere ich das sich die Threads des Spiels um die CPUs streiten und dadurch unnötige Contextwechsel auslösen. Gleichzeitig kann ich aber eine beliebige Anzahl von CPUs nutzen.

[Neomi]

Diese beiden Aussagen stehen imho in einem Widerspruch zueinander.

Entweder es sind Kernel-Level Threads, dann kann man diese auch auf mehreren CPUs parallel bearbeiten lassen, oder es sind reine User-Level Threads, von denen dann aber der Kern selbst nichts weiss.

Ich sehe da keinen Widerspruch. Auf jeder CPU / jedem Kern wird ein Thread gestartet, der dann natürlich auch vom OS kontrolliert wird. Statt eine Aufgabe zu erledigen und sich dann selbst zu terminieren, holt sich ein Thread einfach einen Job nach dem anderen, bis alle abgearbeitet sind.

Startet man für jeden Job einen Thread, dann laufen je nach Anzahl der Jobs mehrere Threads auf einer CPU. Dadurch entsteht mehr Overhead und die Threads blockieren sich gegenseitig, wenn sie sich um gemeinsam genutzte Daten streiten.

Edit: oops, zu langsam. :D

[GloomY]

Ich meinte das Scheduling meiner Jobs. Die Threads welche diese Jobs abarbeiten sind natürlich reguläre Systemthreads und müssen sich die CPUs mit den Threads von anderen Anwendungen teilen. Es gibt aber wie gesagt nur einen solchen Thread pro CPU und dieser ist auch fest an eine CPU gebunden.Okay, dann ist's klar. Übrigends ist das eine recht interessante Idee =)

Wie groß ist der Overhead für die Kommmunikation was welcher Thread ausführen soll? Meinst du mit dem oben angesprochenen "Counting" den Einsatz von Semaphoren?
Dadurch verhindere ich das sich die Threads des Spiels um die CPUs streiten und dadurch unnötige Contextwechsel auslösen. Gleichzeitig kann ich aber eine beliebige Anzahl von CPUs nutzen.Kontextwechsel treten ja nur zwischen verschiedenen Adressräumen auf und deine Threads arbeiten ja alle im gleichen. :) Ich denke, du meinst dass du mit dem festen Binden der Threads an die CPUs die Cachelokalität (bei NUMAs dann natürlich auch den lokalen Speicher) besser nutzen kannst.

[zeckensack]

Kontextwechsel treten ja nur zwischen verschiedenen Adressräumen auf und deine Threads arbeiten ja alle im gleichen. :)Kontextwechsel treten immer auf wenn eine CPU auf einen anderen Thread wechselt. Auch wenn diese Threads alle zum gleichen Prozess gehören (was den gleichen Adressraum impliziert).
Ich denke, du meinst dass du mit dem festen Binden der Threads an die CPUs die Cachelokalität (bei NUMAs dann natürlich auch den lokalen Speicher) besser nutzen kannst.Auch richtig, aber nicht der einzige Grund.

[Demirug]

Okay, dann ist's klar. Übrigends ist das eine recht interessante Idee =)

Wie groß ist der Overhead für die Kommmunikation was welcher Thread ausführen soll? Meinst du mit dem oben angesprochenen "Counting" den Einsatz von Semaphoren?

Semaphoren sind viel zu teuer weil es Kernelobjekte sind und damit jeweils Kontextwechsel bei der Benutzung verursachen. Ich spreche von ganz einfachen Threadsicheren Counting mit Interlocks.

Es gibt da aber sowieo keine grosse Komunikation. Es gibt eine Liste mit den Jobs die ausgeführt werden. Jeder Job hat einen Waitcounter der immer dann um eins verringert wird nachdem ein Job auf den gewartet werden musste beendet ist. Ist der Counter bei 0 hängt sich der Job in die Liste.

Alles sehr einfach man muss aber etwas umdenken weil jetzt nicht mehr alles schön linear verläuft.

Kontextwechsel treten ja nur zwischen verschiedenen Adressräumen auf und deine Threads arbeiten ja alle im gleichen. :) Ich denke, du meinst dass du mit dem festen Binden der Threads an die CPUs die Cachelokalität (bei NUMAs dann natürlich auch den lokalen Speicher) besser nutzen kannst.

Es gibt viel mehr Kontextwechsel in einem System. Jedesmal wenn man vom User in den Kernelbereich geht gibt es einen Kontextwechsel. Das Umschalten der Threads kann nur der Kernel erledigen ausgeführt werden müssen sie aber primär im Userbereich.

[Demirug]

Auch richtig, aber nicht der einzige Grund.

Ja, bei der Zeitmessung wie lange ein Job braucht ist das auch von Vorteil. ;)

[zeckensack]

Ja, bei der Zeitmessung wie lange ein Job braucht ist das auch von Vorteil. ;)Das habe ich schon gelernt (http://www.beyond3d.com/forum/viewtopic.php?t=21106&start=20) :D

[GloomY]

Es gibt viel mehr Kontextwechsel in einem System. Jedesmal wenn man vom User in den Kernelbereich geht gibt es einen Kontextwechsel. Das Umschalten der Threads kann nur der Kernel erledigen ausgeführt werden müssen sie aber primär im Userbereich.Die CPU erhält ja periodisch ein Timer-Interrupt. Dabei wird für das Ausführen des Schedulers eh in den Kern gewechselt. Wo ist der Unterschied, nach diesem Wechsel auf einen anderen oder auf den gleichen Thread zu wechseln, der vorher schon lief? :conf2:
Register, PSW, IP und SP müssen so oder so neu geladen werden.

[Demirug]

Die CPU erhält ja periodisch ein Timer-Interrupt. Dabei wird für das Ausführen des Schedulers eh in den Kern gewechselt. Wo ist der Unterschied, nach diesem Wechsel auf einen anderen oder auf den gleichen Thread zu wechseln, der vorher schon lief? :conf2:
Register, PSW, IP und SP müssen so oder so neu geladen werden.

Interrupt Routinen sind ja eine eigene Welt. IIRC wird da nur ein Bruchteil der Register gesichert. Zudem müssen diese auch nur auf den Stack geschoben werden. Bei einem vollständige Threadwechsel läuft schon mehr ab. Der Timer ist aber gar nicht mal so sehr das Problem. Dieser schlägt ja nur zu um das erreichen der Quota zu überwachen. Es sind die vielen Punkte im System die einen Threadwechsel verursachen weil man eben eine Threadsichere Systemfunktion aufgerufen hat. Mit steigender Anzahl von Threads steigt auch die Gefahr das man einen Threadwechsel auslösst.

Ansonsten führe ich hier einfach mal den Beweiss durch Experiment auf. Es wurde schon mehrfach nachgewiesen das man die höchste Leistung mit einem Thread pro CPU erreicht wenn es um reine Rechenaufgaben geht.

[BUGFIX]

Ansonsten führe ich hier einfach mal den Beweiss durch Experiment auf. Es wurde schon mehrfach nachgewiesen das man die höchste Leistung mit einem Thread pro CPU erreicht wenn es um reine Rechenaufgaben geht.

In wie weit ist das Abhängig von CPU-kenngrößen wie zum Beispiel Cache größe?
Wenn der eine Thread vollständig in den L1 reinpasst, dann führt jede vermehrung der Threads zwangsläufig zu Performanceverlust.
Ich meine damit, dass je mehr Threads pro CPU, desto größer die Wahrscheinlichkeit dass sich die Threads gegenseitig aus den Caches 'rauswerfen' , und das deswegen die Performance am Besten ist, wenn mit nur einem Thread pro CPU gefahren wird.

Sollte ich hier einem Fehler aufsitzen, bitte ich um Klarstellung.
Danke.

MfG

BUGFIX

[Demirug]

In wie weit ist das Abhängig von CPU-kenngrößen wie zum Beispiel Cache größe?
Wenn der eine Thread vollständig in den L1 reinpasst, dann führt jede vermehrung der Threads zwangsläufig zu Performanceverlust.
Ich meine damit, dass je mehr Threads pro CPU, desto größer die Wahrscheinlichkeit dass sich die Threads gegenseitig aus den Caches 'rauswerfen' , und das deswegen die Performance am Besten ist, wenn mit nur einem Thread pro CPU gefahren wird.

Sollte ich hier einem Fehler aufsitzen, bitte ich um Klarstellung.
Danke.

MfG

BUGFIX

Natürlich spielt der Cache da auch eine gewisse Rolle. Wenn weniger Threads laufen müssen steigt die wahrscheinlichkeit für Cachehits. Das hängt aber stark vom Datenset ab das man verwendet. Man kann ein Datenset für so einen Test auch so klein machen das der Cache keine Rolle mehr spielt.

[Trap]

OS-Threads sind nicht das was man eigentlich haben möchte. Die bieten zuviel an: Man kann Threads jederzeit unterbrechen und später fortsetzen. Das kostet sowohl performace als auch Platz. Außerdem sind sie Kernelressourcen was sie nochmal teurer macht.

Die einzige Funktion die man wirklich haben will ist, dass man unabhängige Berechnungen von den verschiedenen Kernen parallel bearbeiten lassen möchte.

Die Lösung mit worker-threads und workunits ist viel näher an dem was man eigentlich möchte.

[Demirug]

OS-Threads sind nicht das was man eigentlich haben möchte. Die bieten zuviel an: Man kann Threads jederzeit unterbrechen und später fortsetzen. Das kostet sowohl performace als auch Platz. Außerdem sind sie Kernelressourcen was sie nochmal teurer macht.

Die einzige Funktion die man wirklich haben will ist, dass man unabhängige Berechnungen von den verschiedenen Kernen parallel bearbeiten lassen möchte.

Die Lösung mit worker-threads und workunits ist viel näher an dem was man eigentlich möchte.

Richtig, OpenMP arbeitet ja nach diesem Prinzip. Letzten Endes ist aber ein Thread nun mal die einzige Möglichkeit um die Arbeit auf mehrer Kerne zu verteilen auch wenn man es hinter sowas wie OpenMP versteckt.

Achja ich habe zwei Spiele aufgetrieben die Multicore nutzen:

Race Driver 3: Das Effektsystem (Wetter, Rauch, ...) kann auf der zweite CPU laufen

Conflict Vietnam: Wenn eine zweite CPU (oder HT) vorhanden ist werden dort für den Himmel dynamische Texturen berrechnet.

[schmid0r]

sorry daß ich zu eurem fach-chinesisch nichts beitragen kann ;)

ich hab ne ganz einfache frage: ist es möglich programme, durch mehr oder weniger große patches, multithreading-fähig zu machen? oder müssen diese von vorneherein darauf ausgelegt sein?

[Demirug]

sorry daß ich zu eurem fach-chinesisch nichts beitragen kann ;)

ich hab ne ganz einfache frage: ist es möglich programme, durch mehr oder weniger große patches, multithreading-fähig zu machen? oder müssen diese von vorneherein darauf ausgelegt sein?

Man kann auch nachträglich noch auf Multithreading umsteigen. OpenMP ist zum Beispiel sehr gut geeignet um nachträglich noch Multithreading einzubauen. Allerdings braucht man dafür einen passenden Compiler.

[schmid0r]

oho.. heißt das, daß es zu umständlich ist?
hm.. also wenn der aufwand nicht groß wäre, dann könnte man doch erwarten, daß einige sehr cpu-lastige spiele/programme multithreading noch nachträglich einführen..
schließlich haben einige alte spiele auch nachträglich den 3d-hardware support spendiert bekommen.

[Neomi]

hm.. also wenn der aufwand nicht groß wäre, dann könnte man doch erwarten, daß einige sehr cpu-lastige spiele/programme multithreading noch nachträglich einführen..

Kommt immer drauf an, was das jeweilige Spiel berechnet und wie die Berechnungen voneinander abhängig sind. Nicht alles ist parallelisierbar. Dazu kommt noch, daß je nach Programmaufbau eine nachträgliche Erweiterung teils deutlich schwieriger sein kann als eine Neuentwicklung, die natürlich länger braucht.

[Demirug]

oho.. heißt das, daß es zu umständlich ist?
hm.. also wenn der aufwand nicht groß wäre, dann könnte man doch erwarten, daß einige sehr cpu-lastige spiele/programme multithreading noch nachträglich einführen..
schließlich haben einige alte spiele auch nachträglich den 3d-hardware support spendiert bekommen.

Wie gesagt für bestehende Programme würde ich das nur mit OpenMP machen. OpenMP selbst ist recht einfach einzubauen. Allerdings muss man im Code immer noch die Stellen suchen wo es sich lohnt die Arbeit auf den zweiten Core umzulegen. Den Vorteil das die Verteilung mit OpenMP automatisch geht nachdem man im Programmcode die Stellen entsprechend makiert hat erkauft man sich allerdings damit das der Code bestimmten Ansprüchen genügen muss damit er dann auch wirklich verteilt ausgeführt wird.

[schmid0r]

hm.. kenn mich da nicht wirklich aus ;)

meine hoffnung ist halt, daß bei sehr anspruchsvollen, aber nicht auf dualcore und multithreading ausgelegten programmen der performance-einbruch aufgrund der niedrigeren taktrate eines einzelnen kerns durch nachträgliche implementierung von multithreading aufgefangen bzw. sogar in einen performance-schub umgewandelt wird.

bedenkt man, daß aktuelle spiele die aktuellen singlecores ganz schön ins schwitzen bringen können, bringen sie, solange sie nicht darauf optimiert sind, wegen der zunächst niedrigeren taktrate erst recht dualcores ins schwitzen.. bis dualcores dann die taktrate von momentanen singlecores erreicht haben, vergeht noch eine weile.. wobei man dann im vergleich zu heute für diese programme noch gar keinen performance fortschritt gemacht hätte.. das wär doch blöd :( .. vor allem wenn die programme noch n bißchen leistung gebrauchen könnten..
ich stell mir gerade vor, daß auf einem dualcore unreal3 besser laufen könnte, als hl2..

[Leonidas]

Auch wenn's hier jetzt nicht unbedingt reingehört: Ich würde jetzt gerne (endlich) mal wissen, ob es sich für mich - jemanden, der viel spielt, jedoch auch viel arbeitet - lohnt, Ende des Jahres auf DC umzusteigen? Momentan hab ich 'nen gammeligen XP2800+ drin.



Eigentlich nein. Wenn Du die Zeit hast, würde ich auf Anfang 2006 warten, dann kommt der 65nm Nachfolger Presler (mit mehr Takt und weniger Verlustleistung) und auch AMD wird dann das Thema DualCore im Desktop stärker forcieren. Wirklich lohnen dürfte es sich noch nicht, aber wenn man schon mal umsteigt und der Takt- und Preisunterschied zu SingleCore gering ist, dann kann man es machen.

Sollten sich allerdings hohe Takt- und Preisunterschiede ergeben, würde ich abwarten. Ich erwarte allerdings, daß beide CPU-Hersteller die DualCores gern in den Markt drücken werden und somit beim Preis wie beim Takt entsprechend reagieren werden.

[GloomY]

Interrupt Routinen sind ja eine eigene Welt. IIRC wird da nur ein Bruchteil der Register gesichert. Zudem müssen diese auch nur auf den Stack geschoben werden. Bei einem vollständige Threadwechsel läuft schon mehr ab.Was denn genau? Alle Register statt nur ein paar?

Mangelns Wissen kann ich hierzu nur spekulieren, aber ich habe zumindest gehört, dass bei einigen Architekturen die Register (d.h. alle) automatisch auf den Stack gepushed werden, wenn ein Interrupt ausgelöst wird. Das ist aber wohl von Hardware zu Hardware unterschiedlich.
Der Timer ist aber gar nicht mal so sehr das Problem. Dieser schlägt ja nur zu um das erreichen der Quota zu überwachen. Es sind die vielen Punkte im System die einen Threadwechsel verursachen weil man eben eine Threadsichere Systemfunktion aufgerufen hat. Mit steigender Anzahl von Threads steigt auch die Gefahr das man einen Threadwechsel auslösst.Hilf' mir etwas auf die Sprünge. Was meinst du mit "threadsicher"? Dass beim Aufrfen einer Systemfunktion nicht der Thread gewechselt wird?
Ansonsten führe ich hier einfach mal den Beweiss durch Experiment auf. Es wurde schon mehrfach nachgewiesen das man die höchste Leistung mit einem Thread pro CPU erreicht wenn es um reine Rechenaufgaben geht.Ich sagte ja bereits zuvor, dass die Hitrate der Caches natürlich davon profitiert, wenn auf einer CPU immer der gleiche Thread läuft (genauso der lokale Speicher bei NUMA). Dass dadurch Threadwechsel teurer werden, ist somit klar. Da sind wir uns ja alle einig :)
Es ging mir aber eigentlich nur um die Frage, ob abgesehen von Einflüssen der Speicherzugriffs-Geschwindigkeit der Wechsel an sich teurer ist (und wenn ja warum).

btw: Ich erinnere mich an OpenMP nur ganz schwach (habe mich nurmal damit eine halbe Stunde beschäftigt). Im Prinzip ist das doch nur das Setzen von Direktiven, was wo und wie parallelisiert werden kann oder sollte. Wie effizient ist das im Vergleich dazu, wenn man sich selbst als Programmierer um Thread-Erzeugung/Zerstörung, Synchronisation uvm. kümmert?

[DocEW]

Interessante Diskussion, der ich teilweise folgen kann, teilweise auch nicht. ;)

Demirug, eine Frage: Geht dein Modell so weit, daß quasi das komplette "Timing" des Spiels durch die Abhängigkeiten der Jobs voneinander modelliert wird?

[Demirug]

Was denn genau? Alle Register statt nur ein paar?

In Treiber und besonders in Interrupt Routinen íst beim Umgang mit allen FP Registern besondere Vorsicht von nönten.

Mangelns Wissen kann ich hierzu nur spekulieren, aber ich habe zumindest gehört, dass bei einigen Architekturen die Register (d.h. alle) automatisch auf den Stack gepushed werden, wenn ein Interrupt ausgelöst wird. Das ist aber wohl von Hardware zu Hardware unterschiedlich.

X86 sichert gar nicht. Da wird nur der hinterlegte Vektor angesprungen. Das Ziel ist dann dafür verantwortlich die Register zu sichern die es verändert.

Hilf' mir etwas auf die Sprünge. Was meinst du mit "threadsicher"? Dass beim Aufrfen einer Systemfunktion nicht der Thread gewechselt wird?

Threadsicher sind funktionen die bedenkenloss von mehr als einem Thread gleichzeitig aufgerufen werden können. Wenn eine solche Funktion nun auf eine globale Resource zugreifen muß bleibt es nicht aus das sie auf ein Syncronisations Objekt zurückgreifen muß. An dieser Stelle kann es dann zu Threadwechsel kommen.

Ich sagte ja bereits zuvor, dass die Hitrate der Caches natürlich davon profitiert, wenn auf einer CPU immer der gleiche Thread läuft (genauso der lokale Speicher bei NUMA). Dass dadurch Threadwechsel teurer werden, ist somit klar. Da sind wir uns ja alle einig :)
Es ging mir aber eigentlich nur um die Frage, ob abgesehen von Einflüssen der Speicherzugriffs-Geschwindigkeit der Wechsel an sich teurer ist (und wenn ja warum).

Er ist teuer weil er sich nicht von aleine durchführt sondern die CPU etwas dafür tun muss. Die Taktzyklen die dabei verbraten werden fehlen mir dann beim rechnen.

btw: Ich erinnere mich an OpenMP nur ganz schwach (habe mich nurmal damit eine halbe Stunde beschäftigt). Im Prinzip ist das doch nur das Setzen von Direktiven, was wo und wie parallelisiert werden kann oder sollte. Wie effizient ist das im Vergleich dazu, wenn man sich selbst als Programmierer um Thread-Erzeugung/Zerstörung, Synchronisation uvm. kümmert?

In einer Idealen Situation würde es keinen Unterschied machen. In einem Spiel wird der zweite Core aber bei der Verwendung von OpenMP über lange strecken nichts zu tun haben.

[Demirug]

Interessante Diskussion, der ich teilweise folgen kann, teilweise auch nicht. ;)

Demirug, eine Frage: Geht dein Modell so weit, daß quasi das komplette "Timing" des Spiels durch die Abhängigkeiten der Jobs voneinander modelliert wird?

Ich bin mir nicht sicher die Frage richtig verstanden zu haben. Nachdem das System jedoch gestartet ist läuft alles nur noch über die Jobs ab.

[BS-Virus]

Hallo :)

Ist das OpenMP auf alle Arten von Programmierung anwendbar oder bezieht sich das in irgendeiner Weise auf OpenGL? :confused:
Sorry für die vielleicht blöde Frage, aber ich bin in Sachen Programmierung nicht einmal halb so sehr begabt wie ihr. :redface:


Grüße
v!

[marco42]

Hallo :)

Ist das OpenMP auf alle Arten von Programmierung anwendbar oder bezieht sich das in irgendeiner Weise auf OpenGL? :confused:
Sorry für die vielleicht blöde Frage, aber ich bin in Sachen Programmierung nicht einmal halb so sehr begabt wie ihr. :redface:


Grüße
v!

schau mal unter OpenMP (http://de.wikipedia.org/wiki/OpenMP) auf wikipedia nach. es hat auch nichts mit OpenGL zu tun(also nicht wie OpenML, OpenVG)

[BS-Virus]

Danke!! :)

[DocEW]

Ich bin mir nicht sicher die Frage richtig verstanden zu haben. Nachdem das System jedoch gestartet ist läuft alles nur noch über die Jobs ab.
Ja, genau das war die Frage. Also hast du auch Jobs für z.B. Usereingabe abwarten oder Jobs, die das Verhalten der KI regeln? Zum Beispiel einen Job, der darauf wartet das eine Tür vom Spieler geöffnet wird und dann ein KI-Script startet usw.? Cool. Ist ja quasi ein riesiges Netzwerk... managst du das mit MS-Projekt? ;)