Artikel :Pentium 4 - Leistungsfragen

[BlackBirdSR]

Hi,

könnt ihr mir bitte mal erklären wie ihr auf den 166MHZ FSB des K8 kommt?

ich hab immernoch nicht raus woran ihr diesen festmachen wollt...

thx

[Unregistered]

der K8 hat gar keinen FSB mehr, das Speicherinterface ist in den Prozessor integriert, was mit Sicherheit zu einer Verkleinerung der Latenzzeiten führt, andere Schnittstellen stellt eine Bridge, die über Hypertransport an die CPU angeschlossen ist zu Verfügung (z.B AGP) an die dann auch die Southbridge angeschlossen wird (auch über Hypertransport aber mit geringerer Bandbreite wie z. B. beim nForce Chipsatz (800MByte/s)).

[BlackBirdSR]

noch was zum Artikel:

Ihr gebt an das der Trace Cache eine Bremse für die CPU ist.

Allerdings denke ich ist der Trace Cache eine der wirklich excellenten neuerungen in der letzten zeit.
So werden die Befehle im Trace Cache nach dem Ausführen nicht nur zwischengespeichert (wodurch sich die Pipelinelänge für einen Befehl von ca 28 auf 20 verringert).
sie werden auch in der richtigen Reihenfolge geordent wenn man so sagen will.

Was die nur 3 µops angeht die den Trace Cache verlassen: wenn ich das richtig verstehe nimmt der Cache sehr wohl 6µops von den Decodern an, arbeitet aber nur bei halben Prozessortakt wodurch nur 3µops verfügbar sind.-
allerdings dachte ich bis jetzt das z.B ein P3 bei einem Durchsatz von ca 1.5-1.7µops liegt.. also die 3µops des P4 jeden Menge sind.
Wenn ich dann hinzunehme das wie bei den FPUs nicht immer alle Einheiten wirklich genutzt werden sind 3µops gar nicht so wenig..
besonders wenn ich das richtig verstehe, stauen sich bei Out of Order CPUs die (zusammenhängenden) µops vor den Ausführungseinheiten an, bis z.B ein spcicherzugriff asugeführt ist, und diese µops werden ja nicht vom Trace Cache begrenzt..
...

spielen eigentlich die höheren Latenzzyklen die der P4 auf sich nehemn muss bei einem Fehlsprung, keine Rolle gegenüber einer kürzeren Pipeline?
ich kann nicht nachvollziehen warum die Pipeline länger irrelevant sein sollte? (hilfe.. was stimmt jetzt?)


thx für die Hilfe..

[Marcel]

Originally posted by BlackBirdSR
noch was zum Artikel:

spielen eigentlich die höheren Latenzzyklen die der P4 auf sich nehemn muss bei einem Fehlsprung, keine Rolle gegenüber einer kürzeren Pipeline?
ich kann nicht nachvollziehen warum die Pipeline länger irrelevant sein sollte? (hilfe.. was stimmt jetzt?)


