Hallo,
immer wieder lese ich ein paar Gerüchte, die nicht immer so ganz stimmen. Ich mache mal einen Sammelfred auf, worauf man dann im Zweifel verlinken kann. Bitte fühlt euch frei Fehler zu korrigieren oder Anmerkungen zu machen, ich ergänze es dann.


1. Hauptspeicher, Grafikspeicher und 32-Bit-Betriebssystem

(Solange das Mainboard Memory-Remapping beherrscht und es aktiviert wurde: )

Nein, der Grafikspeicher wird nicht direkt vom Hauptspeicher abgezogen.
Nein, bei SLI oder Crosfire wird der Grafikspeicher nicht direkt doppelt abgezogen.

Der maximal verfügbare Speicher hängt vom Mainboard und den installierten Komponenten ab. Deshalb kann man keine pauschale Aussage machen, wieviel von 4 GByte übrig bleiben.

Beispiel:
XP 32 Bit mit 4 GByte und 7950 GT 512 = 3.5 GByte frei
XP 32 Bit mit 4 GByte und 9600 GT 1024 = 3.6 GByte frei

Eine detaillierte Erklärung zur Verwaltung von Komponenten und deren Zusammenhang mit dem Hauptspeicher hat 7oby weiter unter gegeben.


2. Brauche ich Grafikspeicher mit 1024 MByte
Die Diskussion macht überhaupt keinen Sinn, wenn ihr sowieso nur mit 1680x1050 Pixel spielt. Durch AA braucht man bis zu 512 MByte, ohne AA würden auch 256 MByte bis 1920x1200 Pixel reichen.

Keine der aktuellen Grafikkarte hat genug Power um bei 2560x1600 mit AA und neuen Spielen flüssig zu laufen, wodurch der Speicher eigentlich unnötig ist. Hätten sie nur 512 MByte, würden sie allerdings noch schlechter laufen.


3. Die 4800er ist 70% schneller als die 9800 GTX
Ja und nein, sie ist in den Standard-Auflösungen 1280-1920 zwischen 5-25% schneller. Es gibt ein paar Auflösungen mit bestimmten Spielen und einer bestimmten Qualitätseinstellung wo sie bis zu 70% schneller ist. Es kommt auch auf die CPU an, die zum Test verwendet wurde. Quad Core Extreme Edition mit 4 GHz oder C2D mit 3 GHz.

Nur weil eine 7950 GT 480% schneller als eine 6800 GT ist, ist sie deshalb nicht die Überkarte. Von 3 auf 6 fps sind schon 100% besser, von 1 auf 10 fps wäre schon 10x schneller. Man muss die Gesamtleistung betrachten und nicht ein Einzelergebnis zitieren.

Mit Standard-CPU sind die aktuellen Karten in den Standardauflösungen 1280 und 1680 fast gleich schnell, spürbare Unterschiede gibt es mit Kantenglättung (AA) und in höheren Auflösungen.


4. Die 4870 verbraucht weniger Strom und wird nicht so warm

Letzter Stand, im 2D-Bereich verbraucht die 4870 bis zu 30 Watt mehr als eine GTX 280. Die 4870 hat einen sehr starken Kühler und ihr Temperaturbereich liegt zwischen 76 und 83 Grad. Der Lüfter muss im 3D-Modus sehr schnell kühlen.


5. Die 4850 ist die bessere Karte

Bei schlecht belüfteten Midi-Gehäusen nicht, die Karte bläst wie die 8800 GT die komplette Abwärme ins Gehäuse.

Amen! Danke!

Hammer! Zahlen gelesen.

Meint ihr, dass sich das Thema lohnt nochmal in einem Artikel aufzubereiten? C2D vs. Q2Q bei modernen Games und den neueren Karten GTX 2x0; AMD 48x0

So'n paar Tabellen, wo man pro Game und Grafikkarte erkennen kann was für einen C2D und Q2D man bräuchte für welche fps Rate?

Nicht verzetteln mit zu vielen Games. Max. 4 Games. Die Prozessoren, Taktraten und evtl. sogar Auflösung + AA sorgt schon für eine große Testmatrix.

Meine Rede

