Prozessoren mit hoher Pro-MHz Leistung?

[ollix]

Hi,

wie man Prozessoren mit hohem Takt baut, weiß man ja inzwischen - die bekannteste Philosophie dürfte sein die Pipeline langzuziehen.

Aber wie baut man Prozessoren mit hoher Pro-MHz Leistung? Die Antwort mit "ohne lange Pipeline" ist irgendwie klar :), aber gibt es für dieses Ziel irgendeine Design Philosophie o.ä.?

Dazu noch eine Frage: Haben die AMD CPUs bzw. die Pentium Ms nur einer kürzere Pipeline oder gar keine?

danke

[StefanV]

1. Breit bauen
2. Speichercontroller integrieren
3. kurz bauen.

Und ja, P-M und A64 haben deutlich kürzere Pipelines, gepaart mit einer breiteren Architektur (mehr Ausführungseinheiten)...

[Duran05]

Wie wäre es mit: "Mehr Cache"?

Bisher hat das bei vielen Prozessoren zu einer ordentlichen Leistungssteigerung geführt...

Ist wahrscheinlich nicht die effektivste Variante, aber ein Weg von vielen...

[ilPatrino]

Wie wäre es mit: "Mehr Cache"?

Bisher hat das bei vielen Prozessoren zu einer ordentlichen Leistungssteigerung geführt...

Ist wahrscheinlich nicht die effektivste Variante, aber ein Weg von vielen...

den kann man reduzieren, indem man den speicher breit, schnell und vor allem mit geringer latenz anbindet. viel cache hilft nur weiter, wenn an der speicheranbindung ein flaschenhals entsteht...außerdem gilt das gesetz des abnehmenden ertrags - irgendwann erreicht man einen punkt, wo mehr cache kaum noch mehrleistung bringt, aber die produktionskosten sowie die verlustleistung massiv erhöht und die speicher(cache)verwaltung an den rand des wahnsinns treibt

[Gast]

Ich würde mich über einen 3ghz Dothan für den aktuellen Intel-Sockel freuen,
oder am besten gleich den Speicherkontroller integrieren.
Dass das was bringt hat man ja beim A64 gesehen.

[Muh-sagt-die-Kuh]

den kann man reduzieren, indem man den speicher breit, schnell und vor allem mit geringer latenz anbindet.Breit ist kein Thema, eine niedrige Latenz mit DRAM schon...Viel cache hilft nur weiter, wenn an der speicheranbindung ein flaschenhals entstehtSpeicher ist der größte Flaschenhals bei heutigen CPUs....außerdem gilt das gesetz des abnehmenden ertrags - irgendwann erreicht man einen punkt, wo mehr cache kaum noch mehrleistung bringt, aber die produktionskosten sowie die verlustleistung massiv erhöht und die speicher(cache)verwaltung an den rand des wahnsinns treibtVergiss nicht, dass Anwendungen auch im anspruchsvoller bezüglich des benötigten Speichers werden....dieser Punkt dürfte nie erreicht werden. Verlustleistung ist bei Cache übrigens kein Problem.

[HellHorse]

Wie wäre es mit: "Mehr Cache"?

Bisher hat das bei vielen Prozessoren zu einer ordentlichen Leistungssteigerung geführt...
Der Barton gehört auf jeden Fall nicht dazu, und beim Athlon 64 bringt's auch nicht besonders viel.

[Thanatos]

Der Barton gehört auf jeden Fall nicht dazu, und beim Athlon 64 bringt's auch nicht besonders viel.


Sieht man ja sumal auch daran das die neuren A64 Modelle nur noch 512kb L2 cache haben anstatt früher 1024kb.

Im moment erhöt man ja immer L2 cache, aber wa ist denn mit dem L1 cache ???Bringt das ned viel den zu erhöhe oder zu teuer und aufwendig?Denn im moment gaukeln ja noch so fast all bei 64kb L1Cache rum.

[StefanV]

Sieht man ja sumal auch daran das die neuren A64 Modelle nur noch 512kb L2 cache haben anstatt früher 1024kb.

Im moment erhöt man ja immer L2 cache, aber wa ist denn mit dem L1 cache ???Bringt das ned viel den zu erhöhe oder zu teuer und aufwendig?Denn im moment gaukeln ja noch so fast all bei 64kb L1Cache rum.
Ist sehr aufwendig...

Wobei die 2x64k des K7(und höher) sind eignetlich mehr als ausreichend, die 8k + 24µOps des Willys/Nordwals bzw 16k des Preskopps sind da schon viel enger...

[Thanatos]

Achja fällt mir grad so ein........


Der neue A64 M (Oakville) soll ja 128kb L1 cache bekommen.Wäre das denn nicht dann doch mal ein ansatz das im desktop segment einzuführen???

[Muh-sagt-die-Kuh]

Ist sehr aufwendig...

Wobei die 2x64k des K7(und höher) sind eignetlich mehr als ausreichend, die 8k + 24µOps des Willys/Nordwals bzw 16k des Preskopps sind da schon viel enger...Kapazität ist bei einem L1 nicht alles....

Ein L1 ist immer ein Trade-Off zwischen Latenz und Hit-Rate....je nach Anwendung mal kann die eine Herangehensweise, mal die andere besser funktionieren.

[BlackBirdSR]

Achja fällt mir grad so ein........


Der neue A64 M (Oakville) soll ja 128kb L1 cache bekommen.Wäre das denn nicht dann doch mal ein ansatz das im desktop segment einzuführen???

die AMD CPUs haben alle seit dem K7 128KB L1 Cache.

[GloomY]

Man baut grundsätzlich Prozessoren mit hoher Leistung, nicht mit hoher Instruktion-pro-Takt Rate. Letzteres kann eine Maßnahme sein, um eine hohe Rechenleistung zu erreichen. Es ist also Mittel zum Zweck, nicht umgekehrt. Niemand baut einen Prozessor, um alleine eine möglichst hohe Pro-Takt-Leistung zu erreichen.
wie man Prozessoren mit hohem Takt baut, weiß man ja inzwischen - die bekannteste Philosophie dürfte sein die Pipeline langzuziehen.

Aber wie baut man Prozessoren mit hoher Pro-MHz Leistung? Die Antwort mit "ohne lange Pipeline" ist irgendwie klar :), aber gibt es für dieses Ziel irgendeine Design Philosophie o.ä.?Man versucht eben möglichst viel parallel zu machen. Das ist die prinzipielle Idee bei superskalaren Prozessoren.

Dies zieht sich durch die komplette Pipeline: Es fängt beim Fetchen der Befehle an. Es werden nicht nur einer sondern mehrere Befehle auf einmal geholt, diese parallel dekodiert und dann in die einzelnen Schlangen für die Ausführungseinheiten gestellt. Wenn alle Operanden bereit liegen, können die einzelnen Befehle parallel zueinander ausgeführt werden. Gleichzeitiger Zugriff auf Caches oder Registerfile hilft sowohl beim parallelen Ausführen als auch beim Rückschreiben der Ergebnisse.


Man darf dabei an keiner Stelle der Pipeline zu stark sparen. Ist z.B. die Fetch-Rate zu niedrig, geht das Dekodieren zu lange und die nachfolgenden Einheiten drehen Däumchen. Wenn zu wenig Ausführungseinheiten vorhanden sind, dann limitieren diese eben die maximal mögliche Parallelität.

Die Wahl der ISA ist für hohen ILP (Instruction-Level-Parallism) wohl mitentscheidend. EPIC versucht mittels explizit im Code festgeschriebener Parallelität die Auffindung selbiger zu verbessern. Üblicherweise haben die meisten RISC ISAs z.B. gegenüber x86 einen Vorteil bei der FPU Befehle, weil diese mehr FPU Register besitzen.
Andere Einflüsse seitens der Architektur oder der Implementierung sind natürlich auch nicht zu übersehen.
Dazu noch eine Frage: Haben die AMD CPUs bzw. die Pentium Ms nur einer kürzere Pipeline oder gar keine?Selbstverständlich sind alle heutigen Prozessoren gepipelined.
die AMD CPUs haben alle seit dem K7 128KB L1 Cache.Reden wir lieber von 2 Mal 64 KiB Instruktions- und Datencache.