Habe das auch so in Erinnerung (auch aus 'ner Vorlesung), dass die Länge der Pipeline sich negativ bei einem nicht vorhergesehenen Sprung auswirkt. Der nächste Befehl nach dem Sprung muss ja die Pipeline komplett durchlaufen, bei 20 statt 10 Stufen ist also eine um 10 Takte längere Pause gegeben.

Gruß,
Marcel

[Marcel]

Ihr gebt leider nur die Temperatur als Argument für eine Vereinfachung der einzelnen Pipeline-Stufen an.
Ein anderes Argument ist die Minestdauer, die die Transistoren zum Schalten benötigen. Wenn die einzelnen Pipeline-Stufen einfacher sind, müssen die elektrischen Signale pro Takt durch weniger Transistoren, und somit verrignert sich die gesamte Signallaufzeit, womit der Takt eben höher getrieben werden kann.
Das war ja im Endeffekt auch das zentrale Problem beim K6. Pro Takt wurde unheimlich viel gemacht, zum Beispiel war die Sprungvorhersage so gut, dass ein K6 heute schon weiß, welchen Befehl er morgen ausführen muss (ernsthaft, kein anderer x86er-Prozessor hat eine so gute Trefferquote). Deswegen war der K6 auch nicht für hohe Taktraten zu gebrauchen.

Gruß,
Marcel

[zeckensack]

Das hätte der Artikel vielleicht auch ansprechen sollen:
Originally posted by BlackBirdSR
Was die nur 3 µops angeht die den Trace Cache verlassen: wenn ich das richtig verstehe nimmt der Cache sehr wohl 6µops von den Decodern an, arbeitet aber nur bei halben Prozessortakt wodurch nur 3µops verfügbar sind.-
Der P4 hat nur einen einzigen Decoder. Selbst wenn es möglich ist, daß ein einzelner x86-Befehl in 6 ops zerlegt wird, so kommt es in der Praxis so gut wie nie vor. Dies ist eine weitere Schwäche des P4: Der Decoder, der den TraceCache füttert, ist unterdimensioniert.

Noch etwas:
aus dem Artikel:Das gleiche gilt im übrigen im Integer-Bereich für die AGU-Einheiten, diese sind auch nur zum Laden und Speichern vorhanden und damit ebenfalls aus Performance-Sicht nicht relevant.
Das stimmt so nicht. Mittels des LEA-Befehls können AGUs auch für Integerberechnung benutzt werden.
Beispiel:
LEA EDI,[EAX+EBX+8*ESI]
führt eine Multiplikation und drei Additionen in einer einzigen Instruktion aus, benötigt nur eine einzige AGU und hält gleichzeitig die ALUs für andere Aufgaben frei. Das klappt nur mit Zweierpotenzen als Faktoren, wird aber von Compilern teilweise sehr heftig benutzt, um Integermultiplikation mit konstanten Faktoren schneller zu machen. Außerdem spart es Register.

Noch'n Beispiel: hier soll EDI:=5*EDI+EBX ausgerechnet werden
MOV EAX,EDI //Multiplikation geht nur in EAX
IMUL 5 //EAX=EAX*5, überschreibt EDX
ADD EAX,EBX
MOV EDI,EAX
Besser wäre:ADD EBX,EDI
LEA EDI,[EBX+4*EDI]

[BlackBirdSR]

Dafür liegen im Trace Cache auch Befehle die andauernd genutzt werden. (Cache).

Sehr viele durchlaufen den Decoder nur ein einziges Mal und können dann für andauernde Berechnungen aus dem Trace Cache geholt werden.

Bei einem fehlsprung müssen die Befehle zwar wieder durch den Decoder, allerdings sind da eh 19 Taktzyklen starfe abzusitzen, und wie schon gesagt stauen sich die µops for den Funktionseinhieten an..

ohne den TraceCache wäre der eine Dekoder wirklich zu wenig.. mehr als dieser eine hätte im jetzigen P4 aber so gut wie keinen Sinn.
Dies ist auch der grund warum es nur einen Decoder gibt.

das ist zumindest meine Meinung.

[aths]

Originally posted by zeckensack
Das hätte der Artikel vielleicht auch ansprechen sollen:
Der P4 hat nur einen einzigen Decoder.

Zeckensack, als ich die Grundfassung schrieb, habe ich auch andere Details ausgelassen. Mir ging es darum, auf das wesentliche zu kommen. In meinen Augen ist der wesentliche (und gewollte) Flaschenhals durch die Eigenarten des Trace-Caches (bzw. deren Anbindung) am besten beschrieben. Dass z.B. der Athlon gleich drei Decoder hat, der P4 nur eine, war mir bekannt. Es ging mir aber nicht darum, den Aufbau der CPU zu beschreiben, dieses machte ich nur soweit, wie es für die Gedankengänge erforderlich ist.

Leo bohrte da an etlichen Stellen noch nach, um sie zu präzisieren. Dabei ging es ihm ebenfalls nicht darum, den Pentium im Detail zu beleuchten; sondern wir suchten Quellen und genaue Angaben, um unsere Schlussfolgerungen mit Tatsachen untermauern zu können.

Ich bin natürlich trotzdem dankbar dafür, dass du einige Dinge präzisiert hast. Wie gesagt konnte wir beim Schreiben nicht alles berücksichtigen, um nicht den roten Faden zu verlieren, jedenfalls nach unserem Ansatz. Ob das wirklich der beste Ansatz war, sei dahin gestellt.


edit: In Dingen Assembler sind Leo und ich nicht allzu firm. Man möge uns verzeihen, dass wir solche Kniffe nicht kennen und der Artikel an dieser Stelle ungenau ist.

[Leonidas]

Ich denke, wir können die Problematik beim P4 nicht auf den nur einen Decoder schieben.

Denn dann hätten wir nachweisen müssen, daß die im TraceCache gespeicherten Instruktionen nicht ausreichend sind, um den schwachen Decoder abzufangen. Das ist zwar eine gute Vermutung, nur derzeit absolut nicht beweissbar.

Wir haben uns hier auf den Output des TraceCache konzentriert, welcher weniger leistet als der des K7 und weniger, als beim P4 möglich wären. Eben darum, weil dieser Fakt nachweisbar ist.

[Leonidas]

Thx @ Zeckenzack bzgl. der Ausführungen zur AGU. Leider haben all die großen WebSeiten nix, aber auch gar nix zu diesem Thema anzubieten. Ich habe jetzt einige Tage damit verbracht, die AGU und die FStore richtig einzuordnen, weil keiner irgendwelche Wahrheiten schreibt (sondern wohl nur als den Intel PDFs ab-schreibt).

[Xmas]

Originally posted by zeckensack
LEA EDI,[EAX+EBX+8*ESI]
führt eine Multiplikation und drei Additionen in einer einzigen Instruktion aus, benötigt nur eine einzige AGU und hält gleichzeitig die ALUs für andere Aufgaben frei.
AFAIK stimmt das beim P4 aber nicht mehr. Müsste nur mal finden wo ich das gelesen hab...

[immi]

Originally posted by Marcel


Habe das auch so in Erinnerung (auch aus 'ner Vorlesung), dass die Länge der Pipeline sich negativ bei einem nicht vorhergesehenen Sprung auswirkt. Der nächste Befehl nach dem Sprung muss ja die Pipeline komplett durchlaufen, bei 20 statt 10 Stufen ist also eine um 10 Takte längere Pause gegeben.

Gruß,
Marcel

ausserdem wurde ein bisschen konfus beschrieben, wie die pipeline die berechnung beschleunigt. Es ist ja nicht so, dass ein befehl zwei takte laenger fuer irgendwas braucht, denn es kommt ja bei jedem Takt ein befehl am Ende der pipeline raus.
wenn man also 1ghz bei 10 stufen hat, kommen die befehle trotzdem nicht so schnell raus, wie bei 2ghz und 20 stufen. bei der erklaerung koennte man annehmen, dass es in beiden faellen nur 100,mhz waeren...
btw: die code-optimierung muesste schon gewaltig sein (oder die micro-op aufbrechung umso gewaltiger) da alle 9-11 Befehle ein Sprungbefehl kommt! (Untesuchung von hp/intel zum thema epic). die 20stufige pipeline waere also effektiv praktisch niemals mit mehr als einem befehl gefuellt, die pipeline waere also tatsaechlich ziemlich irrelevant, auch wenn bei einem sprung nicht die _gesamte_ pipeline geflusht werden muss.
(Nur der alpha hat dieses problem aufgrund seiner doppelten pipeline nicht)
Was aber voellig vergessen wurde: eine so lange pipeline braucht wiederum sehr viel platz, verteilt sich also ganz gut auf dem chip (vor allem bei dieser auslastung), was die thermik wiederum beeinflussen duerfte.

Tschoe,
Ingmar.

[Leonidas]

Originally posted by immi

Was aber voellig vergessen wurde: eine so lange pipeline braucht wiederum sehr viel platz, verteilt sich also ganz gut auf dem chip (vor allem bei dieser auslastung), was die thermik wiederum beeinflussen duerfte.

Tschoe,
Ingmar.


Stand in der Ursprungsfassung des Artikels drin. Da wir haben nicht einen einzigen halben Beweis dafür haben, wurde es rausgekürzt. Es ist eine gute Spekulation - aber mehr eben auch nicht.

[BlackBirdSR]

ich hab vielleicht keine Ahnung von Ahnung von CPU Design..

aber eine Pipeline ist ja keine Röhre innerhalb der CPU.. also keine Funktionseinhiet die Wärme produziert.. vielmehr ist es eine Beschreibung der verschiedenen Arbeitsschritte..

ob ich nun vom Decoder bis zum zurückschreiben und anschließenden Drive Wartezyklus in 12 Stufe gehe, oder dafür 20 brauche... ich laufe durch die selben Chip regionen..
ich kann also nicht glauben dass sich eine längere Pipeline wie ein Darm System beim Menschen durch den Chip zieht und deshalb mehr Wärme produziert..

wie ich sehe gibt es ein paar Probleme mit Daten über die ganze Architektur...kenn ich *g*.. immer nur überall benchmarks..

wenn ihr viel Zeit und lust habt könnt ihr doch mal dort vorbeischauen vielleicht hilft das etwas.. ich kann ja auch nur neue Fragen aufwerfen ;)


http://www.arstechnica.com/cpu/3q99/k7_theory/k7-one-1.html
http://www.arstechnica.com/cpu/3q99/k7_theory/k7-two-1.html
http://www.arstechnica.com/cpu/1q99/ia-64-preview-1.html
http://www.arstechnica.com/cpu/1q00/g4vsk7/g4vsk7-1.html
http://arstechnica.com/cpu/01q2/p4andg4e/p4andg4e-1.html

http://www.realworldtech.com/page.cfm?AID=RWT030300000001
http://www.realworldtech.com/page.cfm?AID=RWT040400000000
http://www.realworldtech.com/page.cfm?AID=RWT091000000000
http://www.realworldtech.com/page.cfm?AID=RWT112000000000

und die Foren beider Seiten..
aber wie gesagt.. wenn ihr VIEL Zeit habt *g*

[Leonidas]

:-) Die Ars Technica Artikel hatte ich für unseren Artikel gelesen, die von RealWorld allerdings noch nicht.