Der Vergleich trifft sogar im Office-Bereich zu. Der E8400 ist beim Erstellen von PDFs (über Adobe Acrobat, z.B. aus Office heraus) ein ganzes Stück lahmer als ein Quad im Originaltakt. Und der Rechner ist während der Erstellung quasi lahmgelegt, beim Quad nicht. Ich bereue es wirklich, mich noch einmal für einen Dualcore entschieden zu haben. Da die Softwareanbieter offensichtlich doch mal anfangen, geeignete Vorgänge zu parallelisieren, ist man selbst mit einem "alten" Quad auf der trockeneren Seite des Datenflusses

@procarion
Deine Karte schon angekommen?

@7oby
Habe ich auf jeden Fall vor, mich würde es brennend interessieren woher der fps-Gewinn kommt.

Wohl hauptsächlich daher, dass man die Engine parallelisiert hat. Es ist nicht sonderlich schwierig ein sehr umfangreiches Programm in kleinere Stücken zu Hacken, Synchronisationsschnittstellen einzufügen und von den Multi-Cores zu profitieren. Nur ist es so, dass man bei den Teilungen nicht gleichgroße Stücke rausbekommt:

Eine Riesen Singlethreaded Anwendung in zwei Stücke geteilt ergibt dann vielleicht in Auslastung (nicht in Lines of Code) gesprochen eine 80% : 20% Teilung. Das kommt daher, dass man sich die Teilungen dort aussucht wo's einfach ist (= wo möglichst wenig ineinander verzahnt ist). Auf vier Teilungen zu kommen ist nicht schwierig. Nur kann die auch so aussehen: 5% : 5% : 15% : 75%. Die läuft auf einem C2D und C2Q bei gleicher Taktrate ziemlich genau gleich schnell. Die 75% Last kann gleichzeitig nur auf einem Core laufen. Der Gewinn der beiden 5% wiegt die Synchronisationsarbeit und die Cache Misses auf.

Word, Firefox usw. haben >20 Threads. Ist ein schlechtes Beispiel, da keine Game Engine.

Teilt man immer weiter, sieht das vielleicht so aus:
5% : 5% : 5% : 10% : 15% : 15% : 20 % : 25%

Die 25% laufen auch nur auf einem Core, aber die anderen lassen sich flexibel aufteilen. Das macht as OS von selbst (man braucht nicht unbedingt eine Core Affinität zu definieren; macht bei Games aber Sinn, wenn man weiß wo man z.B. von einem gemeinsamen Cache profitiert). Das Ding läuft dann schon doppelt so schnell auf einem etwa gleichgetaktetem C2Q gegenüber C2D.

In Deinem Beispiel oben sich ja doch nur zwei SSE3 Prozessoren beteiligt.

Ich kenne SSE4 sehr genau aus dem Videobereich. Zwar ist richtig, dass es DivX und TMPEG-Enc Benchmarks gibt, wo SSE4 gut und gerne 40% gegenüber einer SSE3 Implementierung gewinnt. Allerdings ist es eine Farce. Diese 40% Zuwachs gelten für die dümmste aller Algorithmen: Den ESA (Exhaustive Search Algorithm) bei der Motion Estimation. Ein SSE3 SEA (Successive Elimination Algorithm) bringt exakt das gleiche Ergebnis und zwar schneller (!) als ein SSE4 ESA.

Natürlich sind Games anders und ich will es nicht ausschließen, dass SSE4 dort etwas bringen kann, allerdings ist es sehr, sehr, sehr, sehr, sehr unwahrscheinlich. Es gibt zu viele andere Schrauben (s. oben Multi-Threading), die wesentlich mehr bringen. Gerade im Hinblick auf 8-fach, 16-fach Nehalem mit Hyperthreading.

Jeder Core im C2D oder C2Q hat gleichviel Cache (wenn man mal die kastrierten Versionen weglässt bzw. diese untereinander vergleicht) nämlich bei den 45nm 6MB. Die zweiten 6MB sind für einen bestimmten Core nicht nutzbar. Bei ungeschickter Threadaufteilung wird's sogar langsamer, da der Datenaustausch dann über den Hauptspeicher und nicht den 2nd Level Cache erfolgt.

Viel Cache ist für's Gamen wichtig geworden, aber C2D und C2Q haben ca. gleichviel. In der Praxis können bei geschickter Wahl natürlich auch unterschiedliche Daten im Cache liegen, so dass die Cache-Hits ansteigen.

