Assasin's Creed profitiert von vier cores. Warum? [Archiv]

HOT

2008-05-19, 11:00:35

Die KI wird ein Schlüssel dazu sein. Bisher war es ja oft so, dass die KI in einem eigenen Thread abgearbeitet wurde, weswegen vor allem Strategietitel und Shooter zwar von 2 Kernen halbwegs profitieren (Anno1701, C&C3, Worldshift, Quake4 usw.), aber mit mehr als 2 Kernen garnichts anfangen können. Dafür haben diese Spiele aber den Vorteil, dass sie auf SingleCores noch spielbar sind. Bei AC sieht das anders aus. Da dieser Titel recht fordernd für die CPU ist und sowohl bei XBox als auch PS3 mindestens 6 Kerne gefüttert müssen, hat man auch massiv auf MT optimiert, auch die KI. Es gibt eben nicht mehr wenige, mächtige Threads, sondern diese Threads sind nochmals parallelisiert. Natürlich mit dem Resultat, dass man bei deren PC-Umsetzung bei Single- und DualCores mit entsprechend niedrigen Takten schwere Nachteile aufgrund des hohen Verwaltungsaufwandes verursacht durch das massive Threading hat. Die Core2 reichen bei solchen Games für gewöhnlich (wobei sich auch hier die Frage stellt wie lange noch, wenn man Spiele wie CMR-Dirt und GRID sieht), bei K8 X2 wirds da schon knapp. SingleCores kann man komplett vergessen.
In Zukunft wird es noch weit mehr Umsetzungen von Konsole zu PC geben, da alle grossen Engines auch auf die Konsolen angepasst werden. Auch klassische PC-Genres wie Strategietitel und Shooter erscheinen auf Konsole (z.B. Doom4), weswegen das Verhältnis von Spiele zu mehr Kernen natürlich erheblich besser wird. Nur schauen dann Besitzer von DualCores u.U. in die Röhre.
Ich halte diesen Wolfdale-Hype sowieso für ziemlich daneben, weil der Wolfdale angesichts der zukünftigen Spielesituation in ziemlicher Blender ist. Er ist der letzte grosse DualCore, der hohe Takte bieten wird, nur sind die Vorteile, die er aus Spielen wie Anno1701 ziehen, welche ja regelrecht DualCore-optimiert sind, kann, in Zukunft kaum noch zum Tragen kommt, da die CPUs, die den Ton angeben, eben keine PC-CPUs mehr sind, sondern massiv-MT-CPUs mit mindestens 6 Kernen.

Ectoplasma

2008-05-19, 12:17:23

... Natürlich mit dem Resultat, dass man bei deren PC-Umsetzung bei Single- und DualCores mit entsprechend niedrigen Takten schwere Nachteile aufgrund des hohen Verwaltungsaufwandes verursacht durch das massive Threading hat...

Hmm, ist das so? Wieviele Threads hat AC denn? Die Frage ist auch, ob die Thread-Anzahl mit der Anzahl der CPUs zunimmt. Ich weiss es nicht, wäre aber ein denkbares Scenario.

Brillenschlange92

2008-05-19, 12:37:37

[gelöscht]

Neosix

2008-05-19, 13:45:11

Das Problem bei "zusätzlicher" Grafik wird aber wiederum sein das diese zwar gern von der CPU vor berechnet werden können... müssen jedoch schlussendlich von der Grafikkarte gerendert werden, und wenn diese bereits am Limit ist, wird die Parallelisierung der Effekte bzw Physik dort auch nichts mehr bringen.

Man ist nur so stark wie das schwächste Glied.

Brillenschlange92

2008-05-19, 14:07:59

[gelöscht]

HOT

2008-05-19, 15:42:03

CB hat mit ner 4GHz CPU getestet. So hoch wird nie ein offizieller DualCore oder gar SingleCore verfügbar sein. Von daher wär ich mit dem CB-Test sehr vorsichtig.
Hmm, ist das so? Wieviele Threads hat AC denn? Die Frage ist auch, ob die Thread-Anzahl mit der Anzahl der CPUs zunimmt. Ich weiss es nicht, wäre aber ein denkbares Scenario.
Wenn man sich die Benchmarks aus der PCGH ansieht, die ja einen etwas langsamer getakteten Core2 Quad verwendeten, müssen es sehr viele Threads sein, da der Core2 Quad trotz des Synchronisationsnachteils super skaliert (natürlich deutlich schlechter als die Phenoms) und SingleCores sehr, sehr starke Nachteile haben. Ich denke, die Tools, die für diese Engines verwendet werden, werden auch bei Farcry2 und anderen Ubi-Montreal-Tital zum Einsatz kommen. wir werden auch hier und beim nächsten Splinter-Cell ein ähnliches Verhalten wie bei AC sehen.

ZZ @ work

2008-05-19, 15:49:18

Was mich auch interessiert hätte wäre die Auswirkung einer PhysiX-Karte, da die dem CPU ja nochmal Arbeit abnimmt - lohnt sich die denn überhaupt, wenn man eh 3 oder mehr Kerne für die Physik zur Verfügung hat?

Das kommt natürlich zunächst mal darauf an, ob überhaupt die PhysX-Middleware zum Einsatz kommt bei AC. Ich meine, das wäre nicht der Fall (hab' das Game nicht).
Dass viele Kerne überhaupt nur dann Sinn machen, wenn die Grafikkarte nicht limitiert, sollte klar sein. Fazit wäre also, dass KI und Physik als gut parallelisierbare Aufgaben in der nahen Zukunft der Einsatzzweck für Multicore-CPUs sein werden. Bei AC ist dies bereits erwiesenermaßen (?) der Fall. So in etwa richtig?

Gast

2008-05-19, 17:59:43

Zum einen, alle heutigen und zukünftigen Konsolen umsetzung werden von mehreren Kernen profitieren, weil die Spiele von Grund auf für Mehrkerne ausgelegt sind. Anders wie beim PC wo es ein "kann" ist, muss man auf den Konsolen Mehrkerntechnik einsetzen um genug Performance zu bekommen.

Eine Physix Karte ist wohl eher hinderlich in diesem Zusammenhang, deren Leistung ist ja doch erheblich begrenzt. Da die Konsolen ja auch nicht dediziert darauf zugreifen und etliche Threads deswegen auf den Cores laufen.

Brillenschlange92

2008-05-19, 18:46:10

[gelöscht]

Gast

2008-05-19, 18:54:57

Wieviele Threads hat AC denn?

im spiel 16, und nein diese zahl sagt rein garnichts über die skalierung mit mehreren kernen aus.

=Floi=

2008-05-19, 19:27:59

eine physx physikkarte muß erst einmal unterstützt werden

HOT

2008-05-19, 19:53:29

Die PhysX-Karte ist eh Geschichte. Das geht jetzt erst richtig los mit PhysX, da man wohl jede beliebige 60€ GraKa dafür verwenden können wird ab der R700/GT200 Generation.
im spiel 16, und nein diese zahl sagt rein garnichts über die skalierung mit mehreren kernen aus.
Da glaube ich nicht, dass man das so zählen kann :D. Das wird auf die Lastsituation ankommen, wieviele Thread grad gebraucht werden. Bei AC wird das MT sowohl in vertikale als auch in horizontale Richtung gehen.
Und man kann daran sehr wohl sehen, dass bei dem Spiel mehr Kerne auch mehr Leistung bedeutet, da es darauf ausgelegt ist. Wer soviele Threads ins Spiel bring, sorgt auch dafür, dass man eine gleichmässige Auslastung bekommt, sonst macht das alles keinen Sinn.

Gast

2008-05-19, 20:07:10

Wer soviele Threads ins Spiel bring, sorgt auch dafür, dass man eine gleichmässige Auslastung bekommt, sonst macht das alles keinen Sinn.

davon kann man nicht ausgehen, selbst uraltspiele, die aus mehreren kernen nicht den geringsten nutzen ziehen haben oft 5-10 threads.

BAGZZlash

2008-05-19, 20:38:04

Das ist mir alles zu platt, "Das Spiel ist auf mehrere Kerne ausgelegt". Das ist nicht Gegenstand des Threads. Fraglich ist vielmehr, was AC kann, was andere Spiele nicht können.

Neosix

2008-05-19, 20:51:06

Ist jetzt AC das erste Spiel das bei 4 Kernen Profitiert oder wieso ist die Meldung jetzt so besonders? oO

BAGZZlash

2008-05-19, 21:03:20

Ist jetzt AC das erste Spiel das bei 4 Kernen Profitiert oder wieso ist die Meldung jetzt so besonders? oO

Meiner Meinung nach ist's in der Tat der erste Shooter, der echt parallelisierten Code ausführt, ja.
Bei RTS-Games wie C&C3 oder Supreme Commander ist das streitig, aber möglich.

N0Thing

2008-05-20, 02:56:11

In Extremsituationen scheint sogar nur ein Quadcore (> 2 GHz) oder ein stark übertakteter Dualcore (Core 2 Duo > 4 GHz) ausreichend hohe Frameraten zu liefern.

Dann scheine ich ja während ich AC durchgespielt habe, nie in eine Extremsituation gekommen zu sein und das mit einem A64 x2 4200+ (und einer 8800GT) :tongue:

Freut mich aber trotzdem, daß ein weiteres Spiel von weiteren Kernen profitiert, bei Supreme Commander wünsche ich mir das jedes Mal. :wink:

Simon

2008-05-20, 08:59:46

Die Frage ist, ob die KI im Vergleich zur Grafik ausreicht, die verbleibenden Kerne alle auszulasten?
Es gibt auch noch Collision Detection, die gerade bei so vielen Personen verdammt oft zum Einsatz kommt. Collision Detection & Response läuft komplett auf der CPU und lässt sich auch recht gut parallelisieren. Dann gibt es noch die Berechnung von Animationen, die auf der CPU gemacht werden kann, auch gut parallelisierbar. Decompression von Daten fürs Streaming ist auch auf der CPU. Vernünftiger Mehrkanal-sound braucht auch Leistung.
Also zu tun gibt es für Quadcores mehr als genug ;)

