Core zusammenzählen?!

[=Floi=]

Hallo

es wurde zwar schon so oft gesagt man kann die Mhz nicht zusammenzählen bei dual oder quad core aber irgendwo kann man es doch machen bei bestimmten anwendungen

es gibt genug sachen die gut paralelisierbar sind und deshalb sehr gut mit den core skalieren
gleiches würde doch auch bei einer anhebung der mhz passieren

sicherlich gehören spiele nicht dazu aber wie oben gesagt gibt es genug andere anwendungen die gut skalieren

[Lightning]

Sicher, in solchen Anwendungen kannst du sagen: Ein Athlon64 X2 mit 3 GHz ist so schnell wie ein (fiktiver) Athlon 64 mit 6 GHz.

Zusammenzählen kannst du die MHz bei einer Multicore-CPU trotzdem nicht. Hertz ist eine physikalische Einheit. Wenn alle Cores mit 3 GHz takten, dann takten sie auch alle mit 3 GHz und nicht zusammengezählt mit 6 GHz, das wäre einfach unsinn.

Gleiches gilt auch für die veroppelnde zählweise, die manchmal bei DDR-RAM angewendet wird. Das ist einfach falsch.

[dargo]

Sicher, in solchen Anwendungen kannst du sagen: Ein Athlon64 X2 mit 3 GHz ist so schnell wie ein (fiktiver) Athlon 64 mit 6 GHz.

In welchen Anwendungen? :)

[Lightning]

In welchen Anwendungen? :)

Bei allem, was sich eben problemlos parallelisieren lässt. Nimm z.B. ein Schachprogramm.

[ESAD]

nun ja wirklich zusammezählen lässt es sich nicht da das backend sich nicht verdoppelt was für wirklich 100% mehrleistung benötigt werden würde...

[Spasstiger]

Man wird mit der Vervielfachung des angegebenen Taktes auch dem Latenzverhalten nicht gerecht. Man erwartet bei einem 6-GHz-Prozessor, dass ein Befehl 167 Pikosekunden in einer Pipelinestufe verweilt. Tatsächlich sinds aber 333 Pikosekunden, wenn es sich eigentlich um einen Dual-Core-Prozessor mit 3 GHz handelt.

Bei Ebay ist diese Unsitte der Taktvervielfachung ja leider Gang und Gebe, sogar vor einem "9,6-GHz"-Prozessor (Q6600) wird da nicht zurückgeschreckt. Naja, die Preise sind trotzdem im Rahmen und irgendwo ist auch immer der reale Prozessorname angegeben, die Verkäufer haben also nichts zu befürchten mit ihrer Masche.

[dargo]

Bei allem, was sich eben problemlos parallelisieren lässt. Nimm z.B. ein Schachprogramm.
Was sagst du dazu? :D

DIRT:

C2D@Singlecore@2133Mhz = ~18fps
C2D@Dualcore@2133Mhz = ~36fps
C2D@Singlecore@3300Mhz = ~43fps

[Lightning]

Was sagst du dazu? :D

DIRT:

C2D@Singlecore@2133Mhz = ~18fps
C2D@Dualcore@2133Mhz = ~36fps
C2D@Singlecore@3300Mhz = ~43fps

Dazu sage ich: WTF?! ;)
Wie kann aus 55% mehr Takt 140% mehr Leistung folgen? Da ist was faul.

[dargo]

Dazu sage ich: WTF?! ;)
Wie kann aus 55% mehr Takt 140% mehr Leistung folgen? Da ist was faul.
Hehe, eben nicht! DIRT skaliert mit mehr Takt deutlich mehr als 1:1 mit. :)

Bei Supreme Commander ist es noch extremer:
http://www.3dcenter.de/artikel/2007/06-25_c.php

Madkiller hat das mal sehr schön und plausibel erklärt. Für bestimmte Aufgaben (zb. Physik, KI, Sound) braucht man einen Grundtakt.

Nehmen wir zb. einen C2D mit 2Ghz:

500Mhz für Physik
300Mhz für KI
1200Mhz für den Rest

Wenn du jetzt einen C2D mit 3Ghz nimmst änderst sich nichts am Grundbedarf der Physik und KI, also:

500Mhz für Physik
300Mhz für KI
2200Mhz für den Rest

Wir haben in diesem Fall den CPU-Takt zwar um 50% erhöht, für die Frames stehen aber ~83% mehr CPU-Takt zur Verfügung.
Je mehr Aufgaben (oder diese Aufgaben stärker die CPU belasten) ein Spiel verwendet welches einen Grundtakt vorraussetzt um so mehr sollte diese Anwendung als 1:1 bei höherem Takt skalieren.

Edit:
Nach der Skalierung von DIRT in meiner getesteten Szene wird es in etwa so aussehen.

2Ghz C2D@Singlecore:
Physik + KI + Onboardsound = 1400Mhz
Rest = 600Mhz

3Ghz C2D@Singlecore:
Physik + KI + Onboardsound = 1400Mhz
Rest = 1600Mhz

Damit kriegst du ungefähr eine Skalierung von 1:2,7 hin. :)

[=Floi=]

klingt plausibel aber warum skaliert dann SC zu DC zu fast 100%?

