Was bringt der L3-Cache?

[Schlammsau]

Während das große Einsteiger- und Mittelklasse-Round-Up noch in Arbeit ist und einige Tage mehr in Anspruch nehmen wird, wollen wir vorab einen kleinen Teil des Artikels auskoppeln, der in der Masse an Informationen im finalen Produkt eh nicht die Beachtung bekommen würde, die er verdient. Dabei geht es um die Frage, wer beim Kauf eines AMD-Prozessors doch lieber zu einer Variante mit L3-Cache greifen sollte oder für wen auch der günstigere Ableger ohne den zusätzlichen, schnellen Zwischenspeicher ausreichend ist.......

http://www.computerbase.de/artikel/hardware/prozessoren/2009/kurztest_was_amd_l3-cache/#abschnitt_ueberblick

[Heimatsuchender]

Und worüber sollen wir jetzt diskutieren? Über L3-Cache? Über den Artikel?.....



tobife

[Matrix316]

Cache ist IMO immer wichtig. Und zwar je schneller desto besser. IMO hätte man anstatt den L3 Cache auszubauen, lieber den L2 Cache (wie beim Core 2) steigern sollen. Da hätte man sicher mehr davon gehabt.

[Lawmachine79]

Cache ist IMO immer wichtig. Und zwar je schneller desto besser. IMO hätte man anstatt den L3 Cache auszubauen, lieber den L2 Cache (wie beim Core 2) steigern sollen. Da hätte man sicher mehr davon gehabt.
Das ist eine mathematische Optimierungsfrage. L2-Cache ist teurer als L3-Cache, daher kann die Größe nicht identisch sein.
Wenn die Größe des L2-Caches nicht im ausreichenden Maß gesteigert wird, ist die Miss-Rate immer noch hoch genug, daß kleiner L2-Cache + großer L3-Cache langsamer sein kann als mittlerer L2-Cache.
Man kann auch nicht sagen, daß AMD lieber den L2-Cache hätte vergrößern sollen, da man AMD und INTEL in der Hinsicht nicht vergleichen kann, dazu müßte man en Detail Aussagen über die Qualität und die Besonderheiten z.B. der Sprungvorhersage (die wiederum abhängt z.B. von der Größe des Sprungzielpuffers (Branch Target BuffeR) und der "Sprunghistorie" (Branch History Table) kennen.

[Gast]

Cache ist IMO immer wichtig. Und zwar je schneller desto besser. IMO hätte man anstatt den L3 Cache auszubauen, lieber den L2 Cache (wie beim Core 2) steigern sollen. Da hätte man sicher mehr davon gehabt.

Hallo,

dies ist zwar richtig, aber L3-Cache ist viel billiger und kann auch mit mehr defekten verkauft werden (Stichwort ECC).

Ergo hat man mit 3 L3-Cache etwas mehr Performance, dies aber mit vergleichweise geringem zusätzlichem Fertigungsaufwand. Denkt nur an die Preise der Pentium II/III XEON CPUs mit 2 MB L2-Cache.

mfg

[SavageX]

Cache ist IMO immer wichtig. Und zwar je schneller desto besser. IMO hätte man anstatt den L3 Cache auszubauen, lieber den L2 Cache (wie beim Core 2) steigern sollen. Da hätte man sicher mehr davon gehabt.

Nicht unbedingt. Es gilt tendenziell immer noch das "je größer, desto langsamer" Mantra. Nur weil Intel es beim Core 2 geschafft hat, einen vernünftig schnellen L2 von beachtlicher Größe zwischen zwei Kernen zu teilen (allerdings nur in inklusiver Verwaltung, nicht exklusiv wie bei AMD), heißt es noch lange nicht, dass dies z.B. mit vier Kernen ähnlich reibungslos (schnell) funktioniert. Es gibt Cache-Hierachien nicht ohne Grund, weder Intel noch AMD sind blöd - und beide haben was Phenom und Core i7 angeht vergleichbare Lösungen für das gleiche Problem gefunden.

[Daredevil]

Das Cache wichtig ist sehe ich daran das ich einen Allendale besitze :ugly:
Aber interessanter Artikel!

Ich hätte bei "nicht Spiele" Systemen immer zum Phenom II tendiert da man dort was "solides" hat und nichts abgespecktes, is ja anscheinend nicht so wirklich nötig, zumindest nicht für den Aufpreis.

[Thunder99]

Ein wirklich sehr interessanter Bericht.

Nur durch dieses Fazit fragt man sich, wenn die Ausfallrate wirklich gering ist, wieso bringt dann AMD den Phenom II überhaupt raus ? :confused:

... Für AMD ist diese Entwicklung sowohl Fluch als auch Segen. Der Athlon II ist mit seiner deutlich kleineren Fertigungsmaske wesentlich günstiger herzustellen, weshalb die Gewinnmarge bei diesem Prozessor deutlich höher sein dürfte. Dem gegenüber steht aber der Phenom II; zwei deaktivierte Kerne aber ein in der Produktion teurer L3-Cache. ...
Quelle: CB

[Gast]

Nur weil Intel es beim Core 2 geschafft hat, einen vernünftig schnellen L2 von beachtlicher Größe zwischen zwei Kernen zu teilen (allerdings nur in inklusiver Verwaltung, nicht exklusiv wie bei AMD), heißt es noch lange nicht, dass dies z.B. mit vier Kernen ähnlich reibungslos (schnell) funktioniert.
Der L2 eines Phenom II ist nicht auf 4 Kerne verteilt, sondern jeder Kern hat seinen eigenen L2.

Das Problem muss tiefer sitzen oder andere Gründe haben.
Bei Intel fällt es noch mehr auf, der L2 Einschnitt zum Conroe/Wolfdale ist noch drastischer.

Warum das Ganze?
L3 ist lahmer als L2.
Bloomfield kommt mit einem integrierten Triplechannel DDR3 Controller daher.
Der RAM Zugriff ist im Vergleich zum Core 2 ein gutes Stück schneller, dennoch wird eine Cachestufe eingebaut die die kleiner gewordene Lücke zwischen RAM und L2 auffüllt, gleichzeitig wird L2 kleiner.

Ich kann mir das nur so erklären, das der L2 stattdessen schneller wurde. Bzw der L2 der Core 2 aus Kostengründen ein L2 und kein zusätzlicher L3 wurde, mit dem Nachteil das dieser riesen L2 lahmer war.

[Savay]

Cache ist IMO immer wichtig. Und zwar je schneller desto besser. IMO hätte man anstatt den L3 Cache auszubauen, lieber den L2 Cache (wie beim Core 2) steigern sollen. Da hätte man sicher mehr davon gehabt.

nur das der L2 beim C2D geteilt wird und beim K8/K10 je Kern zur verfügung steht...
wenn man den L2 der K8/K10 architektur dann aufbläst bewirkt es sicherlich vorallem das durch die exklusive architektur der caches deutlich mehr interne bandbreite für abgleiche zwischen den kernen vergeudet werden müsste vorallem je exzessiver SMT verwendet wird...was doch alles über den HT interconnect geht wenn ich mich nicht irre...da ist die bandbreite nunmal begrenzt
und ganz allgemein scheint beim K8/K10 1MB L2 je kern das sinnvolle maximum zu sein. ansonsten wäre AMD nicht in den letzten jahren immer munter zwischen 512kb L2 und 1MB hin und hergesprungen und hätte dem Regor "nur" 1MB je core spendiert.

AMD ist doch wenn man es streng nimmt im grunde einfach den gleichen weg gegangen wie intel, indem sie einen großen monolithischen cache angeflanscht haben der gleichzeitig als interconnect herhält. bei Intel war es nen großer L2...bei AMD schimpft sich das ding eben L3.
zumal sich die aktuellen architekturen von AMD und Intel momentan ja so "ähnlich" sind wie schon lange nicht mehr...3 cache level mit ähnlichem größenverhältniss, integrierter speichercontroller, ähnlich lange pipelines etc. pp.

und wie schon gesagt...inklusive caches vs. exklusive...das sollte durchaus einfluss auf die technische ausrichtung, größe und effektivität der jeweiligen caches haben, vorallem da ein cache ja generell eher langsamer wird je größer er ist. :) groß und schnell gibts einfach nicht...ansonsten wären mehrere cache level ja auch unnötig und man könnte einfach riesige L1 caches verwenden

[Coda]

Chipintern geht nichts über Hypertransport. Aber ich weiß nicht ob du das wirklich gemeint hast.

[Armaq]

mit DDR 1333 wird L3 aber schon überflüssig. Habe nen 955 BE auf nem DDR3 Board samt zügigem Speicher verbaut und die Speedtests sehen L3 und DDR3 gleich auf.

[.alice]

hi,

zum artikel (Kenntnisstand) sage ich mal nichts.

der cache, dessen aufbau/Zugriffsart der kerne, die Strategie die dahinter
steckt ist ist in den letzten jahren bei den Major Herstellern
nahezu auf selben level.

was ich jedoch lange zeit nicht gesehen/erkannt habe, war ist folgendes:

Unterschiede bemerkbarer art findet man eher in *shared/non shared cache.
zb. ob ein Quad ein echter ist oder ein 2xDuo, was natürlich auch
den cache betrifft. das ganze spielt allerdings nur bei mehrkern applikationen
eine rolle, siehe hier (speziell bei den quads schauen):

http://www.maxxpi.net/pages/description/multipi/multipis-scaleability.php

ich habe allerdings die jeweiligen CPU caches (typen) noch nicht ganz aufgeschlüsselt.

cu

[SavageX]

Der L2 eines Phenom II ist nicht auf 4 Kerne verteilt, sondern jeder Kern hat seinen eigenen L2.


Richtig, aber bei Mehrkernprozessoren scheint es eine gute Idee zu sein einen Cache mit an Bord zu haben, den sich die Kerne teilen. Wenn man also auf den L3 verzichtet, dann muss es ja zwangsläufig der L2 Cache werden - und weder Intel noch AMD trauen sich an einen großen, 4+ Kerne-geteilten Cache mit den Zugriffszeiten eines herkömmlichen L2. Dafür gibt es gute Gründe.

[Gast]

weder Intel noch AMD trauen sich an einen großen, 4+ Kerne-geteilten Cache mit den Zugriffszeiten eines herkömmlichen L2.
Irgendwie bezweifel ich, das der L2 des Core2 so schnell wie der des i7 ist.

[robbitop]