Falls ein Spiel Shadow Volumes wie z.B. Doom3 und Quake4 nutzt (heute eher selten), kann man das auch wunderbar auf mehreren CPUs machen.

Spasstiger

2008-05-20, 09:07:52

Dann scheine ich ja während ich AC durchgespielt habe, nie in eine Extremsituation gekommen zu sein und das mit einem A64 x2 4200+ (und einer 8800GT) :tongue:

Freut mich aber trotzdem, daß ein weiteres Spiel von weiteren Kernen profitiert, bei Supreme Commander wünsche ich mir das jedes Mal. :wink:
Im PC-Games-Hardware-Test lag die Framerate auf einem Core 2 Duo E6600 bei 22 fps min, also nicht mehr flüssig (wenn auch noch spielbar). Der Q6600 erreichte 42 fps min.. Mit deinem X2 4200+ wirst du durchaus mal weniger als 20 fps gehabt haben, wenn ich hier selbst feststelle, dass mein Core 2 Duo E4300 @ 3 GHz nicht jede Situation flüssig meistert (sprich mit über 30 fps).

BAGZZlash

2008-05-20, 13:55:40

Collision Detection & Response läuft komplett auf der CPU und lässt sich auch recht gut parallelisieren. Dann gibt es noch die Berechnung von Animationen, die auf der CPU gemacht werden kann, auch gut parallelisierbar. Decompression von Daten fürs Streaming ist auch auf der CPU. Vernünftiger Mehrkanal-sound braucht auch Leistung.
Also zu tun gibt es für Quadcores mehr als genug ;)

Kollisionserkennung per Dreieck ist nicht sonderlich aufwendig. Per Pixel ist es sehr aufwendig, aber das wird bei AC sicherlich nicht gemacht. Übrigens: PhysX sollte per Pixel gekonnt haben, stimmt das? Falls ja, kann man beim CUDA-Port ja auch darauf hoffen. Dekompression spielt eigentlich auch keine Rolle, die GraKa bekommt direkt komprimierte (Textur-)Daten. Beim Sound ist's ähnlich wie bei der Kollisionserkennung: Für "anständig" ist auch mit Quadcore zu wenig Leistung da und bei "gehuddelt" wie bei allen anderen Spielen ist's kein ernstzunehmender leistungskritischer Faktor. Gab' glaub' ich auch auf der 3DC-Hauptseite mal'n Test dazu. Ist aber schon was her, d.h. da waren die CPUs nochmal 'ne Ecke langsamer als heutzutage.
Einzig Animationen - allgemeiner: Geometrie - lasse ich als von Multicore profitierend wirklich zu, allerdings muss auch hier sichergestellt sein, dass es keine Polygonüberlappungen oder so gibt. Immer, wenn sich Modelle gegenseitig beeinflussen, war's das mit der Parallelisierbarkeit. Aber gut, das lässt sich einrichten.
Alles in allem: Keiner der genannten Punkte kann erklären, warum AC so gut auf Multicore skaliert. Frage: Warum sonst? Oder vertu' ich mich?

O RLY?

2008-05-20, 14:03:20

Frag doch die Programmierer ;)
Schließlich wurde das Spiel ja für Current-Gen Konsolen entwickelt und die sind bekanntlich nunmal alle Multi-Core Kisten.

BAGZZlash

2008-05-20, 15:24:19

Frag doch die Programmierer ;)
Schließlich wurde das Spiel ja für Current-Gen Konsolen entwickelt und die sind bekanntlich nunmal alle Multi-Core Kisten.

Danke für der Tip. Kann ich nur leider nicht, ich kenn' keinen. Außerdem: Will ich auch gar nicht, ich will hier - im Diskussionsforum - darüber diskutieren.

Gast

2008-05-20, 15:28:55

Das ist mir alles zu platt, "Das Spiel ist auf mehrere Kerne ausgelegt". Das ist nicht Gegenstand des Threads. Fraglich ist vielmehr, was AC kann, was andere Spiele nicht können.

Ich weiß nicht, ob "können" hier der richtige Begriff ist, denn es ist ja auch eine Designfrage. Wenn ein Hersteller möchte, dass das Spiel auch noch auf Einkernern spielbar bleibt, so muss er eben von vorneherein Kompromisse eingehen.

robobimbo

2008-05-20, 15:38:06

Vielleicht verwendet ja AC schon den neueren Ansatz der "Tasks" - Es werden jeden Menge Tasks erzeugt (viel mehr als es Cores gibt) und die werden dann - je nach Bedarf werden die auf die freien Cores verteilt. Solche Anwendungen skalieren gut mit mehreren Prozessoren, verrecken aber natürliche bei solchen Systemen die nur einen haben, weil dieser Ansatz ja latürnich auch einen gewissen Overhead bedeutet.

Beide Ansätze sieht man bei Intels Threading Building Blocks, sowie in einem MS Vortrag auf der letzten Gamers Developer Conference

Links: http://www.threadingbuildingblocks.org/
http://www.microsoft.com/downloads/info.aspx?na=47&p=2&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=8450db46-283f-4924-b35c-3ccd1db7e97e&u=details.aspx%3ffamilyid%3dA36FE736-5FE7-4E08-84CF-ACCF801538EB%26displaylang%3den

BAGZZlash

2008-05-20, 15:47:33

Ich weiß nicht, ob "können" hier der richtige Begriff ist, denn es ist ja auch eine Designfrage. Wenn ein Hersteller möchte, dass das Spiel auch noch auf Einkernern spielbar bleibt, so muss er eben von vorneherein Kompromisse eingehen.
Ganz sicher skalieren andere Spiele nicht deshalb so schlecht auf Multicoresystemen, weil die Entwickler sich bewusst so entschieden haben. "Können" ist hier ein durchaus rechtfertigbarer Begriff.

Ectoplasma

2008-05-20, 16:40:24

Vielleicht verwendet ja AC schon den neueren Ansatz der "Tasks" - Es werden jeden Menge Tasks erzeugt (viel mehr als es Cores gibt) und die werden dann - je nach Bedarf werden die auf die freien Cores verteilt.

Klingt irgendwie unlogisch. Bei einem Spiel gibt es einen Fluss. Wozu sollte es wesentlich mehr Threads als CPUs geben? Was ich meine ist, dass es doch in einem Spiel kaum eine Aufgabe geben kann, die parallel wartet. Auf was denn? Wenn sich Algorithmen parallelisieren lassen, dann hat man eine Menge von Worker-Threads. Die Anzahl der Threads sollte sich nach der Anzahl der CPUs richten. Man hat vielleicht noch mehrere Worker-Thread-Pools. Z.B. für die Physik oder die Grafik. Das war es aber auch. Ein Worker-Thread-Pool der wesentlich mehr Threads als CPUs hat ist z.B. dann wichtig, wenn viele Ereignisse gleichzeitig eintreten (z.B. bei Multi-User-Games). Ich finde den Anzatz mit vielen Threads für ein Game richtig schlecht. Das skaliert auch auf Multicores mieserabel. Man glaubt gar nicht wieviel Zeit dadurch verbraten wird.

Gast

2008-05-20, 17:26:07

Fraglich ist vielmehr, was AC kann, was andere Spiele nicht können.

fraglich ist vor allem wie man auf solch seltsame ergebnisse kommt. 3 cores bringen kaum mehr als 2, aber mit 4 gibt es wieder einen kleinen schub?

irgendwas muss da doch faul sein, das kann einfach nicht stimmen.

Simon

2008-05-20, 19:00:15

Kollisionserkennung per Dreieck ist nicht sonderlich aufwendig.
Bei so vielen Leuten, die durch die Gegend laufen und der großen Welt, seh ich das etwas anders. Zumal auch die AI Range Checks und Visibility und ähnliches braucht, was ich da mal mit reingenommen hab.

Dekompression spielt eigentlich auch keine Rolle, die GraKa bekommt direkt komprimierte (Textur-)Daten.
Zumindest bei id's Megatexture stimmt das so nicht (http://softwarecommunity.intel.com/articles/eng/1221.htm). Keine Ahnung, wie das bei AC gelöst ist. Ohne technische Details zum Spiel kann dazu auch keiner was sagen.