habe ich hier nen denkfehler oder wechselselt dirt sicht mit den cpus pro frame ab?

bench mal bitte dirt @ dc mit 3300mhz
damit solltest du doch dann auf ca 85fps kommen

[Lightning]

Hehe, eben nicht! DIRT skaliert mit mehr Takt deutlich mehr als 1:1 mit. :)

Bei Supreme Commander ist es noch extremer:
http://www.3dcenter.de/artikel/2007/06-25_c.php

Madkiller hat das mal sehr schön und plausibel erklärt. Für bestimmte Aufgaben (zb. Physik, KI) braucht man einen Grundtakt.

Nehmen wir zb. einen C2D mit 2Ghz:

500Mhz für Physik
300Mhz für KI
1200Mhz für den Rest

Wenn du jetzt einen C2D mit 3Ghz nimmst änderst sich nichts am Grundbedarf der Physik und KI, also:

500Mhz für Physik
300Mhz für KI
2200Mhz für den Rest

Wir haben in diesem Fall den CPU-Takt zwar um 50% erhöht, für die Frames stehen aber ~83% mehr CPU-Takt zur Verfügung.
Je mehr Aufgaben (oder diese Aufgaben stärker die CPU belasten) ein Spiel verwendet welches einen Grundtakt vorraussetzt um so mehr sollte diese Anwendung als 1:1 bei höherem Takt skalieren.

Edit:
Nach der Skalierung von DIRT in meiner getesteten Szene wird es in etwa so aussehen.

2Ghz C2D@Singlecore:
Physik und KI = 1400Mhz
Rest = 600Mhz

3Ghz C2D@Singlecore:
Physik und KI = 1400Mhz
Rest = 1600Mhz

Damit kriegst du ungefähr eine Skalierung von 1:2,7 hin. :)

Das ist sehr interessant, so habe ich noch gar nicht gedacht. Normalerweise rechnet die CPU ja alles so schnell, wie es eben geht. In diesem Fall erkennt die Engine aber, ab wann die Leistung für z.B. die Physikberechnung ausreicht und teilt dem Rest dann selbstständig mehr Rechenleistung zu, habe ich das so richtig verstanden?

Wenn das in Zukunft in mehreren Engines so verwaltet wird (in fast allen bisherigen konnte man das iirc nicht so beobachten, oder wo liegt sonst der Grund?), verkompliziert das den Sachverhalt natürlich recht erheblich. Vor allem was das Abschätzen von Ergebnissen angeht.

[Spasstiger]

Nehmen wir zb. einen C2D mit 2Ghz:

500Mhz für Physik
300Mhz für KI
1200Mhz für den Rest
Soll das heißen, dass das Grafikrendering komplett unabhängig von den KI- und den Physikberechnungen ist und evtl. Frames gerendert werden, die noch überhaupt keine Änderung durch Benutzereingaben, Physik oder KI erfahren haben? Wo dann quasi einfach mit den bestehenden Werten die neue Position errechnet wird?
Vielleicht liegt darin auch der Grund für das Input-Lag von Dirt.

Wie liegt eigentlich die Framerate bei einem schwächeren Prozessor, z.B. einem Pentium 4 2 GHz? Da dürfte ja gar nix mehr fürs Grafikrendering übrig bleiben oder die Nicht-Grafikroutinen laufen alle etwas langsamer/träger als normal.

[dargo]

bench mal bitte dirt @ dc mit 3300mhz
damit solltest du doch dann auf ca 85fps kommen
Das ist leider nicht so einfach. Dafür ist meine übertaktete G8800GTS@612/900Mhz schon in 640x480 ohne AA/AF zu langsam. X-D

Mit 3,3Ghz DC habe ich ~55fps. Dass mehr geht sieht man hier:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=5678654&postcount=12

[dargo]

Das ist sehr interessant, so habe ich noch gar nicht gedacht. Normalerweise rechnet die CPU ja alles so schnell, wie es eben geht. In diesem Fall erkennt die Engine aber, ab wann die Leistung für z.B. die Physikberechnung ausreicht und teilt dem Rest dann selbstständig mehr Rechenleistung zu, habe ich das so richtig verstanden?

Wenn das in Zukunft in mehreren Engines so verwaltet wird (in fast allen bisherigen konnte man das iirc nicht so beobachten, oder wo liegt sonst der Grund?), verkompliziert das den Sachverhalt natürlich recht erheblich. Vor allem was das Abschätzen von Ergebnissen angeht.
Ja, die CPU-Leistung in Games (Savegames!) ist ne Wissenschaft für sich. :D
Das würde bedeuten, dass User mit schnelleren CPUs automatisch schlauere KI Gegner, bessere Physik und besseren (schnelleren :D) Sound erhielten. Ich glaube, das möchte keiner. :wink:

[Lightning]

Ja, die CPU-Leistung in Games (Savegames!) ist ne Wissenschaft für sich. :D
Das würde bedeuten, dass User mit schnelleren CPUs automatisch schlauere KI Gegner, bessere Physik und besseren Sound erhielten. Ich glaube, das möchte keiner. :wink:

Äh, das hast du mich glaube ich missverstanden. "So schnell, wie es geht" impliziert natürlich, dass die CPU, je nachdem, wo das Limit liegt, mit der Berechnung auf andere Umstände warten muss (z.B. auf die Grafikkarte). In DiRT soll es aber nun so sein, dass diese Wartezeit entfällt und die Leistung stattdessen woanders zu Verfügung steht.

[dargo]

Äh, das hast du mich glaube ich missverstanden. "So schnell, wie es geht" impliziert natürlich, dass die CPU, je nachdem, wo das Limit liegt, mit der Berechnung auf andere Umstände warten muss (z.B. auf die Grafikkarte). In DiRT soll es aber nun so sein, dass diese Wartezeit entfällt und die Leistung stattdessen woanders zu Verfügung steht.
Jetzt verstehe ich dich nicht so ganz. Warum sollte die CPU bei Berechnung von Physik, KI etc. auf die Grafikkarte warten müssen? Außerdem, bei den Frames zwischen 18 und 43fps lag immer ein 100%-iges CPU-Limit vor. Wie gesagt, bei ~55fps verhindert meine Grafikkarte schon höhere Frameraten.

[Lightning]

Jetzt verstehe ich dich nicht so ganz. Warum sollte die CPU bei Berechnung von Physik, KI etc. auf die Grafikkarte warten müssen? Außerdem, bei den Frames zwischen 18 und 43fps lag immer ein 100%-iges CPU-Limit vor.

Weil das ganze ja synchronisiert werden muss. Die CPU kann ja nicht beliebig viele Frames im Vorraus berechnen, ohne, dass das Gesamtergebnis vom aktuellen Frame schon berechnet ist.

Das mit der Grafikkarte war nur ein Beispiel für etwas, auf was die CPU warten muss.


edit: Ansonsten kenne ich mich mit dem Thema allerdings viel zu wenig aus, um da wirklich Aussagen treffen zu können. Das obig geschriebene basiert größtenteils nur auf dem, was ich mir von der Logik her so vorstelle. Daher möchte ich mich erstmal nicht weiter im Detail zu dem Thema äußern, wir sind ja nicht im Spekulationsforum. :D Ich warte mal darauf, was unsere Gurus vielleicht noch beitragen können.

[dargo]

klingt plausibel aber warum skaliert dann SC zu DC zu fast 100%?

Weil die Anwendung eben mit einem Multicore sehr gut skaliert. Was ist daran so verwunderlich? :)

[dargo]

edit: Ansonsten kenne ich mich mit dem Thema allerdings viel zu wenig aus, um da wirklich Aussagen treffen zu können. Das obig geschriebene basiert größtenteils nur auf dem, was ich mir von der Logik her so vorstelle. Daher möchte ich mich erstmal nicht weiter im Detail zu dem Thema äußern, wir sind ja nicht im Spekulationsforum. :D Ich warte mal darauf, was unsere Gurus vielleicht noch beitragen können.
Da gehts dir genauso wie mir. :D
Ich bin auch kein Experte um zu sagen was da intern passiert. Ich kann dir höchstens das Endergebnis liefern. :D

Nur von der Behauptung, zb. ein E6850 wäre in jeder Hinsicht max. ~29% schneller als ein E6550 sollte man langsam Abschied nehmen. :)

[Spasstiger]

Nur von der Behauptung, zb. ein E6850 wäre in jeder Hinsicht max. ~29% schneller als ein E6550 sollte man langsam Abschied nehmen. :)
Nur weil die Framerate stärker als 100% skaliert, heißt das nicht, dass der Prozessor auf einmal auch soviel mehr rechnet.
Bei einem 29% höheren Takt kann der Prozessor auch nur 29% mehr rechnen.

Wir lernen daraus nur, dass die Framerate nicht immer ein guter Anhaltspunkt für die Leistung eines Prozessors ist. Im Falle von Dirt sind ja auch deutlich Mängel zu beobachten: Auch wenn die Framerate konstant gut ist, so wirkt das Handling immer noch träge und schwammig. Eingaben werden erst mit einer sichtbaren Verzögerung umgesetzt (hinzu kommt noch die künstliche, beabsichtigte Verzögerung dadurch, dass die eingeschränkte Reaktionszeit des virtuellen Piloten umgesetzt wird).

/EDIT: Mir kommt da gerade eine Idee: Warum nicht mal ein Benchmark, bei dem nur die gefühlte Spielbarkeit bewertet wird? Z.B. auf einer Schulnotenskala von 1 bis 6. Die fps sollen dabei komplett außer Acht gelassen werden, dafür sollten aber mehrere Tester mit unterschiedlichem Spielbarkeitsempfinden spielen. Wäre trotz grober Ungenauigkeiten praxisrelevanter als eine reine fps-Messung.

[ESAD]

die physik ist an die bildrate gebunden
der sound ist an feste zeiteinheiten gebunden

aber die ki? an was ist die gebunden denn eigentlich wäre es doch möglich z.b. wie bei blitzschach mit einer schnelleren cpu mehr züge in der gleichen zeiteinheit zu kalkuliren und dadurch wirklich eine schlauere ki zu erhalten?

[dargo]