mit DDR 1333 wird L3 aber schon überflüssig. Habe nen 955 BE auf nem DDR3 Board samt zügigem Speicher verbaut und die Speedtests sehen L3 und DDR3 gleich auf.
Die Zugriffszeit müsste beim L3 wesentlich besser sein. SRAM ist bei unvorgehersehenen Zugriffen wesentlich fixer als DRAM. Hinzu kommen die Signallaufzeiten bei DDR3.
In der Praxis sieht man es beim Phenom 2 X2 vs Athlon 2 X2. Der Phenom ist z.T. erheblich schneller als ein gleichgetakteter Kern ohne L3.

[Matrix316]

Irgendwie bezweifel ich, das der L2 des Core2 so schnell wie der des i7 ist.
Dafür ist er aber auch 12 Mal so groß und das bringt ja auch was.

[Gast]

Dafür ist er aber auch 12 Mal so groß und das bringt ja auch was.Dafür hat der i7 wiederrum einen L3 und der Core2 nur einen 266/333Mhz FSB.

Hat da mal jemand lustige Diagramme zur Hand?

[SavageX]

Irgendwie bezweifel ich, das der L2 des Core2 so schnell wie der des i7 ist.

Gerade weil der L2 beim i7 massiv kleiner ist.

[Gast]

mit DDR 1333 wird L3 aber schon überflüssig. Habe nen 955 BE auf nem DDR3 Board samt zügigem Speicher verbaut und die Speedtests sehen L3 und DDR3 gleich auf.

Bei der bandbreite vielleicht, in der latenz ist der L3 meilenweit voran.

[reunion]

Man darf auch nicht vergessen das der Athlon II dafür einen doppelten L2-Cache hat.

[Matrix316]

Dafür hat der i7 wiederrum einen L3 und der Core2 nur einen 266/333Mhz FSB.

Hat da mal jemand lustige Diagramme zur Hand?
Was hat denn Cache mit FSB zu tun? Ist es für die Cache Größe nicht egal wo der Speichercontroller sitzt? Der RAM ist ja so oder so außerhalb der CPU auf dem MB.

Der Core 2 hat trotz externem Speichercontroller, jeden AMD mit integriertem abgezogen was die Performance betrifft.

[Spasstiger]

Was hat denn Cache mit FSB zu tun?
Es geht ihm wohl um den Datenaustausch zwischen den Prozessor-Cores. Während der Core i7 das über den L3-Cache bewerkstelligt, muss ein Core 2 Quad den FSB bemühen, wenn mehr als zwei Prozessor-Cores beteiligt sind.

[Matrix316]

Naja, aber so viel Performance kostet das ja auch nicht unbedingt. Ist doch ähnlich bei Multi CPU Systemen. Da sind die Prozessoren noch viel weiter auseinander.

[Spasstiger]

Naja, aber so viel Performance kostet das ja auch nicht unbedingt. Ist doch ähnlich bei Multi CPU Systemen. Da sind die Prozessoren noch viel weiter auseinander.
Und genau da wird Intels FSB doch zum Flaschenhals.

[Gast]

Was hat denn Cache mit FSB zu tun?
Erstens das:
Es geht ihm wohl um den Datenaustausch zwischen den Prozessor-Cores. Während der Core i7 das über den L3-Cache bewerkstelligt, muss ein Core 2 Quad den FSB bemühen, wenn mehr als zwei Prozessor-Cores beteiligt sind.
Lediglich beim Austauch zweier Cores auf einem Die hat Core 2 einen Vorteil im Vergleich zu i7.

Zweitens:
Core 2 hat einen langsamen großen L2 und die lahme RAM Anbindung.
i7 hat einen schnellen kleinen L2 und einen großen L3 und eine schnelle RAM Anbindung.

Core 2 muss quasi immer lange warten, egal ob er auf den L2 zugreift oder auf den RAM.
L3 des i7 mit dem L2 des Core 2 verglichen zeigt mir, das Core 2 neben dem fehlenden IMC auch Cache feht. Ihm fehlt kein L2, sondern irgendwas zwischen L1 und L2.

[S940]

Core 2 muss quasi immer lange warten, egal ob er auf den L2 zugreift oder auf den RAM.
Da vergißt Du die Relationen, der L2 des Core2 ist nicht gerade langsam, der liegt irgendwas um 15 Takte. i7 ist 2-3 Takte schneller so um die 13 Takte. Das sind keine Welten. Welten sind das, was passiert, wenn der i7 einen L2 Cache miss hat, dann muss er zum L3 -> 30-40 Takte.

Wenn man sich überlegt, dass der i7 L2 erstens von 2 Threads benützt wird und zweitens nur ein Zwölftel der Core2 L2 Größe hat, kann man sich vorstellen, dass das etwas häufiger vorkommt.

In jedem Fall gilt aber, dass bei 08/15 Programmen die Prefetcher schon sehr viel Latenz verschleiern.

Ich würde mal gerne einen dual i7 mit 6 MB (oder wenigstens 3 MB) unified L2 sehen ... wirds aber ja leider nicht geben.

Grundproblem ist halt, dass i7 ein 100% Server CPU Design ist, da macht L3 Sinn. Im Desktop Bereich dagegen ... zweifelhaft. Die Athlon II X2 mit 2x1MB können sich mit DDR3 z.B. ganz gut mit den Phenom2 X2 messen. Mal schauen, wie sich AMDs L3 loser Propus mit gutem DDR3 schlagen wird, leider hat der ja nur 4x512kB L2 Cache.

ciao

Alex

[Armaq]

Die Zugriffszeit müsste beim L3 wesentlich besser sein. SRAM ist bei unvorgehersehenen Zugriffen wesentlich fixer als DRAM. Hinzu kommen die Signallaufzeiten bei DDR3.
In der Praxis sieht man es beim Phenom 2 X2 vs Athlon 2 X2. Der Phenom ist z.T. erheblich schneller als ein gleichgetakteter Kern ohne L3.
Laut Everest liege ich bei 9.5 zu 64. (PhII 920 DDR800)

Bei dem neuen PC meines Freundes ist es DDR3 1333 mit zieml guten Latenzen und der ist schon bei 52 zu 9.2. DDR 1600 mit 6 6 6 16 kann hier nochmal aufholen.

Sicherlich ist es eine "Ewigkeit" mehr, was das angeht, aber ab fiktiven DDR3 2500 ist der L3-Cache, wie verbaut, überflüssig.

[Triskaine]

Da hilft es bloss den NB Takt zu erhöhen, da der L3 Cache der K10 Architektur nur mit 64-bit angebunden ist (Nehalem hat eine 128-bittige Verbindung). Wer also seinen PhII mit DDR3-1333 betreibt sollte schauen das er den NB-Takt auf 2,7 GHz bekommt um den Speicher optimal nutzen zu können.

[Coda]

Sind es nicht eher 64 bit pro Kern?

[S940]

Sind es nicht eher 64 bit pro Kern?
Ich las mal irgendwo was von nem Round-Robin verfahren, mit dem der Zugriff der Kerne auf den L3 geregelt wird.

Selbst wenn jeder Kern ne eigene Leitung hätte, dann könnte man die Bandbreite nicht addieren, da gleichzeitige Zugriffe nicht funktionieren.

So wies ausschaut ist die Organisation aber eh Kern(e) -> SRQ -> NB Logik -> L3, ist die logische Variante, alleine wegen der 2 Taktdomänen.

Edit:
@Triskaine:
Wobei beim NB OC noch die Frage ist, wie breit die Anbindung vom Speicherkontroller an die NB ist. Ich denke doch, dass die 128bittig ist, macht sonst wenig Sinn bei einem 2x64bit Speicherinterface, DDR3 war ja beim K10 Design schon bekannt. Der L3 sitzt ja nicht zwischen RAM und L2, der ist nur Auffangbehälter für alles was aus den L1/L2 Cachen rausfällt/verdrängt wird.

ciao

Alex

[Gast]

Da vergißt Du die Relationen, der L2 des Core2 ist nicht gerade langsam, der liegt irgendwas um 15 Takte. i7 ist 2-3 Takte schneller so um die 13 Takte. Das sind keine Welten. Welten sind das, was passiert, wenn der i7 einen L2 Cache miss hat, dann muss er zum L3 -> 30-40 Takte.
Diese genauen Zahlen wusste ich nicht. :)

[Pinoccio]

Diese genauen Zahlen wusste ich nicht. :)In bunt sieht das dann so aus:


http://www.lostcircuits.com/cpu/intel_i7/cachemem1.gif
Lost Circuits: Intel's i7: Codename Nehalem (http://www.lostcircuits.com/mambo//index.php?option=com_content&task=view&id=31&Itemid=1&limit=1&limitstart=6)

Wobei die Diagramme die Zahlen von S940 nicht ganz bestätigen, aber die Tendenz ist richtig.
/edit: Ohje, das sind ja ns - keine Takte, sry.

mfg

[JOjo*]

Man darf hier bei der Sache mit den cache auf keinen fall die sache so stark mit intel vergleichen....
von der verarbeitung her braucht ein amd einfach wenniger zwischenspeicher als ein intel!
Und der L3 ist ja auch nur zuständig für den austausch der daten zwischen den kernen!
Eine erhöhung des l2 würder ergo nicht besonders viel bringen im vergleich zu den kosten!

[Undertaker]

Grundproblem ist halt, dass i7 ein 100% Server CPU Design ist, da macht L3 Sinn. Im Desktop Bereich dagegen ... zweifelhaft. Die Athlon II X2 mit 2x1MB können sich mit DDR3 z.B. ganz gut mit den Phenom2 X2 messen.

Du vergisst den im Desktopbereich nicht gerade unwichtigen Bereich der Spiele. Hier profitiert der Phenom enorm vom L3 Cache - wie man bei CB sieht - und ich vermute, dass dieser bzw. seine sehr schnelle/breite Anbindung auch einer der Gründe für die hohe Leistung des i7 ist.

[Lawmachine79]

Man darf hier bei der Sache mit den cache auf keinen fall die sache so stark mit intel vergleichen....
von der verarbeitung her braucht ein amd einfach wenniger zwischenspeicher als ein intel!
Und der L3 ist ja auch nur zuständig für den austausch der daten zwischen den kernen!
Eine erhöhung des l2 würder ergo nicht besonders viel bringen im vergleich zu den kosten!
Insbesondere der On-Die Speichercontroller schwächt den Einfluss von L2- und L3-Cache auf die Leistung ab, sofern man jetzt K8 und C2D vergleicht. Der Cache ist zwar immer noch ein ganz wesentlicher Einflussfaktor, aber ein Miss mit dem daraus resultierenden Zugriff auf den Hauptspeicher kostet nicht mehr ganz soviel Zeit. Deshalb hat beim C2D der Cache auch einen größeren Performanceeinfluss als beim K8, weshalb der Cache zum einen größer ist und zum anderen auch die Sprungvorhersage besser ist.