Beim Sound ist's ähnlich wie bei der Kollisionserkennung: Für "anständig" ist auch mit Quadcore zu wenig Leistung da und bei "gehuddelt" wie bei allen anderen Spielen ist's kein ernstzunehmender leistungskritischer Faktor. Gab' glaub' ich auch auf der 3DC-Hauptseite mal'n Test dazu. Ist aber schon was her, d.h. da waren die CPUs nochmal 'ne Ecke langsamer als heutzutage.
Sound ist überhaupt nicht mein Gebiet, da müßte man eher Avalox fragen ;)
Gehen wir mal davon aus, dass die Asus Xonar D2 EAX 2 nicht in Hardware kann, also auf der CPU berechnet, dann kostet Sound doch einiges an Leistung, siehe z.B. bei der Computerbase (http://www.computerbase.de/artikel/hardware/multimedia/2008/test_asus_xonar_d2/) Irgendwo stand auch, dass die Xonar EAX 5 via CPU-Emulation bekommen soll, was nochmal extra kostet.

Einzig Animationen - allgemeiner: Geometrie - lasse ich als von Multicore profitierend wirklich zu, allerdings muss auch hier sichergestellt sein, dass es keine Polygonüberlappungen oder so gibt.
Warum keine Überlappungen bzw. was für Überlappungen meinst du?
Meine XBox ist leider seit 7 oder 8 Wochen in Reparatur, sonst würde ich jetzt nochmal nachschauen, aber so aus dem Gedächtnis heraus kommen sich die NPCs sowieso nicht zu nahe.

Warum sonst? Oder vertu' ich mich?
Naja, was bleibt denn noch über an Aufgaben? Multiplayer? ;D

Ich kann hier (http://www.grotesque-game.de/) problemlos einen 3GHz Core2 Duo nur mit AI und Physik (inkl. Collision Detection & Response) zu ~80% auslasten und die Welt ist weder groß noch stark bevölkert ;) Die Kostens fürs Rendering sind minimal im Vergleich zu allem anderen.

Ohne mehr Details zu AC lässt sich kaum sagen, wo das Spiel wieviel CPU verbraucht ;(

Klingt irgendwie unlogisch. Bei einem Spiel gibt es einen Fluss. Wozu sollte es wesentlich mehr Threads als CPUs geben? Was ich meine ist, dass es doch in einem Spiel kaum eine Aufgabe geben kann, die parallel wartet. Auf was denn? Wenn sich Algorithmen parallelisieren lassen, dann hat man eine Menge von Worker-Threads. Die Anzahl der Threads sollte sich nach der Anzahl der CPUs richten. Man hat vielleicht noch mehrere Worker-Thread-Pools. Z.B. für die Physik oder die Grafik. Das war es aber auch. Ein Worker-Thread-Pool der wesentlich mehr Threads als CPUs hat ist z.B. dann wichtig, wenn viele Ereignisse gleichzeitig eintreten (z.B. bei Multi-User-Games). Ich finde den Anzatz mit vielen Threads für ein Game richtig schlecht. Das skaliert auch auf Multicores mieserabel. Man glaubt gar nicht wieviel Zeit dadurch verbraten wird.
Ich glaube, er meint einen Thread Pool (http://en.wikipedia.org/wiki/Thread_pool), nur das seine Erklärung ziemlich falsch ist ;)

Botcruscher

2008-05-20, 19:23:09

fraglich ist vor allem wie man auf solch seltsame ergebnisse kommt. 3 cores bringen kaum mehr als 2, aber mit 4 gibt es wieder einen kleinen schub?

irgendwas muss da doch faul sein, das kann einfach nicht stimmen.

Vermutlich ist die Software fest auf 1,2 oder 4 Cores ausgelegt. Der 3 Core wird nicht verwendet. Dieses "Softwareproblem" macht Tricores noch unatraktiver..

Gast

2008-05-20, 19:37:05

Ganz sicher skalieren andere Spiele nicht deshalb so schlecht auf Multicoresystemen, weil die Entwickler sich bewusst so entschieden haben. "Können" ist hier ein durchaus rechtfertigbarer Begriff.

Naja, das sehe ich wie gesagt anders.
Wenn ich das Spiel von vornherein so Designe, dass ein beträchtlicher Teil der Leistung für Physik, KI usw. verbraten wird, so kann das natürlich wesentlich besser von weiteren Cores profitieren. Das ist kein Hexenwerk.

Gast

2008-05-20, 19:53:22

Vermutlich ist die Software fest auf 1,2 oder 4 Cores ausgelegt. Der 3 Core wird nicht verwendet. Dieses "Softwareproblem" macht Tricores noch unatraktiver..

kaum vorstellbar, wieso sollte man sowas dämliches machen?

ich vermute mal dass assassins creed deutlich mehr worker-threads als cores verwendet, was auch notwendig ist, da man die auslastung der einzelnen threads kaum ausbalancieren kann, wenn man nicht in jedem thread das selbe macht.

Botcruscher

2008-05-20, 20:00:23

kaum vorstellbar, wieso sollte man sowas dämliches machen?

Weil zum Zeitpunkt der Entwicklung von Tricores noch keine Rede war und man es mal eben so fix zusammengeprogt hat. Die unterschiedlichen Tests zum Tricore von AMD zeigen oft solche Abweichungen.

Demirug

2008-05-20, 20:27:53

ich vermute mal dass assassins creed deutlich mehr worker-threads als cores verwendet, was auch notwendig ist, da man die auslastung der einzelnen threads kaum ausbalancieren kann, wenn man nicht in jedem thread das selbe macht.

Mehr worker threads als cores ist Gift. Das fressen dir die Contextwechsel die Leistung weg.

Ich glaube, er meint einen Thread Pool (http://en.wikipedia.org/wiki/Thread_pool), nur das seine Erklärung ziemlich falsch ist ;)

Thread Pools sind schon etwas besser. Funktionieren aber in der Regel nur bei Serveranwendungen die viele Clients bedienen gut.

Neosix

2008-05-20, 20:29:11

Gast

2008-05-20, 20:42:34

Mehr worker threads als cores ist Gift. Das fressen dir die Contextwechsel die Leistung weg.

bei einem präemtiven OS wird nach dem ablauf einer zeitscheibe eh immer ein contextwechsel durchgeführt, dieser ist beim wechsel zwischen mehreren threads eines prozesses auch noch vergleichsweise günstig, da glaub ich kaum, dass diese soviel kosten würden. mit einem SC wäre man ja sonst komplett aufgeschmissen ;)

Demirug

2008-05-20, 20:57:39

Aber gerade wenn ein Spiel so viele Threads verwendet, werden diese doch nur vom Betriebsystem verwaltet und da sollte es egal sein ob man 2 oder 6 cores hat, die Last wir dynamisch verteilt. Oder sehe ich das Falsch?

bei einem präemtiven OS wird nach dem ablauf einer zeitscheibe eh immer ein contextwechsel durchgeführt, dieser ist beim wechsel zwischen mehreren threads eines prozesses auch noch vergleichsweise günstig, da glaub ich kaum, dass diese soviel kosten würden. mit einem SC wäre man ja sonst komplett aufgeschmissen ;)

In der Theorie funktioniert das natürlich alles so. In der Praxis leider nicht. Sobald diese Threads anfangen miteinander zu kommunizieren (und das ist bei einem Spiel im Gegensatz zu einem Multiclient Server unvermeidlich) verursachen die dafür notwendigen Synchronisationobjekte viel mehr Contextwechsel als beim normalen Zeitscheiben verfahren auftreten.
Aus diesem Grund verwendet OpenMP per Default auch nur einem Thread pro Core in der Standardeinstellung.

Simon

2008-05-20, 20:58:30

Thread Pools sind schon etwas besser. Funktionieren aber in der Regel nur bei Serveranwendungen die viele Clients bedienen gut.
Was kannst du denn empfehlen? =)

dargo

2008-05-20, 23:12:36

Im PC-Games-Hardware-Test lag die Framerate auf einem Core 2 Duo E6600 bei 22 fps min, also nicht mehr flüssig (wenn auch noch spielbar). Der Q6600 erreichte 42 fps min..
Der PCGH-Test ist sehr fragwürdig wenn du dir mal die einzelnen CPU-Ergebnisse anschaust. Sollte man durchaus erwähnen. :)

Ectoplasma

2008-05-20, 23:29:51

Vermutlich ist die Software fest auf 1,2 oder 4 Cores ausgelegt. Der 3 Core wird nicht verwendet. Dieses "Softwareproblem" macht Tricores noch unatraktiver..

Es muss ja nicht jede Software so beschissen programmiert sein.

schmacko

2008-05-20, 23:35:10

Sound ist überhaupt nicht mein Gebiet, da müßte man eher Avalox fragen ;)
Gehen wir mal davon aus, dass die Asus Xonar D2 EAX 2 nicht in Hardware kann, also auf der CPU berechnet, dann kostet Sound doch einiges an Leistung, siehe z.B. bei der Computerbase (http://www.computerbase.de/artikel/hardware/multimedia/2008/test_asus_xonar_d2/) Irgendwo stand auch, dass die Xonar EAX 5 via CPU-Emulation bekommen soll, was nochmal extra kostet.

hast du mal geschaut, was für ein testsystem die im januar 2008 genommen haben?

# Prozessor * Intel Pentium 4 3,0 GHz (Northwood-Kern, 130 nm, SSE2, 512 kB Level-2-Cache)
# Motherboard * MSI Neo FIS2R („Intel i875P“-Chipsatz, Sockel 478)

# Arbeitsspeicher * Corsair TwinX1024-3200C2Pro (2x 512 MB, 2-3-2-5, DDR400)

irgendwie hätte ich mir ein anderes testsystem gewünscht - zumindest als gegencheck, ob ein dualcore oder quadcore-pc die asus besser dastehen läßt.

komisch finde ich auch, dass jetzt im 4-kerne-test ein stark übertakteter quad benutzt wird, hier im soundkartentest ein hoffnungslos veralteter singlecore antreten muss. da hätte man mit einem test über mehrere kerne gesehen, ob die softwarelösung weiterhin so hinten liegt.

Ectoplasma

2008-05-20, 23:39:59

Thread Pools sind schon etwas besser. Funktionieren aber in der Regel nur bei Serveranwendungen die viele Clients bedienen gut.

Warum? Anzahl der Worker-Threads = Anzahl der Cores und alles ist gut. Der Witz mit Thread Pools ist doch auch, dass ich vom Software Design einen generischeren Ansatz bekomme, da alle abzuarbeitenden Aufgaben einem simplen Command - Pattern genügen müssen. Ok, man muss den Main-Thread, der die Worker-Thread-Queue füttert, mit einrechnen. Ich denke aber, dass dieser Overhead ziemlich gering im Verhältnis zu den eigentlichen Aufgaben ist.

BAGZZlash

2008-05-20, 23:51:38

Der PCGH-Test ist sehr fragwürdig wenn du dir mal die einzelnen CPU-Ergebnisse anschaust. Sollte man durchaus erwähnen. :)

Könntest Du ein wenig darauf eingehen? Ist's am Ende gar nicht so weit her mit der Multicoreunterstützung von AC?

Ectoplasma

2008-05-21, 00:09:39

In der Theorie funktioniert das natürlich alles so. In der Praxis leider nicht. Sobald diese Threads anfangen miteinander zu kommunizieren (und das ist bei einem Spiel im Gegensatz zu einem Multiclient Server unvermeidlich) verursachen die dafür notwendigen Synchronisationobjekte viel mehr Contextwechsel als beim normalen Zeitscheiben verfahren auftreten.