[Haarmann]

Sooo viel breiter ist ein A64 auch nicht, denn ein P4E. Trotzdem ist er pro MHz deutlich schneller in der Mehrzahl aller Anwendungen.
Längere Pipelines machen auch das Umsortieren schwieriger, nebst neue Sprungvorhersageprobleme entstehen. Damit ich irgendwie sortieren kann bei 30 Stufen, muss ich optimalerweise Befehle für Stufenzahl plus N haben, wobei N möglichst gross sein sollt. Ist natürlich klar, dass da ein A64 mit Befehlen für minimal 30 Takte weit mehr rochieren kann, denn ein P4E mit der gleichen Befehlszahl... Wäre ja saudämlich, wenn man durch die Umordnung sich noch selber das Ei einer Sprungvorhersage legte ;) - das Gegenteil dürfte eher das Ziel sein - die Befehle so umzuordnen, dass das Ergebnis früh genug feststeht. Keine Sprungvorhersage, keine mögliche Fehlvorhersage.
Auch beim Cache würd ich mal vorsichtig sein. Ist der P4 L1 "I-Cache" überhaupt noch ein Cache? Ist der L1 WT Cache nicht eher ein Puffer analog zu den Rows bei nem SDR? Man könnte sogar sagen, dass der P4 gar keinen L1 Cache mehr hat, resp den L2 zu diesem erklären. Den L1 Daten erkläre ich dann zum Read Buffer - auch AMD kennt ja Puffer neben den Caches. Ich finde man kann diese Caches nicht gut vergleichen, denn sie sind einfach zu verschieden. Wer will, der kann zur Anschauung mal Benches mit abgeschalteten Cache Leveln machen. Einmal ohne L1 und einmal ohne L2. Einem P4 ohne L2 geb ich dabei nicht gerade meine Speedempfehlung mit, der könnte schon fast von nem Pentium MMX platt gemacht werden, wogegen sich der A64 noch ganz gut machen dürfte im Vergleich dazu.
Das liegt aber wohl auch am Alter und den damals gängigen Bandbreiten.

[Muh-sagt-die-Kuh]

Sooo viel breiter ist ein A64 auch nicht, denn ein P4E. Trotzdem ist er pro MHz deutlich schneller in der Mehrzahl aller Anwendungen.Der Hauptgrund dafür ist die niedrigere Hauptspeicherlatenz durch den integrierten Controller.Längere Pipelines machen auch das Umsortieren schwieriger, nebst neue Sprungvorhersageprobleme entstehen. Damit ich irgendwie sortieren kann bei 30 Stufen, muss ich optimalerweise Befehle für Stufenzahl plus N haben, wobei N möglichst gross sein sollt. Ist natürlich klar, dass da ein A64 mit Befehlen für minimal 30 Takte weit mehr rochieren kann, denn ein P4E mit der gleichen Befehlszahl... Wäre ja saudämlich, wenn man durch die Umordnung sich noch selber das Ei einer Sprungvorhersage legte ;) - das Gegenteil dürfte eher das Ziel sein - die Befehle so umzuordnen, dass das Ergebnis früh genug feststeht. Keine Sprungvorhersage, keine mögliche Fehlvorhersage.Zu deiner Information: Der Scheduler ist Bestandteil der Pipeline, beim P4 sind es die Stages 10-12.Auch beim Cache würd ich mal vorsichtig sein. Ist der P4 L1 "I-Cache" überhaupt noch ein Cache? Ist der L1 WT Cache nicht eher ein Puffer analog zu den Rows bei nem SDR?Natürlich ist es ein Cache.

[StefanV]

Wer will, der kann zur Anschauung mal Benches mit abgeschalteten Cache Leveln machen. Einmal ohne L1 und einmal ohne L2. Einem P4 ohne L2 geb ich dabei nicht gerade meine Speedempfehlung mit, der könnte schon fast von nem Pentium MMX platt gemacht werden, wogegen sich der A64 noch ganz gut machen dürfte im Vergleich dazu.
Das liegt aber wohl auch am Alter und den damals gängigen Bandbreiten.
Kann ich bei Gelegenheit mal machen ;)

Entweder mit einem 2,6GHz P4 auf einem SIS655FX Brett oder aber auf einem 1729MHz P4 auf einem i850E Brett mit 533MHz RDRAM.

Allerdings: die Ergebnisse eines A64 muss ich AFAIK schuldig bleiben, da mein Gigabyte Board eine deaktivierung der CPU Caches nicht unterstützt...

[Haarmann]

Muh-sagt-die-Kuh

Auch ein Athlon XP hat ne bessere pro MHZ Leistung als ein P4 oder auch ein Pentium M, der gar den gleichen Chipset nutzen kann... Das Alleine kanns daher bestimmt nicht sein. Meinst nicht auch?

Das ist mir schon bewusst, aber es ändert nichts an der prinzipiellen Aussage. Je mehr Befehle ich habe, desto besser kann ich rochieren.

Ein Cache ist bekanntlich immer ein Puffer und doch spricht man nicht bei jedem Puffer von Cache. Ich nenns nun einfach mal Puffer statt Cache und wollt damit anregen, dass man sich das mal überlegt. Wo ist nun der Unterschied zwischen Cache und P/Buffer? Was macht ein Cachelevel aus?

Stefan Payne

Ich hab selber Beides, aber weiss nicht auswendig, ob die Boards es auch können.

[mrdigital]

ein Puffer kann nicht adressiert werden, ein Cache schon. Von der verwendeten Logik ist ein Puffer aber das selbe wie ein Cache, nur das ein Cache eben wesentlich mehr Elemente enthält und eine Adressierungslogik hat (ok ein FIFO hat auch ne Adressierungslogik, die ist aber "autonom", bzw es ist kein wahlfreier Zugriff möglich). In seiner "reinen" Form kann ein Puffer erstmal nur ein Wort speichern.

[Muh-sagt-die-Kuh]

Muh-sagt-die-Kuh

Auch ein Athlon XP hat ne bessere pro MHZ Leistung als ein P4 oder auch ein Pentium M, der gar den gleichen Chipset nutzen kann... Das Alleine kanns daher bestimmt nicht sein. Meinst nicht auch?Der Athlon hat 3 vollwertige ALUs (Naja, nicht ganz, nur eine kann MUL), der P4 nur eine, die FPU des Athlon ist auch nicht so limitiert, die des P4 kann z.B. kein FXCH mit 0 Zyklen Latenz mehr. Dazu ist die Pipeline eben kürzer, was eine kleinere misprediction penalty mit sich bringt.Das ist mir schon bewusst, aber es ändert nichts an der prinzipiellen Aussage. Je mehr Befehle ich habe, desto besser kann ich rochieren.Eine längere Pipeline bedeutet, dass man mehr Instruktionen verfolgen muss, das ist korrekt. Der Umfang an Instruktionen aus denen man sich unabhängige raussuchen kann hängt aber nur von der Größe der Scheduler-Warteschlangen ab.Ein Cache ist bekanntlich immer ein Puffer und doch spricht man nicht bei jedem Puffer von Cache. Ich nenns nun einfach mal Puffer statt Cache und wollt damit anregen, dass man sich das mal überlegt. Wo ist nun der Unterschied zwischen Cache und P/Buffer? Was macht ein Cachelevel aus?Siehe mrdigital.

[sputnik1969]

Üblicherweise haben die meisten RISC ISAs z.B. gegenüber x86 einen Vorteil bei der FPU Befehle, weil diese mehr FPU Register besitzen.
Andere Einflüsse seitens der Architektur oder der Implementierung sind natürlich auch nicht zu übersehen.
Nicht nur RISC-CPUs. Ich denke, es liegt weniger an der geringen Anzahl an Registern als an der perversen Art, die Daten über den Stack übergeben zu müssen anstelle eines direkten Registerzugriffs wie z.B. bei der Motorola 68881/2 Architektur. Nicht ohne Grund hat AMD eine "flache" FPU-Architektur in den K8 einbringen wollen, welche dann nur durch SSE2 "ersetzt" wurde...