[S940]

Du vergisst den im Desktopbereich nicht gerade unwichtigen Bereich der Spiele. Hier profitiert der Phenom enorm vom L3 Cache - wie man bei CB sieht - und ich vermute, dass dieser bzw. seine sehr schnelle/breite Anbindung auch einer der Gründe für die hohe Leistung des i7 ist.
Da vermutest Du falsch ^^

Ja - Spiele profitieren von viel Cache. Jetzt überleg mal logisch was für Spiele (oder andere Cache lastige Applikationen) schneller wäre:

großer schneller Cache
großer langsamer Cache


ciao

Alex

[SavageX]

großer schneller Cache
großer langsamer Cache



Man kann nicht immer das Pony UND den Kuchen haben. Wenn Du Deine Hit-rate vergrößerst (größerer Cache und/oder höhere Assoziativität) muss man tendenziell mit einer geringern Zugriffsgeschwindigkeit rechnen.

[S940]

Man kann nicht immer das Pony UND den Kuchen haben. Wenn Du Deine Hit-rate vergrößerst (größerer Cache und/oder höhere Assoziativität) muss man tendenziell mit einer geringern Zugriffsgeschwindigkeit rechnen.
Doch den Ponykuchen Cache gibts bei Intels C2D/C2Q - 6MB L2 14-15 Takte, 24fach Assoziativität, sicherlich eine topp Hitrate - ist doch perfekt.

ciao

Alex

[Undertaker]

Ja - Spiele profitieren von viel Cache. Jetzt überleg mal logisch was für Spiele (oder andere Cache lastige Applikationen) schneller wäre:

großer schneller Cache
großer langsamer Cache



Nun, und was haben wir beim i7? Einen nochmals schnelleren kleinen L2 Cache, dazu den großen L3, der sich nach Everest-Benches nicht vor der Performance des alten L2 der Core 2 verstecken muss. :wink:

Doch den Ponykuchen Cache gibts bei Intels C2D/C2Q - 6MB L2 14-15 Takte, 24fach Assoziativität, sicherlich eine topp Hitrate - ist doch perfekt.


Und dieses offenbar perfekte Konzept wird einfach aufgegeben? Die Ingenieure bei Intel werden nicht dumm sein. ;) Btw, ich würde mich nicht so stark auf die theoretischen Werte fixieren. Die reale Cacheperformance scheint beim i7 im Verhältnis deutlich besser zu sein.

4GHz Core 2 Duo: http://www.abload.de/img/everest4.6v0ad.png
4,2GHz Core i7: http://www.abload.de/img/rameverseto3tq.gif

Seine theoretisch deutlich höhere Latenz kann der L3 des i7 in der Praxis anscheinend perfekt verstecken. Übrigens schön zu sehen, am L1 hat sich gar nichts getan.

[S940]

Nun, und was haben wir beim i7? Einen nochmals schnelleren kleinen L2 Cache, dazu den großen L3, der sich nach Everest-Benches nicht vor der Performance des alten L2 der Core 2 verstecken muss. :wink:
Och Undertaker ... was willst Du denn jetzt. Nen Real-World Vergleich (Spiele) oder nen Synth Vergleich(Everest) ?
Entscheide Dich mal fürs eins, beides gleichzeitig und auch noch Schlussfolgern von einem aufs andre ist gefährlich ...


Und dieses offenbar perfekte Konzept wird einfach aufgegeben? Die Ingenieure bei Intel werden nicht dumm sein. ;)Jo, da Nehalem ein Serverdesign ist. Wäre das Designziel Desktop CPU gewesen, hätten sies nicht aufgegeben, denn die Intel Ingenieure sind nicht dumm ;D


Btw, ich würde mich nicht so stark auf die theoretischen Werte fixieren. Die reale Cacheperformance scheint beim i7 im Verhältnis deutlich besser zu sein.
Lol ... siehe oben. Ist ja schön, dass Dus einsiehst, das man sich nicht auf theoretische Werte fixieren sollte, aber wieso ausgerechnet Everest mit seinen linear - primitiven Zugiffsmustern die Realität/Praxis wiederspiegeln soll ist mir schleierhaft.

Seine theoretisch deutlich höhere Latenz kann der L3 des i7 in der Praxis anscheinend perfekt verstecken. Übrigens schön zu sehen, am L1 hat sich gar nichts getan.Wenn die Praxis für Dich Everest heißt, geb ich Dir gerne Recht.

Für mich ist das was andres, aber immerhin haben wir Deine Begriffsdefinition diesmal schnell geklärt :)

ciao

Alex

[JOjo*]

Geiler Link zum Thema^^ er Phenom Profitiert doch stärker vom L3 cache wie ich dachte...
http://www.computerbase.de/artikel/hardware/prozessoren/2009/kurztest_was_amd_l3-cache/

[Gast]

Übrigens schön zu sehen, am L1 hat sich gar nichts getan.

Wirklich?

Zumindest laut dem von dir verlinkten tests ist die latenz beim L1 vom Core2 immerhin ~25% geringer, das ist doch "etwas" mehr als nichts.

[Undertaker]

Och Undertaker ... was willst Du denn jetzt. Nen Real-World Vergleich (Spiele) oder nen Synth Vergleich(Everest) ?
Entscheide Dich mal fürs eins, beides gleichzeitig und auch noch Schlussfolgern von einem aufs andre ist gefährlich ...

Ich bin zu allen Vergleichen bereit. ;) Aber wie willst du in einer Real-World Anwendung Performancevergleiche auf den Cacheteil beschränken? Everest bietet sich hier insofern an, als des es diese Betrachtung weitestgehend isoliert ermöglicht, dabei aber die Gesamtheit aller beeinflussenden Parameter misst und nicht nur Latenzen auf dem Papier zählt.


Jo, da Nehalem ein Serverdesign ist. Wäre das Designziel Desktop CPU gewesen, hätten sies nicht aufgegeben, denn die Intel Ingenieure sind nicht dumm ;D

Deswegen setzt auch der Lynnfield auf den praktisch gleichen Core, sicher... Dieses Thema ist doch von vorn bis hinten abgedroschen, weitere Wiederholungen machen es nicht richtiger. Der L3 bringt offensichtlich auch ganz konkrete Performancevorteile im Desktopbereich, zusätzliche Cacheebenen sind kein Geniestreich aus dem Profibereich. Als Server-Designelemente kannst du aber gerne das Triple-Channel Interface sowie zusätzliche QPIs bei den Workstation- und Serverderivaten sehen, und genau auf die verzichtet Lynnfield auch.

Lol ... siehe oben. Ist ja schön, dass Dus einsiehst, das man sich nicht auf theoretische Werte fixieren sollte, aber wieso ausgerechnet Everest mit seinen linear - primitiven Zugiffsmustern die Realität/Praxis wiederspiegeln soll ist mir schleierhaft.

Nun, erneut die Aufforderung, zeige mir, anstatt nur zu kritisieren, die bessere Alternative zur Messung der resultierenden isolierten Cacheperformance. :)

Wirklich?

Zumindest laut dem von dir verlinkten tests ist die latenz beim L1 vom Core2 immerhin ~25% geringer, das ist doch "etwas" mehr als nichts.

Naja, der i7 hatte 200MHz Mehrtakt und Everest zeigt nur eine Nachkommastelle an - das würde ich zunächst mal nicht überbewerten, ohne jetzt eine definitive Aussage treffen zu wollen. Edit: Nein, du hast natürlich Recht: Der i7 taktet ja höher und hat trotzdem die schlechtere Latenz, laut Intel ist die Zugriffszeit auch um einen Cycle verlängert wurden. Das würde also passen, nur an der Bandbreite hat sich taktbereinigt nichts getan.

[S940]

Ich bin zu allen Vergleichen bereit. ;)
Ja, leider auch zu schlechten :biggrin:
Aber wie willst du in einer Real-World Anwendung Performancevergleiche auf den Cacheteil beschränken?
Wenn Du wirkliche Praxiswerte haben willst, dann misst Du mit VTune oder Codeanalyst im Hintergrund die Cache-Hit Raten etc., während Du im Vordergrund das jeweilige Praxisprogramm laufen lässt. Hatte ich auch schon im Luxx verlinkt hat keinen interessiert. Ist wohl zu kompliziert für die Forenuser dort.

Everest bietet sich hier insofern an, als des es diese Betrachtung weitestgehend isoliert ermöglicht, dabei aber die Gesamtheit aller beeinflussenden Parameter misst und nicht nur Latenzen auf dem Papier zählt.
Everest mißt sehr isoliert - ja und zwar den best case. Anbieten tuts sichs damit nicht. Zu meinen Latenzangaben besteht da nicht viel Unterschied, da ist nur die Einheit anders. Ich geb die Latenz in Takten an, du - per Everest - die best case Werte in Nanosekunden. Auf deutsch, von den 30-40 Takten, die ich für den i7 L3 genannt habe, mißt Everest die ~30 Takte und gibt die - je nach CPU Takt- dann in ns aus.


Deswegen setzt auch der Lynnfield auf den praktisch gleichen Core, sicher... Dieses Thema ist doch von vorn bis hinten abgedroschen, weitere Wiederholungen machen es nicht richtiger.
Bist Du wirklich so einfältig um zu glauben, dass Intel sich die Komplettentwicklung für nen Desktop Kern leisten würde, obwohl man erst Millionen in den i7 gesteckt hat und der Spiele auch einigermaßen gut verdaut ?

Der L3 bringt offensichtlich auch ganz konkrete Performancevorteile im Desktopbereich,Gib mal konkrete Gründe an, wieso ein L3 nach Deiner Lesart bei Spielen schneller sein sollte als ein ähnlich großer, doppelt so schnelle L2 ?


Nun, erneut die Aufforderung, zeige mir, anstatt nur zu kritisieren, die bessere Alternative zur Messung der resultierenden isolierten Cacheperformance. :)
Siehe oben ;-)
Everest ist aber sogar als Synth Programm schlecht/primitiv.