Richtig. Sie müssen aber nicht mal miteinander kommunizieren. Es genügt auch schon, wenn n - Threads fleißig Gebrauch von new/delete bzw. malloc/free machen. Hoch lebe die Synchronisation :wink:

robobimbo

2008-05-21, 07:59:28

Ectoplasma

2008-05-21, 08:14:30

"Thread Pools" bzw. "Tasks" zum austesten - abgesehen von euren Vorbehalten bezüglich Situationen scheint es doch auch Ansätze zu geben bei denen Thread Pools gut fuktionieren:

Destroy the Castle: http://softwarecommunity.intel.com/articles/eng/1363.htm

Lies doch noch mal die letzten paar Mails in diesem Threads. Dann wirst du feststellen, dass es gar nicht so viele Vorbehalte gibt ;)

Simon

2008-05-21, 08:17:29

hast du mal geschaut, was für ein testsystem die im januar 2008 genommen haben?
Argh, mein Fehler :( Ich dachte, die benutzen ihren Core 2 Quad Extreme, so wie für die Grafikkarten-Tests und hab dann nicht weiter nachgeschaut ;(

Irgendwie testen die ganzen Reviews nur mit diesem Rightmark-Ding:|

Mal ein paar andere Reviews:
1) Hartware.net (http://www.hartware.de/review_734_7.html): XFi immer 5-10% schneller, wobei die EAX 5 berechnet, die Xonar nur max EAX2. (Irgendwie find ich in dem Review das Test System nicht)
2) Bjorn3d (http://www.bjorn3d.com/read.php?cID=1185&pageID=4146): Audigy 2 5-10% schneller als die Xonar, wobei die Audigy 2 EAX 3 kann.

Und der Unterschied zwischen EAX 2 auf 3-5 ist doch recht groß, was die Features angeht, meine ich: http://en.wikipedia.org/wiki/Environmental_audio_extensions

robbitop@work

2008-05-21, 08:34:49

Piffan

2008-05-21, 09:49:59

robbitop@work

2008-05-21, 09:57:59

peanball

2008-05-21, 10:49:08

Die so tolle Skalierung von Spielen mit mehreren Kernen ist AFAIK oft nur Blendwerk. Die Anzahl der Threads ist für Singlecores (und nun anscheinend für Dual Cores auch?) zu hoch. Die Synchronisierung der Threads kostet natürlich CPU Zeit. Die Leistung müßte, wenn man es anders ausgelegt hätte, nicht so einbrechen bei Singlecores. (und nun auch Dualcores)
Ist das nicht gerade das "zukunftssichere" an diesen Engines?
Ich meine wenn ein Spiel von X CPUs profitieren kann - und die aktuelle Entwicklung läuft auch bei den CPU-Herstellern genau in die Richtung - dann sollte man doch von der Mehrleistung profitieren.
Klar verbrät man Leistung für die Verwaltung von Threads und sonstwas aber das zahlt sich doch letztendlich dank der ausgenutzten Leistung von Mehrkernprozessoren aus.
Natürlich werden Single cores dabei benachteiligt, aber schließlich sterben Single cores über kurz oder lang aus bei der aktuellen Entwicklung.
Es wäre also meiner Meinung nach ziemlich fahrlässig für die Entwickler sich zu stark auf single oder maximal dualcores zu beschränken, damit die PC-Zocker mit ihren alten veralteten Möhren auch noch optimal mitmachen können.

Ein etwas gewagter und weit hergeholter Vergleich wär die Forderung nach einem konkurrenzfähigen Software-Renderer, der gegen die brachiale Rechenleistung einer Grafikkarte nicht ankommen würde.
Ironischerweise würde sich der Software-Renderer aber recht gut parallelisieren lassen ;)

Piffan

2008-05-21, 10:56:43

Erazor;6518656']Ist das nicht gerade das "zukunftssichere" an diesen Engines?
Ich meine wenn ein Spiel von X CPUs profitieren kann - und die aktuelle Entwicklung läuft auch bei den CPU-Herstellern genau in die Richtung - dann sollte man doch von der Mehrleistung profitieren.
Klar verbrät man Leistung für die Verwaltung von Threads und sonstwas aber das zahlt sich doch letztendlich dank der ausgenutzten Leistung von Mehrkernprozessoren aus.
Natürlich werden Single cores dabei benachteiligt, aber schließlich sterben Single cores über kurz oder lang aus bei der aktuellen Entwicklung.
Es wäre also meiner Meinung nach ziemlich fahrlässig für die Entwickler sich zu stark auf single oder maximal dualcores zu beschränken, damit die PC-Zocker mit ihren alten veralteten Möhren auch noch optimal mitmachen können.

Ein etwas gewagter und weit hergeholter Vergleich wär die Forderung nach einem konkurrenzfähigen Software-Renderer, der gegen die brachiale Rechenleistung einer Grafikkarte nicht ankommen würde.
Ironischerweise würde sich der Software-Renderer aber recht gut parallelisieren lassen ;)

Ich werde mich da nicht beirren lassen. So lange ein Core- Duo bei Konsolentiteln wie AC gut mithält, ist es mir wurscht, ob vier oder mehr Kerne was bringen. Bei der nächsten Konsolen- Generation wird es vielleicht wieder für den PC eng, wenn er über "zu wenig" Cores verfügt.

Klassische Pc- Anwendungen wie Videoschnitt profitieren natürlich von mehr CPU- Power, von daher werden manche User schon eher aufrüsten. Der Zocker hingegen kann getrost bis zur nächsten Konsolengeneration die Füße still halten. Aufrüsten für zukünftige Spiele war noch nie besonders schlau. :tongue:

Edit: Apropo Dichtung und Wahrheit bei den Anforderungen neuer Spiele: Die Angaben zu den Systemanforderungen von AC sagen, dass AGP nicht unterstützt wird. Lustisch, denn auf meiner X1950XT AGP mit mageren 256mb Vram habe ich nicht den Eindruck, dass die Graka der Flaschenhals ist. Eher das System, vielleicht ist ja die Bandbreite des DDR1- Speichers zu gering, wer weiß....:wink:
Dennoch ist das Spiel in hoher Qualität und befriedigender Performance absolut flüssig spielbar. Gelegentlich geringe FPS- Werte bei Rundblick vom höchsten Turm werden bestimmt auch auf neuester Hardware auftreten.

dargo

2008-05-21, 11:05:06

Könntest Du ein wenig darauf eingehen? Ist's am Ende gar nicht so weit her mit der Multicoreunterstützung von AC?
http://www.pcgameshardware.de/aid,637474/Test/Benchmark/Assassins_Creed_im_PCGH-Test_DX10_schneller_als_DX9_-_aber_nur_mit_minimalen_Details/&menu=browser&image_id=797259&article_id=637474
Ein E6600 kann nicht bei den min.fps langsamer sein als ein E6320. Hat die PCGH da die Werte vertauscht? Mich wundert es sehr, dass es den Redakteuren noch nicht aufgefallen ist.

Piffan

2008-05-21, 11:07:35

Erazor;6518656']Ist das nicht gerade das "zukunftssichere" an diesen Engines?
Ich meine wenn ein Spiel von X CPUs profitieren kann - und die aktuelle Entwicklung läuft auch bei den CPU-Herstellern genau in die Richtung - dann sollte man doch von der Mehrleistung profitieren.
Klar verbrät man Leistung für die Verwaltung von Threads und sonstwas aber das zahlt sich doch letztendlich dank der ausgenutzten Leistung von Mehrkernprozessoren aus.
Natürlich werden Single cores dabei benachteiligt, aber schließlich sterben Single cores über kurz oder lang aus bei der aktuellen Entwicklung.
Es wäre also meiner Meinung nach ziemlich fahrlässig für die Entwickler sich zu stark auf single oder maximal dualcores zu beschränken, damit die PC-Zocker mit ihren alten veralteten Möhren auch noch optimal mitmachen können.

Ein etwas gewagter und weit hergeholter Vergleich wär die Forderung nach einem konkurrenzfähigen Software-Renderer, der gegen die brachiale Rechenleistung einer Grafikkarte nicht ankommen würde.
Ironischerweise würde sich der Software-Renderer aber recht gut parallelisieren lassen ;)

Es ist Unfug zu glauben, dass die Spiele mit der Zahl der Cores unbegrenzt skalieren. Der Unterschied wird zunehmend geringer, irgendwann ist die Zitrone "parallelisierbarer Code" komplett ausgequetscht und weitere Kerne bringen gar nix mehr. Es sei denn, man schiebt den Kernen Aufgaben zu, die bisher Hoheitsgebiet der Graka sind. Nur ist auch da mal Schluss. Am Ende frisst die Revolution ihre Kinder und die Verwaltung der Threads wird zum Nadelöhr. Und spätestens da ist Schluss mit Parallelität....Es kann nur einen geben. ;)

BAGZZlash

2008-05-21, 12:03:33

Der Gag dabei ist, dass gerade die Grafik so richtig schön parallel zu verarbeiten ist. Es könnte also sein, dass man in Konsolen den CPUs Dinge anvertraut, die eigentlich Sache der Graka wären. Für die Performance der Konsole gut, für den PC- Zocker der Zwang zum Vielkerner.....

Das wäre natürlich ein Hammer. Ich kenn' mich mit solchen Portierungen nicht so gut aus. Wäre es denn zwingend nötig, solche Einschränkungen (zumindest für den PC sind es welche) bei einer Portierung mitzunehmen? Anders ausgedrückt: Wie stark wird bei einer solchen Portierung die Engine redesignt?

http://www.pcgameshardware.de/aid,637474/Test/Benchmark/Assassins_Creed_im_PCGH-Test_DX10_schneller_als_DX9_-_aber_nur_mit_minimalen_Details/&menu=browser&image_id=797259&article_id=637474
Ein E6600 kann nicht bei den min.fps langsamer sein als ein E6320. Hat die PCGH da die Werte vertauscht? Mich wundert es sehr, dass es den Redakteuren noch nicht aufgefallen ist.