Im Falle von Dirt sind ja auch deutlich Mängel zu beobachten: Auch wenn die Framerate konstant gut ist, so wirkt das Handling immer noch träge und schwammig. Eingaben werden erst mit einer sichtbaren Verzögerung umgesetzt (hinzu kommt noch die künstliche, beabsichtigte Verzögerung dadurch, dass die eingeschränkte Reaktionszeit des virtuellen Piloten umgesetzt wird).
Das ist nicht bei jedem Controller so. Aber was hat das jetzt mit dem Thema zu tun? :)

die physik ist an die bildrate gebunden

Woher weißt du das? Bzw. erkläre das bitte mal genauer. Ich sehe nämlich keinen Sinn darin.

aber die ki? an was ist die gebunden denn eigentlich wäre es doch möglich z.b. wie bei blitzschach mit einer schnelleren cpu mehr züge in der gleichen zeiteinheit zu kalkuliren und dadurch wirklich eine schlauere ki zu erhalten?
Das wäre zwar technisch ohne weiteres möglich. Ich glaube aber nicht, das die Spieleentwickler das so haben wollen. Ich stelle mir das gerade vor - mit einem C2D@2Ghz Schwierigkeitsgrad normal, mit 4Ghz super schwer. ;D

[Endorphine]

Die Taktraten von mehreren parallel arbeitenden CPUs zusammen zu rechnen ist generell Unsinn. Das impliziert, dass die Leistung auch bei der Abarbeitung von einzelnen Instruktionen oder nicht-parallelisierbaren Codeblöcken steigt, was aber nicht der Fall ist. Es steigt nur im besten Fall der Durchsatz des Gesamtsystems. Das selbe Phänomen wie bei Hyperthreading.

Was gibt's da groß zu diskutieren?

[Spasstiger]

Das ist nicht bei jedem Controller so. Aber was hat das jetzt mit dem Thema zu tun? :)
Wenn ein Input-Lag bedingt durch die Engine vorhanden ist, dann ist nunmal die Spielbarkeit eingeschränkt. Da ändert dann auch eine doppelt so hohe Framerate nix dran.
Ist das Input-Lag denn mit bestimmten Controllern nicht vorhanden?

Woher weißt du das? Bzw. erkläre das bitte mal genauer. Ich sehe nämlich keinen Sinn darin.
Naja, es kann ja sein, dass ein Spiel keine Threads verwendet, sondern einfach alle Programmteile sequentiell in einer Schleife abarbeitet. Erst die Eingaben, dann die Physik, dann die KI und das Gameplay, dann der Sound und zuletzt das Rendering. Und sollte die Grafikkarte beim Rendering-Schritt noch mit dem letzten Frame beschäftigt sein, muss die CPU eben warten.
Bei Dirt wird dagegen der Rendering-Thread offenbar so schnell abgearbeitet wie nur möglich, unabhängig davon, wie lange die Physik- oder KI-Berechnungen brauchen. Es kann zwar sein, dass der Rendering-Thread mal auf die Grafikkarte warten muss, die anderen Thread arbeiten aber trotzdem weiter, die CPU wird immer mit Arbeit versorgt.

[dargo]

Was gibt's da groß zu diskutieren?
Wie siehst du das? :)
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=5712815&postcount=7

[dargo]

Wenn ein Input-Lag bedingt durch die Engine vorhanden ist, dann ist nunmal die Spielbarkeit eingeschränkt.

Was macht dich hier so sicher? Ich habe noch keinen solchen Beweis in dieser Hinsicht gesehen/gelesen. :)


Ist das Input-Lag denn mit bestimmten Controllern nicht vorhanden?
Ich habe keinen Input-Lag bei der Tastatur. Bei meinem DFP ist er praktisch nicht zu merken (bei der Demo war das noch ganz anders). Aber hat nicht jeder Controller eine gewisse Verzögerung? Ich meine Madkiller hätte behauptet, beim G25 sind es auch einige ms.

Naja, es kann ja sein, dass ein Spiel keine Threads verwendet, sondern einfach alle Programmteile sequentiell in einer Schleife abarbeitet. Erst die Eingaben, dann die Physik, dann die KI und das Gameplay, dann der Sound und zuletzt das Rendering. Und sollte die Grafikkarte beim Rendering-Schritt noch mit dem letzten Frame beschäftigt sein, muss die CPU eben warten.
Bei Dirt wird dagegen der Rendering-Thread offenbar so schnell abgearbeitet wie nur möglich, unabhängig davon, wie lange die Physik- oder KI-Berechnungen brauchen.
Afaik verwendet DIRT bis zu 8 Threads.

[ESAD]

Woher weißt du das? Bzw. erkläre das bitte mal genauer. Ich sehe nämlich keinen Sinn darin.


es ist logisch es bringt nicht mehr physik zu berechnen wenn sie nicht dagesellt werden kann...

z.b. ich berechne einen ball der irgendwo runterfällt
was bringt es mir ausgerechnet zu haben wie der ball vom boden abprallt wenn ich gerade erstmal die halbe strecke des balls gezeigt habe? vorallem das die brechnungen unter umständen aufgrund von äußeren faktoren verworfen werden müssten..

[dargo]

es ist logisch es bringt nicht mehr physik zu berechnen wenn sie nicht dagesellt werden kann...