Kein Parameter, nur *ein* einziger Test
single threaded --> lastet die Speicherkanäle von Multicore CPUs nicht voll aus.
Bei AMD wird der dual ported L1 nicht getestet, die L1 Everest Werte müßte man verdoppeln - falls man das Maximum haben will(*).

Profis nehmen da den Rightmark memory analyzer. Leider gibts davon keine Artikel mehr zu aktuellen CPUs. Die letzten Tests gabs zum Barcelona / Core1:
Aber zur Übersicht, was man so alles an nem Cache testen kann, sind auch die alten Artikel sehr gut:
http://ixbtlabs.com/articles2/cpu/rmma-yonah.html

ciao

Alex
(*)War zumindest bei alten Versionen so, hab das nicht weiter beobachten ... da der Gesamttest eben uninteressant ist.

[Undertaker]

Wenn Du wirkliche Praxiswerte haben willst, dann misst Du mit VTune oder Codeanalyst im Hintergrund die Cache-Hit Raten etc., während Du im Vordergrund das jeweilige Praxisprogramm laufen lässt. Hatte ich auch schon im Luxx verlinkt hat keinen interessiert. Ist wohl zu kompliziert für die Forenuser dort.

Was interessiert die reine Hitrate, wenn wir über die Geschwindigkeit reden? Das wäre dann eher ein Bench der in erster Linie von der Größe profitiert.


Everest mißt sehr isoliert - ja und zwar den best case. Anbieten tuts sichs damit nicht. Zu meinen Latenzangaben besteht da nicht viel Unterschied, da ist nur die Einheit anders. Ich geb die Latenz in Takten an, du - per Everest - die best case Werte in Nanosekunden. Auf deutsch, von den 30-40 Takten, die ich für den i7 L3 genannt habe, mißt Everest die ~30 Takte und gibt die - je nach CPU Takt- dann in ns aus.

Nicht wirklich. schau dir mal die Differenzen zwischen theoretischer Zugriffszeit von L2 und L3 an und dann die in Everest gemessenen. Der L3 ist praktisch im Verhältnis schneller, als die von dir so etwas voreilig herangezogen theoretischen Zahlen es vorhersagen. So einfach ist die Sache dann eben doch nicht. ;)

Bist Du wirklich so einfältig um zu glauben, dass Intel sich die Komplettentwicklung für nen Desktop Kern leisten würde, obwohl man erst Millionen in den i7 gesteckt hat und der Spiele auch einigermaßen gut verdaut

Etwas vorsichtig mit deinen Beleidigungen ;) Einigermaßen gut ist bei den zu beobachtenden Vorteilen wohl gelinde gesagt untertrieben. Diese Differenzen hättest du mit einem leicht modifizierten Core 2 schwerlich erreicht. Das interessante am i7 ist ja gerade seine Spieleperformance, gemessen an der nur gering gestiegenen theoretischen Float und Int Leistung.

Gib mal konkrete Gründe an, wieso ein L3 nach Deiner Lesart bei Spielen schneller sein sollte als ein ähnlich großer, doppelt so schnelle L2 ?

Wir rätseln nach wie vor über die reale Geschwindigkeit. Und da scheint der L2 des Core 2 nicht doppelt so schnell zu sein, wie der L3 des i7. Laut Everest womöglich sogar etwas langsamer - denn auch wenn Everest sehr isoliert bencht, warum sollten die L3 Ergebnisse davon mehr profitieren als die des L2?

[SavageX]

Doch den Ponykuchen Cache gibts bei Intels C2D/C2Q - 6MB L2 14-15 Takte, 24fach Assoziativität, sicherlich eine topp Hitrate - ist doch perfekt.


Also, ich kann ganz ehrlich nicht einschätzen, ob der Ponykuchen auch weiterhin nur 14-15 Takte Zugriffszeit hätte, wenn 4 Kerne eine Zugriffsmöglichkeit darauf benötigen und ob es nicht eher viel Sinn macht, eine Hierachie einander sich ergänzender Caches mit unterschiedlicher Assoziativität und Ersetzungsstrategie zu haben, um mit einem breiten Spektrum an Workloads gut fertig zu werden.

[S940]

Was interessiert die reine Hitrate, wenn wir über die Geschwindigkeit reden? Das wäre dann eher ein Bench der in erster Linie von der Größe profitiert.Aha ... Du wechselst also mal wieder schnell das Thema ... es ging bisher immer über die Latenz, angefangen mit meinen Latenz- Taktangaben.
Wenn Du jetzt auf einmal über die Geschwindigkeit=Bandbreite redest, dann sags früher :|

Nicht wirklich. schau dir mal die Differenzen zwischen theoretischer Zugriffszeit von L2 und L3 an und dann die in Everest gemessenen. Der L3 ist praktisch im Verhältnis schneller, als die von dir so etwas voreilig herangezogen theoretischen Zahlen es vorhersagen. So einfach ist die Sache dann eben doch nicht. ;)
*Gähn* schon mal was von Prefetcher gehört ... Tipp: Wurde hier schon im Thread erwähnt. Falls Dus nicht wissen solltest, die Prefetcher arbeiten gaaanz super mit dem einfachen Everest Zugriffsmuster. Wozu das dann führt überlasse ich Deinem Denkvermögen & Recherchefähigkeiten ;-)
Noch ein Tipp: Es ist kein Praxiswert.


Etwas vorsichtig mit deinen Beleidigungen ;) Einigermaßen gut ist bei den zu beobachtenden Vorteilen wohl gelinde gesagt untertrieben. Diese Differenzen hättest du mit einem leicht modifizierten Core 2 schwerlich erreicht. Das interessante am i7 ist ja gerade seine Spieleperformance, gemessen an der nur gering gestiegenen theoretischen Float und Int Leistung.
Wichtig bei Caches ist v.a. die Latenz, höchstwahrscheinlich hat Intel die BW beim i7 erhöht, um den 2ten Thread ausreichen versorgen zu können.
Schau Dir den gerade verlinkten AMD Test an, was da der L3 Test an Vorteilen bringt ... und dann schau mal auf dessen Bandbreite.

Wir rätseln nach wie vor über die reale Geschwindigkeit. Und da scheint der L2 des Core 2 nicht doppelt so schnell zu sein, wie der L3 des i7. Laut Everest womöglich sogar etwas langsamer - denn auch wenn Everest sehr isoliert bencht, warum sollten die L3 Ergebnisse davon mehr profitieren als die des L2?
Solange Du nicht von Deinem Everest Trip runterkommst hat die Cache Diskussion keinen Sinn. Wenn Everest für die die Realität/Praxis etc. ist, dann geb ich Dir recht, siehe oben. Dann darfst Du auch glauben, dass der i7 L3 ne schnellere Zugriffszeit hat, als der L2 des C2D.

@SavageX:
Richtig, das ist noch die Frage.
Aber da sollte man mal abwägen, ob man wirklich gegenseitigen Cache Zugriff braucht. Das C2Q Konzept könnte sehr gut für Desktopanwendungen ausreichen. Also 2 Kerne teilen sich einen großen Cache, dazu dann IMC+QPI. Bei den AMD Dual Cores gabs nie shared Caches und die Performance war nicht schlecht.

Im hypotetischen C2Q/i7 Zwitter Fall wären das also 2x4 MB L2 für je 2 Kerne, danach die NB -> RAM. Sind dann auch 8 MB Cache, wobei man die 4x256kB der i7 L2 einsparen würde.
Mal schauen, wieviel AMDs Propus gegenüber den Denebs verliert, da bekommt man nen (sehr groben) Anhaltspunkt.

ciao

Alex

[Undertaker]

Aha ... Du wechselst also mal wieder schnell das Thema ... es ging bisher immer über die Latenz, angefangen mit meinen Latenz- Taktangaben.
Wenn Du jetzt auf einmal über die Geschwindigkeit=Bandbreite redest, dann sags früher :|

Mit Geschwindigkeit eines Caches würde ich Latenz und Bandbreite assoziieren, du etwa nicht?

*Gähn* schon mal was von Prefetcher gehört ... Tipp: Wurde hier schon im Thread erwähnt. Falls Dus nicht wissen solltest, die Prefetcher arbeiten gaaanz super mit dem einfachen Everest Zugriffsmuster. Wozu das dann führt überlasse ich Deinem Denkvermögen & Recherchefähigkeiten ;-)
Noch ein Tipp: Es ist kein Praxiswert.

*zusammenzieh*

Solange Du nicht von Deinem Everest Trip runterkommst hat die Cache Diskussion keinen Sinn. Wenn Everest für die die Realität/Praxis etc. ist, dann geb ich Dir recht, siehe oben. Dann darfst Du auch glauben, dass der i7 L3 ne schnellere Zugriffszeit hat, als der L2 des C2D.

Und jetzt fassen wir nochmal zusammen, wer sagt dir, dass dieser bessere Prefetcher (bitte nicht dieses von-oben-herab-Besserwissertum) nicht auch in der Praxis vergleichbare Auswirkungen hat? Das ist ja gerade die Preisfrage, mir fällt keine auch noch so Cachelastige Anwendung ein, die auf einem Nehalem bei gleichem Takt zum Penryn langsamer geworden wäre. Selbstverständlich nur ein Indiz, aber über die schwierige Benchbarkeit sind wir uns ja schon einig geworden.


Wichtig bei Caches ist v.a. die Latenz, höchstwahrscheinlich hat Intel die BW beim i7 erhöht, um den 2ten Thread ausreichen versorgen zu können.
Schau Dir den gerade verlinkten AMD Test an, was da der L3 Test an Vorteilen bringt ... und dann schau mal auf dessen Bandbreite.

Ich bin immer vorsichtig mit solchen Quervergleichen: Die Cachestruktur des Phenom II eine völlig andere, damit auch das daraus resultierende Verhalten: Die etwas höheren Latenzen und die geringere Bandbreite zum Ram, der langsamere, aber deutlich größere L1/L2 Cache - all das lässt sich schwer in einen Topf werfen, umrühren und dann auf gleiches Verhalten schließen.

[S940]

Mit Geschwindigkeit eines Caches würde ich Latenz und Bandbreite assoziieren, du etwa nicht?
Jein. Bandbreite ist nicht sooo wichtig, solange es breit genug ist. Am Wichtigsten ist die Hit-rate = Größe & Assoziativität und eben die Latenz.
Wenn die Bandbreite wichtig wäre, dann könnte sich AMD z.B: den L3 gleich ganz sparen, denn die L3 BW ist nicht größer als dual channel 1066/1333.