Danke. (y) Hmm, das ist wirklich merkwürdig.

Es ist Unfug zu glauben, dass die Spiele mit der Zahl der Cores unbegrenzt skalieren. Der Unterschied wird zunehmend geringer, irgendwann ist die Zitrone "parallelisierbarer Code" komplett ausgequetscht und weitere Kerne bringen gar nix mehr. Es sei denn, man schiebt den Kernen Aufgaben zu, die bisher Hoheitsgebiet der Graka sind. Nur ist auch da mal Schluss. Am Ende frisst die Revolution ihre Kinder und die Verwaltung der Threads wird zum Nadelöhr. Und spätestens da ist Schluss mit Parallelität....Es kann nur einen geben. ;)

Richtiger und wichtiger Einwurf. Selbstverständlich geht es nicht immer weiter. Natürlich gilt das Gesetz vom abnehmenden Grenzertrag (http://de.wikipedia.org/wiki/Ertragsgesetz) auch bei Rechenkernen, wie übrigens AMD und Intel selbst hier (http://www.golem.de/0805/59793.html) ausgeführt haben.

Mein Zwischenfazit:
1.) Auch Programmierprofis (es haben sich ja mittlerweile einige hier im Thred zu Wort gemeldet) können das angeblich gute Skalieren der AC-Engine mit mehreren Cores nicht erklären. Hinzu kommt, dass es bei der CB Ungereimtheiten mit der Skalierung drei zu vier Kernen gibt. Dies wäre allenfalls dadurch erklärbar, dass die Engine auf zwei oder vier Kerne zugeschnitten ist, nicht aber auf drei. Da ich mich mit der Praxis der parallelisierten Programmierung nicht gut auskenne, kann ich das nicht beurteilen. Wenn man aber wie weiter oben diskutiert annimmt, dass automatisch verwaltet wird, welcher Kern welche Aufgabe übernimmt (alles Andere wäre eigentlich Blödsinn), ist es wohl eher unwahrscheinlich, dass die Engine per se mit drei Kernen weniger gut klar kommt, als mit vier.

2.) Einige gebrachte Erklärungsversuche für das angeblich gute Skalieren bringen allenfalls teilweise Erklärungen. Die von Piffan eingeworfene Möglichkeit, dass die CPU eventuell einen Teil der Grafikarbeit leisten muss, hat ihren Reiz.
Reizvoll ist auch der Einwurf, dass Sound-, KI- und andere Berechnungen viel CPU-Zeit benötigen. Allerdings kann das meiner Meinung nach nicht wirklich den angeblich massiven Zuwachs auf Quadcores erklären.

3.) Dargo wirft methodische Fehler der CB in die Runde. Dies und die Tatsache, dass es ausser diesem Thread kaum Wirbel um die angeblich gute Skalierung von AC gibt (man stelle sich vor, welchen Werberummel Intel daraus wohl gemacht hätte, sollte AC wirklich so gut skalieren), führt mich zu dem Schluss, dass hier einfach irgendwas nicht stimmt.

Letzlich bleibt es schade, dass die massive Rohleistung, die Multicore-CPUs mit sich bringen, zumindest in Spielen immer noch nicht umgesetzt werden kann. Im Gegenteil, wie Robbitop sagt: Singlecores werden durch den erhöhten Verwaltungsaufwand benachteiligt. Multicoresysteme sind etwas schneller nicht, weil sie mehr Rechenleistung auf die Straße bringen, sondern weil sie nicht so sehr gebremst werden durch die auf Singlecores sinnlose, durch Multicoresysteme nötig gewordene Zusatzarbeit.

Ich hoffe, dass sich hier bald mal was tut. Wie viel Leistungspotential in als Gamermaschinen genutzten Dual- oder Mehrkernsystemen ungenutzt brach liegt, darf man sich gar nicht vorstellen... :frown:

dargo

2008-05-21, 12:08:28

Letzlich bleibt es schade, dass die massive Rohleistung, die Multicore-CPUs mit sich bringen, zumindest in Spielen immer noch nicht umgesetzt werden kann. Im Gegenteil, wie Robbitop sagt: Singlecores werden durch den erhöhten Verwaltungsaufwand benachteiligt. Multicoresysteme sind etwas schneller nicht, weil sie mehr Rechenleistung auf die Straße bringen, sondern weil sie nicht so sehr gebremst werden durch die auf Singlecores sinnlose, durch Multicoresysteme nötig gewordene Zusatzarbeit.

Ich würde diesen Punkt nicht überbewerten. Wer weiß schon wie teuer die Verwaltung wirklich ist.

pest

2008-05-21, 12:13:29

Ich würde diesen Punkt nicht überbewerten. Wer weiß schon wie teuer die Verwaltung wirklich ist.

code doch mal auf nem single-core mit mehreren threads die synchronisiert werden müssen. :rolleyes:, da verliert man massig leistung

dargo

2008-05-21, 12:19:50

code doch mal auf nem single-core mit mehreren threads die synchronisiert werden müssen. :rolleyes:, da verliert man massig leistung
Wenn du dich da so gut auskennst wirst du mir auch sicherlich sagen können wieviel bei dir massig bedeutet.

Piffan

2008-05-21, 12:23:04

Und dann nicht vergessen: Es gibt immer Jobs im Loop der Engine, die aufgrund wechselseitiger Abhängigkeit nicht parallelisierbar sind, da kann komme was wolle. Nada, nix.

Die Frage ist, wie hoch der prozentuale Anteil dieser Abhängigkeiten ist. Gesetzt den FAll, dass er 30 Prozent beträgt, dann kann der Gewinn durch Mehrkern- Systeme maximal die restlichen 70 Prozent beschleunigen. Der harte Kern des nicht parallisierbaren Codes skaliert auschließlich durch mehr Taktzahl.

Man könnte bei den Passagen der wechselseitigen Abhängigkeiten "auf Verdacht im Voraus rechnen" und die Alternative, die aufgrund einer falschen Prognose entstanden ist, verwerfen. Dürfte allerdings eine krasse Herausforderung für die Programmierer sein.

Wenn man Dinge wie Physik oder KI auf die Kerne verteilt, nützt dass nicht allzuviel. Es sei denn man vereinfacht im Bereich der Physik drastisch und setzt den Fokus mehr auf die Effektphysik. Echte Physik des Gameplays geht auf keinen Fall "nebenher", da müssen alle Vorgänge in engen Intervallen abgeglichen werden. Und das kostet ebenfalls viel Zeit.

pest

2008-05-21, 12:27:26

Wenn du dich da so gut auskennst wirst du mir auch sicherlich sagen können wieviel bei dir massig bedeutet.

massig ist abhängig davon wie gut die programmierer waren. du kannst ein Programm nicht auf 1-x Cores gut skalieren lassen. Ein Single Core der mit
einem seriellen Prozess (i/o, spielefluss) beschäftigt ist, und ständig von einem anderen Thread unterbrochen wird, ist damit total überlastet, im Gegensatz dazu, wäre alles vielleicht halb so schlimm, hätte man die Abhängigkeiten (von vornherein) in einem Thread realisiert.

dargo

2008-05-21, 12:33:09

massig ist abhängig davon wie gut die programmierer waren. du kannst ein Programm nicht auf 1-x Cores gut skalieren lassen. Ein Single Core der mit
einem seriellen Prozess (i/o, spielefluss) beschäftigt ist, und ständig von einem anderen Thread unterbrochen wird, ist damit total überlastet, im Gegensatz dazu, wäre alles vielleicht halb so schlimm, hätte man die Abhängigkeiten (von vornherein) in einem Thread realisiert.
Das ist mir alles zu viel Theorie. Schau dir zb. Need for Speed: ProStreet an:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=5658521&postcount=414

Das Spiel lastet beide Cores nahezu zu 100% aus. Dh. es müssen zwangsläufig mehrere Threads gleichzeitig abgearbeitet werden. Trotzdem sehe ich hier überhaupt keinen Nachteil für einen entsprechenden Singlecore.

Edit:
Wobei ich hier erwähnen sollte, dass der SC die vollen 2MB Cache zur Verfügung hat. Dh., mit 1MB Cache bräuchte der SC etwas mehr an Takt um mit dem 1,6Ghz DC gleichzuziehen. Das ist aber in meinen Augen Peanuts.

pest

2008-05-21, 12:39:57

Trotzdem sehe ich hier überhaupt keinen Nachteil für einen entsprechenden Singlecore.

steht ein Post über meinem ;)
je länger die Synchronisationsintervalle, desto weniger Nachteil bei weniger Cores. Früher oder später wird man allerdings versuchen jedem Pups einen eigenen Thread zuzuordnen.

dargo

2008-05-21, 12:43:32

steht ein Post über meinem ;)
je länger die Synchronisationsintervalle, desto weniger Nachteil bei weniger Cores. Früher oder später wird man allerdings versuchen jedem Pups einen eigenen Thread zuzuordnen.
Soweit sind wir noch laaaange nicht. Ich betrachte da eher die aktuellen Games.

BAGZZlash

2008-05-21, 13:16:42

Schau dir zb. Need for Speed: ProStreet an:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=5658521&postcount=414

Das Spiel lastet beide Cores nahezu zu 100% aus. Dh. es müssen zwangsläufig mehrere Threads gleichzeitig abgearbeitet werden.

Ich kenne das Spiel jetzt nicht, aber das muss nicht unbedingt so sein. Man kann auch im Taskmanager eine 100%-Auslastung angezeigt bekommen, ohne dass auch nur irgendwas gerechnet wird. Der Prozess reserviert wohl einfach alle vorhandene Prozessorzeit und schwupps! 100% Auslastung.

Ectoplasma

2008-05-21, 13:21:14

