Das hat miteinander nur leider gar nix zu tun.
Nur mal so ein kleines Geheimnis nur für dich: Wartezyklen erhöhen die Latenz. Aber sags niemandem weiter
Der physisch kürzere Weg stimmt in der Tat. Das was du allerdings als "virtuelle Latenz" bezeichnest ist viel mehr die reale Latenz, wenn man durchgutes prefetching in der Praxis letztlich doch das gleiche Resultat erzielt ist nur das entscheidend. Nehalem wird letztlich beide Vorteile kombinieren und nocheinmal einen weitaus schnelleren Zugriff besitzen.
Nein. Die reale Latenz lässt sich mit anderen Tools, die die reale Latenz auch messen, ermitteln. Z.B. mit CPU-Z. Probier es mal aus, wir können ja einen extra Thread dafür ausmachen. Und, oh Wunder, der Phenom wird ca. 1/3 schneller sein.
Nocheinmal, die Theorie interessiert fü die praktische Performance Null. Nada. Niente. Real hat der Phenom mehr Bandbreite zur Verfügung, die er durch den im Vergleich kleinen Cache aber auch gut nutzen kann.
Siehe oben. Auch hier wieder, theoretische Werte will ich hier gar nicht diskutieren, die interessieren nicht die Bohne. Siehe die TFlop-Diskussion bei GT200 vs. RV770.
Was eigentlich interessiert, ist, wie die praktische Performance zustande kommt, um überhaupt interprätieren zu können, was diese überhaupt für eine Aussage hat. Wenn dich das nicht interessiert, kannst du das Diskutieren gleich ganz lassen...
Intel steigt um, weil der FSB im Multi-Sockel Betrieb bzw. perspektifisch auch Single-Socket mit mehr Kernen ein Hindernis ist bzw. werden würde. Um dies zu eliminieren sind immer weiter wachsende Caches nötig, was auf lange Sicht ein äußert unökonomischer Weg ist. Weiterhin bitte auch einfach nur genau lesen, es ging darum das der FSB im diskutierten Beispielfall keine Limitierung darstellt (da CPUs mit verschiedenen FSB-Takten ein und diesselbe Performance erzielen -> Bottleneck nicht an dieser Stelle)
Das kann der FSB auch leisten. Der FSB kann x CPUs und einen Chipsatz verbinden. Warum bekommt wohl beim Tigerton eine CPU einen doppelten FSB bzw. jeder CPU-Kern seinen eigenen FSB und warum ist Tigerton wohl monolithisch? Je mehr CPUs, desto mehr Wartezyklen, desto höher die Latenz. Tigerton umgeht das, indem er den FSB als Punkt-zu-Punkt-Verbindung nutzt. Es ist einfach unglaublich, was Intel da für einen Aufwand reingesteckt hat.
Genau deshalb steigt Intel um. Ein IMC ist in datenlastigen Anwendungen einfach viel, viel performanter.
Das ist ein Widersruch in sich. Low-Level spiegelt in keinster Weise eine reale Performance wieder, ein Programm wie Sandra geht einfach nur den gewünschten Weg über das schlaue Prefetching. Dieses bewusst zu umgehen, ist praxisirrelevant.
Um reale Performance überhaupt interprätieren zu können, muss man
wissen, was da vor sich geht. Die low-level-Performance ist kein Geheimnis, da kommt jeder drauf. Der Phenom hat eine um 1/3 niedriegere
reale Speicherlatenz.
Das habe ich nie bestritten. Ich widersetze mich aber wehement deiner Theorie, abstrakte physikalische Einzelwerte zu vergleichen. Real erreicht der C2 eine identische Zugriffszeit wie der K10, und nur genau das zählt. Auf die Multi-Sockel Diskussion will ich mich jetzt gar nicht einlassen, aber hier kannst du mit einem Vergleich der letzten Xeon-Generationen sehr gut sehen, wie der angehobene FSB die Skalierung mit mehreren Sockeln verbessert hat. Hier bringt die Bandbreite dann doch etwas, schau dir einfach die entsprechenden Tests dazu in der c't an.
Nein das tut er nicht.
Real ist er 1/3 langsamer pro Zugriff.
Virtuell gleicht der (pre)fetcher diesen Malus wieder aus. Nur
deshalb bekommst du identische Ergebnisse. Der Algorithmus wird mit purer Absicht genau darauf angepasst sein. Das sagt dir aber garnichts, nur, dass der C2D-Prefetcher
begrenzt, nämlich genu bei diesem Algorithmus, genauso schnell auf Daten zugreifen kann. Das ist nicht repräsentativ für andere Situationen, ganz im Gegenteil.
Grober Unfug. Bandbreite und Latenz müssen in keinerlei Zusammenhang zueinander stehen, ich kann alle 10ns ein Datenpaket übertragen oder alle 20ns zwei, gleiche Bandbreite steht hier doppelter Latenz gegenüber.
Dazu muss man erstmal begreifen
was Sandra
überhaupt testet. Sandra testet im Bandbreitentest nicht die Bandbreite, das ist der ganze Witz bei der Geschichte. Sandra testet, wieviel Bandbreite bei der aktuellen Latenz mit Einfluss des (Pre)fetchers bei dem verwendeten Testalgorithmus zur Verfügung steht, sonst
garnichts. Das hat für andere Anwendungen
überhaupt keine Aussagekraft, weil da völlig anders geartete Datenzugriffe durchgeführt werden. SiSoft ist dafür bekannt, seine Benchmarks genau auf die vorhandene Hardware auf dem Markt optimal anzupassen. Teste mal uralte Sandra-Versionen, mit denen bekommst du andere Effekte, weil das andere Algorithmen sind.
Zuerstmal war der IMC mit Sicherheit keine AMD-Erfindung
Und dann nochmal was zu deiner Bandbreiten-Theorie und das ja nur Latenz etwas bringt:[...]
Kann mich nicht erinnern, das behauptet zu haben. Nur du begreifst den eigentlichen
Sinn des IMC einfach nicht, oder willst es nicht begreifen.
[...]Das hat keiner bestritten. Dann ist es im Umkehrschluss aber unsinnig, dass der Phenom mit sinkender Auflösung kein einziges FPS mehr liefert, wenn die Grafikkarte als wie du schon richtig sagtest "Framelimiter" entlastet wird. Das ist ein klarer Messfehler in diesem Test, und das nicht der einzige.
Was macht ein Framelimiter? Er schneidet die
oberen FPS-Bereiche ab. Was bleibt übrig? Die unteren FSB-Bereiche. Und hier ist der Phenom offensichtlich besser... genau das zeigt der Bench. Das ist kein Messfehler. Diese Ergebnisse kommen doch nicht von Zauberhand zustande... der Rechner
ist schneller, die Frage ist, warum...
.
Das ist Everest. Everest nutzt einen anderen Algorithmus als Sandra, ist aber im Prinzip ähnlich. Everest misst, wieviel Bandbreite bei aktueller Latenz und Prefetcher bei genau diesem Algorithmus erreicht werden kann, er misst weder nur Bandbreite noch nur Latenz.
Bei der realen, hohen, FSB-Latenz kann Everest nicht mehr Bandbreite des Speichers ausnutzen, deshalb ist die Linie da unten schon abgeschnitten. Der Prefetcher kann hier auch nicht mehr die miese Latenz ausgleichen, weil der Algorithmus dem Prefetcher offensichtlich nicht liegt und der C2D hier keine Vorteile daraus ziehen kann. Der Athlon kann durch die viel geringere Latenz die vorhandene Bandbreite des Speichers bei diesem Algorithmus jedoch halbwegs optimal nutzen. Der FSB hat eine deutlich höhere Bandbreite als das, was da gemessen wurde. Nur kann diese aufgrund des verwendeten Algorithmus nicht erreicht werden. Um zu begreifen, was da passiert, muss man Bandbreite und Latenz auseinanderhalten und wissen, wie diese zusammen bei einer High-Level-Anwendung interagieren.
Man sieht recht gut, wie sich der oben festgestellte Effekt auf Halflife überträgt. Nur arbeitet hier der Prefetcher deutlich effizienter. Der C2D hat die Daten bereits vorliegen (im Cache) und kann sie verarbeiten, während der Athlon erst Speicherzugriffe fahren muss. Anders als bei Everest werden hier aber keine Daten gestreamt, sondern oftmals dieselben Daten aus dem TLB geladen. Hier ist der grosse L2-Cache des C2D im Zusammenhang mit dem mächtigen Prefetcher sehr stark im Vorteil. Die Speicherzugriffe des Athlon sind zwar schnell, aber immernoch ca. 10x so langsam wie der L2-Cache des C2D. Der C2D läd bevor der Speicherzugriff nötig wird und hat dadurch garkeine Latenz. Deshalb ist der C2D hier schneller. Das ist im Prinzip auch der riesige Vorteil des C2D. Er kann die Daten früh genug effizient besorgen, sodass die Anwendung sofort rechnen kann, ohne dass ein Speicherzugriff erfolgt. Dieses Prinzip gerät bei MT aber aus den Fugen und versagt bei andauernden Datentrasfer komplett, wobei es auch hier wieder auf die Art des Datentransfers ankommt, es ist also wichtig, wieviel gerechnet werden muss. Bei Everest wird nur gestreamt, hier hat der K8 den Vorteil, bei einem Videocodierer z.B. wird mehr gerechnet, hier hat der riesige L2 des C2D im Zusammenhang mit dem Prefetcher wieder den Vorteil. Der C2D ist der optimale DualCore, aber die optimale QuadCore sind hier nur K10 und Nehalem. Hier lässt sich nichts mehr durch den Prefetcher ausgleichen, hier zählt die reale Latenz. Deshalb ist der Nehalem wie der K10 vom Prinzip her designt.
Wenn man jetzt noch ne Schippe drauflegt und neue MT-Games vergleicht, wird das Verhalten durchaus erkärbar. Wenn ein Thread die Oberhand behält, also dauerhaft limitierend wirkt, kann der C2D-Prefetcher wieder gewinnen. So sind 90% der DualCore Games designt. Hier entlasten Hilfsthreads den Hauptthread, der Hauptthread limitiert aber das Game (Anno1701, C&C3, Quake 1.4 usw.). Hier bleibt der C2D aufgrund seiner Architektur der Gewinner, weil der seine Recheneinheiten besser auslasten kann. AC, LP und die ganzen XBox-Titel sind aber anders. Hier gibt es keinen Thread, der einzig limitiert, dafür wäre ein Kern der XBox-CPU zu schwach (die sind in-order, wie der Atom!). Deshalb muss hier die Arbeit effizient auf die 6 virtuellen Kerne verteilt werden. Hier kann der Prefetcher des C2D schlechter herausfinden, welche Daten grade gebraucht werden. Deshalb funktioniert er hier nur teilweise effizient. Läuft es gut, ist das Ergebnis sehr gut und L2 mit Prefetcher funzen wieder. Kommt was unvorhergesehenes, wird ein laaaanger Speicherzugriff fällig, und das ganze Gebilde bricht in sich zusammen. Somit kann man sehr gut schlussfolgern, was hier eigentlich passiert!
1.) Während der K10 die Daten im L3-Cache behält, weil der die Kohärenz der Kerne sicherstellt, hat er mehr Daten schon im L3, die der Core2 diese jedesmal neu aus dem Speicher holen müsste.
2.) Wenn der K10 Daten aus dem Speicher holen muss, weil er sie nicht hat, holt der Core2 die Daten um 1/3 langsamer rein.
Dadurch erklärt sich auch das Leistungsbild der Core2 ggü. dem K10. Wenns beim Core2 gut läuft, übertrifft er den K10 um längen, die FPS rasen bis zum GPU-Limit hoch. Wenns beim Core2 schlecht läuft, wird er langsamer als der K10, weil er die Daten erst langwierig reinholen muss. Wie gesagt passiert das nur bei
massivem MT. Aber genau das erlärt das homogenere Leistungsbild des K10 ggü. des Core2 bei entsprechenden Games, und das erklärt noch mehr, warum Intel den Nehalem so designt hat. Man hat versucht, AMDs Architektur mit den Core2-Vorzügen zu verschmelzen. Das Ding wird sicherlich gut, aber beim Core2 braucht man nichts mehr beschönigen. Ggü. dem K10 ist er veraltet.
. Der Phenom ist deshalb schneller, weil er mehr Daten schneller im Speicher unterbringen und wieder laden kann, da die physikalische Latenz geringer ist. Was glaubst du, warum der K8 Opteron so wahnsinnig beliebt war? Er war die perfekte Datenbank-CPU. In diesem Segment hat der Core2 immernoch das Nachsehen. Warum? Weil er einen FSB hat. Intel betriebt einen riesen Aufwand mit Quad-Channel-Interface und Die-Monolithisierung (Tigerton ist ein monolithischer QuadCore) um ein ähnliches Ergebnis wie AMD zu erreichen - der Core2 mit seinem FSB alleine ist einfach zu langsam für grosse Datenmengen. Übrigens ist der Tigerton trotzdem noch im Nachteil ggü. dem K10, weil dieser auf billige Quad-Boards zurückgreifen kann (Board kostet <1000€).