Um was Du jeweils redest solltest Du vorher sagen. Vor Deinem Posting gings nur um Leistung im Sinne von Latenz.



Und jetzt fassen wir nochmal zusammen, wer sagt dir, dass dieser bessere Prefetcher (bitte nicht dieses von-oben-herab-Besserwissertum) nicht auch in der Praxis vergleichbare Auswirkungen hat? Das ist ja gerade die Preisfrage, mir fällt keine auch noch so Cachelastige Anwendung ein, die auf einem Nehalem bei gleichem Takt zum Penryn langsamer geworden wäre. Selbstverständlich nur ein Indiz, aber über die schwierige Benchbarkeit sind wir uns ja schon einig geworden.Lad Dir VTune runter und schau die L2 Cache Hit Rate an, dann siehst Du wie gut die Prefetcher bei Spielen arbeiten :)
Cachelastige Anwendungen sind in der Regel auch sehr speicherintensiv. Da hast Du beim i7 dann einen IMC und einen 3 spurigen unganged DDR3 Datenhighway. Core2 muss sich dagegen mit nem FSB + einem ganged MC rumschlagen. Hättest Du nen C2Q + IMC, wäre der sicher nicht schlechter als der i7 ;-)

Ich bin immer vorsichtig mit solchen Quervergleichen:
Ich erinnere Dich bei Gelegenheit wieder daran ;-) Aber:
Die Cachestruktur des Phenom II eine völlig andere, damit auch das daraus resultierende Verhalten: Die etwas höheren Latenzen und die geringere Bandbreite zum Ram, der langsamere, aber deutlich größere L1/L2 Cache - all das lässt sich schwer in einen Topf werfen, umrühren und dann auf gleiches Verhalten schließen.
..in dem Fall kann man mixen, wir reden nur von der Latenz & Bandbreite im Allgemeinen. Dass der L3 eines i7 mit den kleineren L1 und L2 caches, weniger starken Einfluss als AMDs L3 hätte, ist abwegig.

ciao

Alex

[Undertaker]

Jein. Bandbreite ist nicht sooo wichtig, solange es breit genug ist. Am Wichtigsten ist die Hit-rate = Größe & Assoziativität und eben die Latenz.
Wenn die Bandbreite wichtig wäre, dann könnte sich AMD z.B: den L3 gleich ganz sparen, denn die L3 BW ist nicht größer als dual channel 1066/1333.

Um was Du jeweils redest solltest Du vorher sagen. Vor Deinem Posting gings nur um Leistung im Sinne von Latenz.

Nicht wirklich, ich sprach immer von beidem. Die Hit-Rate ist imho durch ihre Größenabhängigkeit schon nicht mehr zum Punkt "Geschwindigkeit" zu zählen, aber darüber kann man sich jetzt streiten; davon

Lad Dir VTune runter und schau die L2 Cache Hit Rate an, dann siehst Du wie gut die Prefetcher bei Spielen arbeiten :)
Cachelastige Anwendungen sind in der Regel auch sehr speicherintensiv. Da hast Du beim i7 dann einen IMC und einen 3 spurigen unganged DDR3 Datenhighway. Core2 muss sich dagegen mit nem FSB + einem ganged MC rumschlagen. Hättest Du nen C2Q + IMC, wäre der sicher nicht schlechter als der i7 ;-)

würde ich zumindest definitiv nicht ausgehen. Bestes Beispiel ist der Phenom II, der sich trotz deutlich höherer Speicherbandbreite und kürzeren Latenzen in solchen Fällen eben nicht vom Core 2 absetzen kann. Teils fallen hier die üblichen 10-15% IPC Unterschied zwischen beiden auf einen Gleichstand zusammen, die in Teilfällen (wie aktuell Anno) auftretenden >50% Vorsprung für den i7 lassen sich aber schwerlich darauf schieben.


..in dem Fall kann man mixen, wir reden nur von der Latenz & Bandbreite im Allgemeinen. Dass der L3 eines i7 mit den kleineren L1 und L2 caches, weniger starken Einfluss als AMDs L3 hätte, ist abwegig.


Wir reden doch auch genau vom Gegenteil, nämlich das der L3 beim i7 den deutlich größeren Einfluss auf die resultierende Performance v.a. in Spielen hat.

[S940]

Nicht wirklich, ich sprach immer von beidem. Die Hit-Rate ist imho durch ihre Größenabhängigkeit schon nicht mehr zum Punkt "Geschwindigkeit" zu zählen, aber darüber kann man sich jetzt streiten; davonZu Geschwindigkeit nicht, aber zu Leistung / Performance, und das ist das, wovon Du in Deinem ersten Posting sprachst:
Die reale Cacheperformance scheint beim i7 im Verhältnis deutlich besser zu sein.Das Du darunter v.a. Bandbreite verstehst oder Latenz, oder beides ... kann ich nicht riechen.

würde ich zumindest definitiv nicht ausgehen. Bestes Beispiel ist der Phenom II, der sich trotz deutlich höherer Speicherbandbreite und kürzeren Latenzen in solchen Fällen eben nicht vom Core 2 absetzen kann. Teils fallen hier die üblichen 10-15% IPC Unterschied zwischen beiden auf einen Gleichstand zusammen, die in Teilfällen (wie aktuell Anno) auftretenden >50% Vorsprung für den i7 lassen sich aber schwerlich darauf schieben.
Lol, jetzt tritt genau obiger Fall ein, das war früh, wie sagtest Du so schön vor ein paar Minuten:
all das lässt sich schwer in einen Topf werfen, umrühren und dann auf gleiches Verhalten schließen.
Genau das ... Du schließt jetzt *nur* von Cacheigenschaften auf die Gesamtperformance --> Error.

Wir reden doch auch genau vom Gegenteil, nämlich das der L3 beim i7 den deutlich größeren Einfluss auf die resultierende Performance v.a. in Spielen hat.
Jo davon reden wir. Ich schrieb doch: "Kleinerer Einfluss ist abwegig" übersetzt bedeutet das: großer Einfluss. Immer den ganzen Satz lesen und in seiner Gesamtheit erfassen. :biggrin:

ciao

Alex

[Undertaker]

Zu Geschwindigkeit nicht, aber zu Leistung / Performance, und das ist das, wovon Du in Deinem ersten Posting sprachst:
Das Du darunter v.a. Bandbreite verstehst oder Latenz, oder beides ... kann ich nicht riechen.

Das sind die üblichen Parameter, wenn man von Geschwindigkeit eines Speichers spricht. ;) Aber nun ist ja klar, worum es ging.


Lol, jetzt tritt genau obiger Fall ein, das war früh, wie sagtest Du so schön vor ein paar Minuten:

Genau das ... Du schließt jetzt *nur* von Cacheigenschaften auf die Gesamtperformance --> Error.

Nein, nochmal nachdenken: Ich rede von der relativen Performance von Core 2 zu Phenom II in Relation zueinander. Und genau die ist in schöner Regelmäßigkeit pro Takt ausgeglichen (und eben nicht 10-15% niedriger) genau in den Fällen, wo der i7 besonders weit vorne liegt. Das ist der Punkt.


Jo davon reden wir. Ich schrieb doch: "Kleinerer Einfluss ist abwegig" übersetzt bedeutet das: großer Einfluss.

Jetzt fühl ich mich von dir aber gelinde gesagt veralbert:

Du vergisst den im Desktopbereich nicht gerade unwichtigen Bereich der Spiele. Hier profitiert der Phenom enorm vom L3 Cache - wie man bei CB sieht - und ich vermute, dass dieser bzw. seine sehr schnelle/breite Anbindung auch einer der Gründe für die hohe Leistung des i7 ist.

Da vermutest Du falsch ^^


Was ist denn nun deine Ansicht? Ja, nein, unentschlossen? :confused:

[.alice]

hi,

Naja, aber so viel Performance kostet das ja auch nicht unbedingt. Ist doch ähnlich bei Multi CPU Systemen. Da sind die Prozessoren noch viel weiter auseinander.

und genau das kostet eben zeit, viel zeit, hier nochmals als kleiner ansatz
(bitte bei den 8cores schauen):

http://www.maxxpi.net/pages/description/multipi/multipis-scaleability.php

und aus reiner neugierde, habe ich eine spezielle version von maxxpi auf 32cores getrimmt und einen dicken server rangelassen=>

AMD Opteron 8384 (@2.7Ghz, HP DL785G5), 256GB, also 8x4 = 32 echte cores (memsubsystem:ddr2 667,5-5-5-15),

SW, Memory Allocator: http://www.hoard.org/ (in meinen augen momentan einer der besten)

resultat: ernüchternt, ich sage mal nur etwa 50-60% er erwarteten leistung, klar das ist immernoch *höllisch schnell
(unter 128M braucht man garnicht anzufangen mit dem benchen)
aber eben nicht das was ich erwartet hatte.

ot: geil wars trotzdem, zu sehen wie die last auf dem server mal locker 100%
auf 32cores erreichte, mit einer PMU von ca. 80% auf jedem core! :biggrin:
ich glaub, dass wird dem nie wieder wiederfahren...

cu

[S940]

Das sind die üblichen Parameter, wenn man von Geschwindigkeit eines Speichers spricht. ;) Aber nun ist ja klar, worum es ging.
Jo endlich ... ^^
Vor allem, da Du selbst anfangs selbst nur von Latenz sprachst ;-)
Seine theoretisch deutlich höhere Latenz kann der L3 des i7 in der Praxis anscheinend perfekt verstecken.Hatte ich bisher ganz übersehen ;-)

Nein, nochmal nachdenken: Ich rede von der relativen Performance von Core 2 zu Phenom II in Relation zueinander. Und genau die ist in schöner Regelmäßigkeit pro Takt ausgeglichen (und eben nicht 10-15% niedriger) genau in den Fällen, wo der i7 besonders weit vorne liegt. Das ist der Punkt.Und ? Die relative Performance - nehmen mir mal an, dass die gleich ist, wie Du sagst - hat völlig unterschiedliche Grundlagen. Das kannst Du nicht vergleichen -> Nochmal nachdenken ;-)
Ich könnte jetzt wieder nen Vergleich bringen, aber sowas hattest Du noch nie verstanden, bzw. fühltest Dich beleidigt, also lass ichs mal hier in dem Fall.



Jetzt fühl ich mich von dir aber gelinde gesagt veralbert:
*Lach*

