Dual CPU bei spielen?

[Kollar]

ein anderer thread hat mich auf die idee gebracht. im prinzip teilt doch OSX die beiden CPUS auf, und vergibt die Tasks.

Es gibt auch Mac games, die für die velocity engine optimiert sind. Benutzen diese Spiele auch Dual Cpus effektiv? Also nutzen sie beide CPUs?

Gibt es games, die dieses tun?
Ich denke eigentlich nicht, da es dann schon recht peinlich wäre, dass einige CPUlastige Games auf einem Dual G5 nicht aus den pötten kommen (Portierung mal hin und her) im Vergleich zu einem Single AMD (z.B.).

Ich meine also nicht, dass man mit einer CPU spielen und mit der anderen surfen kann etc., sondern wirklich BEIDE CPUS mit einem Spiel.

Danke, das Interessiert mich eben. Und wenn das in der Tat nicht so üblich ist: warum? ist das so schwer oder würde das kaum etwas bringen, weil dann die Graka zu langsam wäre?

 

[ctopfel2]

Da Spiele primär für das Windows-OS entwickelt werden, und vielfach dann eine billig-Portierung auf den Mac erfahren, sind die wenigsten Spiele dual-CPU optimiert.

Ich denke wenn man die Tasks aufteilen würde, könnte man auf DUAL-CPU's geniale Sachen machen.. aber eben, das ist Wunschdenken

ctopfel

 

[NyenVanTok]

Wie Du schon geschrieben hast, übernimmt das Betriebsystem das Prozess-Scheduling. Es kümmert sich als OS X um die Prozesszuteilung an die Prozessoren. Somit werden beide Prozessoren verwendet. Wie ideal das nun ist, kann ich dir nicht sagen. Aber es werden beide verwendet.

Viele Grüße
NyenVanTok

 

[Kollar]

hm, das ist doch irgendwie jetzt ein widerspruch?