Das würde aber auf der anderen Seite bedeuten, dass zb. ein G8800GTX User mit einem C2D@4Ghz mehr Physik zu sehen/"fühlen" bekommt als ein G8600GT User mit einem C2D@2Ghz. Und das glaube ich nicht.

[Endorphine]

Wie siehst du das? :)
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=5712815&postcount=7 Ohne Einblick in den Code zu haben oder zumindest einen Entwickler darüber reden zu hören würde ich mich jetzt nicht aus dem Fenster lehnen, dort irgendetwas rein zu interpretieren.

Die Diskussion darum geht auch irgendwie am Thema "Taktfrequenzen von Multiprozessor-CPUs zusammenzählen" vorbei.

[Spasstiger]

Das würde aber auf der anderen Seite bedeuten, dass zb. ein G8800GTX User mit einem C2D@4Ghz mehr Physik zu sehen/"fühlen" bekommt als ein G8600GT User mit einem C2D@2Ghz. Und das glaube ich nicht.
Es würde schon Sinn machen, wenn die Physik bei einer höheren Framerate auch genauer arbeitet, zumindest im Singleplayer.
Und wenn man alle Programmteile stur sequentiell ohne geplante Wartepausen abarbeitet, dann ist es auch so. Jeder Schritt bei der Physikberechnung ist dann mit einem Frame auf dem Bildschirm verknüpft.
Ich kann mir jedenfalls gut vorstellen, dass bei einigen Konsolenspielen so gearbeitet wurde, die CPU ist dort ja immer gleich schnell.

[dargo]

Die Diskussion darum geht auch irgendwie am Thema "Taktfrequenzen von Multiprozessor-CPUs zusammenzählen" vorbei.
Ich sehe da schon einen Zusammenhang. :)

Ein Beispiel - womit bekomme ich mehr Frames bei DIRT wenn die Graka nicht limitiert?
Mit einem C2D Dualcore@3,6Ghz oder mit einem Kentsfield@2,66Ghz?

Ist gar nicht so einfach zu beantworten wenn ich mir die Skalierung mit mehr Taktrate und mehr Cores so anschaue.


Ich kann mir jedenfalls gut vorstellen, dass bei einigen Konsolenspielen so gearbeitet wurde, die CPU ist dort ja immer gleich schnell.
Ok, bei einer Hardwarebasis macht das durchaus Sinn. :)

[Gast]

Ist doch ganz einfach ich habe jetzt eine 2000 MHz CPU
damit es sich lohnt kommt jetzt wieder ein Pentium (E2180)
oder ein Core 2 Duo (E4400) mit zweimal 2000 MHz neu rein !

[Tesseract]

es wurde zwar schon so oft gesagt man kann die Mhz nicht zusammenzählen bei dual oder quad core aber irgendwo kann man es doch machen bei bestimmten anwendungen

jo, und wenn man 200 taktoren aneinanderkettet kann dieses gespann auch 6000 km/h fahren!

hertz ist keine geschwindigkeitsangabe, sondern die interne frequenz. es ist vollkommen egal, ob 100 mio., 500 mio. oder 5000 mio. transistoren, organisiert in 1, 2, 4 oder 100 kernen, auf 3GHz laufen, es bleiben 3GHz.

du könntest eventuell ein performancerating verdoppeln, so wie du dieses rating bei höherer leistung/MHz zwischen verschiedenen architekturen anpassen kannst. aber das ist ein ganz anderes kapitel.

[dargo]

Nur weil die Framerate stärker als 100% skaliert, heißt das nicht, dass der Prozessor auf einmal auch soviel mehr rechnet.
Bei einem 29% höheren Takt kann der Prozessor auch nur 29% mehr rechnen.

Das nicht, aber die Anwendung kann um ein vielfaches schneller ablaufen. :)

[Gast]

Ist gar nicht so einfach zu beantworten wenn ich mir die Skalierung mit mehr Taktrate und mehr Cores so anschaue.

wobei die übermäßige skalierung abnehmen sollte, wenn die cpu immer schneller wird.

Das nicht, aber die Anwendung kann um ein vielfaches schneller ablaufen.

die anwendung nicht, höchstens ein teil davon.

[dargo]

wobei die übermäßige skalierung abnehmen sollte, wenn die cpu immer schneller wird.

Nicht, wenn die Grafikkarte nicht limitiert.


die anwendung nicht, höchstens ein teil davon.
Ja, ok. :cool:
Aber der wichtigste Teil, nämlich der der für mehr Frames zuständig ist. ;) :)

[Neomi]

es ist logisch es bringt nicht mehr physik zu berechnen wenn sie nicht dagesellt werden kann...

Sorry, aber es tut schon fast weh, sowas lesen zu müssen.

Physik wird iterativ berechnet, mit kleineren Zeitschritten wird sie also genauer. Und die Unterschiede sieht man deutlich. Natürlich nicht innerhalb eines Frames, aber durch die Auswirkungen in Folgeframes. Angenommen, die Physik wird mit konstant 60 Hz berechnet, dann legt ein Objekt mit einer Geschwindigkeit von 216 km/h exakt einen Meter pro Rechenschritt zurück. Kleinere Objekte können dabei schon durcheinander durchtunneln.