[Haarmann]

mrdigital und Muh-sagt-die-Kuh

Wenn ich mal 8kb, also 8096 Bytes L1 D-Cache des P4 nehme. Wie kann ich dem Cache sagen, dass ich das erste Byte will? Hat ein Cache überhaupt ein erstes Byte? Ist er nicht doch ein dummer Puffer, den ich nicht direkt von 0-8095 adressieren kann?

[StefanV]

Ich behaupte mal an dieser Stelle, daß der P4 mit den L1 Caches des P6 deutlich schneller wäre, bei gleichem Takt, als er jetzt ist.

So 10-30% sollten durchaus drin sein, vermute ich.

[Muh-sagt-die-Kuh]

mrdigital und Muh-sagt-die-Kuh

Wenn ich mal 8kb, also 8096 Bytes L1 D-Cache des P4 nehme. Wie kann ich dem Cache sagen, dass ich das erste Byte will? Hat ein Cache überhaupt ein erstes Byte? Ist er nicht doch ein dummer Puffer, den ich nicht direkt von 0-8095 adressieren kann?Keiner hat hier von direkter Adressierbarkeit geredet...

Ein Puffer funktioniert im allgemeinen nach dem FIFO Prinzip und dient nur zur kurzzeitigen Speicherung von Daten aus einem Datenstrom. Daten fliessen in den Puffer und verlassen ihn nach recht kurzer Zeit wieder, die Daten werden nur durchgereicht, ein semantischer Zugriff findet auf sie nicht statt. Das alles trifft z.B. auf die Sense-Amps eines DRAMs oder den Receive-Buffer einer LAN-Karte zu.

Ein Cache dagegen speichert Daten aus einem Datenfeld, auf die Daten wird semantisch zugegriffen und die Speicherung erfolgt nicht nur kurzzeitig.....all dies trifft auf Sense-Amps nicht zu, auf den L1-D Cache des P4 aber zu 100%....

[Muh-sagt-die-Kuh]

Ich behaupte mal an dieser Stelle, daß der P4 mit den L1 Caches des P6 deutlich schneller wäre, bei gleichem Takt, als er jetzt ist.

So 10-30% sollten durchaus drin sein, vermute ich.Auf was basiert diese Vermutung?

[BlackBirdSR]

Ich behaupte mal an dieser Stelle, daß der P4 mit den L1 Caches des P6 deutlich schneller wäre, bei gleichem Takt, als er jetzt ist.

So 10-30% sollten durchaus drin sein, vermute ich.

Das ist reinste Spekulation, der ich sogar widersprechen möchte.
Keiner von uns hat die Simulationsergebnisse die Intel ausgeführt hat. Also kann auch kaum jemand sagen wie das am Ende ausgesehen hätte.

[StefanV]

Naja, die Frage ist doch weniger, ob größere L1 (WB) Caches was bringen sondern wieviel gegenüber dem 8/16k L1 WT+ Trace Cache...

[Haarmann]

Muh-sagt-die-Kuh

Aber von Adressierbarkeit. Die Caches sind ja SW-Transparent -> er ist gar nicht adressierbar für die SW. Und daher sage ich, dass ein Cache nicht adressierbar ist für die CPU.

Puffer für alle Arten von Netzwerken sind wohl oft adressierbar. Wär sonst nicht grad einfach z.B. nen Switch zu bauen oder nen Router... alleine schon Mehrfach-Bridges brauchen "adressierbare" Puffer.

DRAMs hatten zumindest früher die Fähigkeit 4 Rows offen zu haben und nicht eine. Man musste dann nur selektieren und nicht neu "laden", was minimal schneller war. Trotzdem würd ich ned als Cache bezeichnen. Auch das alte EDRAM mit integriertem SRAM war nur ein Lesepuffer. Cache nannte mans ehrlicherweise nicht.

Für mich ists dann ein Cache, wenn man auch drauf schreiben kann. Wenn der Datenfluss also umkehrbar ist.

BlackBirdSR

Würdest Du das "ausrollen" von Schleifen als sinnvoll sehen oder ists nicht vielmehr ein Murks/Krücke, weil die heutigen CPUs damit (Schleifen) langsamer sind als mit der ausgerollten Variante?
Da bliebe doch auch die Frage der Compiler nicht unangetastet. Ich finde Schleifen wesentlich sinnvoller als ausgerollter Code. Und eigentlich sollte es auch schneller sein... Wieso dem Heute nimmer ist, darfst Dir mal überlegen.

[Muh-sagt-die-Kuh]

Naja, die Frage ist doch weniger, ob größere L1 (WB) Caches was bringen sondern wieviel gegenüber dem 8/16k L1 WT+ Trace Cache...Die Latenz eines Cache spielt eine nicht zu unterschätzende Rolle...und die betrachtest du in keinster Weise.

[Muh-sagt-die-Kuh]

Muh-sagt-die-Kuh
Puffer für alle Arten von Netzwerken sind wohl oft adressierbar. Wär sonst nicht grad einfach z.B. nen Switch zu bauen oder nen Router... alleine schon Mehrfach-Bridges brauchen "adressierbare" Puffer.Ein Switch oder ein Router haben eine eigene CPU mit eigenem Speicher....das ist nicht das, was ich mit einem Receive-Buffer meine.Für mich ists dann ein Cache, wenn man auch drauf schreiben kann. Wenn der Datenfluss also umkehrbar ist.Wieso willst du dann den L1-D Cache des P4 als Puffer bezeichnen?BlackBirdSR

Würdest Du das "ausrollen" von Schleifen als sinnvoll sehen oder ists nicht vielmehr ein Murks/Krücke, weil die heutigen CPUs damit (Schleifen) langsamer sind als mit der ausgerollten Variante?
Da bliebe doch auch die Frage der Compiler nicht unangetastet. Ich finde Schleifen wesentlich sinnvoller als ausgerollter Code. Und eigentlich sollte es auch schneller sein... Wieso dem Heute nimmer ist, darfst Dir mal überlegen.Was hat das mit dem zu tun, was BlackBird geschrieben hat?

[StefanV]

die Latenz spielt schon eine Rolle, nur wenn ich mehr Daten im L2 oder im RAM lassen muss, schauts wieder anders aus...

[Muh-sagt-die-Kuh]

die Latenz spielt schon eine Rolle, nur wenn ich mehr Daten im L2 oder im RAM lassen muss, schauts wieder anders aus...Auch wenn man bei jedem Zugriff 50% länger warten muss?

[Haarmann]

Muh-sagt-die-Kuh

Switches sind nicht ideal als Exempel bei Ethernet. Bei ATM wärs was anderes.
Eine Mehrfachbridge sprich ein Router mit verschiedenen Interfacetypen wird Dir schnell zeigen, wieso das eben dann sinnvoll wird. Du kannst nicht alle Daten an einen Core weitergeben...

Seit wann kann der D-Cache des P4 von der CPU her beschrieben werden? Ist das ein neues undokumentiertes Feature?

Intel liefert nicht nur die CPU, sondern auch den passenden Compiler plus Richtlinien. Ohne optimierten Code schleicht der P4 nur so durch die Gegend. Schon aufgefallen, dass die AMDs und der P3/PM etwa in den gleichen Benches versagen/gewinnen? Warum ist wohl ein P4 mit SDRAM so ne Schnecke und bei nem K7 oder nem P3 funktionierte das noch gut?
Seine Lange Pipeline hat eben auch seine Vorteile, aber die kann er ohne passenden Speicher nicht ausspielen.

[Muh-sagt-die-Kuh]

Muh-sagt-die-Kuh

