GloomY schrieb am 31. August 2004 14:23
> Gerade bei einer recht breiten Architektur wie der des Athlons /
> Opterons ist besonders der letzte Punkt wichtig, denn man muss 3
> Integer-, 3 Adress-Generation und drei FP-Units pro Takt mit Befehlen
> und Daten versorgen. In der Praxis klappt das natürlich hinten und
> vorne nicht. Der x86 Dekoder des Hammers - der schon recht heftig
> ausgelegt und imho fast schon überdimensioniert ist - stellt maximal
> 3 µOps/Takt aus 16 Byte x86 Code zur Verfügung. 3 µOps/Takt bei 9
> hungrigen Ausführungseinheiten, das sollte die Frage nach der
> durchschnittlichen Auslastung beantworten ;-)
Na ganz so schlimm ist es nicht, da es bei Athlon keine µOps nach
Intel-Art sondern MacroOps sind. Die tun etwas mehr, sprich, man kann
mit 3 MacroOps bis zu 6 Einheiten auslasten. Z.B. wird "ADD eax,
[ebx+ecx*4+32]" von den Decodern in eine einzige MacroOp übersetzt
und dann beim Dispatch in eine Integer Pipeline in zwei µOps zerlegt,
mit der dann sowohl eine ALU als auch eine AGU ausgelastet werden.
Die ALUs und AGUs in einer Pipeline sind außerdem eng gekoppelt,
sprich es können keine zwei MacroOps gleichzeitig dorthin abgesetzt
werden. Der Scheduler kann also die MacroOps nur in 6 Ports absetzen,
nicht in 9. Der P4 hat übrigens 4 Ports, durch die er maximal 6µOps
pro Takt schleusen kann (Port0 und 1 sind die double pumped ALUs, die
maximal 2 µops pro Takt aufnehmen). Der P4 hat also eine "dispatch
width" von 6 µOps, ein Athlon von 6 MacroOps (entsprechen maximal
9µOps). Wobei der TraceCache beim P4 maximal 3µOps pro Takt liefert,
die Decoder beim Athlon dagegen maximal 3 MacroOps (entsprechen
maximal 6µOps).
Gipsel
> Gerade bei einer recht breiten Architektur wie der des Athlons /
> Opterons ist besonders der letzte Punkt wichtig, denn man muss 3
> Integer-, 3 Adress-Generation und drei FP-Units pro Takt mit Befehlen
> und Daten versorgen. In der Praxis klappt das natürlich hinten und
> vorne nicht. Der x86 Dekoder des Hammers - der schon recht heftig
> ausgelegt und imho fast schon überdimensioniert ist - stellt maximal
> 3 µOps/Takt aus 16 Byte x86 Code zur Verfügung. 3 µOps/Takt bei 9
> hungrigen Ausführungseinheiten, das sollte die Frage nach der
> durchschnittlichen Auslastung beantworten ;-)
Na ganz so schlimm ist es nicht, da es bei Athlon keine µOps nach
Intel-Art sondern MacroOps sind. Die tun etwas mehr, sprich, man kann
mit 3 MacroOps bis zu 6 Einheiten auslasten. Z.B. wird "ADD eax,
[ebx+ecx*4+32]" von den Decodern in eine einzige MacroOp übersetzt
und dann beim Dispatch in eine Integer Pipeline in zwei µOps zerlegt,
mit der dann sowohl eine ALU als auch eine AGU ausgelastet werden.
Die ALUs und AGUs in einer Pipeline sind außerdem eng gekoppelt,
sprich es können keine zwei MacroOps gleichzeitig dorthin abgesetzt
werden. Der Scheduler kann also die MacroOps nur in 6 Ports absetzen,
nicht in 9. Der P4 hat übrigens 4 Ports, durch die er maximal 6µOps
pro Takt schleusen kann (Port0 und 1 sind die double pumped ALUs, die
maximal 2 µops pro Takt aufnehmen). Der P4 hat also eine "dispatch
width" von 6 µOps, ein Athlon von 6 MacroOps (entsprechen maximal
9µOps). Wobei der TraceCache beim P4 maximal 3µOps pro Takt liefert,
die Decoder beim Athlon dagegen maximal 3 MacroOps (entsprechen
maximal 6µOps).
Gipsel