Bericht Bericht: 1, 2, 3 oder 4 CPU-Kerne?

[florian.]

Je nachdem ist ein Single-Core ja auch nicht so langsam. Natürlich gibt es Spiele, wo das so ist. Deswegen empfehlen wir am Ende ja auch eine DC-CPU und keine SC-CpU.

Dieses Fazit stimmt zwar hat allerdings nichts mit dem Artikel zu tuen.
scheinbar besteht zwischen Singel und Dualcore ein unterschied von 6%
Rechtfertigt das einen gewaltigen aufpreis und den erheblich höheren Stromverbrauch?

Ich hoffe du verstehst worauf ich hinaus will.

Jetzt habt ihr einen CPU-Artikel, der keiner sein will und auch keine Aussagen zur Spieleleistung irgendeiner handelsüblichen CPU oder gar zur Mehrkernunterstützung aktueller Engines zulässt.

es sollte wohl die benötigte CPU leistung aufgezeigt werden.
das ging ein bisschen in die Hose da keine Unterschiede sichtbar wurden.
womöglich hat der Autor die CPU Belastung der Spiele anfangs überschätzt

in der Überschrift steht allerdings das die Multicore optimierung von Spielen Geprüft werden sollte.
das kann man allerdings nur in einem Richtigen CPU Test.

 

[Stormbilly]

Das finde ich nicht. Angenommen innerhalb von fünf Minuten hast du einmal eine Sekunde lang einen FPS-Wert von 10 FPS, danach aber immer 30 FPS. Stört denn dieser einer Wert wirklich so sehr? Interessiert er dich mehr als die restlichen 4 Minuten und 59 Sekunden?

Ja tut er. Schonmal irgendeinen Multiplayershooter gespielt? Diese Sekunde kommt immer im ungünstigsten Moment... ^^
Bitte nochmal mit 2,66 GHz testen, dann sind auch 1280*1024 in Ordnung.
So wie jetzt ist der Test halt vollkommen für die Katz.

 

[smith0815]

Ja tut er. Schonmal irgendeinen Multiplayershooter gespielt? Diese Sekunde kommt immer im ungünstigsten Moment... ^^

Das ist auch kein Zufall, gerade in Multiplayer-Shootern kommt die CPU dann ins Schwitzen, wenn richtig was los ist und 20 Leute dir gleichzeitig einen Einlauf verpassen wollen.

Die 5min beim Campen @30fps fallen da wirklich kaum ins Gewicht...

 

[SirOPIUM]

Was soll diese komische Diskussion über die Frameratenmessung, wenn offensichtlich jedem von euch die Grundlagen dafür fehlen.
Ohne Differentialrechnung und etwas mehr Physikgrundlagen seh ich da bei euch nur einen schwarzen Bildschirm

Kannst du das bitte genauer erklären?
Welche physikalischen Grundlagen, die bisher offenbar nicht beachtet wurden, spielen auch noch eine Rolle? ... und was willst du mithilfe der Differentialrechnung ermitteln?

...
Das finde ich nicht. Angenommen innerhalb von fünf Minuten hast du einmal eine Sekunde lang einen FPS-Wert von 10 FPS, danach aber immer 30 FPS. Stört denn dieser einer Wert wirklich so sehr? Interessiert er dich mehr als die restlichen 4 Minuten und 59 Sekunden?
...

Eine Sekunde von 300 ist durchaus sehr wenig. Ich hatte eher an häufiger auftretende Effekte (etwa 5% oder mehr) gedacht. In einer externen (bereits oben verlinkten) Grafik (hier) treten bei knapp 3,9% der Zeit FPS-Werte kleiner als 20 und bei weiteren 12% FPS-Werte zwischen 20 und 25 auf. Trotz der AvgFPS von 31,82 denke ich, dass diese Effekte negativ auffallen. (edit: das mit den Shootern ist ein schönes Beispiel, wann genau das stört, auch wenn ich eher selten welche spiele)

... Meinst du, wie Fraps arbeitet? Ich schätze, dass es genau so sein wird.

Da war ich mir eben nicht ganz sicher. Es können ja sowohl FPS als auch Frametimes ermittelt werden. Wenn die Frametimes vorhanden sind, kann ich daraus einfach die FPS rauszählen (auch nachträglich), wenn dagegen die Frames gezählt werden, kann ich daraus keine Rückschlüsse auf die Frametimes machen. Die Frametimes sind nach meiner Ansicht aber aussagekräftiger. Mir stellt sich aber immer noch die Frage, wie genau diese gemessen werden können.