Seit wann kann der D-Cache des P4 von der CPU her beschrieben werden? Ist das ein neues undokumentiertes Feature?Woher hast du denn diesen Mist? "Write-Through" bedeutet nicht, dass in den L1 nicht geschrieben wird.Intel liefert nicht nur die CPU, sondern auch den passenden Compiler plus Richtlinien. Ohne optimierten Code schleicht der P4 nur so durch die Gegend. Schon aufgefallen, dass die AMDs und der P3/PM etwa in den gleichen Benches versagen/gewinnen?Warum ist wohl ein P4 mit SDRAM so ne Schnecke und bei nem K7 oder nem P3 funktionierte das noch gut?
Seine Lange Pipeline hat eben auch seine Vorteile, aber die kann er ohne passenden Speicher nicht ausspielen.Und was soll mir das sagen? Das hat immer noch nichts mit dem zu tun, was BlackBird schrieb.

[Haarmann]

Muh-sagt-die-Kuh

Man schreibt nicht in den L1, sondern in den L1 und in den L2... Du kannst nicht in den L1 schreiben. Nur in L1 und L2. Ev hätte ichs sauberer ausformulieren müssen, dass klar war, was ich meinte. Wie das dann wieder technisch gelöst wird, ist ein noch anderer Hut. Viele Wege führen da zu Ziel.

Dann erklär mal Du, was Blackbird für Dich schrieb ich glaube nämlich wir lesen dessen Sätze so unterschiedlich, dass dabei nix rauskommen kann, solange wir das so machen. Für mich schrieb er, dass es Spekulation ist von den "nomalen" Caches der 4 genannten CPUs auf ne allgemeine Mehrleistung zu Schliessen.

Nachtrag
Damits verständlicher sein sollt. Der L1 wird als WT definiert und nicht Buffered WT. Da besteht ein Riesenunterschied dazwischen.

[Muh-sagt-die-Kuh]

Muh-sagt-die-Kuh

Man schreibt nicht in den L1, sondern in den L1 und in den L2... Du kannst nicht in den L1 schreiben. Nur in L1 und L2. Ev hätte ichs sauberer ausformulieren müssen, dass klar war, was ich meinte. Wie das dann wieder technisch gelöst wird, ist ein noch anderer Hut. Viele Wege führen da zu Ziel.Was ist das denn bitte für eine Logik? Weil man in L1 und L2 schreibt kann man nicht in den L1 schreiben? Wenn du versuchst, etwas "sauberer auszuformulieren" wird es meist nur noch konfuser.....

Der P4 schreibt in den L1, da gibt es nichts zu diskutieren.Dann erklär mal Du, was Blackbird für Dich schrieb ich glaube nämlich wir lesen dessen Sätze so unterschiedlich, dass dabei nix rauskommen kann, solange wir das so machen. Für mich schrieb er, dass es Spekulation ist von den "nomalen" Caches der 4 genannten CPUs auf ne allgemeine Mehrleistung zu Schliessen.BlackBird redet von Simulationsergebnissen.....sprich man simuliert das Verhalten von mehreren Cache-Typen bei unterschiedlichen Zugriffsmustern. Es geht auch nicht um 4 CPU Typen sondern um Paynes Vermutung, dass ein P4 mit einem P3 L1 schneller wäre. Darauf bist du in keinster Weise eingegangen.Nachtrag
Damits verständlicher sein sollt. Der L1 wird als WT definiert und nicht Buffered WT. Da besteht ein Riesenunterschied dazwischen.Verständlicher wird dadurch nichts.....ich sehe da nämlich absolut keinen "Riesenunterschied".

[BlackBirdSR]

Muh-sagt-die-Kuh


Dann erklär mal Du, was Blackbird für Dich schrieb ich glaube nämlich wir lesen dessen Sätze so unterschiedlich, dass dabei nix rauskommen kann, solange wir das so machen. Für mich schrieb er, dass es Spekulation ist von den "nomalen" Caches der 4 genannten CPUs auf ne allgemeine Mehrleistung zu Schliessen.

Nachtrag
Damits verständlicher sein sollt. Der L1 wird als WT definiert und nicht Buffered WT. Da besteht ein Riesenunterschied dazwischen.
Ich denke msdk hat schon verstanden, was ich meinte.
Man kann nicht aussagen, welche Leistung ein P4 mit traditionellen Caches erreicht hätte.
Nichtmal beim Prescott kann man aussagen, wieviel der verdoppelte L1 Cache nun bringt. Schließlich sind die Latenzen um 100% gestiegen.

Es ist viel zu komplex, und am Ende bleibt uns nur der Fall, in dem nur eine einzige Variable geändert wird, und somit ein direkter Vergleich möglich ist.
Das geht eben hier nicht. Ohne die Simulationsergebnisse, würde ich nichtmal versuchen eine Performanceschätzung abzugeben.

@Nachtrag:
Ich glaube du meinst "Write Back" mit buffered Write Through, oder?

[Bokill]

Zitat von Stefan Payne
Ich behaupte mal an dieser Stelle, daß der P4 mit den L1 Caches des P6 deutlich schneller wäre, bei gleichem Takt, als er jetzt ist.

So 10-30% sollten durchaus drin sein, vermute ich.

Da neige ich eher zu BlackBirdSR. Der Trace Cache für Instruktionen ist ja rattenschnell geblieben. Der Vorteil vom Trace Cache ist ja, dass die µOps (oder wie die sich immer nennen) schon im RISC-ähnlichen Format vorliegen, (etct.).. Der Decoder muss da nicht mehr ran.

Der Nachteil, dass da wiederum der Code wesentlich mehr Platz wegnimmt, wird durch ein an sich sehr schnelles I/O-Interface kompensiert. Nur wehen denn, wenn doch mal die Pipeline leerkäuft und dann auf den Speicher zugegriffen werden muss.

Man könnte sogar sagen [Spekulation], dass ohne Trace-Cache der Pentium4 10-30% langsamer sein könnte. Der Trace-Cache kann ja deswegen (vorcodierte wiederverwendete Codesequenzen) eine "stockende" Pipeline (bubbles) teilweise verdecken.

MFG Bokill

[Haarmann]

Muh-sagt-die-Kuh

Beim WT kannst den L1 nicht ansprechen, wo der Buffered WT ansprechbar bleibt im gleichen Fall - ich finde das ist ein riesiger Unterschied. Aber da kann man geteilter Meinung sein.

Wie gesagt - diese "Vermutung" gründet sich auf mehrere verschiedene CPUs. Ganz unbegründet ists daher nicht. Weil nur wegen der Pipelinelänge kanns nicht sein, sonst müsste der PPro die gleichen Probleme unter 32Bit gehabt haben... hat er nur nicht.

BlackBirdSR

Nein, ein Buffered WT locked den Cache nicht, während er durchschreibt. Bei WB wird gar nicht durchgeschrieben, bis die Line rausfliegt und auch dann nur, wenn sie geändert wurd, aber das ist in dem Fall ja klar der Fall.
Ich schliesse es natürlich nicht aus, dass der P4 das so tut (B-WT), aber ich habs bisher nie so gelesen. Da der Latenzunterschied zwischen L1 und L2 auch nicht riesig ist, ist der Verlust klein, aber vorhanden.

[mrdigital]

Haarmann, man kann nie den Cache direkt ansprechen, ein Cache ist immer transparent. Die Cachestrategie wird vom Cachecontroller und nicht dem CPU Kern gesteuert. Dabei spielt es dann keine Rolle, ob es WT oder WB oder was auch immer ist.

[Muh-sagt-die-Kuh]

Muh-sagt-die-Kuh