Vielleicht sollte man sich bei der Diskussion nicht einmal überlegen, was überhaupt parallelisierbar ist.

Was beduetet es denn, wenn man für jeden Pups einen Thread haben will? Mehr Threads sind doch nur dann Sinnvoll, wenn es überhaupt parallele Aufgaben gibt oder Ereignisse parallel eintreten können. Letzteres ist bei Games eher nicht gegeben, es sei denn man ordnet jedem Charakter oder jedem Objekt einen eigenen Thread zu.

Interessant für mich wäre allerdings die Frage, welche Grafikaufgaben parallel laufen könnten.

robbitop@work

2008-05-21, 13:33:05

Ich würde diesen Punkt nicht überbewerten. Wer weiß schon wie teuer die Verwaltung wirklich ist.
Synchronisationsvorgänge sind teuer. Das hat mit überbewerten nichts zu tun. Coda oder Demirug haben sich zu dem Thema bereits desöfteren geäußert.

HOT

2008-05-21, 13:50:44

Soweit sind wir noch laaaange nicht. Ich betrachte da eher die aktuellen Games.

Na ja, DRID und DIRT sprechen da aber eine ganz andere Sprache. Auf SingleCores unspielbar, auf DualCores langsam, auf QuadCores optimal. Ich denke, solche Titel beweisen, dass es durchaus machbar ist, die Rechenleistung der Quads (oder mehr) auszunutzen, nur wird das eben zu einem gewissen Preis erkauft. In Zukunft wird das immer wieder so laufen, weil die Konsolen-CPUs nunmal so sind, wie sie sind. Und sie sind nicht umsonst so wie sie sind, das wurde schon alles mit Sinn und Verstand so entwickelt.
Bei diesen Games ist es vor allem so, dass die MinimumFPS bei Quads deutlich steigen, nicht das jemand denkt, die Leistung wäre ungleich verteilt, weil irgendjemand behauptet, es ließe sich nicht alles parallelisieren. Diese Titel beweisen das genaue Gegenteil von dieser Behauptung - je mehr Kerne, desto homogener das Leistungsbild.

Synchronisationsvorgänge sind teuer. Das hat mit überbewerten nichts zu tun. Coda oder Demirug haben sich zu dem Thema bereits desöfteren geäußert.

Das kommt auf die CPU an, wie teuer die letztendlich sind.

mapel110

2008-05-21, 13:56:53

Bei diesen Games ist es vor allem so, dass die MinimumFPS bei Quads deutlich steigen, nicht das jemand denkt, die Leistung wäre ungleich verteilt. Im Gegenteil, je mehr Kerne, desto homogener das Leistungsbild.
Logisch, dann ist man auch wieder mehr GPU-limitiert und die deckelt dann gut. Auflösung auf 800x600 runter und schon hast du wieder deine großen Leistungsschwankungen. ^^

HOT

2008-05-21, 13:59:56

Logisch, dann ist man auch wieder mehr GPU-limitiert und die deckelt dann gut. Auflösung auf 800x600 runter und schon hast du wieder deine großen Leistungsschwankungen. ^^
Das wurde doch alles in 640x480 gebencht. Ich bin nie von was anderem ausgegangen. Das GPU-Limit tritt bei GRID erst sehr spät ein. Das Game ist 100% CPU-limitiert.

Ronny145

2008-05-21, 14:20:52

Na ja, DRID und DIRT sprechen da aber eine ganz andere Sprache. Auf SingleCores unspielbar, auf DualCores langsam, auf QuadCores optimal.

Ich kann Grid auch auf einem läppigen A64 SC spielen. DualCore langsam, aha. Wovon redest du da?

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6497060&postcount=25
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6506591&postcount=65

Sind ja nahezu unglaubliche Unterschiede, also man kann es auch manchmal übertreiben. Wo soll das langsam sein?

Gast

2008-05-21, 15:17:41

Ich kann Grid auch auf einem läppigen A64 SC spielen. DualCore langsam, aha. Wovon redest du da?

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6497060&postcount=25
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=6506591&postcount=65

Sind ja nahezu unglaubliche Unterschiede, also man kann es auch manchmal übertreiben. Wo soll das langsam sein?

versuch das game mal in einer höheren auflösung als 640*480 mit deinen sc zu zocken ;)

Ronny145

2008-05-21, 15:23:48

versuch das game mal in einer höheren auflösung als 640*480 mit deinen sc zu zocken ;)

Auch kein Problem, der CPU ist die höhere Auflösung egal. Du musst zwischen CPU und GPU Limit unterscheiden. Natürlich muss ich das meiste runterstellen, unspielbar bleibt trotzdem falsch.

Gast

2008-05-21, 15:35:46

Bei diesen Games ist es vor allem so, dass die MinimumFPS bei Quads deutlich steigen, nicht das jemand denkt, die Leistung wäre ungleich verteilt, weil irgendjemand behauptet, es ließe sich nicht alles parallelisieren. Diese Titel beweisen das genaue Gegenteil von dieser Behauptung - je mehr Kerne, desto homogener das Leistungsbild.

Es gibt jedoch immer Code, der sich nicht parallelisieren lässt, und man das daher berücksichtigen muss. Das kann ich abschwächen, indem ich mir künstlich weitere Engpässe schaffe. Ein Spiel so zu schreiben, dass es mit 2 Cores schlecht, mit 4 Core hingegen gut performt, ist keine Kunst. Die Kunst ist eher, das auch mit 2 oder gar einem Core gut hinzubekommen.
Es ist auch kein Problem das so hinzubekommen, dass es auf 4 Core schlecht läuft und noch erheblich von 8 cores profitiert. Aber wo liegt da derzeit der Sinn?

versuch das game mal in einer höheren auflösung als 640*480 mit deinen sc zu zocken ;)

Wenn er einen Software-Renderer nutzen sollte, dann haut das natürlich ziemlich rein.

dargo

2008-05-21, 22:56:40

Synchronisationsvorgänge sind teuer. Das hat mit überbewerten nichts zu tun. Coda oder Demirug haben sich zu dem Thema bereits desöfteren geäußert.
Das mag vielleicht bei sehr vielen Threads der Fall sein. Einen kleinen Hinweis darauf gibts auch hier:
http://www.golem.de/0805/59793.html

Bei den heutigen Spielen glaube ich das aber weniger. Und meine Benches beweisen das auch.

Ich kenne das Spiel jetzt nicht, aber das muss nicht unbedingt so sein. Man kann auch im Taskmanager eine 100%-Auslastung angezeigt bekommen, ohne dass auch nur irgendwas gerechnet wird. Der Prozess reserviert wohl einfach alle vorhandene Prozessorzeit und schwupps! 100% Auslastung.
In erster Linie interessieren mich nur die Frames und nicht das was der Taskmanager anzeigt, das ist richtig.

robbitop

2008-05-21, 23:00:14

Bei den heutigen Spielen glaube ich das aber weniger. Und meine Benches beweisen das auch.

Inwiefern beweisen sie das?

dargo

2008-05-21, 23:00:50

Na ja, DRID und DIRT sprechen da aber eine ganz andere Sprache. Auf SingleCores unspielbar, auf DualCores langsam, auf QuadCores optimal. Ich denke, solche Titel beweisen, dass es durchaus machbar ist, die Rechenleistung der Quads (oder mehr) auszunutzen, nur wird das eben zu einem gewissen Preis erkauft. In Zukunft wird das immer wieder so laufen, weil die Konsolen-CPUs nunmal so sind, wie sie sind. Und sie sind nicht umsonst so wie sie sind, das wurde schon alles mit Sinn und Verstand so entwickelt.
Bei diesen Games ist es vor allem so, dass die MinimumFPS bei Quads deutlich steigen, nicht das jemand denkt, die Leistung wäre ungleich verteilt, weil irgendjemand behauptet, es ließe sich nicht alles parallelisieren. Diese Titel beweisen das genaue Gegenteil von dieser Behauptung - je mehr Kerne, desto homogener das Leistungsbild.

Darum gings hier aber nicht. Dass man eine Quad noch gut auslasten kann bezweifelt ja keiner. Es geht um die zukünftigen CPUs mit 8 oder gar 16 Cores. Lese dir den Artikel mal durch. Selbst die Hersteller sagen, dass bei 16 Cores Schluss ist.

dargo

2008-05-21, 23:05:12

Inwiefern beweisen sie das?
Ich teste immer wieviel Taktfrequenz ich beim Singlecore brauche um mit dem 1,6Ghz DC gleichzuziehen. Wenn der DC also 40fps liefert und ein 3,2Ghz SC auch dann sehe ich hier keine Nachteile für den SC was die Synchronisation betrifft. Wäre die Synchronisation teuer müsste der SC viel mehr Takt brauchen um diese 40fps zu erreichen. Ich beziehe mich hier natürlich nur erstmal auf den SC/DC Vergleich. Der Aufwand der Synchronisation mag bei einem 4- oder gar 8-Kerner ganz anders aussehen.

robbitop

2008-05-21, 23:09:54

Ich teste immer wieviel Taktfrequenz ich beim Singlecore brauche um mit dem 1,6Ghz DC gleichzuziehen. Wenn der DC also 40fps liefert und ein 3,2Ghz SC auch dann sehe ich hier keine Nachteile für den SC was die Synchronisation betrifft.
Dieser Logik kann ich nicht folgen.

Ich sage ja nicht, dass 100% durch Synchronisierung anfallen. Aber ein beachtlicher Teil. Wenn Demirug als EA-Entwickler sowas schon in den Mund nimmt, wird das auch Hand und Fuß haben.

dargo

2008-05-21, 23:17:20

Dieser Logik kann ich nicht folgen.