Was ist denn nun deine Ansicht? Ja, nein, unentschlossen? :confused:
Ok, war wohl etwas viel ;-) Aber Du wolltest diskutieren, wenn Du das willst, musst Du dann auch den Überblick behalten ^^
Da heute Sonntag ist, helf ich mal noch, ist einfach, Du bist wieder am Anfang:

* großer schneller Cache
* großer langsamer Cache

Das obige AMD L3 Beispiel war nur dazu gedacht, zu verdeutlichen, das bei Caches die Latenzen wichtig sind. Siehe eben AMDs L3 Beispiel, der keine tolle Bandbreite hat, aber eine bessere Latenz als RAM. Das rentiert sich, weswgen AMD da jetzt sogar 6 MB aufs Die "pappt".

Das muss jetzt beim i7 genauso sein, da er noch kleinere L1/L2 Caches hat, ergo wird der L3 noch höher frequentiert werden, als der bei AMD, da die L1/L2 miss rate höher sein muss.
Das wiederum bedeutet, dass der L3 des i7 wichtig ist - ja :)

Aaaaber, mit nem großen *L2* wär das Ganze natürlich noch besser.

ciao

Alex

[Lawmachine79]

Das muss jetzt beim i7 genauso sein, da er noch kleinere L1/L2 Caches hat, ergo wird der L3 noch höher frequentiert werden, als der bei AMD, da die L1/L2 miss rate höher sein muss.

Klar ist die Cachegröße ein wichtiger Einflussfaktor auf die Hitrate, aber Cachegröße kann man immer noch durch eine gute Sprungvorhersage wegmachen.
Und die Qualität der Sprungvorhersage wiederum hängt von vielen Einflußfaktoren ab:
http://www.kreissl.info/diggs/ra_07.php
Letztenendes ist es Güterabwägung: die Logik für eine gute Sprungvorhersage frisst auch Transistoren, die Transistoren dürften auch wesentlich teurer sein als stupide aneinandergereihte Speicherzellen. Welche Mischung an Sprungvorhersagequalität/Cachestufen/Cachegröße die Richtige ist, ist 1) eine Architekturfrage und 2) ein mathematisches Optimierungsproblem. Gerade Zweiteres ist derart komplex, daß 940 und Undertaker sich ewig im Kreis drehen können, welche Lösung die Richtige ist. Ich denke die Cachestrategie von AMD und Intel konvergiert vor dem Hintergrund der jeweiligen Architektur betrachtet gegen perfekt (wahrscheinlich lässt sich das mathematische Problem nämlich gar nicht exakt lösen). Was die Architekturen selbst angeht sind bei AMD und Intel durchaus strategische Fehlentscheidungen möglich (siehe Netburst, als Paradebeispiel) aber die Architekturen selbst sind in sich stimmig. Sicher war alles in einer Netburst CPU perfekt an Netburst angepasst, dennoch war Netburst selbst eben grottenschlecht (es zählen nun einmal Ergebnisse), um mal ein Beispiel zu nennen.

[Gast]

Aaaaber, mit nem großen *L2* wär das Ganze natürlich noch besser.

Selbst eine Verdoppelung auf 512KiB wären schon "groß".
So ein Schritt sollte der nächste Shrink mit sich bringen, Intel war so clever und hat gleich ein Hintertürchen für mehr Performance ohne Mehrtakt offen gelassen.

[Coda]

aber Cachegröße kann man immer noch durch eine gute Sprungvorhersage wegmachen.
Wie kommst du denn darauf? :|
Klar, wird das hin und wieder mal einen Load oder Store vermeiden, aber im Regelfall dürfte gutes Prefetching weitaus wichtiger sein.

[S940]

Klar ist die Cachegröße ein wichtiger Einflussfaktor auf die Hitrate, aber Cachegröße kann man immer noch durch eine gute Sprungvorhersage wegmachen.
Und die Qualität der Sprungvorhersage wiederum hängt von vielen Einflußfaktoren ab:
http://www.kreissl.info/diggs/ra_07.php
Möglich, aber wies so schön im Artikel heißt:
Dynamische Verfahren erreichen Trefferraten bei der Vorhersage von 98% und mehr!
AMD hat beim K10 nachgelegt und ist jetzt mehr oder minder auf Intel Niveau, das nimmt sich nicht viel. Aber mit dem Rest hast Du Recht, ein ganzes CPU Design ist immer eine ganz große Trade Off Geschichte.

@Gast:
Mit "groß" meinte ich eigentlich Core2 Dimensionen also so 3-6 MB.
Wie auch immer, da der i7 nunmal da ist, hatte ich auch gehofft, dass bei 32nm L2 nachgelegt wird. Wird aber nicht, es bleibt bei 256kB, nur der L3 wird größer.
http://www.hardwareluxx.de/index.php/news/hardware/prozessoren/12767-intel-gulftown-in-wprime-getestet.html

ciao

Alex

[Undertaker]

Und ? Die relative Performance - nehmen mir mal an, dass die gleich ist, wie Du sagst - hat völlig unterschiedliche Grundlagen.

Schade das du hier die Grundlagen nicht verstehst. ;) Einmal versuche ich es noch, deine Aussage war:

Hättest Du nen C2Q + IMC, wäre der sicher nicht schlechter als der i7

Du möchtest diskutierte Unterschiede von z.B. 50% im diskutierten Fall in Anno einzig und allein auf den IMC schieben. Genau das funktioniert nicht. Warum? Würde der IMC in diesem Fall soviel Leistung bringen, würde sich die Relation Phenom II zu Core 2 völlig anders darstellen.


Das wiederum bedeutet, dass der L3 des i7 wichtig ist - ja :)


Interessant, wie sich deine Meinung innerhalb eines Tages um 180° drehen kann, aber ich vermute, es ging von Anfang an nur darum, widersprechen zu wollen, richtig?
Schau dir nochmal das zuletzt von mir zitierte Ausgangsposting von mir an (in diesem spreche ich übrigens auch explizit von der Bandbreite, Stichwort "breite Anbindung" - hast du wohl überlesen), ich sprach von der großen Bedeutung des L3 für die hohe Performance, wobei du mir nun endlich auch zustimmst. Genau dieser L3 ist beim PII nun ein gutes Stück langsamer (was das umfasst, hatten wir geklärt), was auch einen der wichtigen Gründe für die Leistungsunterschiede in diversen Fällen darstellt.


Mit "groß" meinte ich eigentlich Core2 Dimensionen also so 3-6 MB.
Wie auch immer, da der i7 nunmal da ist, hatte ich auch gehofft, dass bei 32nm L2 nachgelegt wird. Wird aber nicht, es bleibt bei 256kB, nur der L3 wird größer.
http://www.hardwareluxx.de/index.php/news/hardware/prozessoren/12767-intel-gulftown-in-wprime-getestet.html


...Was übrigens wohl der beste Beweis dafür ist, dass du mit deiner Analyse daneben liegst. ;) Die Bedeutung großer L2-Caches wie beim Core 2 hat sich mit der Nehalem-Architektur extrem gemindert.

[S940]

Schade das du hier die Grundlagen nicht verstehst. ;) Jo, ich glaube ich kapitulier auch in diesem Forum vor dem Ausbund deiner strahlenden Weisheit ... jeder hat ja ne 2te Chance und Dein Avantar hier ist etwas "friedlicher" als im Luxx, aber die Beitragsqualität ist deswegen leider auch nicht qualifizierter.

Du möchtest diskutierte Unterschiede von z.B. 50% im diskutierten Fall in Anno einzig und allein auf den IMC schieben. Anno ist bisher das *einzigste* Spiel, das SMT ausnützen kann und Du nimmt es als Paradebeispiel her. Oh wie sinnvoll, ein Beweis Deiner leuchenden Klugheit :umassa:....

Interessant, wie sich deine Meinung innerhalb eines Tages um 180° drehen kann, aber ich vermute, es ging von Anfang an nur darum, widersprechen zu wollen, richtig?
Ne,
a) es hat sich nichts gedreht,
b) Du kapierst nur wieder mal nichts, selbst nach 2maligen Erklärungsversuchen.

Allerletzter Versuch:
Ich rede die ganze Zeit (in diesem Zusammenhang) von der Cachegröße. Ich kopiers das 3. Mal, vielleicht schaffen es die Buchstaben mal vom Auge ins Gehirn:

Was ist besser ?:
* großer schneller Cache
* großer langsamer Cache

Die Größe (und Latenz) ist wichtig. Deswegen ist auch der (große) L3 des i7 wichtig, besser als gar nichts ist er allemal. Aber der L3 hat ne schlechte Latenz. Die gleiche Cachegröße in L2 mit der halben Latenz wäre besser. Das zieht aber einen Rattenschwanz an Designentscheidungen und Nachteilen im Serverbereich nach sich, weswegen das keine Option war.

...Was übrigens wohl der beste Beweis dafür ist, dass du mit deiner Analyse daneben liegst. ;) Ich verneige mich vor der Prägnanz Deiner stichhaltigen Schlussfolgerung. Du hast natürlich Recht, die Narren, die das auf die inklusive Cache Architektur schieben würden, bei der mehr L2 automatisch mehr Platzverschwendung im L3 bedeutet würde, leben alle im finsteren Tal der Ahnungslosen.

Frohes Forendasein wünsche ich noch, falls noch was sein sollte, bitte PM.

*ingore aktiviert*

Alex

[Undertaker]

Sehr schade, dass du mit deinem aggressiven Schreibstil und unvorstellbarer Selbstüberschätzung auch hier die Diskussion zu Boden drückst. Ich versuch es nochmal mit Fakten:


Ich rede die ganze Zeit (in diesem Zusammenhang) von der Cachegröße.

Und das reicht eben nicht zu. Die Entscheidende Bedeutung der Geschwindigkeit desselben darf nuneinmal nicht vernachlässigt werden.

Die Größe (und Latenz) ist wichtig. Deswegen ist auch der (große) L3 des i7 wichtig, besser als gar nichts ist er allemal. Aber der L3 hat ne schlechte Latenz. Die gleiche Cachegröße in L2 mit der halben Latenz wäre besser.

Genau. Sinnvollerweise beschränken wir uns in der Diskussion aber auf die praktisch realisierbaren Alternativen, da stellt das bisherige Konzepte von einem auf je 2 Kerne aufgeteilten L2 die schlechtere Alternative dar.



Anno ist bisher das *einzigste* Spiel, das SMT ausnützen kann

SMT bringt in Anno keine 10% von taktbereinigt über 80% zwischen dem i7 920 und dem X4 965 (X4 955 mit 200MHz Übertaktung per Multi). Das kann es wohl nicht sein.