Schon eher. Wie gesagt: C2D vs. C2Q wäre interessant. Klar kann man auch 1MB vs. 2MB vs. 4MB Cache (bzw. 3MB vs. 6MB) vergleichen, aber das habt ihr eh schon in den Games getan:
http://www.tomshardware.com/de/Pen [...] 062-3.html

sorry, für's Offtopic werden.

CB erreicht ähnlich hohe Werte, allerdings mit 4 GHz OC, was ich nachvollziehbarer finde, als die 3GHz-Werte mit QX6850.

Im Crosstest mit dem Q6600 hatte ich noch Crysis Patch 1.2 nicht 1.21. Dort hat die Quad Core nicht reagiert und sich kaum vom C2D unterschieden. Die QX macht jetzt mit den neuen Karten einen richtigen Sprung. Laut Angaben zum Patch 1.21 wurde nur eine Sicherheitslücke im Multiplayer geschlossen und keine Veränderung am Game vorgenommen.

Der Leistungsprung ist jedenfalls ungewöhnlich, für einen CPU-Wechsel ein gewaltiges Potential. Bei 16 auf 26 fps würde es sich rechnen auf eine neue Quad Core umzusteigen.

Widerspricht auf jeden Fall den Ergebnissen im letzten Crosstest mit Q6600:
http://www.tomshardware.com/de/CPU [...] 02-16.html

Wenn es am Patch 1.21 liegt, hatte Crytek die 4 Core Unterstützung wohl schon im Game und gibt sie jetzt erst frei. Das wäre ein echter Hammer, gewollte Täuschung? um die Ergebnisse der neuen 3D-Karten nach oben zu jagen.

Moin

@7obi
Du verteilst jetzt nicht die 100% Last auf 4 Kerne mit jeweils
Kern 1: 75%
Kern 2: 15%
Kern 3: 5%
Kern 4: 5%
oder? Wenn die Auslastung einer Anwendung auf einem Quadcore so aussieht, ist die Anwendung definitiv NICHT parallelisiert. Die Verteilung kommt vom Windows.
Insgesamt wird der komplette Quadcore Prozessor dabei zu 25% belastet, also quasi nur einem Kern. Erst, wenn eine Anwendung mehr als 75% belegt, ist sie auch für den Mehrkernbetrieb ausgelegt. Außer die Software die explizit nur 2 Kerne anspricht, diese dümpelt dann bei 50% herum.

Beim Video encodieren (in diesem Fall DivX)
siehts doch schon mal ganz gut aus

Hab's nicht gut erklärt, wollte nicht zuviel offtopic schreiben. Gemeint war etwas anderes:

Eine Anwendung/Spiel kann Arbeit von mehreren Cores erledigen lassen, indem es diese Arbeit in Prozesse oder Threads aufteilt. Das Betriebssystem verteilt diese auf die zur Verfügung stehenden Cores.

Die Arbeit, die zu verrichten ist, entspricht 100%. Diese habe ich in exemplarische vier Teile zerlegt. Den Teilen geben wir noch Namen:

T1 ist 75% der Gesamtarbeit
T2 ist 15% der Gesamtarbeit
T3 ist 5% der Gesamtarbeit
T4 ist 5% der Gesamtarbeit

Zusammen ergibt diese Arbeit 100%. T entspricht dabei zufällig der Assoziation Thread. Das Betriebssystem verteilt nun diese Threads auf verschiedene Cores. Eine exemplarische Verteilung könnte wie folgt aussehen:

DualCore:
Core1 : T1
Core2 : T2, T3, T4

QuadCore:
Core1 : T1
Core2 : T2
Core3 : T3
Core4 : T4

Im Fall des DualCores entspricht T2 + T3 + T4 = 25% < 75%. Obwohl sich T2, T3, T4 alle einen Core teilen müssen, muss T1 praktisch nie auf die anderen warten oder hat keinen freien Timeslot zum Rechnen auf einem Core.

Der Gesamtperformancegewinn gegenüber SingleCore ist in diesem Beispiel: 33% (= 100%:75% - 1)

Völlig egal ob das Ding auf einem DualCore oder QuadCore läuft. Ca. 33% Performancegewinn.