Ich sage ja nicht, dass 100% durch Synchronisierung anfallen. Aber ein beachtlicher Teil. Wenn Demirug als EA-Entwickler sowas schon in den Mund nimmt, wird das auch Hand und Fuß haben.
Dann verstehen wir wohl unter teuer was anderes. :)
Ich mag diese Begriffe teuer, massig, viel nicht besonders. Mit Zahlen bzw. Prozenten kommt man der Sache schon näher. Um es mal auf den Punkt zu bringen - wenn durch die Synchronisation mir ein einstelliger Prozentsatz an Leistung flöten geht dann finde ich das in Ordnung, vorallem wenn man weiß, dass die Technologie keine höheren Frequenzen bzw. effizientere CPUs mit weniger Cores (im Idealfall also SC) zulässt.

Kleine Ergänzung:

Bei Bioshock
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=5658521&postcount=414

sieht es schon etwas anders aus. In der getesteten Szene scheint der SC schon ~10% mehr Takt (den Cache-Unterschied schon berücksichtigt) zu brauchen um die gleichen Frames eines 1,6Ghz DC zu liefern.

Demirug

2008-05-21, 23:36:52

Man kann SC und DC nicht direkt vergleichen weil sich „gute“ Software von sich aus schon anders verhält. Ich würde bei einem SC nie auf die Idee kommen einen Workerthread zu starten. Man führt dann die entsprechenden Jobs direkt aus und die Sync Objekte sind Dummys die nichts tun. Zudem verhält sich das Betriebssystem auch anders. Während bei einem SC niemals zwei Threads gleichzeitig auf ein Sync Objekt zugreifen können geht das beim einem MC natürlich. Entsprechend ist die Implementierung der Syncobjekte auch unterschiedlich.

Was nun die Verluste angeht so kann man ganz leicht einen Quadcore auf 90% treiben und dann langsamer sein als vorher ohne multicore „Optimierung“. Da muss man höllisch aufpassen was man macht. Vor allem da das Windows Multithreading so ein paar Eigenheiten hat die daher kommen das es ursprünglich für Server (also hohen IO Durchsatz mit multiplen Clients) und nicht für Hochleistung Clients (eine Anwendung mit heftigen Anforderungen an Bandbreite und Rechenleistung) entworfen wurde.

Aquaschaf

2008-05-22, 00:55:54

Ich denke, solche Titel beweisen, dass es durchaus machbar ist, die Rechenleistung der Quads (oder mehr) auszunutzen

Rechenleistung von n Cores zu nutzen ist ja keine hohe Kunst. Die Frage ist ob man sie sinnvoll ausnutzt. Dass diese Spiele mehrere Cores brauchen beweist nicht dass es keine Implementierung gibt die das selbe auf weniger Cores genauso schnell schafft.

Zur Zeit wird - denke ich - fast ausschließlich der Grad der Parallelität fest im Design verankert (und das macht ja auch Sinn für XBox360 und PS3). Dann ist es mit der Skalierung nach unten oder oben sehr schlecht bestellt. Das heißt die Tatsache dass manche Spiele mit 1 oder 2 Cores so schlecht laufen heißt nicht man bräuchte für diese Spiele prinzipiell mehr Cores, sondern dass die Software für mehr Cores designt wurde. In Zukunft dürfte der Trend in Richtung n-Core-Parallelität gehen, dann könnten Spiele wieder besser nach unten skalieren.

robbitop@work

2008-05-22, 08:21:24

Dann verstehen wir wohl unter teuer was anderes. :)
Ich mag diese Begriffe teuer, massig, viel nicht besonders. Mit Zahlen bzw. Prozenten kommt man der Sache schon näher.
Das Problem ist, dass es eben auf viele Randbedingungen ankommt. So läßt sich nicht mal eben dieser Faktor generell quantifizieren. Vermutlich nichtmal für eine Anwendung, da es von der jeweiligen Szene abhängt.

Vieleicht ließe sich pro Spiel eine grobe Spannweite definieren, was Synchronisation kostet. Vieleicht kann sich Demirug mal dazu äußern. Es ist jedenfalls nicht irrelevant.

Um es mal auf den Punkt zu bringen - wenn durch die Synchronisation mir ein einstelliger Prozentsatz an Leistung flöten geht dann finde ich das in Ordnung, vorallem wenn man weiß, dass die Technologie keine höheren Frequenzen bzw. effizientere CPUs mit weniger Cores (im Idealfall also SC) zulässt.
Es sollte locker im zweistelligen Bereich liegen. Man müßte die Anzahl der Threads dynamisch mit der Anzahl der Kerne skalieren. Dann hätte man das Problem nicht. Das würde gewiss wieder etwas Entwicklungszeit kosten.

Wenn man sich mal Amdahls Law anschaut und im Hinterkopf behält, was für Interdependenzen in den mathematischen Algoritmen, die in Spielen hauptsächlich vorkommen, vorhanden sind, sollte einem schnell klar werden, dass eine solche Skalierung so nicht hinhauen kann.

Natürlich ist es gut, wenn Multi-CPUs auch genutzt werden. Allerdings sind diese Skalierungen Augenwischerei. Single-Cores müßten nicht so einbrechen, wenn auch für diese mitentwickelt worden wäre.
Dass ich privat einen Quadcore besitze, ändert an dieser technischen Meinung wenig.

Ectoplasma

2008-05-22, 10:37:08

Es sollte locker im zweistelligen Bereich liegen. Man müßte die Anzahl der Threads dynamisch mit der Anzahl der Kerne skalieren. Dann hätte man das Problem nicht. Das würde gewiss wieder etwas Entwicklungszeit kosten.

Jein. Der Aufwand sollte bei n > 1 egal sein. Es kann einen Aufwand zwischen SC und MC geben, wenn man auch speziell für SC optimieren will. Ansonsten sollte man einmal sein Software-Design überdenken.

Demirug

2008-05-22, 11:03:02

Das Problem ist, dass es eben auf viele Randbedingungen ankommt. So läßt sich nicht mal eben dieser Faktor generell quantifizieren. Vermutlich nichtmal für eine Anwendung, da es von der jeweiligen Szene abhängt.

Vieleicht ließe sich pro Spiel eine grobe Spannweite definieren, was Synchronisation kostet. Vieleicht kann sich Demirug mal dazu äußern. Es ist jedenfalls nicht irrelevant.

Ich schrieb doch schon das die Synchronisation so teuer werden kann das sie am Ende mehr Zeit benötigt als die Aufgabe die man löschen will. Im Gegenzug kann man unter entsprechenden Voraussetzungen auch mit so wenig Synchronisation auskommen das sie nicht ins Gewicht fällt.

Es sollte locker im zweistelligen Bereich liegen. Man müßte die Anzahl der Threads dynamisch mit der Anzahl der Kerne skalieren. Dann hätte man das Problem nicht. Das würde gewiss wieder etwas Entwicklungszeit kosten.

Natürlich hat man das Problem dann immer noch. Mit steigender Threadanzahl steigt auch der Synchronisationsaufwand unabhängig von der Anzahl der Kerne die zum abarbeiten der Threads benutzt werden. Bei mehr workerthreads (IO Threads sind da etwas anderes) als Cores kommt dann zusätzlich noch der Overhead für die Contextwechsel hinzu. Was man allerdings auch nicht vergessen darf ist das mit steigender Anzahl von Cores die Wahrscheinlichkeit zunimmt das zwei oder mehr davon zum gleichen Zeitpunkt die gleichen synchronisierten Daten benutzten wollen. Dies treibt die Synchronisationskosten noch weiter nach oben.

Wenn man sich mal Amdahls Law anschaut und im Hinterkopf behält, was für Interdependenzen in den mathematischen Algoritmen, die in Spielen hauptsächlich vorkommen, vorhanden sind, sollte einem schnell klar werden, dass eine solche Skalierung so nicht hinhauen kann.

Die Argumentation mit Amdahl im Umfeld von Computerspielen ist komplex. Amdahl untersuchte die Frage wie weit sich die Zeit bis zum Ergebnis durch zusätzliche Prozessoren verringern lässt (ms/Frame). Bei einem Computerspiel will man primär jedoch in der gleichen Zeit mehr Ergebnisse (Frames/s). Oder um es etwas anschaulicher zu machen. Amdahl wollte wissen wie schnell ein einzelnes Auto gebaut werden kann wenn man unterschiedlich viele Arbeiter an diese Aufgabe setzt. Wir wollen allerdings wie Henry Ford viele Autos in möglichst kurzer Zeit bauen. In seiner Autofabrik setzte er dafür bekanntermaßen ein Fließband ein und bei Spielen nutzt man ähnliche Verfahren um die FPS zu steigern. Amdahls Law ist daher nur begrenzt anwendbar. Es gilt lediglich wenn die gesamte multicore Optimierung nur aus dem Einsatz von klassischem Fork und Join besteht.

Natürlich ist es gut, wenn Multi-CPUs auch genutzt werden. Allerdings sind diese Skalierungen Augenwischerei. Single-Cores müßten nicht so einbrechen, wenn auch für diese mitentwickelt worden wäre.
Dass ich privat einen Quadcore besitze, ändert an dieser technischen Meinung wenig.

Man muss auch hier etwas vorsichtig sein. Die Anzahl der Threads die ein Spiel erzeugt sagt nicht zwingend etwas über den Grad der multicore Optimierung aus. So hat man auch bei einem Singelcore einige zusätzliche IO Threads. Das prominenteste Beispiel sind hier sicherlich Threads zur Soundausgabe. Da sich eine Unterbrechung im Datenstrom hier äußerst schlecht auswirken würde nutzt man Threads die notfalls auch den Hauptthread unterbrechen dürfen um zu verhindern dass der Ausgabepuffer leer läuft. Eine fehlende Berücksichtigung von Singlecores erkennt man daher nicht an der Anzahl von Threads sondern an der Anzahl von Contextwechsel welche von diesen durchgeführt werden.

mapel110

2008-05-22, 11:22:40