Beim WT kannst den L1 nicht ansprechen, wo der Buffered WT ansprechbar bleibt im gleichen Fall - ich finde das ist ein riesiger Unterschied. Aber da kann man geteilter Meinung sein.Wo ist da ein "riesiger Unterschied" im Kontext von Schreibzugriff auf L1 oder kein Schreibzugriff auf L1?Wie gesagt - diese "Vermutung" gründet sich auf mehrere verschiedene CPUs. Ganz unbegründet ists daher nicht. Weil nur wegen der Pipelinelänge kanns nicht sein, sonst müsste der PPro die gleichen Probleme unter 32Bit gehabt haben... hat er nur nicht.Du springst absolut zusammenhangslos zwischen Themen hin und her....von was redest du gerade?

[Haarmann]

mrdigital

Ich nannts SW transparent, weil man sich trefflich streiten könnte, ob nun der Cachecontroller zur CPU gehört bei nem P4 oder nicht. Da ich diese Debatte gleich erwürgen wollt hab ichs SW transparent genannt.

Muh-sagt-die-Kuh

Bei WT ists nicht zwingend nötig nen Pfad von der CPU zum L1 zu unterhalten.
Wieviele Cachecontroller haben K7/K8, P3 Cumine, P-M und ein P4? Ich fand da keine exakten Angaben dazu.

Ich erspar nur die Zitate, wenn ich sie nicht für zwingend nötig erachte. Von daher kanns springend wirken - sorry, wenns nicht klar ist.

[Muh-sagt-die-Kuh]

Muh-sagt-die-Kuh

Bei WT ists nicht zwingend nötig nen Pfad von der CPU zum L1 zu unterhalten.Und was macht der L1 ohne Verbindung zum Kern so? ;)Wieviele Cachecontroller haben K7/K8, P3 Cumine, P-M und ein P4? Ich fand da keine exakten Angaben dazu.Einen.Ich erspar nur die Zitate, wenn ich sie nicht für zwingend nötig erachte. Von daher kanns springend wirken - sorry, wenns nicht klar ist.Zitate sind ein sinnvolles Strukturierungswerkzeug, das man nutzen sollte.

[Haarmann]

Muh-sagt-die-Kuh

Ich sagte nicht, dass es keine Verbindung L1->CPU gibt... Nur weil ich sagte, dass es nicht zwingend ist von CPU->L1 einen zu haben.
Mit einem CC von L1 und L2 zu sprechen fänd ich aber seltsamst, aber das ist dann Nebensache. Die P2 hatten ja bekanntlich noch 2 CC (Intern und Extern), die ersten P3 wohl also auch noch.

Zitate können aber auch den Lesefluss behindern :). Bei Heise sind deswegen solche Zitatposts nicht so gerne gesehen.

[Muh-sagt-die-Kuh]

Muh-sagt-die-Kuh

Ich sagte nicht, dass es keine Verbindung L1->CPU gibt... Nur weil ich sagte, dass es nicht zwingend ist von CPU->L1 einen zu haben.Eine solche Verbindung ist normalerweise ein Bus, den in beide Richtungen arbeitet ;)Mit einem CC von L1 und L2 zu sprechen fänd ich aber seltsamst, aber das ist dann Nebensache. Die P2 hatten ja bekanntlich noch 2 CC (Intern und Extern), die ersten P3 wohl also auch noch.Ähm, was rede ich auch...ich meine einen pro Cachelevel.Zitate können aber auch den Lesefluss behindern :). Bei Heise sind deswegen solche Zitatposts nicht so gerne gesehen.Heise würde ich nicht unbedingt als Maßstab nehmen, in dem Forum tummeln sich mehr Trolle als in allen Fantasiereichen zusammen ;)

Dazu kommt noch, dass das Ding layout- und bedienungstechnisch einfach nur mies ist...

[Haarmann]

Muh-sagt-die-Kuh

Ich hab ehrlicherweise nicht gefunden, wie das gelöst ist bei nem P4. Ich weiss nur, dass es nicht zwingend Bidirektional sein muss und man sich vieles sparen kann, wenn mans nicht bidirektional macht. Würde ich das konzipiert haben mit WT und ned B-WT, dann hätte ich schlicht eine Hinleitung gemacht von L1->CPU und eine Rückleitung von CPU->L2 und ne Sperrleitung von CPU->L1. Die CPU kann ja von L2 eh nicht direkt lesen, also ist dort auch nur ein "halber" Bus in der Richtung. Dann wärs doch nur logisch, wenn in die andere Richtung auch ein "halber" Bus wäre. Das ist natürlich Spekulation, wie ich Oben schon andeuten wollt, aber so erscheint es mir logisch.

Da bin ich ja richtig froh, weil ich sonst allen CPUs keine L2 Caches attestiert hätte. Ohne CC kein Level imho. Du hast mich jedenfalls verwirrt mit dieser Aussage.

Ich wollte nur erwähnen, dass man es auch Anders sehen kann. Ich lese bei Heise selten mehr denn die CT auf Papier und den Ticker.

[BlackBirdSR]

Muh-sagt-die-Kuh

Die CPU kann ja von L2 eh nicht direkt lesen, also ist dort auch nur ein "halber" Bus in der Richtung. .

Der P4 liest zumindest Befehle nur aus dem L2 Cache.
Wars bei FPU Daten nicht auch so? Oder verwechsel ich das mit dem IA64?

[Aqualon]

Der P4 liest zumindest Befehle nur aus dem L2 Cache.
Wars bei FPU Daten nicht auch so? Oder verwechsel ich das mit dem IA64?
Ist bei beiden so. Ich verweise einfach mal schamlos auf folgendes Posting:

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2224531&postcount=14

Aqua

[Haarmann]

BlackBirdSR

Tschuldigung für meine Unpräziesheit, aber mangels L1 I-Cache ist das imho imminent...
Das mit der FPU ist imho auch klar... Kompatibilität sag ich nur.

Nachtrag
Macht sogar Sinn, dann den L2 Cache aus I Sicht als L1 zu bezeichnen ;).

[BlackBirdSR]

BlackBirdSR

Tschuldigung für meine Unpräziesheit, aber mangels L1 I-Cache ist das imho imminent...
Das mit der FPU ist imho auch klar... Kompatibilität sag ich nur.

Nachtrag
Macht sogar Sinn, dann den L2 Cache aus I Sicht als L1 zu bezeichnen ;).

Gut, dann denke ich haben wir das Unterthema geklärt.
Ich denke nämlich nicht, dass hier sehr viele User noch durchblicken. Hier wurde ganz wirr geschrieben und von einem Punkt zum Anderen gesprungen.
Wenn ich nur anfange, das oberflächlich zu lesen, bleibt absolut Null hängen. Ein schlechtes Zeichen.

Lasst uns wieder aufs Thema zurückkommen.. oder so.

[iam.cool]

Wie wäre es mit: "Mehr Cache"?

Bisher hat das bei vielen Prozessoren zu einer ordentlichen Leistungssteigerung geführt...

Ist wahrscheinlich nicht die effektivste Variante, aber ein Weg von vielen...


Mehr Cache vervielfacht aber auch die Produktionskosten, der P4 EE ist nicht aus spas so teuer sondern weil das mehr an Cache die Kosten in die höhe treibt.

[CrazyIvan]

Gut, dann denke ich haben wir das Unterthema geklärt.
Ich denke nämlich nicht, dass hier sehr viele User noch durchblicken. Hier wurde ganz wirr geschrieben und von einem Punkt zum Anderen gesprungen.
Wenn ich nur anfange, das oberflächlich zu lesen, bleibt absolut Null hängen. Ein schlechtes Zeichen.

Lasst uns wieder aufs Thema zurückkommen.. oder so.

Schade eigentlich. Ich fand das Thema so vom reinen Mitlesen her sehr interessant. Auch muss die geringe Beteiligung kein Indiz für Desinteresse oder mangelnden Sachverstand der Leserschaft sein. Alle involvierten Poster waren einfach nur kompetent genug, Einwände und Anmerkungen größtenteils überflüssig zu machen. Wer will schon alle drei Posts ein "Das sehe ich genau so" lesen ;)

Ich möchte nur noch anmerken, dass die Cachestruktur des P4 ihm in meinen Augen eine weit geringere Missprediction Penalty einbringt, als dies mit einer herkömmlichen Struktur der Fall wäre. Insofern sehe ich in der derzeitigen Implementation durchaus mehr Vor- als Nachteile.