klar regelt dass OS die CPUs, so dass um beispiel eher beide 50% auslastung haben als eine 100% und die andere 0%. aber wenn ein spiel läuft werden wohl auch eher beide nur auf 50% laufen? (insgesamt steigt also die CPU anzeige nicht über 100% (obwohl 200% möglich sind).

das kann man ja zum beispiel bei einem entpacker gut sehen (letztens WOW)..
einige spiele werden doch auch von den teams selbst gemacht (doom3 z.B. oder Warcraft), ist es denn so schwer da etwas zu "basteln" eine CPU Management Biblio wirds doch sicherlich geben von Apple?

Schade eigentlich

 

[pks85]

Die Quake3 Engine nutzt AFAIK beide CPUS - zumindest und WIndows/Linux (x86).

 

[NyenVanTok]

@Kollar: Nene,

da hast Du eine falsche Vorstellung. Die Spiele bekommen ja ihre CPU Zeit zugeteilt. Und die nehmen gern alles was sie kriegen können!

Bei 3D-Shootern äussert sich das gern in z.B. höherer Frame-Rate...

Ich glaub' heut zu Tage gibts kaum noch spiele, die sich mit weniger als dem Maximum zufrieden geben. Falls doch: Ja, dann hast Du halt eine geringere Auslastung als je 100%... Aber wie gesagt: Bei den aktuellen Spielen ist das eher nicht zu erwarten

Viele Grüße
NyenVanTok

 

[Domino]

hmm. bin kein programmierer; aber wenn es so einfach wär dann gäbs sicher auch viel bessere portierungen, die mindestens alle blizzard-standard haben

aber 1. sind wohl die wenigsten spiele beim pc darauf ausgelegt (ich kenne jetzt auf anhieb keins)

2. sollte bei den g5-towern nicht der prozessor das prob sein - eher die graka. ram ist auch wichtiger als ein zweiter prozessor - sag ich mal so.

also erstmal anständig den prog-code schreiben (hier ist meistens schon alles vorbei), dann ordentlich ram zur verfügung und eine fixe grafikkarte haben (was bei den g5-towern ja leider nicht der fall ist)

ein g5 reicht sicher für die derzeitigen games aus.

Gn8

 

[cla]

Das Problem bei Mehrprozessorsystemen ist, das nur paralellisierbare Rechenoperationen auf mehrere Prozessoren aufgeteilt werden können. Da diese selten zum gewollten Zeitpunkt mit der Berechnung fertig sind, können entweder nur unabhängige Rechenoperationen aufgeteilt werden, oder ein Prozessor muss auf den anderen Warten.
Das Aufteilen von CPU-Last auf verschiedene CPUs funktioniert also wunderschön, wenn es UNTERSCHIEDLICHE Programme sind (funktioniert mit jedem Programm), oder wenn die Programme so geschrieben worden sind, das die Arbeit aufgeteilt werden KANN (ist nur bei speziell angepassten Programmen der Fall).

Bei Spielen läßt sich das aber sehr schwer umsetzen, da meist alle Berechnungen zeitgebunden fertig werden müssen, und auch relativ wenig Berechnungen wirklich parallel durchgeführt werden können.

cla

 

[NyenVanTok]

hmm. bin kein programmierer; aber wenn es so einfach wär dann gäbs sicher auch viel bessere portierungen

Nein, denn

2. sollte bei den g5-towern nicht der prozessor das prob sein

CPU-Power ist eben nicht alles. OS X verwendet ja z.B. eine ganz andere System-API. Eine andere Grafik- und Sound- Umgebung etc. Rundum: Eine andersartige Software-Architektur.

Hier muss üblicherweise einiges angepasst werden. Wenn man das nicht effizient macht, nützt Dir auch die schnelle CPU nichts... Und gerade bei 3D-Engines kann man viel optimieren und auch einiges an die Grafik-Prozessoren abgeben.

Viele Grüße
NyenVanTok

 

[Domino]

@NyenVanTok
öhm. ja, das hab ich ja auch so gemeint. vielleicht war es ja zu unverständlich geschrieben.

 

[oneOeight]

Das Problem bei Mehrprozessorsystemen ist, das nur paralellisierbare Rechenoperationen auf mehrere Prozessoren aufgeteilt werden können. Da diese selten zum gewollten Zeitpunkt mit der Berechnung fertig sind, können entweder nur unabhängige Rechenoperationen aufgeteilt werden, oder ein Prozessor muss auf den anderen Warten.

nicht unbedingt, es reicht ja schon wenn das programm threaded. dann kann man die verschiedenen threads auf die cpus verteilen...
und synchronisieren kann man threads auch...

aber meistens begnügen sich die programmier nur damit, die grafik vom sound zu trennen und die dann zu verteilen...

 

[oneOeight]

einige spiele werden doch auch von den teams selbst gemacht (doom3 z.B. oder Warcraft), ist es denn so schwer da etwas zu "basteln" eine CPU Management Biblio wirds doch sicherlich geben von Apple?

os x hat symmetrisches multiprozessing, die einzelnen cpus wählen selbst ihre prozesse...

 

[Gero]

Die Spiele müssen konkret für zwei Prozessoren geschrieben sein, um sie zu unterstützen. Quake 3 tut das, aber nur unter OS 9. Unter OS X nutzt es ebenfalls nur einen Prozessor, allerdings liegen dann sämtliche Hintergrundprozesse auf dem zweiten Prozi. Einziges mir bekanntes Beispiel für die Nutzung des zweiten Prozessors ist UT2k4 - dort wird mit einem nachträglichen Patch die Soundgenerierung auf die zweite CPU gelegt, während der Rest des Spiels auf der ersten CPU läuft.

 

[NyenVanTok]

nicht unbedingt, es reicht ja schon wenn das programm threaded. dann kann man die verschiedenen threads auf die cpus verteilen...
und synchronisieren kann man threads auch...

Das stimmt nicht so ganz. OS X und Windows können -zumindest meines Wissens nach- nur verschiedene Prozesse auf die CPUs verteilen.

Das Problem vom Threads ist, dass sie den selben Adressraum eines einzigen Prozesses verwenden. Wenn nun zwei Threads auf zwei CPUs laufen, muss sichergestellt sein, dass beide auf diesen Adressraum zugreifen können.

Bei der Verteilung von Prozessen auf verschiedene CPUs ist das Problem nicht so groß, da die Prozesse ihre eigenen Adressräume haben.

Viele Grüße
NyenVanTOk

PS: Theoretisch ist es mit Synchronisation und Prozessaufteilung trotzdem Möglich ein Programm entsprechend zu zerteilen. Bei Strategiespielen könnte ich mir selbiges z.B. gut vorstellen. Aber um auf die Portierung zurückzukommen: Ein solches Optimieren ist sicher aufwendig und damit teuer.

 

[oneOeight]

Das stimmt nicht so ganz. Die einzige Architektur die mir bekannt ist, die verschiedene Threads eines Prozesses auf mehrere CPUs verteilen kann, kommt von SUN. OS X und Windows können -zumindest meines Wissens nach- nur verschiedene Prozesse auf die CPUs verteilen.

Das Problem vom Threads ist, dass sie den selben Adressraum eines einzigen Prozesses verwenden. Wenn nun zwei Threads auf zwei CPUs laufen, muss sichergestellt sein, dass beide auf diesen Adressraum zugreifen können.

dir ist schon klar, dass beide cpus auf den gleichen hauptspeicher zugreifen?

 

[NyenVanTok]

dir ist schon klar, dass beide cpus auf den gleichen hauptspeicher zugreifen?

"dir ist schon klar..." - oh man...

Und hast Du dir mal Gedanken über die Nebenläufigkeiten gemacht, wenn auf einmal beide CPUs gleichzeitig (!) im selben Adressraum (eines Prozesses) lesen/schreiben? Und das tun sie... da der Adressraum zweier Threads (eines Prozesses) jeweils der Adressraum des Prozesses ist.

Und wie sieht es mit den ganzen Prozess-Parametern aus, die in die Register der CPU geladen werden?

Und welche Speicher-Seiten werden nun vom OS eigentlich gesperrt? Wenn überhaupt?

Was ist mit den Daten die im Cache liegen? Nützt der Cache dann überhaupt noch etwas?

Was ist damit?


Viele Grüße
NyenVanTok

 

[oneOeight]

Und hast Du dir mal Gedanken über die Nebenläufigkeiten gemacht, wenn auf einmal beide CPUs gleichzeitig (!) im selben Adressraum (eines Prozesses) lesen/schreiben? Und das tun sie... da der Adressraum zweier Threads (eines Prozesses) jeweils der Adressraum des Prozesses ist.

eine thread implementierung setzt nun mal voraus, dass die nebenläufigkeit beachtet wird. die leute, die multi threaded prozess-scheduler programmieren haben normalerweise alle schon operating system concepts gelesen, und kennen das readers/writers problem, deadlocks, monitore und semaphoren...
und wo ist jetzt das problem? schreibst du programme, die nur globale variablen haben, deren threads alle gleichzeitig ungesichert auf eine globale variable zugreifen und die verändern?

Und wie sieht es mit den ganzen Prozess-Parametern aus, die in die Register der CPU geladen werden?

ja und? was soll damit sein? der scheduler lädt ständig bei jedem wechsel die register neu. ein thread hat auch einen kontext, und verändert nicht zwangsläufig den größeren kontext des prozesses...

irgendwie vermischt du prozess scheduling mit thread programmierug

 

[NyenVanTok]

@oneOeight: Jip hast recht. Hab' mich verrant. Weißt Du denn (sicher) dass OS X auch einzelne Threads auf beide CPUs verteilt, oder eben nur Prozesse?

Viele Grüße
NyenVanTok

 

[oneOeight]

@oneOeight: Jip hast recht. Hab' mich verrant. Weißt Du denn (sicher) dass OS X auch einzelne Threads auf beide CPUs verteilt, oder eben nur Prozesse?

hab da auf die schnelle bei google nichts gefunden.
müsste man mal die ganzen xnu mach und bsd 4.4 dokus durchgucken...