Messe mal ein "paar Minuten" die FPS-Angaben mit Fraps. Und du wirst staunen, wie viel Zahlen du da erhälst ...

Je nach dem ... 20k bis 1M behaupte ich mal. Damit sollten dann ja theoretisch recht genaue Verlaufsdiagramme erstellt werden können. Ich fände es schön, wenn hierfür nicht nur knapp 20 Stützstellen, sondern vllt 100 verwendet werden. Also nicht nur alle 5 Sekunden, sondern jede Sekunde.
Aus einem Zickzack-Verlauf kann man eine Tendenz nur schwer ermitteln. Ich erhoffe mir aus der höheren Anzahl an verwendeten Werten einen etwas glatteren Verlauf.

 

[Qualit-Y]

Erklärt mal jetzt für " Dumme" was an dem Test falsch ist /war?

 

[Maik.x]

Wie schon oft erwähnt... in der Schule hätte unter dem Test Thema verfehlt gestanden!!!

 

[abulafia]

Hier wiederholt sich alles. *gähn

Wenn man mit Fraps wirklich die Framezeiten bekommt, also genau wann welches Bild dargestellt wurde, ist das mehr als genug. Daraus kann man alles weitere berechnen. Wenn man jetzt noch mit mindestens zwei unterschiedlichen Frequenzen mit jeweils unterschiedlicher Kernanzahl misst, ... wie schön das wäre ... mit den Daten könnte man schon den Punkt berechnen, ab dem die Spielleistung von der CPU-Leistung unabhängig wird.

Differentialrechnung? Denk mal an Momentangeschwindigkeit, und überleg dir den Zusammenhang.

 

[SirOPIUM]

Was soll ich dann aus dem Verlauf der Änderung der FPS von einer Spielsituation zur nächsten herauslesen?

 

[HomerJSi]

Differentialrechnung? Denk mal an Momentangeschwindigkeit, und überleg dir den Zusammenhang.

Auch wenns nich an mich gewandt ist ... Rechnet man bei der Differentialrechnung nicht mit infinitesimalen (= unmessbar kleinen) Größen? Haben wir zumindest in der Schule so gemacht (falls ich mich da richtig zurückerinnere). Problem: Frametimes werden in Milisekunden gemessen. Eine echte Momentangeschwindigkeit (Framerate) im Sinne einer Grenzrate kann man da doch gar nicht ermitteln? Da müsstest du schon nochmal den Lehrer raushängen lassen Die Frame-Zeit-Funktion (im Sinne einer Weg-Zeit-Funktion) kannst du bereits voraussetzen? Lasse mich in der Hinsicht gerne belehren.

 

[abulafia]

Der Unterscheid ist, dass man hier durch die Messung keine stetig diffbare Funktion hat, sondern diskrete Messwerte. Der zugrunde liegende Vorgang (Bildberechnug) kann aber (vereinfacht) als stetig angenommen werden.

Das gleiche Problem gibts bei einer Geschwindigkeitsmessung auch.
Die Analogie funktioniert dann so:
Du möchtest messen, wie schnell ein Auto ist. Messen kannst du aber nur dir Zeit für eine Umdrehungen des Rades, also zum Beispiel mit einer Lichtschranke, die immer unterbrochen wird, wenn das Rad genau einmal herum ist. Dadurch bekommt man auch nur diskrete Daten einer stetigen Funktion.

Ich wollte nur sagen, dass man Framerate genauso wenig wie Geschwindigkeit direkt messen kann. Die Geschwindigkeit ist eine Ableitung der Strecke, und die Framerate ist eine Ableitung der berechneten (zurückgelegten) Bilder nach dt.

Statt der Strecke (die praktisch auch nur diskret gemessen werden kann) nimmt man hier die Anzahl der fertig berechneten Bilder. Die Zwischenräume werden dann interpoliert. Allerdings wird man hier nicht auf eine hübsche quadratische Funktion kommen wie bei einer gleichförmig beschleunigten Bewegung, sondern auf ein Polynom n-ter Ordnung, so etwas wie bei einem Geländewagen auf einer Offroad Teststrecke.

 

[Roi-Danton]