[GloomY]

Haarmann,

könntest du dich in Zukunft bitte bemühen, dich klar und eindeutig auszudrücken? Das rumge-eiere um den heissen Brei ist ja fürchterlich. Vielleicht gibt's deswegen auch so wenig Feedback von anderen Lesern...

Zum Thema L1 Cache beim P4: Hat sich jemand mal angeschaut, wie klein der L1-D beim P4 Northwood ist? Ich habe das Die-Foto von Hans-de-Vries als Din A1 Plakat in meinem Zimmer hängen und ich kann Euch sagen, dass dieser verdammt klein ist. Das ist imho auch der Grund warum bei diesem wahnsinnig hohen Takt des P4s trotzdem eine so geringe Load-to-Use Latency von nur zwei Takten möglich ist. Kaum ist der Cache beim Presscot doppelt so groß (und doppelt so hohe Assotiativität), klettert die Latenz schon mal eben um 100%. :|

btw: Der Itanium2 profitiert von seiner 1 Takt Latenz des L1-D laut einigen Simulations-Messungen um immerhin 6% mehr (Gesamt-)Performance gegenüber einem Cache mit 2 Takten Latenz. Da wird klar, dass Latency bei Caches besonderns bei den "kleinen" Leveln durchaus der Bringer sein kann - vorrausgesetzt man kann die niedrige Hit-Rate durch höhergelegene Cache-Level wieder abfangen :)

Die getätigte Vermutung, dass der P6 Ansatz beim L1 mehr Performance brächte, würde ich somit eher zurückweisen.

Der L1-D beim P4 ist WT, und das ist imho auch eher sinnvoll. Ein kleiner Cache hat prinzipiell eher eine hohe Miss-Rate, muss also öfters mal Sachen aus dem Cache rauswerfen, um Platz für neue Lines zu schaffen. Wenn bereits alle Änderungen in der nächst höher gelegenen Speicherhierarchie vorhanden sind, kann man die rauszuwerfenden Lines einfach verwerfen, ohne diese im höhergelegenen Level(s) updaten zu müssen. Dieses Updaten kostet bei 64 Byte/Cacheline und 128 Bit Anbindung im schlimmsten Fall immerhin 4 Takte. Die (relativ) niedrige L2 Latency beim P4 ist imho nur dadurch möglich, dass der L1 WT ist und somit einfach nur bei einem L1 Miss und L2 Hit die Daten im L1 verworfen werden müssen und die neuen Daten aus dem L2 transferiert werden müssen. Ohne WT würde das deutlich länger dauern.
Und wie wir bereits oben gesehen haben, gilt bei niedrigen Cache Leveln oftmals: Latency wins! ;)

[Haarmann]

GloomY

Ich dachte ich schreibe Deutsch. Ev müssten paar Leute sich mal überlegen, ob sie nicht einfach mal aufhöhren sollten Sachen hineinzuinterpretieren, die nirgens stehen. Wenn ich sage es ist nicht zwingend, dass etwas vorhanden ist, so deute ich damit nur an, dass mans auch ohne lösen kann. Wies gelöst wurde kann man aber eh wohl nicht nachlesen. Nur ists wahrscheinlich, dass man nicht notwendige Dinger wohl einfach weglässt.

Wenn ich von nem Switch spreche und die Leute draus nen 10/100 FastEthernet Switch machen im Kopf, dann kann ich da nichts dafür...

Ich weiss nicht, wann man den P4E mit diesem Cache versehen hat, aber ich kann mir gut vorstellen, dass man dabei an mehr den 3 GHz Takt gedacht hat und die absolute Latenz ähnlich geblieben wär. Das dem nun ja so nicht ist, das ist klar, aber hier ist Ursache/Wirkung uU anders zu sehen. Bei 6 GHz, wie mal angepeilt waren, würde es wirklich ungefähr ja aufgehen.
Im Prinzip müsste sonst ein 1.6er NW ja auch mit einem Takt Latenz auskommen und ein 3.2er mit 2 Takten, wenn man das so einfach "umschalten" könnt. Ich tippe mal drauf, dass dies nicht so einfachst geht.

Itaniums eigenen sich nicht gut für einen Vergleich imho. Die Architektur ist nicht vergleichbar mit einer x86. Da macht ja der Compiler, die Arbeit der x86 CPU.