Diese Modellrechnung beachtet weder die Betriebssystem-Grundlast, noch Reibungsverluste durch Synchronisieren noch die Tatsache, dass jeweils zwei Cores einen 2nd Level Cache teilen.

Mein erstes Beispiel beschäftigt mit 4 Threads bis zu 4 Kerne gleichzeitig. Trotzdem ist es nicht schneller als auf dem DualCore.

Kernproblem beim Multithreaden ist: Die Arbeitsaufteilungen, die ich wähle, werden die Last im allgemeinen nicht gleichmäßig aufteilen. Manche Vorgänge lassen sich praktisch gar nicht aufteilen (z.B. Syntax-Parsen oder bestimmte verlustlose Kompressionen). Andere Vorgänge lassen sich besser aufteilen, sind aber aus Synchronisationsicht schlecht oder skalieren nicht (Beispiel: Du stehst an einer Kasse mit einem riesen Wocheneinkauf. Drei offene Kassen und deren KassiererInnen erlauben Dir den Gesamteinkauf zu dritteln und jede kassiert einen Teil gleichzeitig. Blöderweise musst jeweils mit Deiner EC Karten PIN 3x getrennt an jeder Kasse bezahlen. Das skaliert genau so lange wie der Teil den Du auf eine andere Kasse verteilst langsamer durch die anderen bereits arbeitenden Kassen gezogen würde als 1x zusätzlich zu bezahlen dauert. In der Praxis vielleicht 2-3 KassierInnen).

Anhaltspunkte für's Aufteilen findet man durch Nachdenken oder Profiling Tools.

Videokompression allgemein (DivX, H.264) lässt sich hervorragend aufteilen. Denn das Bild wird ohnehin in 16x16 Macroblöcke zerlegt und auf dieser Basis komprimiert. Die Schwierigkeiten liegen trotzdem im Detail und DivX skaliert auch derzeit nur bis 4 Cores gut. x264 macht problemlos 8 Cores und mehr und skaliert sehr gut. Um bei CUDA gut zu skalieren müsste man die Arbeit in ca. 128 - 256 verschiedene Teile zerlegen. Das ist nicht immer effizient möglich oder nur mit einem enormen Aufwand.

Also: Videokompression erzeugt relativ einfach eine gleichmäßig volle Last auf den Cores (*). Bei Games ist das anders. Es könnte z.B. so sein, dass Szenen mit vielen Gegnern gut von QuadCores erledigt werden, während der DualCore in die Knie geht. Das merkt man dann bei der Average FPS kaum, aber bei der Minimum FPS kann der Unterschied gravierend sein. Kurve gekriegt, back on Topic: We need X-Testing.

(*) weiterarbeiten ohne Verzögerung kann man übrigens auch auf dem DualCore. Man muss lediglich die Prozesspriorität des Kompressionsprozesses auf niedrig stellen.

Moin

@7obi
Jo, hatte mich nur etwas gewundert, da du sonst immer sehr kompetent und verständlich antwortest.

Nichts desto trotz hier, hauptsächlich für andere, mal ein gutes Beispiel zum Thema Multithreading, auch wenn es jetzt etwas vom eigentlichen Thema abweicht:

Einige behaupten nämlich, wenn ihre Anwendung auf mehreren Kernen läuft, sie aber nicht voll auslastet, das wäre schon Multithreading. Sehr schwer, denen zu erklären, dass es für eine Anwendung besser ist, dass sie alle Kerne voll auslastet, als nur so ein bisschen. Habe selbst so ein Heimchen als Kumpel, ich weiß, wovon ich rede

Sehr schön zu sehen ist das mit WinRAR in einer aktuellen Version (ich habe 3.70) unter "Extras -> Benchmark und Hardwaretest". Man beachte im Bild jeweils rechts das Kästchen zur Aktivierung von Multithreading sowie das Ergebnis in Kb/s und links die Auswirkung auf den Prozessor.

@Thema
Ja, bitte ein Aufklärungsartikel von Dr. 3D Sommer

Nur schlaue Köpfe im Forum
Danke für die viele tolle Beiträge.

mfg

Die Anzahl der Threads einer Anwendung kann man sich auch anzeigen lassen:
Task-Manager / Reiter Prozesse / Menu Ansicht / Spalten auswählen / [x] Threads