das Supreme Commander durch die Parallelisierung so schlecht programmiert ist oder doch die Grafik Stellenweise limitiert, das eine Erhöhung der Taktraten von 2,4 Ghz bei einem Q6600 auf 3,6 Ghz nur 2 FPS mehr bringt.

In Supreme Commander sind nicht die FPS entscheidend, sondern die Spielgeschwindigkeit. Bei CPU-Limitierung nimmt vor allem die Spielgeschwindigkeit ab, insofern kann man anhand von FPS Werten bei Supreme Commander nur schwer auf die Leistung der CPU schließen bzw. auf eine "schlechte Programmierung". Man müsste dazu eine Messung der Spielgeschwindigkeit durchführen (leicht möglich, da die Spielgeschwindigkeit anhand der Zeitanzeige im Spiel zu sehen ist).

 

[little_dragon]

Nun ja computerbase in aller Ehre, aber welcher Zocker würde sich heutzutage noch eine Ein-Kerne CPU zulegen? Wenns die überhaupt noch gibt? Da meistens die GPU limitiert hat das ganze sowieso keine grosse Aussagekraft. Nächstesmal vielleicht doch lieber Qualitätseinstellungen nicht auf Max stellen.

 

[FloW3184]

Hammersatz bei Crysis... ergibt für mich keinen Sinn, das im "very high" zu testen:

Wir testen die auf Version 1.21 aktualisierte Vollversion des Spiels. Auch wenn die Einstellung „Very High“ für viele (vor allem günstigere) Grafikkarten unspielbar ist, haben wir uns dennoch für die höchste Qualitätsstufe entschieden, um selbst mit zukünftigen Grafikkarten keine CPU-Limitierung bei gewährleisteter Vergleichbarkeit zu schaffen.

Ihr sagt doch selbst, dass es dann rein GPU-limitiert ist...

 

[HomerJSi]

[...]

OK, wenn ich das richtig verstanden habe würde also gelten: Frames = f(Zeit)

Abgeleitet (falls f stetig differenzierbar): dFrames = f'(Zeit)*dt <=> dFrames/dt = f'(Zeit) mit dFrames/dt bzw. f'(Zeit) als Framerate (die man in Frames/Milisekunde, Frames/Sekunde etc. angeben kann) bzw. Momentan-Framerate.

Durch den Graph einer Liste mit Frametimes (also ein Punktdiagramm der Art: (50 ms,1), (80ms, 2), (130ms, 3), ...) könnte man dann eine stetige Funktion: Frames = f(Zeit) durchlegen (so ähnlich wie man das bei ner linearen Funktion mit der Methode der kleinsten Qudrate macht, nur dass f(Zeit) wie du sagst vermutlich irgend ein Polynom ist und das Schätzverfahren dementsprechend komplizierter sein dürfte) und die Ableitung dieser Funktion wäre dann die Momentan-Framerate. Wenn ich das richtig verstanden habe.

Bleibt für mich noch die spannende Frage - Wenn ich ne Liste mit Frametimes habe und daraus direkt den Kehrwert nehme (mir also den Umweg über die stetige Funktion spare)

1. Definitiv liegt eine Änderungsrate vor
2. Es wäre aber eine mittlere bzw. durchschnittliche Änderungsrate (wobei der Durchschnitt über die Frametime gebildet wird) also eine mittlere bzw. durchschnittliche Framerate.
3. Könnte man eine dermaßen gebildete Framerate (Kehrwert der Frametime) als grobe Annäherung der Momentan-Framerate interpretieren und zwar unter der Bedingung, die Differentialrechnung nicht verwenden zu wollen ... also unter der Bedingung, nur mit messbaren Einheiten zu arbeiten.
4. Oder wäre es dann (unter der Bedingung nur mit messbaren Einheiten zu arbeiten bzw. keine Differentialrechnung zu verwenden) sinnvoller, in fest vorgegebenen Zeitintervallen (beispielsweise 1 Sekunde) Bilder zu zählen ... wie das FRAPS tut: (Sekunde 1, 34 Frames), (Sekunde 2, 45 Frames) u.s.w. (ich glaube kaum, dass FRAPS diese Liste durch Integrieren über ein Sekundenintervall aus der oben angesprochenen stetigen Funktion erstellt).

 

[SirOPIUM]