[Madkiller]

Ich meine Madkiller hätte behauptet, beim G25 sind es auch einige ms.
Ne, das G25 ist soweit ich das beurteilen kann soweit lagfrei. Das MOMO hat nen 100-150ms höheren Lag als das G25. :)

Es würde schon Sinn machen, wenn die Physik bei einer höheren Framerate auch genauer arbeitet, zumindest im Singleplayer.
Ein wenig schon. Es muß ja öfters (auf die Zeit bezogen) genaue Koordinaten ausgepuckt werden.
Dennoch muß die Physik pauschal immer berechnet werden, ob 100fps oder nur 1fps.
Wenn ein Objekt bei Sekunde 0 an Stelle A ist, und bei Sekunde 1 an Stelle B. So muß die gesamte Physic komplett berechnet werden damit das Objekt auch bei B ankommt - und das bei 1fps sowie bei 100fps. Sonst würde sich das Objekt ja bei unterschiedlichen fps unterschiedlich verhalten.
Also sollte die Physik ne Pauschallast (zumindest im Großen und Ganzen) erzeugen, wo bei ner CPU mit mehr Leistung relativ gesehen mehr CPU-Leistung für den Rest übrig bleiben sollte.

[Gast]

Nicht, wenn die Grafikkarte nicht limitiert.


doch. die übermäßige skalierung kommt ja dadurch zustande dass ein teil der engine immer eine konstante rechenlast erzeugt, während andere teile (wie die grafik) den rest der verfügbaren leistung aufbrauchen.
wird die cpu schneller, wird der prozentuale anteil des konstanten teils an der gesamten rechenlast immer kleiner, und damit auch die überproportionale skalierung.

[Gast]

Also sollte die Physik ne Pauschallast (zumindest im Großen und Ganzen) erzeugen, wo bei ner CPU mit mehr Leistung relativ gesehen mehr CPU-Leistung für den Rest übrig bleiben sollte.

das kommt auf die engine an, wobei es durchaus sinnvoll sein kann, die physik mit einer deutlich höheren frequenz als die der grafik zu berechnen.

[dargo]

doch. die übermäßige skalierung kommt ja dadurch zustande dass ein teil der engine immer eine konstante rechenlast erzeugt, während andere teile (wie die grafik) den rest der verfügbaren leistung aufbrauchen.
wird die cpu schneller, wird der prozentuale anteil des konstanten teils an der gesamten rechenlast immer kleiner, und damit auch die überproportionale skalierung.
Eben nicht. Schau dir das nochmal an. :)
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=5712855&postcount=9

Je mehr Rechenleistung für die Frames zur Verfügung steht umso höher skaliert die Anwendung bei des fps mit, natürlich solange was anderes nicht limitiert.

Ne, das G25 ist soweit ich das beurteilen kann soweit lagfrei. Das MOMO hat nen 100-150ms höheren Lag als das G25. :)

Oh, sorry. Dann hatte ich das falsch in Erinnerung.

[Gast2]

@dargo
Ich glaub du hast nicht ganz verstanden, worauf der Gast hinaus wollte.

Irgendwann ist die Skalierung am Ende, weil die Anwendung nicht mehr Leistung braucht.

Bei Colin DIRT ist auch das der Fall. Während du mit einem 4 Core Processor noch einiges an Auslastung erreichst, werden es mit steigenden Taktraten immer weniger. z.B. schaffste noch 90% Auslastung bei 2,4 GHz, aber dann nur noch z.B. 70% bei 3 GHz und mehr...

heutige Anwendungen aus dem Spielebereich haben eigentlich alle ihre Grenzen, da wird die Leistung irgendwann zuviel sein und diese ungenutzt verpuffen.

[dargo]

@dargo
Ich glaub du hast nicht ganz verstanden, worauf der Gast hinaus wollte.

Tut mir leid, aber ich verstehe euch echt nicht. ;(


Irgendwann ist die Skalierung am Ende, weil die Anwendung nicht mehr Leistung braucht.

Das musst du mir mal genauer erklären. :)
Nehmen wir mal an, die Anwendung braucht 40% CPU Leistung für Physik, KI, Sound. Sind ja Bereiche die an einen festen Wert angebunden sind - zb. Zeit usw. Die anderen 60% sind für die fps zuständig. Warum sollte die Anwendung nicht schneller ablaufen (sprich mehr Frames) wenn mehr CPU Leistung zur Verfügung steht? :confused:

Bei Colin DIRT ist auch das der Fall. Während du mit einem 4 Core Processor noch einiges an Auslastung erreichst, werden es mit steigenden Taktraten immer weniger. z.B. schaffste noch 90% Auslastung bei 2,4 GHz, aber dann nur noch z.B. 70% bei 3 GHz und mehr...

Das liegt aber daran, dass die Grafikkarte höhere Auslastung beim Quadcore verhindert. Da hilft höchstwahrscheinlich selbst ein G8800GTX SLI Gespann nicht. Zumindest, wenn der Quadcore mit 3Ghz getaktet ist.

[Gast]

Warum sollte die Anwendung nicht schneller ablaufen (sprich mehr Frames) wenn mehr CPU Leistung zur Verfügung steht? :confused:

Weil gewisse Dinge nicht weiter skalieren. Du kannst 10x so viel CPU Power haben, es wird aber trotzdem nicht 10x so viel Sound berechnet ... irgendwann ist halt schluß.
Dazu kommt, das selbst andere Dinge durch die Engine bewusst von den Entwicklern eingebremst werden. Manche Engines erlauben z.B. nicht mehr als 100fps.

Das liegt aber daran, dass die Grafikkarte höhere Auslastung beim Quadcore verhindert.

Nein, mit der Grafikkarte hat das nicht im geringsten zu tun. Denk doch mal an Managergenre, was schon auf einer Onboardkarte flüssig läuft. Mit mehr Leistung verkürzt du dort die Rechenzeit. Aber irgendwann ist die Rechenleistung so hoch, das die Rechenzeit nicht noch weiter verkürzt werden kann, weil die datenmenge (in dem Fall eine Spielerdatenbank z.B.) nicht größer wird, sondern ewig so bleibt.

So lange die Entwickler bewusst Grenzen setzen (das tun sie auch aus Kompatibilitätsgründen, da sie z.B. nicht wissen, wie sich die Anwendung verhalten würde, wenn sie auf schnellerer Hardware läuft), verpufft die Mehrleistung irgendwann bei eigentlich jedem mir bekanntem Game.

[dargo]

Weil gewisse Dinge nicht weiter skalieren. Du kannst 10x so viel CPU Power haben, es wird aber trotzdem nicht 10x so viel Sound berechnet ... irgendwann ist halt schluß.

Ich habe doch gerade gesagt, dass unter anderem der Sound an einem Zeitfaktor hängt. :)
Diese Rechenleistung bleibt konstant. Es geht um die Rechenleistung die zur Berechnung der Bilder frei ist. Und warum diese mit mehr CPU Leistung nicht weiter skalieren sollte musst du mir mal erklären.


Dazu kommt, das selbst andere Dinge durch die Engine bewusst von den Entwicklern eingebremst werden. Manche Engines erlauben z.B. nicht mehr als 100fps.

Ich weiß jetzt nicht was ein Framelimiter hier zu suchen hat (den man oft abstellen kann).


Nein, mit der Grafikkarte hat das nicht im geringsten zu tun. Denk doch mal an Managergenre, was schon auf einer Onboardkarte flüssig läuft. Mit mehr Leistung verkürzt du dort die Rechenzeit. Aber irgendwann ist die Rechenleistung so hoch, das die Rechenzeit nicht noch weiter verkürzt werden kann, weil die datenmenge (in dem Fall eine Spielerdatenbank z.B.) nicht größer wird, sondern ewig so bleibt.

Ähm, wir haben hier gerade von einem Rennspiel gesprochen. Eine hohe Framerate bei einem Managergenre wird wohl niemand brauchen. :cool:

[Gast]

Hehe, eben nicht! DIRT skaliert mit mehr Takt deutlich mehr als 1:1 mit. :)

Bei Supreme Commander ist es noch extremer:
http://www.3dcenter.de/artikel/2007/06-25_c.php

Madkiller hat das mal sehr schön und plausibel erklärt. Für bestimmte Aufgaben (zb. Physik, KI, Sound) braucht man einen Grundtakt.

Nehmen wir zb. einen C2D mit 2Ghz:

500Mhz für Physik
300Mhz für KI
1200Mhz für den Rest

Wenn du jetzt einen C2D mit 3Ghz nimmst änderst sich nichts am Grundbedarf der Physik und KI, also:

500Mhz für Physik
300Mhz für KI
2200Mhz für den Rest

Wir haben in diesem Fall den CPU-Takt zwar um 50% erhöht, für die Frames stehen aber ~83% mehr CPU-Takt zur Verfügung.
Je mehr Aufgaben (oder diese Aufgaben stärker die CPU belasten) ein Spiel verwendet welches einen Grundtakt vorraussetzt um so mehr sollte diese Anwendung als 1:1 bei höherem Takt skalieren.

Edit:
Nach der Skalierung von DIRT in meiner getesteten Szene wird es in etwa so aussehen.

2Ghz C2D@Singlecore:
Physik + KI + Onboardsound = 1400Mhz
Rest = 600Mhz

3Ghz C2D@Singlecore:
Physik + KI + Onboardsound = 1400Mhz
Rest = 1600Mhz

Damit kriegst du ungefähr eine Skalierung von 1:2,7 hin. :)


Hätt ich dann aber nicht bei nem DC

Physik + KI + Onboardsound = 1400Mhz
Rest = 600Mhz + 2133 Mhz

und müsste dementsprechend bei guter MC-Skalierung (Die ja gegeben ist) auf viel mehr FPS kommen als der DC@SC 3,3GHZ? Die Engine wird ja wohl nicht so geproggt sein, dass auf nem DC "Physik + KI + Onboardsound" zweimal berechnet wird und für Rest nur 600Mhz + 600 Mhz übrig bleiben.

[dargo]

Hätt ich dann aber nicht bei nem DC

Physik + KI + Onboardsound = 1400Mhz
Rest = 600Mhz + 2133 Mhz

