Und klar ist es der Software egal, wieviel Kerne es gibt, aber hat es nicht den gleichen Effekt, wenn die Software eben so programmiert wird, dass es nur so viele Threads gibt, wie zum Zeitpunkt der Entwicklung Kerne vorhanden waren? Oder haben aktuelle Spiele jetzt schon genug Threads für Gulftown und mehr? Ich weiss, immer nur die Spiele zu betrachten ist beschränkt, aber hier wird am meisten über den mangelnden Nutzen zusätzlicher Kerne gemeckert.
Wie gesagt, du solltest dich von der Meinung lösen, das die Anzahl der Cores entscheidend ist. Denn das ist sie nicht.
Viel eher ist entscheidend, wie sich die Software aufteilen lässt. Also wie gut werden mehr Threads auch gleichzeitig abarbeitbar sein.
Games gehören seit Jahr und Tag zur Kategorie des extrem dynamischen Inhalts. Es lässt sich nicht alles gleichzeitig berechnen. Da viel voneinander abhängt und auch viel sequenziel berechnet werden muss mit Ergebnissen vorheriger Berechnungen usw. Dazu kommt die Aktion des Games durch Eingaben mit der Maus/Tastatur usw.
Was man heutzutage macht um Games Multicore ready zu machen ist eben anstatt zu optimieren einfach immer mehr an Berechnungen reinzuknallen. So wird halt die Physik oder KI für jeden NPC in einem Thread berechnet. Laufen vier durchs Bild, werden vier Threads quasi unabhängig voneinander abarbeitbar sein.
In zwei Jahren laufen dann halt 10 Leute durchs Bild usw.
Vllt nochmal das fiktive Beispiel von Kaffee kochen.
Du willst Kaffee kochen und hast eine Kaffeemaschine.
Arbeitsschritte wären:
- Wasser in Kanne
- Wasser von Kanne in Maschine
- Filter in Maschine
- Kaffee in Filter
- Kanne unter Maschine stellen
- start drücken und kochen lassen
Diese sechs Schritte brauchen angenommen immer die gleiche Zeit. Mit nem SingleCore würdest du alle sechs hintereinander abarbeiten. Brauchst also sechs Zeiteinheiten für eine Kanne Kaffee.
Fängst du nun an zu optimieren, könnte man "Wasser in Kanne" sowie "Filter in Maschine" also auch "Wasser von Kanne in Maschine" sowie "Kaffee in Filter" jeweils gleichzeitig ausführen.
Macht also:
- Wasser in Kanne / Filter in Maschine
- Wasser von Kanne in Maschine / Kaffee in Filter
- Kanne unter Maschine stellen
- start drücken und kochen lassen
In Summe noch vier Zeiteinheiten für eine Tasse Kaffee mit einem DualCore.
Weiter lässt sich diese Berechnung nicht optimieren. Die Kanne kann erst unter die Maschine, wenn das Wasser aus ihr raus ist. Auch kann erst gestartet werden, wenn alle anderen Schritte vorher getätigt wurden.
Mehr Rechenkerne würden absolut keinen Vorteil bringen...
Es werden also defintiv vier Zeiteinheiten gebraucht um eine Kanne Kaffe zu kochen.
Um auf die Games zurück zu kommen. Man kann jetzt für QuadCore CPUs einfach zwei Kannen Kaffe kochen lassen. Sprich man stellt zwei Maschinen auf und lässt beide gleichzeitig arbeiten. Schon hast du nen Quad ausgelastet. Und kannst innerhalb von ebenso vier Zeiteinheiten aber zwei Kannen Kaffee, also die doppelte Menge in gleicher Zeit kochen...
Vllt wirds anhand des Kaffeebeispiels verständlicher... Denn so läuft das aktuell.
Würde man aber die Berechnung nach oben hin nicht begrenzen und der User dreht maximale Settings ein, so würden heutige DualCore CPUs oder QuadCore CPUs mit 8, 12, 16 oder noch mehr Berechnungen überstrapaziert werden. Es würde also nix mehr laufen. Irgendwo muss eine Grenze rein... Und die begrenzt bei derartiger Auslastungspolitik die Nutzbarkeit der Cores...
Mit der Anzahl der nutzbaren Threads hat das aber nix zu tun...
PS: schau mal in deinen Taskmanager von Windows. Dort steht die Anzahl der aktuell laufenden Threads
bei mir sind das aktuell über 1000 Stück bei nem Quad als CPU... Nur im Vergleich...
Du hast Regor mit doppeltem L2-Cache vergessen
Aber hier wird bis auf wenige Ausnahmen nie mehr als ein verschiedener DIE für eine Prozessormarke benutzt. PhenomII X2-X4 sind im freien Handel immer Deneb (bis auf 840, der ist immer Propus), X6 immer Thuban. AthlonII X2 sind immer Regor. Nur AthlonII X3 und X4 waren anfangs sowohl Propus, als auch Deneb (und sind es immernoch?).
Ich weiss schon, was fdsonne sagen will, bei den K8 mit E-Stepping hat AMD von Anfang bis Ende munter paralell DIEs mit echten 512KB L2-Cache und teildeaktivierte 1024er verkauft, AFAIR auch beim C-Stepping. Beim F2-Stepping war damit aber glaub ich Schluss, da hat man ja sogar die langsamer getakteten Windsor-1024 zumindest im F2-Stepping nie im Handel gesehen, weil sie sich nicht lohnten.
Bei Allendale und Conroe weiss ich es nicht, ich glaube, spätestens als es die E6x20er mit garantiertem Conroe gab, war hier Schluss mit teildeaktiviert.
Ich weiss aber nicht, ob das auf Bulldozer so übertragbar ist. Hier muss wesentlich mehr deaktiviert werden, als ein bischen Cache oder ein Kern, AFAIK muss es immer ein ganzes Modul sein.
Genau darum gehts mir... Aber ob nun ganzes Modul oder nur bisschen Cache ist denke ich ziemlich banane... Sofern es sich deaktivieren lässt, spricht nichts dagegen.
Wie gesagt, ich schließe nicht aus, das AMD andere Masken für die kleineren CPUs nutzen wird. Aber es muss denke ich nicht von Anfang an sein. Eben gerade weil die Yields wohl mit neuer Architektur + neuer Fertigung noch nicht sonderlich berauschend sein werden. Man könnte beinahe sagen, für die kleinen Modelle ist das was deaktivert wird quasi als Reserve vorhanden, auf welche man bei schlechten Modellen zurück greift. Für die Dauer ist derart viel deaktiveren sicher aber nix, das mag schon stimmen
Zum Thema Core2. Das war noch weit vor es diese ganzen neueren Modelle vom Core2Duo gab.
Anfangs gabs nur die E6300-X6800 CPUs im DualCore Bereich.
Ich hab zum Beispiel bei nen E6400 mit Conroe DIE damals bei nem Kumpel verbaut. Kurze Zeit später gabs aber nur noch welche mit Allendale Kern zu kaufen. Man berichtete gar, das diese im OC weit weniger erreichen als die erste Ladung Conroe CPUs.
Guckst du hier: (hab nur das auf die schnelle gefunden)
http://hwbot.org/signature.img?iid=8535&thumb=false&iehack=.jpg
http://valid.canardpc.com/cache/screenshot/1511539.png