Ich habs bei SP so verstanden, dass er den Tracecache drin lässt. Ich borge mir schnell die Pentium-M Zahlen von dort ( http://www.tecchannel.de/hardware/1381/6.html ) und hoffe, sie stimmen. So viel schlechter stehen die ja auch nicht da... So viel langsamer wurde ja der P4E vs P4C auch nicht durch die 4 vs 2 Takte. Mit dem Cache müsste ich dann wohl gar auf 4 aufstocken wie der P4E, aber die Trefferquote steigt wohl auch um Einiges, aber das ist bekanntlich auch ne Frage der Anwendung.

Ich sagte nicht, dass es beim P4 nicht sinnvoll ist, ich sagte nur, dass man den D-L1 auch als "dummen" Puffer, der dafür sehr schnell ist, sehen kann und somit die Levels sich um eines reduzieren, denn der TC hat kein Level.
Wie komme ich nun auf diese Idee? Schlicht, weil er kein Buffered-WT ist. Bei Buffered WT müsste das Signal zwingend CPU->L1->L2 laufen. Bei WT gibts ne andere Option - CPU->L2->L1.

[Muh-sagt-die-Kuh]

GloomY

Ich dachte ich schreibe Deutsch. Ev müssten paar Leute sich mal überlegen, ob sie nicht einfach mal aufhöhren sollten Sachen hineinzuinterpretieren, die nirgens stehen. Wenn ich sage es ist nicht zwingend, dass etwas vorhanden ist, so deute ich damit nur an, dass mans auch ohne lösen kann. Wies gelöst wurde kann man aber eh wohl nicht nachlesen. Nur ists wahrscheinlich, dass man nicht notwendige Dinger wohl einfach weglässt.Es gibt so viele Dinge, die nicht zwingend nötig sind......wenn man sie aber weglässt kommt eine Krüppellösung ohne Ende raus. Eine CPU kann man auch mit nur einem Register bauen, ist das nun sinnvoll?Wenn ich von nem Switch spreche und die Leute draus nen 10/100 FastEthernet Switch machen im Kopf, dann kann ich da nichts dafür...Das hat hier keiner gemacht, mal abgesehen davon würde das, konzeptionell gesehen, sowieso keinen Unterschied machen.Itaniums eigenen sich nicht gut für einen Vergleich imho. Die Architektur ist nicht vergleichbar mit einer x86. Da macht ja der Compiler, die Arbeit der x86 CPU.Was hat die technische Realisierung eines Caches mit dem CPU Befehlssatz zu tun?Ich habs bei SP so verstanden, dass er den Tracecache drin lässt. Ich borge mir schnell die Pentium-M Zahlen von dort ( http://www.tecchannel.de/hardware/1381/6.html ) und hoffe, sie stimmen. So viel schlechter stehen die ja auch nicht da... So viel langsamer wurde ja der P4E vs P4C auch nicht durch die 4 vs 2 Takte. Mit dem Cache müsste ich dann wohl gar auf 4 aufstocken wie der P4E, aber die Trefferquote steigt wohl auch um Einiges, aber das ist bekanntlich auch ne Frage der Anwendung.Eher eine Frage der Kapazität....die beim Prescott doppelt so hoch ist.Ich sagte nicht, dass es beim P4 nicht sinnvoll ist, ich sagte nur, dass man den D-L1 auch als "dummen" Puffer, der dafür sehr schnell ist, sehen kann und somit die Levels sich um eines reduzieren, denn der TC hat kein Level.Der L1-D ist und bleibt ein Cache, daran gibt es nichts zu diskutieren.Wie komme ich nun auf diese Idee? Schlicht, weil er kein Buffered-WT ist. Bei Buffered WT müsste das Signal zwingend CPU->L1->L2 laufen. Bei WT gibts ne andere Option - CPU->L2->L1.Diese Argumentation ist einfach nur haarsträubend....Option Nr. 2 ist wieder eine der oben angesprochenen Krüppellösungen. Bei solch einem performancekritischen Bauteil würde niemand mit nur etwas Verstand überhaupt an sowas denken....

[Haarmann]

Muh-sagt-die-Kuh

Ein Switch oder ein Router haben eine eigene CPU mit eigenem Speicher....das ist nicht das, was ich mit einem Receive-Buffer meine.

Ausser nem 0815 Ethernet Switch fällt mir echt kein Teil ein, das so trivial aufgebaut ist. Kann sein, dass Dir was Anderes vorschwebte, aber die Aussage klingt für mich nicht nach mehr. Ich geb aber zu, dass ich mich hier irren könnt.

Ich finde eine CPU ohne sichtbare "Register" sogar sehr sinnvoll, dann brauchst auch kein HT mehr ;). Soweit ich mich gerade entsinne, haben diese alten Cray Vektorrechner doch keine SW Register und doch würde ich sie nicht grad als Krüppel bezeichnen... Ich hörte im Gegenteil die Dinger immer gelobt.

Ich sagte nur, dass man vom Itanium nicht auf nen x86 schliessen sollte in Bezug auf Cacheverhalten, denn durch die Compilerarbeit und die Architektur sollen ja bestimmte "Fehler" des x86 ausgebüglet worden sein. Da diese dann wohl auch kaum auftreten werden, weil nicht vorhanden, kann mans somit schwer vergleichen.

Eher eine Frage der Kapazität....die beim Prescott doppelt so hoch ist.

Warum hat denn der 1.6er NW nicht ne 1er Latenz? Wenns bis 3.8 GHz mit LuKü mit ner 2er geht, dann müsst es bei 1.6 doch mit ner einer gehen. Da führt kein Weg dran vorbei. Diese Logik mag dumm sein, aber entspricht schlicht den Tatsachen.

Der L1-D ist und bleibt ein Cache, daran gibt es nichts zu diskutieren.

Das ist Deine Meinung. Argumente hast aber nicht ein Einziges da zu liefern. Ich nenns nen strohdummen Puffer.

Diese Argumentation ist einfach nur haarsträubend....Option Nr. 2 ist wieder eine der oben angesprochenen Krüppellösungen. Bei solch einem performancekritischen Bauteil würde niemand mit nur etwas Verstand überhaupt an sowas denken....

Nein, das ist die Lösung, die bei WT sogar am Schnellsten und am Kleinsten ist. Aber zudem ist sie auch noch einfacher. Würde ich das Signal von CPU->L1->L2 schicken, dann verliere ich Zeit im L1 CC - das ist schlicht ein Fakt. Das könnt ich nur verhindern, wenn ich gleichzeitig ne Leitung zu L1 und L2 hätte. Das ist aber ein grosser Mehraufwand und vor allem wärs dann kein WT mehr, sondern würde glatt wie ein Buffered WT funktionieren und ihn somit darstellen. Schicke ichs aber direkt an den L2 CC. dann kann dieser einfach so tun, als würde er den L1 "laden" und den gleichen Pfad nutzen, den er immer nutzt für dies. Da der L1 eh schneller reagiert, denn der L2, tut dieser Umweg auch Niemandem weh. Bis nämlich der L2 fertig ist, wirds der L1 auch sein. Tiefe Latenz kann man auch so ausnutzen.
Dass der L1 auch in Teilbereichen und nicht nur in Linien beschrieben werden kann ist ebefalls bei beiden Lösungen nötig. Von daher entsteht kein zusätzlicher Aufwand.

[Muh-sagt-die-Kuh]

Muh-sagt-die-Kuh

Ich sagte nur, dass man vom Itanium nicht auf nen x86 schliessen sollte in Bezug auf Cacheverhalten, denn durch die Compilerarbeit und die Architektur sollen ja bestimmte "Fehler" des x86 ausgebüglet worden sein. Da diese dann wohl auch kaum auftreten werden, weil nicht vorhanden, kann mans somit schwer vergleichen.Für einen D-Cache ist das irrelevant.Das ist Deine Meinung. Argumente hast aber nicht ein Einziges da zu liefern. Ich nenns nen strohdummen Puffer.Deine Erinnerung ist offenbar nicht mehr die beste....
Ein Puffer funktioniert im allgemeinen nach dem FIFO Prinzip und dient nur zur kurzzeitigen Speicherung von Daten aus einem Datenstrom. Daten fliessen in den Puffer und verlassen ihn nach recht kurzer Zeit wieder, die Daten werden nur durchgereicht, ein semantischer Zugriff findet auf sie nicht statt. Das alles trifft z.B. auf die Sense-Amps eines DRAMs oder den Receive-Buffer einer LAN-Karte zu.

Ein Cache dagegen speichert Daten aus einem Datenfeld, auf die Daten wird semantisch zugegriffen und die Speicherung erfolgt nicht nur kurzzeitig.....all dies trifft auf Sense-Amps nicht zu, auf den L1-D Cache des P4 aber zu 100%....Nein, das ist die Lösung, die bei WT sogar am Schnellsten und am Kleinsten ist. Aber zudem ist sie auch noch einfacher. Würde ich das Signal von CPU->L1->L2 schicken, dann verliere ich Zeit im L1 CC - das ist schlicht ein Fakt. Das könnt ich nur verhindern, wenn ich gleichzeitig ne Leitung zu L1 und L2 hätte.Das ist aber ein grosser Mehraufwand und vor allem wärs dann kein WT mehr, sondern würde glatt wie ein Buffered WT funktionieren und ihn somit darstellen. Schicke ichs aber direkt an den L2 CC. dann kann dieser einfach so tun, als würde er den L1 "laden" und den gleichen Pfad nutzen, den er immer nutzt für dies. Da der L1 eh schneller reagiert, denn der L2, tut dieser Umweg auch Niemandem weh. Bis nämlich der L2 fertig ist, wirds der L1 auch sein. Tiefe Latenz kann man auch so ausnutzen.
Dass der L1 auch in Teilbereichen und nicht nur in Linien beschrieben werden kann ist ebefalls bei beiden Lösungen nötig. Von daher entsteht kein zusätzlicher Aufwand.Bei deiner Lösung wäre es auch ein Fakt, dass man im L2 CC "Zeit verliert" und somit den weitaus wichtigeren L1 Schreibzugriff aufhält. CPUs fragen immer zuerst den L1 und dann den L2 ab....oder was denkst du, warum die gesamte Latenz bei einem L2 Hit immer gleich der L1 Latenz plus der L2 Latenz ist? ;)

[Haarmann]

Muh-sagt-die-Kuh

Wenn ich kein kompliziertes Befehlsumsortieren hab, weil mir diese Arbeit der Compiler abgenommen hat, dann sortiert man sie auch nimmer so gut... Da wirkt sich diese Latenz ganz anders aus, weil die CPU etwas nicht hat, was die Andere hat.

Das ist Deine Ansicht, dass es nur solche Puffer gibt. Ich sah schon andere...
Es ist hier auch nur ne Definitionsfrage imho.

Bei WT wird der L1 gelockt, solange L2 schreibt. Bei nicht gelocktem L1 spricht man von Buffered WT... Schaus mal von der Seite an. Ev wird Dir dann klar, wieso ich zuerst in den lahmeren L2 schreiben würd und nicht in den schnelleren L1... Ich las bisher nicht von nem Buffered WT Verhalten beim P4 - ich schliesse das zwar nicht aus, aber ich las es nie.

[GloomY]

Haarmann,