und müsste dementsprechend bei guter MC-Skalierung (Die ja gegeben ist) auf viel mehr FPS kommen als der DC@SC 3,3GHZ? Die Engine wird ja wohl nicht so geproggt sein, dass auf nem DC "Physik + KI + Onboardsound" zweimal berechnet wird und für Rest nur 600Mhz + 600 Mhz übrig bleiben.
Bei 3,3Ghz DC im Vergleich zum 2,13Ghz DC wird die Skalierung sicherlich kleiner als 1:2,7 ausfallen. Das liegt daran, dass man halt nicht alles parallisieren kann.

[Gast]

Eben nicht. Schau dir das nochmal an. :)
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=5712855&postcount=9


du bestätigst mich damit doch ;)

rechnen wir das beispiel nunmal weiter:

"fixkosten" (rechenleistung/zeiteinheit): 1600MHz

CPU-takt: 2000MHz
bleibt 400MHz für den rest, der mit der framerate skaliert

CPU-takt: 3000MHz
--> 1400MHz für den rest
cpu-takt erhöhung: faktor 1,5
erhöhung der verfügbaren takte für den kritischen bereich: 3,5
verhältnis: 1:2,33

CPU-takt: 4000MHz
--> 2400MHz für den leistungskritischen pfad
cpu-takt-steigerung: 1,33
kritischer bereich: 1,71
verhältnis: 1:1,29 --> frameleistung steigt nur mehr um 30% "zu viel"-

CPU-takt: 5000MHz
3400MHz für den kritischen pfad
cpu-takt-steigerung: 1,25
steigerung im kritischen bereich: 1,42
verhältnis: 1,13

wie du siehst nimmt die verhältnismäßig übermäßige steigerung ab, je schneller die cpu wird, auch ohne eine limitierung von anderer seite.

Nehmen wir mal an, die Anwendung braucht 40% CPU Leistung für Physik, KI, Sound. Sind ja Bereiche die an einen festen Wert angebunden sind - zb. Zeit usw. Die anderen 60% sind für die fps zuständig. Warum sollte die Anwendung nicht schneller ablaufen (sprich mehr Frames) wenn mehr CPU Leistung zur Verfügung steht?

für prozessor X ist das verhältnis möglicherweise 40:60

wenn wir allerdings annehmen, dass für eine höhere framerate nur der 60%ige teil mehr leistung braucht (was sein muss, damit eine übermäßige steigerung der framerate zustande kommen kann) sieht es bei einem anderen prozessor ganz anders aus.
wird dieser beispielsweise doppelt so hoch getaktet ist das verhältnis plötzlich nur mehr 20:80, der (für die framerate) kritische teil bekommt ein immer höheres gewicht, je schneller der prozessor wird.

[dargo]

du bestätigst mich damit doch ;)

rechnen wir das beispiel nunmal weiter:

"fixkosten" (rechenleistung/zeiteinheit): 1600MHz

CPU-takt: 2000MHz
bleibt 400MHz für den rest, der mit der framerate skaliert

CPU-takt: 3000MHz
--> 1400MHz für den rest
cpu-takt erhöhung: faktor 1,5
erhöhung der verfügbaren takte für den kritischen bereich: 3,5
verhältnis: 1:2,33

CPU-takt: 4000MHz
--> 2400MHz für den leistungskritischen pfad
cpu-takt-steigerung: 1,33
kritischer bereich: 1,71
verhältnis: 1:1,29 --> frameleistung steigt nur mehr um 30% "zu viel"-

CPU-takt: 5000MHz
3400MHz für den kritischen pfad
cpu-takt-steigerung: 1,25
steigerung im kritischen bereich: 1,42
verhältnis: 1,13

wie du siehst nimmt die verhältnismäßig übermäßige steigerung ab, je schneller die cpu wird, auch ohne eine limitierung von anderer seite.

Ach so meinst du das. Dann hatte ich dich falsch verstanden. Ich meinte das so:

Ausgangsbasis 2Ghz CPU

"fixkosten" (rechenleistung/zeiteinheit): 1600MHz

CPU-takt: 2000MHz
bleibt 400MHz für den rest, der mit der framerate skaliert

CPU-takt: 3000MHz
--> 1400MHz für den rest
cpu-takt erhöhung: faktor 1,5
erhöhung der verfügbaren takte für den kritischen bereich: 3,5
verhältnis: 1:2,33

CPU-takt: 5000Mhz
--> 3600Mhz für den rest
cpu-takt erhöhung: faktor 2,5
erhöhung der verfügbaren takte für den kritischen bereich: 9
verhältnis: 1:3,6

CPU-takt: 8000Mhz
--> 6400Mhz für den rest
cpu-takt erhöhung: faktor 4
erhöhung der verfügbaren takte für den kritischen bereich: 16
verhältnis: 1:4

CPU-takt: 12000Mhz
--> 10400Mhz für den rest
cpu-takt erhöhung: faktor 6
erhöhung der verfügbaren takte für den kritischen bereich: 26
verhältnis: 1:4,33

Edit:
Ok, du hast natürlich recht. Ich hatte da einen Denkfehler. An meinem Beispiel sieht man, dass man bei dieser Rechnung praktisch bei 8Ghz schon eine Skalierung von 1:1 wieder bekommt. :)