Das prominenteste Beispiel sind hier sicherlich Threads zur Soundausgabe. Da sich eine Unterbrechung im Datenstrom hier äußerst schlecht auswirken würde nutzt man Threads die notfalls auch den Hauptthread unterbrechen dürfen um zu verhindern dass der Ausgabepuffer leer läuft.
Aha. Und das wird wohl schon sehr lange so gehandhabt. Deswegen läuft häufig der Sound weiter, wenn das Game eigentlich abgeschmiert ist. Sry4Offtopic, aber das fand ich jetzt mal sehr interessant. Weitermachen... :weg:

/edit
http://www.tecchannel.de/webtechnik/entwicklung/1758836/
Tecchannel hat gerade einen Artikel über Multi-Core-Programmierung online.

Gast

2008-05-22, 18:18:14

Ein E6600 kann nicht bei den min.fps langsamer sein als ein E6320. Hat die PCGH da die Werte vertauscht? Mich wundert es sehr, dass es den Redakteuren noch nicht aufgefallen ist.

doch kann er, die messdauer der min-fps ist für einen aussagekräftigen wert viel zu kurz, und hat eine recht große zufallskomponente, da kann es schon mal passieren, dass in einem durchlauf das eigentlich langsamere system die höheren min-fps erzeugt.

Gast

2008-05-22, 18:21:38

Das wäre natürlich ein Hammer. Ich kenn' mich mit solchen Portierungen nicht so gut aus. Wäre es denn zwingend nötig, solche Einschränkungen (zumindest für den PC sind es welche) bei einer Portierung mitzunehmen? Anders ausgedrückt: Wie stark wird bei einer solchen Portierung die Engine redesignt?

sehr unwahrscheinlich, dass man das ganze so machen würde, konsolen-cpus sind verhältnismäßig schwach, da wird man ihnen kaum noch zusätzliche aufgaben aufhalsen.

beim cell ginge dass eh nur über die auslastung der SPEs, dann ist eine anpassung auf "normale" cpus unumgänglich.

Gast

2008-05-22, 18:36:08

Wenn der DC also 40fps liefert und ein 3,2Ghz SC auch dann sehe ich hier keine Nachteile für den SC was die Synchronisation betrifft.

synchronisation ist immer böse, egal ob ein SC oder ein MC daran rechnet. es nützt recht wenig wenn zwar auf jedem kern ein thread läuft, diese ihre arbeit aber icht machen können, weil sie dazu ein objekt brauchen, welches gerade von einem anderen thread blockiert wird. auf einem MC ist die wahrscheinlichkeit natürlich höher, dass der blockierende thread das objekt schnell wieder freigibt, während bei einem SC zwingend erstmal ein oder mehrere contextwechsel notwendig sind bis der thread der arbeiten darf auch an die reihe kommt.

dargo

2008-05-22, 18:52:45

doch kann er, die messdauer der min-fps ist für einen aussagekräftigen wert viel zu kurz, und hat eine recht große zufallskomponente, da kann es schon mal passieren, dass in einem durchlauf das eigentlich langsamere system die höheren min-fps erzeugt.
Woher kennst du die Messdauer? Ich habe dazu bei PCGH nichts gefunden. Zu lange Messdauer wirkt sich aber auch negativ bei CPU-Benches aus. Ich verwende da immer nur 5 Sekunden.

Gast

2008-05-22, 19:27:54

Woher kennst du die Messdauer?

minimal sagt ja schon, dass die messdauer extrem kurz ist, sonst wären es ja nicht die minimalen fps.

dargo

2008-05-22, 19:47:42

minimal sagt ja schon, dass die messdauer extrem kurz ist, sonst wären es ja nicht die minimalen fps.
Hä? Was ist das denn für eine Logik? :confused:
Hast du schon mal mit Fraps gebencht? :)

Ich kann die Benchdauer auf 30 Minuten einstellen, trotzdem spuckt mir Fraps die min.fps aus, eben aus einer Szene wo die Frames am tiefsten waren.

Gast

2008-05-22, 22:05:38

Ich kann die Benchdauer auf 30 Minuten einstellen, trotzdem spuckt mir Fraps die min.fps aus, eben aus einer Szene wo die Frames am tiefsten waren.

und? die restlichen 30min haben auf die min-fps keinen einfluss.

Coda

2008-05-22, 22:12:49

Die Argumentation mit Amdahl im Umfeld von Computerspielen ist komplex. Amdahl untersuchte die Frage wie weit sich die Zeit bis zum Ergebnis durch zusätzliche Prozessoren verringern lässt (ms/Frame). Bei einem Computerspiel will man primär jedoch in der gleichen Zeit mehr Ergebnisse (Frames/s). Oder um es etwas anschaulicher zu machen. Amdahl wollte wissen wie schnell ein einzelnes Auto gebaut werden kann wenn man unterschiedlich viele Arbeiter an diese Aufgabe setzt. Wir wollen allerdings wie Henry Ford viele Autos in möglichst kurzer Zeit bauen. In seiner Autofabrik setzte er dafür bekanntermaßen ein Fließband ein und bei Spielen nutzt man ähnliche Verfahren um die FPS zu steigern. Amdahls Law ist daher nur begrenzt anwendbar. Es gilt lediglich wenn die gesamte multicore Optimierung nur aus dem Einsatz von klassischem Fork und Join besteht.
Meinst du dass man bestimmte Dinge ein oder zwei Frames im vorraus berechnet?

Sonst versteh ich nicht was du als Analogon zu Autos verwendest in der Metapher.

dargo

2008-05-22, 22:20:33

und? die restlichen 30min haben auf die min-fps keinen einfluss.
:confused:

Jetzt verstehe ich dich überhaupt nicht mehr. Wer sagt denn, dass die min.fps immer in der ersten Benchsekunde auftauchen?

Demirug

2008-05-23, 10:59:04

Meinst du dass man bestimmte Dinge ein oder zwei Frames im vorraus berechnet?

Sonst versteh ich nicht was du als Analogon zu Autos verwendest in der Metapher.

Man berechnet eigentlich nicht im voraus sondern akzeptiert die zusätzliche Latenz. Aber solche Verfahren fallen in die Kategorie in denen Amdahls Law nicht mehr gültig ist. Ich habe den Bezug zum Fließband gemacht weil man das ganze auch gerne als Pipelineing bezeichnet. Die Idee ist mehr oder minder aus dem Chipdesign geklaut. Dort zerlegt man ja bekanntermaßen lange sequenzielle Vorgänge in Pipelinestufen um den Durchsatz auf Kosten der Latenz zu steigern.

Allerdings skalieren solche Verfahren sehr schlecht da man, genügend freie Rechenleistung auf dem zusätzlichen Kern vorausgesetzt, schon mit einem Kern das maximum erreicht. Beim Fork and Join hat man ja theoretisch mit steigender Kernanzahl immer noch einen Gewinn. Wenn dieser auch immer kleiner wird und in der Praxis vom steigenden Overhead kompensiert wird.

Aus der Sicht der Performance ist Pipelineing immer dem klassischen Fork and Join vorzuziehen. Allerdings ist letzteres einfacher zu realisieren.

Gast

2008-05-23, 12:22:33

Jetzt verstehe ich dich überhaupt nicht mehr. Wer sagt denn, dass die min.fps immer in der ersten Benchsekunde auftauchen?

niemand, aber sie beziehen sich auf einen zeitraum von <1s, sagen also über die eigentlich 30minütige szene nichts aus.

das wäre ungefähr das selbe wenn kimi raikonnen in einer runde die schlechteste zeit des gesamten feldes fährt, im restlichen rennen aber allen auf und davonfährt. wäre jetzt die aussage, dass er der schlechteste fahrer des rennens ist richtig, nur weil das auf eine einzige runde zutrifft?

oder anders ausgedrückt: ich mach eine meinungsumfrage, befrage dabei aber nur eine einzige person und stelle diese antwort als ergebnis dar.

um eine vernünftige aussage über eine messung tätigen zu können brauche ich eine möglichst große anzahl an messungen, die min-fps reduzieren aber gerade diese auf ein minimum und sind deshalb für eine vernünftige aussage nicht zu gebrauchen.

Gast

2008-05-23, 12:25:31

Spielecode ist lange nicht so toll parallelisierbar, wie diese Benches zeigen. Die alten CPUs werden vor allem benachteilt.

naja, man könnte immer noch eine art software-AFR machen, der input-lag ist dann zwar nicht mehr so schön, die framerate sollte in cpu-limitierten szenarien aber wunderbar skalieren. andererseits macht man ja auch auf der GPU AFR mit bis zu 4 karten, und mehr als 4 kerne haben wir bei der cpu ja auch noch nicht.

Gast

2008-05-26, 10:08:43

niemand, aber sie beziehen sich auf einen zeitraum von <1s, sagen also über die eigentlich 30minütige szene nichts aus.

das wäre ungefähr das selbe wenn kimi raikonnen in einer runde die schlechteste zeit des gesamten feldes fährt, im restlichen rennen aber allen auf und davonfährt. wäre jetzt die aussage, dass er der schlechteste fahrer des rennens ist richtig, nur weil das auf eine einzige runde zutrifft?

oder anders ausgedrückt: ich mach eine meinungsumfrage, befrage dabei aber nur eine einzige person und stelle diese antwort als ergebnis dar.

um eine vernünftige aussage über eine messung tätigen zu können brauche ich eine möglichst große anzahl an messungen, die min-fps reduzieren aber gerade diese auf ein minimum und sind deshalb für eine vernünftige aussage nicht zu gebrauchen.

Die Analogie zur Formel1 ist hier aber falsch. Wenn ich UT Spiele und auf einem System an bestimmten Stellen niedrige FPS habe macht es das Spiel für mich unspielbar. Auf dem anderen System, das im Durchschnitt weniger FPS hat, aber höhere min FPS hat, ist es dann noch spielbar.
Min FPS sind also gerade deswegen wichtig. Man muss natürlich mehrere Messungen durchführen, damit man nicht zufallsbedingt an manchen Stellen FPS Einbrüche kriegt, weil Windows gerade etwas auslagert o.ä..