Aber selbst wenn mehrere Threads laufen, heißt das noch lange nicht, dass die auch was zu tun haben. Die allermeisten sind nur geparkt und warten auf Arbeit: Liest man in Word ein Dokument in der Seitenansicht, dann ist der Rechtschreibkorrekturthread geparkt.

Zu Erklärung warum selbst eine Single-Threaded Anwendung auf allen Cores Last erzeugt, aber auf keinem die 100% vollkriegt.
. Vereinfachen wir indem jeder Thead die gleiche Priorität kriegt.
. 90% aller Threads schafen. Sie warten auf einen eintreffenden Interrupt (z.B. Timer läuft ab) oder eine Eingabe (Maus, Tastatur)

. Es sind ein paar wenige Threads, die was zu rechnen haben. Und einer davon ist die große Single-Threaded Anwendung.
. Dieser Thread wird auf einen Core gelegt und dort solange gerechnet wie eine Zeitscheibe (= Betriebssystemabhängig) lang ist. Je nachdem sind das ca. 100 Millisekunden.
. Diese Zeitscheibe ist jetzt abgelaufen und sagen wir der ein Animationsthread kommt nun an die Reihe.
. Alle anderen Cores rechnen noch.
. Nun wird ein Core frei. Das ist zwar nicht der wo die Single-Threaded Anwendung vorher drauf lief, aber der ist jetzt frei und kein anderer hat gerade etwas zu tun. Auf jeden Fall rechnet die Anwendung nun auf dem weiter.

Das erklärt im wesentlichen das Core-Hopping. In Wirklichkeit ist das Scheduling nochmals deutlich komplizierter, da Prioritäten von Windows dynamisch geändert werden und auch einige Heuristiken mit hineinspielen, die den Scheduler für einige Spezialfälle optimieren.

Im Prozessmonitor sieht man nur eine Auslastung von vielleicht 50% auf dem Core während der Zeit. Das rührt daher, dass die Zeitscheiben des Schedulers deutlich kleiner sind als die Abnahmeabschnitte des Task-Managers. Wenn der Thread nur die Hälfte der Abnahmezeit (aber da mit 100% Last) auf einem Core war, dann ist der Schnitt 50% und das wird angezeigt.

Bei der Gesamtprozessorauslastung addiert Windows die Lasten der Cores zusammen und so kommt es, dass

DualCore mit 1A Single-Threaded Anwendung ziemlich genau 50% Last erzeugt.
QuadCore mit 1A Single-Threaded Anwendung ziemlich genau 25% Last erzeugt.

Das läuft jederzeit auf einem Core zum Anschlag und so schnell es geht, aber beschäftigt eben immer nur einen gleichzeitig. Auch wenn das im Taskmanager teilweise etwas anders aussieht.

@DHAmoKK

Die hatten noch nie ein ruckelndes HD Video mangels Pure Video Unterstützung, da sind dann die 2 Kerne einer C2D mit je 50% ausgelastet, ruckelt zwar wie sau, aber hey ist doch Multithreading

Darfst gerne die Nachtschwester spielen


@fluppe
1. Es gibt wenig Spiele, die den Speicher >512 auslasten.
2. Wenn sie ihn auslasten, laufen 3D-Karten mit weniger als 1024 kaum langsamer.
3. Der Geschwindigkeitsvorteil bleibt gering und erst ab 1680 mit AA zu bemerken.

Egal wieviel getestet wird, 512 auf 1024 bringt momentan im Gesamtergebnis irgendwas zwischen 1 und 3%. Crysis ist das einzige Spiel in meiner Benchmarksuite, welches von 512 auf 1024 profitiert.

Entscheidend ist nicht ob 800 MB belegt werden, sondern wieviel Speed man gegenüber 256 oder 512 MByte gewonnen hat. Spiele sind für die breite Masse ausgelegt und die Hardware-Anfoderungen orientieren sich daran. Sieht man an den Doppelchipkarten, die nur 2x512 MByte haben.

Crysis läuft ohne AA schon kaum, mit AA nur mit 1280 VH auf GTX 280, 88 Ultra SLI und 88 GT 1024 SLI oder man packt eine neue Quad Core drauf, womit wir wieder bei der CPU wären.