was meinst du mit "locken" bzw. "gelockt"? Dass der L1 solange blockiert ist, wie der L2 braucht, um die Daten zu schreiben? Imho ist das nicht der Fall. Der L1-D ist Dual-ported mit einem Load- und einem Store-Port. Es ergäbe keinen Sinn, wenn der Store-Port benutzt würde, dass dann der Load-Port blockiert wäre. Dann würde man nicht von zwei Ports sprechen.

Ansonsten ist der L1-D auch noch non-blocking mit bis zu vier ausstehenden Load Misses.

[Muh-sagt-die-Kuh]

Muh-sagt-die-Kuh

Wenn ich kein kompliziertes Befehlsumsortieren hab, weil mir diese Arbeit der Compiler abgenommen hat, dann sortiert man sie auch nimmer so gut... Da wirkt sich diese Latenz ganz anders aus, weil die CPU etwas nicht hat, was die Andere hat.Sinn gibt das, was du hier schreibst beim besten Willen nicht.Das ist Deine Ansicht, dass es nur solche Puffer gibt. Ich sah schon andere...
Es ist hier auch nur ne Definitionsfrage imho.Das hier auch nicht.Bei WT wird der L1 gelockt, solange L2 schreibt. Bei nicht gelocktem L1 spricht man von Buffered WT... Schaus mal von der Seite an. Ev wird Dir dann klar, wieso ich zuerst in den lahmeren L2 schreiben würd und nicht in den schnelleren L1... Ich las bisher nicht von nem Buffered WT Verhalten beim P4 - ich schliesse das zwar nicht aus, aber ich las es nie.Um den ganzen Prozess nochmal zu verdeutlichen:

Wie GloomY schon sagte, der L1 hat einen Load und einen Store Port und ist dazu noch non-blocking.

Write-Through tritt nur dann in Aktion, wenn ein L1 Hit beim Schreiben auftritt. Ist dieser Fall eingetreten so reicht der L1 Controller das Datum einfach an einen Store-Port des L2 weiter und bearbeitet den nächsten Store. Er blockiert definitiv nicht, bis der L2 mit dem Schreiben fertig ist, wieso auch?

[Haarmann]

GloomY

Dann wärs ein Buffered WT Cache, wenn er nicht locked würd. Da das bisher nirgens so zu lesen war, gehe ich schlicht davon aus, das er es nicht ist.

Ich finds übrigens schön, dass er einen Load und einen Store Port hat. Hätte er bei meinem Aufbau ja auch, aber er hätte 2 Store Ports (von der CPU her und vom L2 her), wenn er nach anderer Leute Idee hier aufgebaut wär. Und es ergibt durchaus Sinn nen Cache zu sperren, wenn man drauf schreibt. Könnte ja sein, dass man grad beschreibt, was man lesen will...

Muh-sagt-die-Kuh

Wenn man jeweils Äpfel und Birnen vergleicht, dann kommt immer Mist raus. Von nem Itanium auf nen x86 zu schliessen ist schlicht noch hirnrissiger, denn von nem P3 und seinem Cache auf nen P4... Aber das hälst ja Du selber für hirnrissig ;). P3 und P4 sind aber doch nur Granny-Smith und Gravensteiner...

Wie GloomY schon sagte, der L1 hat einen Load und einen Store Port und ist dazu noch non-blocking.

Hiesse das nicht, dass keine zusätzliche Latenz anfällt beim durchmarsch vom L2? Ich könnte schwören, dass Du das vor kurzer Zeit mal anders gesehen hast...

oder was denkst du, warum die gesamte Latenz bei einem L2 Hit immer gleich der L1 Latenz plus der L2 Latenz ist?

Beides kanns nicht sein - entscheide Dich mal.

Write-Through tritt nur dann in Aktion, wenn ein L1 Hit beim Schreiben auftritt. Ist dieser Fall eingetreten so reicht der L1 Controller das Datum einfach an einen Store-Port des L2 weiter und bearbeitet den nächsten Store. Er blockiert definitiv nicht, bis der L2 mit dem Schreiben fertig ist, wieso auch?

Weil das Nichtblockieren Buffered WT genannt würd etwa?
Ich bin absolut Deiner Meinung, wenn Buffered WT zutrifft, aber dann wärs doch angeschrieben!

[Muh-sagt-die-Kuh]

Muh-sagt-die-Kuh

Wenn man jeweils Äpfel und Birnen vergleicht, dann kommt immer Mist raus. Von nem Itanium auf nen x86 zu schliessen ist schlicht noch hirnrissiger, denn von nem P3 und seinem Cache auf nen P4... Aber das hälst ja Du selber für hirnrissig ;). P3 und P4 sind aber doch nur Granny-Smith und Gravensteiner...Ich frage dich nochmal: Was unterscheidet IA-64 von x86 bei den Daten?Hiesse das nicht, dass keine zusätzliche Latenz anfällt beim durchmarsch vom L2? Ich könnte schwören, dass Du das vor kurzer Zeit mal anders gesehen hast...Definitiv nicht.Beides kanns nicht sein - entscheide Dich mal.CPU Hersteller geben eine Zugriffslatenz immer nur für einen Cachelevel an, die darüberliegenden Level fliessen in diese Latenz nicht ein. Gibt ein Hersteller also eine Latenz von 2 für den L1 und eine Latenz von 8 für den L2 an, so braucht jeder L2 Zugriff insgesamt 10 Zyklen.Weil das Nichtblockieren Buffered WT genannt würd etwa?
Ich bin absolut Deiner Meinung, wenn Buffered WT zutrifft, aber dann wärs doch angeschrieben!Hör einfach auf, auf diesem Begriff rumzureiten....du kannst davon ausgehen, dass es so ist. Mal abgesehen davon bist du der einzige, der diesen Begriff je verwendet hat ;)

[Haarmann]

Muh-sagt-die-Kuh

Der Itanium läuft viel näher an der Grenze der Kapazität seiner Ausführungseinheiten - das war ja der Sinn dieser Konstruktion...
Ein x86 läuft nicht wirklich dort... Daher ist der Datenbedarf anders. Des Weiteren verfügt ein Itanium über ne ganz andere Anzahl Register. Da ändert sich im Datenverkehr so Einiges.

Wenn nach 2 Takten die Daten in der CPU sind und der CC 2 Takte brauchen soll, damit er sieht, ob die Daten da sind, dann ist das seltsam. Es ist ja nicht der gleiche Vorgang, ob man die Daten liefern oder nur nachschlägt. Ungleiche Vorgänge haben selten gleiche Ausführungszeiten.

Der Begriff mag Dir nicht bekannt sein, aber das ist nicht mein Problem. Es spricht nicht für euch, wenn ihr den Begriff nicht kennt ;).

[GloomY]

Haarmann,

Ich kenne diese (deine) Begriffe auch nicht. Wirklich, ich habe sie noch nirgends gelesen.
GloomY

Dann wärs ein Buffered WT Cache, wenn er nicht locked würd. Da das bisher nirgens so zu lesen war, gehe ich schlicht davon aus, das er es nicht ist.

Ich finds übrigens schön, dass er einen Load und einen Store Port hat. Hätte er bei meinem Aufbau ja auch, aber er hätte 2 Store Ports (von der CPU her und vom L2 her), wenn er nach anderer Leute Idee hier aufgebaut wär. Und es ergibt durchaus Sinn nen Cache zu sperren, wenn man drauf schreibt. Könnte ja sein, dass man grad beschreibt, was man lesen will...Sowas muss die Kontroll-Logik schon im Vorfeld verhindern, sprich: Dazu darf es gar nicht kommen.
Wenn nach 2 Takten die Daten in der CPU sind und der CC 2 Takte brauchen soll, damit er sieht, ob die Daten da sind, dann ist das seltsam. Es ist ja nicht der gleiche Vorgang, ob man die Daten liefern oder nur nachschlägt. Ungleiche Vorgänge haben selten gleiche Ausführungszeiten.Die Frage, ob der Cache trifft oder nicht, kann man (meist) schneller beantworten, als die Load-to-Use Latency, also die Zeit, bis die Daten wirklich geliefert werden.