Es handelt sich um ein zeitdiskretes Signal, von dem wir hier sprechen, da die Frames eben nur zu festen Zeitpunkten fertig berechnet sind und anschließend ausgegeben werden. Würde am Monitor ein zeitkontinuierliches Bild dargestellt, hätte man wesentlich geringere Probleme mit langsamen Berechnungsintervallen der Komponenten.

Die Zeit von einem Frame zum nächsten bzw die Bildrate als Kehrwert davon ist der entscheidende Punkt, ob ein fküssig wirkendes Bild entsteht oder nicht. Selbst bei 50 FPS kann das Bild muss das Bild nicht flüssig sein, wenn 48 Bilder in einer halben Sekunde und zwei in der anderen Hälfte berechnet wurden. Wenn die MinFPS auch nur durch zählen ermittelt werden, fällt es hier auch nicht auf. Aus der Frametime dagegen ist dieses Problem genau ersichtlich - ohne jegliche Differentialrechnung und Zeitkontinuität des Bildverlaufs.

 

[Eusterw]

Ihr habt sie doch nicht alle...

 

[silent-efficiency]

Ich weiß gar nicht, was alle an der Auflösung rummeckern. Man testet alle Spiele durch und die, die bei der relativ kleinen Auflösung (in der noch oft gespielt wird) immer noch GPU-Abhängig sind, obwohl die schnellste Graka der Welt verbaut ist, sind halt für die CPU unwichtig. Es ist doch dann egal, ob bei 800x600 ein 4-Kerner mehr FPS gebracht hätte. Wieso sollte man also in 800x600 testen, wenn keiner in der Auflösung spielt, es sei den er hat eine GeForce FX 5200? Das bringt doch nichts. Die gewählte Auflösung ist schon richtig!

 

[Fairy Ultra]

müsig es euch zu erklären.

wie ein user erklärte:

mögliche Erzielbare Leistung = Min(CPU Leistung, GPU Leistung, Ram, Festplatte usw...)

wenn die CPU Leistung in niedrigen Auflösungen ausreicht, dann gilt dies auf für höhere Auflösungen.
soll heißen liefert eine, CPU ausreichend frames bei niedrigerer Auflösung so könnte das Spiel wenn die GPU nicht limitiert auch in höherer Auflösung mit dieser selben FPS Zahl laufen.

Ist dies nicht der Fall so liegt eventuell ein GPU limit vor.
(selbst wenn eine stärkere CPU verwendet wird verbessert sich das ergebnis nicht; und gerade das ist hier der Fall mit 4 ghz pro Kern, die Unterschiede fallen geringer aus als sie in der Realität eigentlich wären, oder verwendet jeder von euch seinen Quad mit 4 ghz? ich glaube die Masse der Leute jedenfalls nicht)

Deswegen testet man einen Prozessor so CPU limitiert wie möglich, und eine Grafikkarte so GPU limitiert wie möglich um eine Aussage kräftiges Ergebnis im Bezug auf die Leistungfähigkeit zu erhalten.

 

[bensen]

Aber ich persönlich würde gerne auch etwas die Zusammenhänge sehen und etwas daraus lernen...
Vielleicht bin ich ja auch zu anspruchsvoll was den Lerngehalt betrifft

ja ne, ich fänd es auch interessant
aber man kann es dem autor schlecht als fehler ankreiden wenn der test so etwas gar nicht zeigen soll

 

[silent-efficiency]

wenn die CPU Leistung in niedrigen Auflösungen ausreicht, dann gilt dies auf für höhere Auflösungen.
soll heißen liefert eine, CPU ausreichend frames bei niedrigerer Auflösung so könnte das Spiel wenn die GPU nicht limitiert auch in höherer Auflösung mit dieser selben FPS Zahl laufen.

Warum sollte ich testen ob die CPU-Leistung in 800x600 ausreichend ist, wenn ich in der Auflösung eh nicht spiele? Es gibt im Test auch kein Spiel, dass unspielbare FPS aufgrund der GPU liefert, so dass man die Auflösung deswegen veringern müsste.

Der Test ist Praxisrelevanter, wenn er in einer niedriegen Auflösung, in der man noch spielt, testet. Da man da eben sieht, was man von der CPU hat, wenn man die stärkste Grafikkarte der Welt hat. Wenn man mit der Auflösung noch tiefer geht, hat das keinen praktischen nutzen.