[zeckensack]

Originally posted by Xmas

AFAIK stimmt das beim P4 aber nicht mehr. Müsste nur mal finden wo ich das gelesen hab... Okay, hier mal ein paar Auszüge aus meinen gesammelten Optimierungs-Manuals:

Für P4/Xeon (http://developer.intel.ru/design/pentium4/manuals/248966.htm):In many cases an lea instruction or a sequence of lea, add, sub, and shift
instructions can be used to replace constant multiply instructions. The lea instruction
can be used sometimes as a three or four operand addition instruction, for example,
lea ecx, [eax + ebx + 4 + a]
Using the lea instruction in this way can avoid some unnecessary register usage by not
tying up registers for the operands of some arithmetic instructions. It may also save
code space.
The lea instruction is not always as fast on the Pentium 4 processor as it is on the
Pentium II and Pentium III processors. This is primarily due to the fact that the lea
instruction can produce a shift µop. If the lea instruction uses a shift by a constant
amount then the latency of the sequence of µops is shorter if adds are used instead of a
shift, and the lea instruction is replaced with the appropriate sequence of µops.
However, this increases the total number of µops, leading to a trade-off:
Assembly/Compiler Coding Rule 40. (ML impact, M generality) If an lea instruction
which uses the scaled index is on the critical path, the sequence with the adds may be better,
but if code density and bandwidth out of the trace cache are the critical factor, then the lea
instruction should be used.
Für Pentium III (http://developer.intel.com/design/pentiumii/manuals/245127.htm):In many cases a lea instruction or a sequence of lea, add, sub, and
shift instructions can be used to replace constant multiply instructions.
Use the integer multiply instruction to optimize code designed for
Pentium II and Pentium III processors. The lea instruction can be used
sometimes as a three/four operand addition instruction, for example,
lea ecx, [eax+ebx+4+a]
Using the lea instruction in this way can avoid some unnecessary register
usage by not tying up registers for the operands of some arithmetic
instructions.
On the Pentium II and Pentium III processors, both lea and shift
instructions are single µop instructions that execute in one cycle. However,
that short latency may not persist in future implementations. The Intel
C/C++ Compiler checks to ensure that these instructions are used correctly
whenever possible.
For the best blended code, replace the shift instruction with two or more
add instructions, since the short latency of this instruction may not be
maintained across all implementations.

P3/P4 arbeiten hier also ganz anders und die Optimierungen für den P3 führen auf dem P4 teilweise zu schlechterer Performance, als reiner Schlabbercode liefern würde.

[Frank]

Zu den Multitasking im Artikel von mir mal ne Frage zum Verständnis:

Was meint ihr mit Registern und Unterregistern??
Soweit ich weiss löscht der P4 genauso wie all seine Vorgänger seine ganze TLB bei einer Prozeßumschaltung, was die ganze Sache natürlich ziemlich teuer macht, wenn der dann irgendwann mal wieder auf schon zugegriffene Speicherplätze über die Seitentabelle zugreifen will.

Oder gings da um die virtuellen Tags mit der der P4 seinen Cache verwaltet?

???

[immi]

Originally posted by Frank
Zu den Multitasking im Artikel von mir mal ne Frage zum Verständnis:

Was meint ihr mit Registern und Unterregistern??
Soweit ich weiss löscht der P4 genauso wie all seine Vorgänger seine ganze TLB bei einer Prozeßumschaltung, was die ganze Sache natürlich ziemlich teuer macht, wenn der dann irgendwann mal wieder auf schon zugegriffene Speicherplätze über die Seitentabelle zugreifen will.

Oder gings da um die virtuellen Tags mit der der P4 seinen Cache verwaltet?

???

nein, ich denke es ging darum, dass die register, die du als programmierer siehst, fast nichts mehr mit den physikalischen zu tun haben. Diese befinden sich ohnehin in einem register-file (ein array quasi), worauf fuer jeden task nur noch ein pointer fuer den anfang gespeichert wird, was das umschalten sehr einfach macht. Aber auch bei register renaming etc. wird da drin rumgewuehlt. Mit den Registern von frueher, welche im Grunde Flipflops waren, hat das praktisch nichts mehr zu tun.
Ausserdem hast du danoch Schattenregister drin, die fuer fast-write-back und andere pipelineningstrategien verwendet werden.

[BlackBirdSR]

jetzt hat mir immernoch keiner von 3dcenter erklärt wie sie auf den 166MHZ FSB für den Hammer kommen ;(

könnt ihr auch mal erklären warum ihr eine Pipeline die um 2 Stufen erweitert wurde (12 Integer), verbesserte Branchprediction und wer weiß was sonst noch als fast identisch zum K7 Core bezeichnet? (minimale Natur??)


thx

[zeckensack]

Ich versuch's mal.
Der Hammer hat einen Speichercontroller für DDR333. Daher wahrscheinlich die Aussage vom 166MHz FSB. Das stimmt natürlich nicht, wenn da irgendwo ein FSB ist, dann isses der HyperTransport-Link, aber der lüppt viel schneller als 166MHz.

Die zwei Extra-Stufen in der Pipeline hängen direkt mit dem Speichercontroller zusammen, zählen also eigentlich nicht.

Allerdings ist im Rest der Pipeline doch einiges herumgewürfelt, lediglich das Back-End (die Ausführungseinheiten) ist weitgehend unverändert, bis auf die 64-bit-Sachen natürlich.

[BlackBirdSR]

hmm soweit ich das gehört habe ist der FSB doch die Verbindung des Systems zum Speicherbus... bei den GTL Bussystemen also über die Northbridge.

Hypertransport und Speicherbus treffen sich aber eigentlich erst am XBar Controller also hat HT mit dem Speicher gar nichts am Hut.. er verbindet alleine die restliche Sytemperipherie mit der CPU, bzw die CPU mit einer anderen CPU..

Hat der Hammer nur einen Controller für DDR333? oder ist es dem Controller eigentlich egal ob er nun 166MHZ Speicher oder auch 200MHZ Speicher anspricht? gibt es dazu infos?

Und nich was: wenn die zusätzlichen Pipeline Stufen nur dem Speichercontroller "gehören", dann würde dies auch heissen das sie nicht beteiligt sind den Befehlsfluss auf mehr Pipelines zu verteilen, und deshalb mehr Takt ermöglichen?
sicher das die Pipeline Stufen des Speichercontrollers nicht nach denen des L2 Cache kommen (13-19)? (integer natürlich)

[zeckensack]

Nee, FSB hat er natürlich in dem Sinne nicht. Der HT-Link ist lediglich das, was man am ehesten damit vergleichen kann.

In den Opteron-Präsentationen steht immer was von DDR266-DDR333 bei den Speichercontrollern. Evtl gibt's da später auch schnellere Varianten, aber das kann man noch nicht genau sagen.

Zur Pipeline: Sieht aus, als seien die 12 Stufen tatsächlich ohne Speichercontroller.