i7, 2,66GHz: 46fps
X4, 3,4GHz: 32,1fps

-> 43,3% Differenz + 27,8% Taktunterschied. Resultiern gut 80% taktbereinigt, die ich aber gar nicht weiter verallgemeinern möchte, bin ja auch ein PII Besitzer. ;)

SMT on vs. off: 46,9fps zu 42,7fps, knapp 10%. Verbleiben etwa 65% taktbereinigt ohne SMT.

Beleidigungen im Sinne der Diskussionskultur herausgeschnitten, verzeih. :)

[Gast]

Klar ist die Cachegröße ein wichtiger Einflussfaktor auf die Hitrate, aber Cachegröße kann man immer noch durch eine gute Sprungvorhersage wegmachen.

Nicht wirklich, 1x durchlaufene abhängige sprünge sind ohnehin nicht vorhersagbar und vorhersagen für mehrfach durchlaufene sprünge wie beispielsweise schleifen sind recht einfach vorhersagbar.
Auf die hitrate im cache hat das überhaupt keinen einfluss. Der cache wird ja auch erst sinnvoll wenn daten mehrfach verwendet werden, für einen einzigen zugriff auf eine speicheradresse bringt der cache rein garnichts.


Letztenendes ist es Güterabwägung: die Logik für eine gute Sprungvorhersage frisst auch Transistoren, die Transistoren dürften auch wesentlich teurer sein als stupide aneinandergereihte Speicherzellen.

Nicht wirklich, wie gesagt kann die sprungvorhersage nur bei schleifen verbessert werden, und dort ist es recht einfach. Im prinzip ist die ganze sprungvorhersage nichts anderes als eine art cache, der eben die sprünge abspeichert.

[Lawmachine79]

Nicht wirklich, wie gesagt kann die sprungvorhersage nur bei schleifen verbessert werden, und dort ist es recht einfach. Im prinzip ist die ganze sprungvorhersage nichts anderes als eine art cache, der eben die sprünge abspeichert.
Stimmt, ein Buffer ist ja nichts anderes als ein Cache...

[Coda]

Nicht wirklich, wie gesagt kann die sprungvorhersage nur bei schleifen verbessert werden, und dort ist es recht einfach. Im prinzip ist die ganze sprungvorhersage nichts anderes als eine art cache, der eben die sprünge abspeichert.
Moderne Sprungvorhersagealgorithmen können weitaus mehr vorhersehen als nur Schleifen.

[Aquaschaf]

Moderne Sprungvorhersagealgorithmen können weitaus mehr vorhersehen als nur Schleifen.

"Schleifen vorhersehen" ist vielleicht etwas überspitzt formuliert. Aber sehr viel mehr geht doch tatsächlich nicht? Wenn die Chance für den Ausgang eines Sprungs in die Richtung von 50/50 geht, dann bringt keine Art von Sprungvorhersage etwas.

[Gast]

Wenn die Chance für den Ausgang eines Sprungs in die Richtung von 50/50 geht, dann bringt keine Art von Sprungvorhersage etwas.

Sie bringt insofern etwas, als dass sie zu 50% richtig ist. Garkeine sprungvorhersage heißt ja, dass die pipeline bei einem sprung die auf jeden fall blockiert. Mit der primitivsten sprungvorhersage die nichts anderes macht als auf gut glück zu springen hat man immerhin im schnitt in 50% der fälle recht.

[Coda]

"Schleifen vorhersehen" ist vielleicht etwas überspitzt formuliert. Aber sehr viel mehr geht doch tatsächlich nicht? Wenn die Chance für den Ausgang eines Sprungs in die Richtung von 50/50 geht, dann bringt keine Art von Sprungvorhersage etwas.
Sprünge sind sehr selten zufällig. Man erreicht schon mit einem primitivstem Branch-Target-Buffer >80% korrekte Vorhersagen (selbst implementiert). Moderne Algorithmen liegen eher >95%.

[Gast]

Sprünge sind sehr selten zufällig. Man erreicht schon mit einem primitivstem Branch-Target-Buffer >80% korrekte Vorhersagen (selbst implementiert). Moderne Algorithmen liegen eher >95%.

Der bringt dir aber bei einem 1x ausgeführten sprung genauso wenig.

[Gast]

Sprünge sind sehr selten zufällig. Man erreicht schon mit einem primitivstem Branch-Target-Buffer >80% korrekte Vorhersagen (selbst implementiert). Moderne Algorithmen liegen eher >95%.

Wenn du genau wissen willst, ein Pentium 4, hat im Druchschnitt auf 160 Vorhersagen, eine Falsche => 159/160 = 99,375% Erfolgsrate.

Bei den Core 2 Duos und den i7 siet es och etwas besser aus.

Wobei Server CPUs (P6, Itanium) In-Order sind und keine Sprungvorhersgae haben.

[Der_Donnervogel]

Der bringt dir aber bei einem 1x ausgeführten sprung genauso wenig.Auch dem kann man mit Überlegungen und Optimierungen z.B. bei Compilern entgegenwirken. z.B. gibt es in Programmen viele Schleifen, die im allgemeinen mindestens einmal, meistens aber öfters durchlaufen werden. Wenn man also gar nichts über einen Sprung weiß, kann man z.B. per default einfach davon ausgehen dass er genommen wird. Wegen der Schleifen und falls auch noch die Compiler passenden Code produzieren, der dafür sorgt dass nach Möglichkeit Sprünge immer genommen werden, kann man so schon leicht die Wahrscheinlichkeit auf Treffer auf Werte >50% heben. Da die Leute von Intel & Co auf dem Gebiet aber schon jahrzehntelange Erfahrungen haben, gibt es dazu sicher sehr ausgefeilte Strategien um mittels Heuristiken eine möglichst gute Vorhersage zu treffen.

[samm]

Wenn du genau wissen willst, ein Pentium 4, hat im Druchschnitt auf 160 Vorhersagen, eine Falsche => 159/160 = 99,375% Erfolgsrate.Bei welchem Benchmark? ;) Oder hat man das tatsächlich an einem laufenden Computer mit diversen Programmen getestet? An einem derart effizienten Sprungvorhersage-Algorithmus wären auch ganz andere Bereiche als nur Prozessorhersteller interessiert, könnte ich mir denken.

[Aquaschaf]

Sprünge sind sehr selten zufällig.

Das ist mir schon klar. Aber mehr als auf Basis früherer Ausgänge eines Sprungs zu raten kann kein Algorithmus. Sonst würde er das Halteproblem lösen :D

[Der_Donnervogel]

Das ist mir schon klar. Aber mehr als auf Basis früherer Ausgänge eines Sprungs zu raten kann kein Algorithmus. Sonst würde er das Halteproblem lösen :DWie gesagt man braucht nicht mal frühere Ausgänge von Sprüngen. Diese zusätzliche Information verbessert nur die Trefferchance. Was man allerdings wirklich nicht kann ist es einen Sprung immer korrekt vorherzusagen (außer es ist ein unbedinger Sprung ;) ).

[SavageX]

Wobei Server CPUs (P6, Itanium) In-Order sind und keine Sprungvorhersgae haben.


Gerade in-order Prozessoren können eine gute Sprungvorhersage gut gebrauchen, da sie nicht zwischenzeitlich andere Happen in die Pipeline einschieben können bis das Sprungziel feststeht.

Der P6 ist natürlich der Pentium Pro, also über Pentium II und III der Urvater aktueller Intel-Prozessoren und selbstverständlich out-of-order und spekulativ.

[Coda]

Wobei Server CPUs (P6, Itanium) In-Order sind und keine Sprungvorhersgae haben.
Das ist Quatsch. Nur weil etwas In-Order ist heißt es noch lange nicht das man keine Sprungvorhersage braucht. Das ist bei jeder CPU mit Pipeline nötig.

Selbst der erste Pentium hatte schon einen BTB.

[BlackBirdSR]

Wenn du genau wissen willst, ein Pentium 4, hat im Druchschnitt auf 160 Vorhersagen, eine Falsche => 159/160 = 99,375% Erfolgsrate.

Bei den Core 2 Duos und den i7 siet es och etwas besser aus.

Wobei Server CPUs (P6, Itanium) In-Order sind und keine Sprungvorhersgae haben.

verwechselst du das mit spekulativer Ausführung?
Aber da hatte der P4 sicherlich keine 159 von 160. Sonst hätte man Replay gar nicht erst gebraucht.

[Coda]

Klar braucht man Replay. Das ist dazu da die Instruction zu wiederholen wenn man im Nachhinein einen Data-Cache-Miss feststellt. Da hilft auch die beste Branch Prediction nicht.

[Lawmachine79]

verwechselst du das mit spekulativer Ausführung?
Aber da hatte der P4 sicherlich keine 159 von 160. Sonst hätte man Replay gar nicht erst gebraucht.
Naja bei einer 3x-stufigen Pipeline tut auch ein Miss auf 160 weh.

[Aquaschaf]

Wie gesagt man braucht nicht mal frühere Ausgänge von Sprüngen.

Und wie soll das gehen? Ein Compiler/Profiler kann vielleicht begrenzt Muster finden, oder den Code ausprobieren. Und darauf basierend Hinweise für den Prozessor platzieren. Aber aufwendige Code-Analyse in Hardware? Ich glaube nicht.

Btw: tolle Aussage, dass man die Trefferrate auf über 50% heben kann. Das ist keine Kunst. 50% hab ich ja auch schon wenn ich eine Münze werfe. ;)

[Der_Donnervogel]

Und wie soll das gehen? Ein Compiler/Profiler kann vielleicht begrenzt Muster finden, oder den Code ausprobieren. Und darauf basierend Hinweise für den Prozessor platzieren. Aber aufwendige Code-Analyse in Hardware? Ich glaube nicht.Das habe ich auch nicht behauptet. :confused:

Ich habe nur gesagt, dass es prinzipiell möglich ist eine Sprungvorhersage zu treffen selbst wenn man nichts über die Befehlshistorie kennt und dass diese dann dann besser ist als reiner Zufall. Dass man so nicht auf die besten Raten kommen kann ist klar. Je mehr Informationen hat umso besser kann die Heuristik gestaltet werden die hinter der Sprungvorhersage steckt. Es bleibt aber immer raten. Man kann nur die Wahrscheinlichkeiten dass man richtig rät verbessern.
Btw: tolle Aussage, dass man die Trefferrate auf über 50% heben kann. Das ist keine Kunst. 50% hab ich ja auch schon wenn ich eine Münze werfe. ;)Doch genau das ist die Kunst. Denn 50% würde man bei völlig zufälligem Verhalten erwarten. Allerdings sind die Sprünge im Code nicht völlig zufällig. Aus diesem Grund würde man wenn man also eine Münze werfen würde in weniger als 50% der Fälle richtig liegen, da das Verhältnis von "Sprung" zu "Nicht Sprung" eben nicht bei je 50% liegt. Beispielsweise tendieren viele Programmierer dazu den boolschen Ausdruck bei Bedingungen so zu formulieren dass im allgemeinen der if-Zweig und nicht der else-Zweig ausgeführt wird. Ganz ähnliches tritt bei Schleifen auf, wo zB. eine for-Schleife die nie durchlaufen wird eine Ausnahme und mehr als ein Durchlauf die Regel ist. Wird das bei der Codegenerierung berücksichtigt, kann der Compiler also die Sprünge entsprechend vorbereiten sodass sie nach Möglichkeit zum default-Verhalten der CPU passen. Natürlich kann man das dann zur Laufzeit, wenn der Sprung schon einmal genommen wurde noch weiter verfeinern. Damit kann man dann wirklich "erkennen" ob man sich beispielsweise in einer Schleife befindet.

edit: Dabei kann man schon mit sehr einfachen Methoden auf recht hohe Raten kommen. Beispielsweise indem man sich einfach mit zwei Bit speichert ob die Sprünge genommen wurden ("strong taken", "weakly taken", "weakly not taken", "strong not taken") und das dann zur Laufzeit anpasst. Ganz wichtig ist dabei aber auch der Intialzustand in dem das System startet. Wenn da ein Fehler ist, und zB das System mit "strong not taken" als Default startet, man sich aber zB in einer Schleife befindet dann hat man zuerst zwei falsche Vorhersagen ("strong not taken" -> "weakly not taken" -> "weakly taken") ehe man das erste mal richtig vorhersagt. Deshalb ist alleine nur die Information zur Laufzeit nicht ausreichend. Natürlich werden moderne Prozessoren noch ausgeklügelte Mechanismen haben, aber das Problem der ersten Vorhersage bleibt bestehen.

[Aquaschaf]

Ich habe nur gesagt, dass es prinzipiell möglich ist eine Sprungvorhersage zu treffen selbst wenn man nichts über die Befehlshistorie kennt und dass diese dann dann besser ist als reiner Zufall.

Wie bereits gesagt: wie denn bitteschön? Außer Annahmen zu treffen darüber wie sich Sprünge in einem "normalen" Programm verhalten und zu hoffen dass das dann zutrifft kann man prinzipiell nichts machen. Letztendlich läuft es aufs Halteproblem hinaus. Bei vielem realen Code erzielt man zwar gute Ergebnisse, aber ich kann dir problemlos etwas (sinnvolles) schreiben bei dem Branch Prediction überhaupt nichts bringt.

Bzw. ist es aufgrund dieser Tatsache unter Umständen besser mehr Komplexität in Kauf zu nehmen, wenn man dafür Sprünge bekommt die nicht ganz zufällig sind. Beispielsweise ist es bei Quicksort vorteilhaft Pivotelemente etwas ungeschickter zu wählen, anstatt auf eine Weise die die erwartete Zahl an Vergleichen minimiert. Denn letztere Vorgehensweise führt dazu dass man irgendwann 50% Branch Misses hat.

Du erzählst mir nichts neues, ich kenne die Verfahren.

[Coda]

Er hat es doch schon erklärt. Es ist z.B. bei Schleifen wahrscheinlicher dass der Sprung genommen wird. Das kann man mit einem Loop-Detector in der CPU schon feststellen. Da muss man nicht gleich das Halteproblem dafür lösen ;)

[Aquaschaf]

Er hat es doch schon erklärt. Es ist z.B. bei Schleifen wahrscheinlicher dass der Sprung genommen wird.

Es geht mir doch nur um die Aussage: auch ohne die Branch-History zu kennen könne man Vorhersagen treffen die besser sind als zu eine Münze zu werfen. Und das geht nicht.

[SavageX]

Ich glaube ihr müsst definieren, welche Situation ihr genau beschreibt.

Üblicherweise werden Schleifen mehrfach durchlaufen, so dass ich mit einem statischen Prädiktor, der einfach fest für Schleifen einen zu nehmenden Sprung annimt, global betrachtet über das gesamte Programm im Mittel besser als eine Münze bin.

Das bedeutet nicht, dass ich lokal für eine Schleife gesehen besser sein muss. Bei einer Schleife, die niemals durchlaufen wird, habe ich bei einem derartigen statischem Prädiktor eine falsche Vorhersage in 100% der Fälle.

[BlackBirdSR]

Ich glaube ihr müsst definieren, welche Situation ihr genau beschreibt.

Üblicherweise werden Schleifen mehrfach durchlaufen, so dass ich mit einem statischen Prädiktor, der einfach fest für Schleifen einen zu nehmenden Sprung annimt, global betrachtet über das gesamte Programm im Mittel besser als eine Münze bin.

Das bedeutet nicht, dass ich lokal für eine Schleife gesehen besser sein muss. Bei einer Schleife, die niemals durchlaufen wird, habe ich bei einem derartigen statischem Prädiktor eine falsche Vorhersage in 100% der Fälle.

Die meisten Schleifen laufen zum Glück mehrmals durch :). wie Predictor und die einzelnen Tables für verlässliche Informationen sorgen, um die Wahrscheinlichkeit des Austritts sehr gut vorherzubestimmen... das beeindruckt mich jedesmal aufs Neue. Vor Allem im Vergleich zum pentium ^^

Aber jetzt sind wir von einem reinen victim-Cache auf Probleme ab L1-Cache bis hinter die Decoder abgerutscht

[Aquaschaf]

Ich glaube ihr müsst definieren, welche Situation ihr genau beschreibt.

Mir geht es um Sprünge im Allgemeinen. Ohne irgendwelche Annahmen darüber wie ein Programm aussieht.

Die meisten Schleifen laufen zum Glück mehrmals durch :). wie Predictor und die einzelnen Tables für verlässliche Informationen sorgen, um die Wahrscheinlichkeit des Austritts sehr gut vorherzubestimmen...

Naja, ich finde das nicht unbedingt beeindruckend (womit ich natürlich nichts gegen Sinn und Zweck solcher Mechanismen sage). Wie gut diese einfachen Heuristiken funktionieren zeigt anders herum eher wie wenig Entropie in den meisten Sprüngen steckt.

[Gast]

Gerade in-order Prozessoren können eine gute Sprungvorhersage gut gebrauchen, da sie nicht zwischenzeitlich andere Happen in die Pipeline einschieben können bis das Sprungziel feststeht.

Das kann ein OoO genauso wenig ohne sprungvorhersage.

Eine sprungvorhersage bedeutet ja erstmal nur dass die befehlsausführung bei einem sprungbefehl trotzdem weitergeführt wird. Selbst wenn der prozessor einfach sprünge generell ausführt ist das eine art vorhersage die bei rein zufälligen sprüngen immerhin schon 50% erfolgswahrscheinlichkeit hat.

[Gast]

Wie gesagt man braucht nicht mal frühere Ausgänge von Sprüngen.

Dafür braucht es aber branch-hints im maschinencode die unterstützt werden müssen.

[Coda]

Es geht mir doch nur um die Aussage: auch ohne die Branch-History zu kennen könne man Vorhersagen treffen die besser sind als zu eine Münze zu werfen. Und das geht nicht.
Doch. Ich habe dir gerade erklärt warum. Die CPUs kennen zumindest ansatzweise den Kontext der Branch-Instruction, und daraus können sie Schlüsse ziehen.

Dafür braucht es aber branch-hints im maschinencode die unterstützt werden müssen.
Nein. CPUs haben z.B. Erkennungsmechanismen für Schleifen, die sie ausnutzen um Sprünge vorherzusagen.

[BlackBirdSR]

Das kann ein OoO genauso wenig ohne sprungvorhersage.



Da reden wohl 2 Leute von 2 unterschiedlichen Sachen.

[Gast]

Bei welchem Benchmark? ;) Oder hat man das tatsächlich an einem laufenden Computer mit diversen Programmen getestet? An einem derart effizienten Sprungvorhersage-Algorithmus wären auch ganz andere Bereiche als nur Prozessorhersteller interessiert, könnte ich mir denken.

Bei "normaler" Software, du kannst das bei Intel CPUs aus den internen Countern auslesen. Dieser Wert erscheint hoch, ist es aber nicht wirklich, wenn man bedenkt was für folgen ein falsch vorhergesater Sprung hat, es sind im Mittel 200 bis 300 Takte ( Flush der Pipeline + nicht vorgehaltene Berechnungsergebisse). Bei AMD kenn ich den genauen Wert auch nicht, aber die lliegen auch bei über 99% korrekte vorhersagen.

Es ist ja auch mehr als "nur" ein Algorithmus, da ist Codeanalyse im mehrere Millionen Transistoren gegossen.

mfg

[Aquaschaf]

Doch. Ich habe dir gerade erklärt warum. Die CPUs kennen zumindest ansatzweise den Kontext der Branch-Instruction, und daraus können sie Schlüsse ziehen.

Wie sieht man denn in x86 ob ein Sprung zu einer Schleife gehört? Dafür braucht man doch schon Code-Analyse.

Es ist ja auch mehr als "nur" ein Algorithmus, da ist Codeanalyse im mehrere Millionen Transistoren gegossen.

Hast du dazu relevante Papers parat? Mich überrascht es dass man sowas in Hardware gegossen on-the-fly machen können soll?

[Coda]

Naja die CPU weiß ja z.B. wo eine Funktion angefangen hat. Wenn dann ein Rücksprung kommt der nicht weiter als die Grenze springt, dann ist es wohl eine Schleife. Gibt sicher auch noch andere Kriterien.

Das schöne an Branch Prediction ist, dass man sich einfach riesige Traces speichert von reellen Programmen und auf diese dann sehr schnell ein Verfahren testen kann. Das macht das testen von Heuristiken sehr einfach.

[Gast]

Naja die CPU weiß ja z.B. wo eine Funktion angefangen hat. Wenn dann ein Rücksprung kommt der nicht weiter als die Grenze springt, dann ist es wohl eine Schleife.

Dafür reicht dann aber auch eine einfache history table, und über den ersten sprung weißt du trotzdem nichts.