01/04/03 News: Der relativ schwache Durchsatz des Trace Caches ist bekanntermaßen

[BlackBirdSR]

Sag mal, könnt ihr mal damit aufhören, einen eurer Artikel als allseits bestätigt aufzuführen,
der bestimmt schon einige Male kritisiert wurde, und dessen Inhalt ich auf keiner der in-depth Hardwareseiten finden kann?

ich sag jetzt mal ich habe Null Ahung von der ganzen Sache: also erklärt mir bitte mal einer, warum die 3µOps des TraceCache so furchtbar wenig sind.
Und warum kommt ihr auf die Idee dies in eurem NewsPost so hinzustellen, als wäre es eine allgemein bekannte Tatsache die man ständig kritisiert..

Leistungsbremse TraceCache... :...(
ihr wisst schon, dass viele 3dcenter Leser, hier Alles für bare Münze nehmen.

[Leonidas]

Originally posted by BlackBirdSR
Sag mal, könnt ihr mal damit aufhören, einen eurer Artikel als allseits bestätigt aufzuführen,
der bestimmt schon einige Male kritisiert wurde, und dessen Inhalt ich auf keiner der in-depth Hardwareseiten finden kann?



Wurde doch aber schon zu Willy-Zeiten von erstklassigen Leuten kritisiert - leider sind diese Dokumenten nicht mehr online. Wirklich neu war unser Artikel aber mitnichten, da gibt es wesentlich umfangreichere Abrechnung mit dem P4 lange vor unserem Artikel. Deswegen das "bekanntermaßen" - die Themtik wurde schon 2000 auf anderen Webseiten ausführlich erläutert, worauf in unseren damaligen News auch hingewiesen wurde.


Zum Durchsatz des Trace Cache:
Milchmädchen-Rechnung: Die Ausführungseinheiten des P4 könnten im Idealfall 9 MicroOps verarbeiten, es kommen aber nur maximal 3 MicroOps in die Pipeline. Die Folge ist im schlimmsten Fall eine totale Unterlastung des Prozessors (womit sich dieser natürlich besser hochtakten lässt).

[BlackBirdSR]

Originally posted by Leonidas
Wurde doch aber schon zu Willy-Zeiten von erstklassigen Leuten kritisiert - leider sind diese Dokumenten nicht mehr online. Wirklich neu war unser Artikel aber mitnichten, da gibt es wesentlich umfangreichere Abrechnung mit dem P4 lange vor unserem Artikel. Deswegen das "bekanntermaßen" - die Themtik wurde schon 2000 auf anderen Webseiten ausführlich erläutert, worauf in unseren damaligen News auch hingewiesen wurde.


Ja der damalige anti P7 Teil der Websites.. aber nicht jede der inDepth Seiten, die versteht wie die Abläufe in der CPU sind.
Also?, ist nun die Wahrheit korrekt, deren Seite man ergreift?


Originally posted by Leonidas
Zum Durchsatz des Trace Cache:
Milchmädchen-Rechnung: Die Ausführungseinheiten des P4 könnten im Idealfall 9 MicroOps verarbeiten, es kommen aber nur maximal 3 MicroOps in die Pipeline. Die Folge ist im schlimmsten Fall eine totale Unterlastung des Prozessors (womit sich dieser natürlich besser hochtakten lässt).


und jetzt ohne Milchmädchen-Rechnung, also ohne billiges Abzählen von Ausführungseinheiten?
"Idealfall steht da aus gutem Grund, und "schlimmsten Fall" steht da auch aus gutem Grund.
Keineswegs ergibt sich für mich aus diesen Worten eine Situation die eure Behandlung rechtfertigt.

[Endorphine]

Wenn alles so einfach wäre wie es der Artikel anreisst hätte Intel der Architektur sicher nicht so ein aufwändiges Konstrukt wie SMT hinzugefügt, wenn man eine ähnliche Durchsatzsteigerung auch durch einen entdrosselten trace Cache hinbekommen hätte. Auch in F&E gelten immer noch ökonomische Grundsätze.

Wenn man es genau nimmt ist die Kritik am P4-Design eine reine Vermutung. Und selbst wenn man der Vermutung nachgeht: ist die Kritik noch berechtigt wenn das SMT im Prescott sogar noch deutlich verfeinert wurde und damit die Begrenzung des Trace Cache auf sechs µOps in zwei Takten hinfällig wird?

[Leonidas]

Originally posted by BlackBirdSR


Ja der damalige anti P7 Teil der Websites.. aber nicht jede der inDepth Seiten, die versteht wie die Abläufe in der CPU sind.
Also?, ist nun die Wahrheit korrekt, deren Seite man ergreift?



Wenn die anderen Seiten rein die Intel-Dokumente abpinseln und sich keinesfalls kritisch damit beschäftigen, dann bleibt letztlich nur eine einzige Stimme übrig, welche sich überhaupt mit dem Thema wirklich auseinandergesetzt hat. Du willst doch wohl nicht die Masse der PDF-Abschreiber jetzt als Argument anführen?

[Leonidas]

Originally posted by Endorphine
Wenn alles so einfach wäre wie es der Artikel anreisst hätte Intel der Architektur sicher nicht so ein aufwändiges Konstrukt wie SMT hinzugefügt, wenn man eine ähnliche Durchsatzsteigerung auch durch einen entdrosselten trace Cache hinbekommen hätte. Auch in F&E gelten immer noch ökonomische Grundsätze.



Gegenargument: Wenn das gilt, wieso dann den Durchsatz beim Prescott auf 4 erhöhen? Er hat nicht mehr Ausführungseinheiten ...

[BlackBirdSR]

Originally posted by Leonidas



Wenn die anderen Seiten rein die Intel-Dokumente abpinseln und sich keinesfalls kritisch damit beschäftigen, dann bleibt letztlich nur eine einzige Stimme übrig, welche sich überhaupt mit dem Thema wirklich auseinandergesetzt hat. Du willst doch wohl nicht die Masse der PDF-Abschreiber jetzt als Argument anführen?

keinesfalls will ich die PDF-abschreiber damit aufführen, aber vielleicht einige der Seiten und deren Community, die kapiert haben, dass der TraceCache nicht nur µOps ausspuckt wie ein Decoder, sonder sie auch noch schön zurechtlegt und Branches mit einbezieht.
Vielleicht will ich die Leute aufführen, die kapiert haben, dass µOps aus dem TraceCache nicht gleich an die Funktionseinheiten geleifert werden, und die in Betracht gezogen haben, dass die Ausführung vieler Befehle mehr als einen Takt dauert.

Dann frage ich mich: Steht da jetzt ein Artikel, der sowas in Betracht zieht, und sich zurecht damit schmückt allseits bekannten Inhalt zu haben, oder ist es ein Artikel, der die Anzahl der Funktionseinheiten mit der Anzahl der µOps vergleicht, und daraus folgert dass zuwenig µOps ausgespuckt werden?

Es geht nicht darum, ob der TraceCache nicht mit mehr µOps noch ein paar % herausholen könnte, in einigen Situationen. Sondern darum wie ihr es in dem Artikel hinstellt, als wäre die gesamte TraceCache Geschichte ein großer Fehler von Intel.

Originally posted by Leonidas
Gegenargument: Wenn das gilt, wieso dann den Durchsatz beim Prescott auf 4 erhöhen? Er hat nicht mehr Ausführungseinheiten ...


Vielleicht hat es Vorteile für Hyperthreading?, immerhin hat Intel nur 1µOps/Takt mehr hinzugefügt, nicht mehr.
3µOps mögen für den Willy und NW, völlig ausreichend gewesen sein, aber sobald man anfängt effizientes SMT zu implementieren können viel mehr Befehle gleichzeitig abgearbeitet werden. In einigen Fällen kann es dann plötzlich lohnen 4µOps/Takt zur Verfügung zu haben.
Vielleicht hat Intel den TraceCache auch etwas umorganisiert, schließlich wird er von 2/4 logischen Prozessoren benutzt.
In keinem Fall sehe ich darin die Bestätigung, dass der P7 durch den TraceCache stark unausgelastet ist.

[StefanV]

Originally posted by BlackBirdSR
Es geht nicht darum, ob der TraceCache nicht mit mehr µOps noch ein paar % herausholen könnte, in einigen Situationen. Sondern darum wie ihr es in dem Artikel hinstellt, als wäre die gesamte TraceCache Geschichte ein großer Fehler von Intel.

Hm, so ganz begeistert vom Trace Cache scheinen nicht alle Entwickler bei Intel zu sein...

Siehe Banias, der einen 'klassichen' Daten und Instruktionscache hat...

PS: der Banias ist auch (mehr oder minder) ein 'optimirter' P4, wenn ich den Artikel in der c't richtig verstanden hab).

[BlackBirdSR]

Originally posted by Stefan Payne


Hm, so ganz begeistert vom Trace Cache scheinen nicht alle Entwickler bei Intel zu sein...

Siehe Banias, der einen 'klassichen' Daten und Instruktionscache hat...

PS: der Banias ist auch (mehr oder minder) ein 'optimirter' P4, wenn ich den Artikel in der c't richtig verstanden hab).

nein, er begann als P3 Core, und wurde daraufhin erweitert und umgebaut wie es nötig war.

[aths]

BlackBirdSR,

hast du was an Argumenten anzubieten, dass der 3DC-Artikel in Dingen Trace-Cache-Limit falsch ist? Wenn ja, bitte nennen, und wir werden den Artikel ändern.

Bei 9 Execution Units nur 3 µOps pro Takt in die Pipeline zu lassen ist sicher eine höhere Unterauslastung als wenn man bis zu 6 Ops in die Pipe entsendet (so beim Athlon.)

Der Trace-Cache ansich wird im Artikel nicht als Fehler, sondern als sinnvolle Sache betrachtet (da der Decoder entlastet wird.)

[Muh-sagt-die-Kuh]

Originally posted by Leonidas
Zum Durchsatz des Trace Cache:
Milchmädchen-Rechnung: Die Ausführungseinheiten des P4 könnten im Idealfall 9 MicroOps verarbeiten, es kommen aber nur maximal 3 MicroOps in die Pipeline. Die Folge ist im schlimmsten Fall eine totale Unterlastung des Prozessors (womit sich dieser natürlich besser hochtakten lässt). Hast du je etwas von ILP (Instruction Level Paralellism) gehört? Wenn ja, dann wüsstest du dass 9 µops pro Takt vollkommen utopisch sind, mehr als 2,x µops pro Takt lassen sich aus normalem x86 Code nur in den allerseltensten Fällen rausholen.

Wo wir grad bei dem Artikel sind....der hat noch ein paar andere üble Böcke in diesem Abschnitt:

- Die Länge der Pipeline hat sehr wohl Einfluß auf die erreichbaren Taktfrequenzen, wieso das so ist sollte man eigentlich als Verfasser eines solchen Artikels wissen

- Ein thermisch optimiertes Design ist der P4 schon....aber auf ganz andere Art und Weise.

[Muh-sagt-die-Kuh]

Originally posted by aths
BlackBirdSR,

Bei 9 Execution Units nur 3 µOps pro Takt in die Pipeline zu lassen ist sicher eine höhere Unterauslastung als wenn man bis zu 6 Ops in die Pipe entsendet (so beim Athlon.)ILP, die 6 Ops die der Athlon an die ExUnits schicken kann sind nicht der Grund für seine höhere pro-Mhz Leistung.Der Trace-Cache ansich wird im Artikel nicht als Fehler, sondern als sinnvolle Sache betrachtet (da der Decoder entlastet wird.) Das kommt irgendwie nicht so gut raus...

[aths]

Originally posted by Muh-sagt-die-Kuh
ILP, die 6 Ops die der Athlon an die ExUnits schicken kann sind nicht der Grund für seine höhere pro-Mhz Leistung.... sondern?
Originally posted by Muh-sagt-die-Kuh
Das kommt irgendwie nicht so gut raus... Ich als latenter pro-Intler bin eigentlich zufrieden mit dem Grundton.

[BlackBirdSR]

Originally posted by aths
BlackBirdSR,

hast du was an Argumenten anzubieten, dass der 3DC-Artikel in Dingen Trace-Cache-Limit falsch ist? Wenn ja, bitte nennen, und wir werden den Artikel ändern.

Bei 9 Execution Units nur 3 µOps pro Takt in die Pipeline zu lassen ist sicher eine höhere Unterauslastung als wenn man bis zu 6 Ops in die Pipe entsendet (so beim Athlon.)

Der Trace-Cache ansich wird im Artikel nicht als Fehler, sondern als sinnvolle Sache betrachtet (da der Decoder entlastet wird.)

mal sehen,
fangen wir damit an, dass die Auslastung eine typischen CPU eigentlich bei 50% oder niedriger liegt.
Schuld daran sind Latenzzyklen, und Befehle die mehr als 1 Takt brauchen.
Der Athlon im Speziellen, kann seine FPUs z.B nicht mit max Effektivität nutzen, da zu viele Load/Store Befehle durch die Pipe kommen, und zuwenige paralelle MUL/ADD.
Der P4 hat zwar 3 ALUs, aber die beiden Fast-Alus mit 0.5 Takten Pro Befehle kommen nur sehr selten zum Zuge, da nur wenige Befehle in 0.5 Takten bearbeitet werden können.
Für den Rest kommt die Slow-Alu mit mehr als 1 Takt zum Einsatz.
Bei den FPUs ist es noch übler;
So ist FXCH nicht mehr kostenlos, und eine MUL Operation kann nur jeden 2. Takt begonnen werden.
(aceshardware)

Es ist schon viel wenn man auf 1.7-2.5 µOps pro Takt kommt. (realworldtech foren)

Die Auslastung des Kerns beim P4 beträgt in der SpecSuite ca 30-50% (C't)
Hyperthreading hilft, weil man damit wartende Funktionseinheiten weiter beschäftigen kann. Unmöglich wenn zu wenige Befehle im Umlauf wären.
Der TraceCache speichert nicht nur häufig benutzt Befehle, sondern ordnet sie nach dem Prinzip der Lokalität, und speichert auch noch durchgeführte speukulative Braches.

Und zuletzt, alle Funktionseinheiten sind an Scheduler geknüpft, welche die Befehle an diese Verteilen.
Da Befehle länger brauchen, und es ständig Abhängigkeiten gibt, sammeln sich an diesen Schedulern Befehle aus dem TraceCache an.
Es sind also nur in den seltensten Fällen nicht genug Befehle vorhanden.

Die CPU mag noch so viele Funktionseinheiten haben, die werden noch lange nicht Alle gleichzeitig genutzt.

Für mich stellen die 3µOps daraus keinen Engpass da, der einer der hauptkritikpunkte wäre.
WIe schon gesagt, mögen 4µOps noch 1-2% rausholen, aber das lohnt sich nicht für eine CPU ohne SMT.

[Muh-sagt-die-Kuh]

Originally posted by aths
... sondern?
BlackBirdSR war schneller, er hat eigentlich alle relevanten Punkte aufgelistet....mal abgesehen von der hohen Misprediction Penalty durch die lange Pipeline. Auch beim Athlon sammeln sich die ROPs in den Schedulern....sogar noch schneller als beim P4 ;)

[aths]

Originally posted by BlackBirdSR
Es ist schon viel wenn man auf 1.7-2.5 µOps pro Takt kommt. (realworldtech foren)Gibt es hierfür eine sichere Quelle?

[Muh-sagt-die-Kuh]

Originally posted by aths
Gibt es hierfür eine sichere Quelle? Die Jungs bei Realwordtech wissen wovon sie reden, mehr zur relativen Sicherheit dieser Daten später, das Grundproblem findes du hier (http://www.aceshardware.com/Spades/read.php?article_id=15000184) erläutert.

[Muh-sagt-die-Kuh]

So aths, hier die versprochenen sicheren Quellen

1. Es gibt Performance-Analysatoren die interne Performance-Counter der CPUs auslesen. Hier (http://www.aceshardware.com/read.jsp?id=25000191) findest du diesbezügliche Daten eines Pentium III, der die TraceCache "Limitierung" bekanntlich nicht hat.

2. Man könnte manuell auch folgendermaßen vorgehen:
- sich ein Programm mit einem klar definierten Ablauf schnappen (etwa Teiltests der SPEC-Suite).
- sich überlegen in wieviele µops sich jede x86 Instruktion wahrscheinlich zerlegen lässt.
- alle abgearbeiteten Befehle aufsummieren und mit der dazugehörigen Anzahl µops bewerten
- durch die Anzahl der Takte für einen Benchmarklauf teilen

Ich hoffe mal, du glaubst uns jetzt, dass die 3 µops pro Takt keine Bremse darstellen. :)

[Leonidas]

Ich muß hier mal in die Runde werfen: Wieso so eine Beschränkung? Eine Aufweitung auf 6 MicroOps kostet 300 Transistoren mehr. Irgendeinen Zwecke muß diese Beschränkung haben ...

[BlackBirdSR]

Originally posted by Leonidas
Ich muß hier mal in die Runde werfen: Wieso so eine Beschränkung? Eine Aufweitung auf 6 MicroOps kostet 300 Transistoren mehr. Irgendeinen Zwecke muß diese Beschränkung haben ...

kostet es wirklich 300 Transistoren mehr, 6µOps pro Takt herrauszugeben?
Was ist mit dem erforderlichen Platz, und den Timings?

Der TraceCache ist ein ziemlicher Logikbrocken, die wie gesagt mehr macht als nur Befehle wie ein Cache zu speichern.
Ständig müssen neue TraceSegmente erstellt und bearbeitet werden.
Vielleicht ist es momentan einfach nicht möglich, 6µOps pro Takt auszuspucken da die TraceSegmente nicht schnell genug gebaut werden können.
Warum sollte Intel darauf auch Zeit verschwenden, wenn es nicht nötig ist?
Der TraceCache scheint irgendwie sehr kritisch zu sein, wenn es um erreichbare Taktraten geht, warum also mehr als unbedingt nötig ausspucken, und das Design verlangsamen?

Eine endgültige Antwort habe ich als nicht-Intel-Ingeniuer allerdings natürlich nicht.

[Muh-sagt-die-Kuh]

Meine Herren, was ist los? Keine weiteren Kommentare?

[Leonidas]

Originally posted by BlackBirdSR


kostet es wirklich 300 Transistoren mehr, 6µOps pro Takt herrauszugeben?
Was ist mit dem erforderlichen Platz, und den Timings?



Dann kostet es halt eine Millionen. Also um eine mögliche Limitierung auszuschließen, wäre mir dies nicht zu schade.


Nebenbei muß ich mal erwähnen, daß sich einige der Pro-P4-Stimmen hier so anhören, als würde der P4 eine Pro-MHz-Leistung wie ein P3 oder ein K7 haben. Hat er aber nicht - sie liegt immer noch 30% darunter. Insofern *muß* das Design Schwächen haben (wenn sie auch aufgrund der höheren Taktbarkeit sich wieder in Stärken umwandeln, aber rein von der Pro-MHz-Seite her gesehen sind es Schwächen).

[Endorphine]

Originally posted by Leonidas
Nebenbei muß ich mal erwähnen, daß sich einige der Pro-P4-Stimmen hier so anhören, als würde der P4 eine Pro-MHz-Leistung wie ein P3 oder ein K7 haben. Hat er aber nicht - sie liegt immer noch 30% darunter. Insofern *muß* das Design Schwächen haben (wenn sie auch aufgrund der höheren Taktbarkeit sich wieder in Stärken umwandeln, aber rein von der Pro-MHz-Seite her gesehen sind es Schwächen).
Wieso "muss" das Design Schwächen haben? Wieso wird Leistung überhaupt vom Takt abhängig gemacht? Wieso wird ein P4 nicht einfach nach der Leistung gekauft und fertig?
Aus meiner Sicht ist der P4-Kern einfach dafür entworfen worden, längere Zeit Basis für Leistungssteigerungen zu sein, leichte Taktbarkeit eingeschlossen. Dass dadurch die Leistung pro Takt etwas gesenkt wurde - who cares? Kann das dem Kunden nicht vollkommen egal sein, wie eine CPU eine bestimmte Leistung erbringt, solange sie sie erbringt?

Der AMD Athlon ist im Vergleich zu früheren CPUs ineffizient bezogen auf sein Rating, der P4 auf seine Taktfrequenz. So what?

[BlackBirdSR]

Originally posted by Leonidas



Dann kostet es halt eine Millionen. Also um eine mögliche Limitierung auszuschließen, wäre mir dies nicht zu schade.


Nebenbei muß ich mal erwähnen, daß sich einige der Pro-P4-Stimmen hier so anhören, als würde der P4 eine Pro-MHz-Leistung wie ein P3 oder ein K7 haben. Hat er aber nicht - sie liegt immer noch 30% darunter. Insofern *muß* das Design Schwächen haben (wenn sie auch aufgrund der höheren Taktbarkeit sich wieder in Stärken umwandeln, aber rein von der Pro-MHz-Seite her gesehen sind es Schwächen).

ich fühle mich gekränkt, dass du in diese halbwegs sachliche Diskussion so was wie "Pro-P4 Stimmen", einbringst.
Hier geht es weder darum, ob ich den K7 lieber mag als den P7 oder Intel von AMD bevorzuge.
Hier geht es nur um techn. Details und den Artikel.

Endo geht schon in die richtige Richtung finde ich:
Wenn überhaupt sind Schwächen relativ im Verrgleich, und während der P4 gegenüber dem K7 durchaus an vielen Stellen den Kürzeren ziehen muss, so trifft es den K7 an ganz anderen Stellen.
Das ist eine Sackgasse.

Was den TraceCache angeht, so scheinst du immernoch nicht mit einzubeziehen, dass hier nicht nur die logischen Gatter eine Rolle spielen, sondern Timings und Anzahl der max. erstellbaren TraceSegmente.
Was du eine mögliche Limitierung bezeichnest, ist für mich nach der Betrachtung von Latenzen, und Schdulern keine schwere Limitierung.
Schon gar nicht, verglichen mit den Probleme die ein schnellerer TraceCache dem Design hinsichtlich Skalierung bringen könnte.

Einer CPU die im Schnitt vielleicht 1.7- 2.xµOps gleichzeitig bearbeiten kann 6µOps output zu geben, welche nur die Scheduler füttert, ist es nicht wert, der CPU mehrere MHz Takt zu rauben.

[Leonidas]

Originally posted by Endorphine

Wieso "muss" das Design Schwächen haben? Wieso wird Leistung überhaupt vom Takt abhängig gemacht? Wieso wird ein P4 nicht einfach nach der Leistung gekauft und fertig?
Aus meiner Sicht ist der P4-Kern einfach dafür entworfen worden, längere Zeit Basis für Leistungssteigerungen zu sein, leichte Taktbarkeit eingeschlossen. Dass dadurch die Leistung pro Takt etwas gesenkt wurde - who cares? Kann das dem Kunden nicht vollkommen egal sein, wie eine CPU eine bestimmte Leistung erbringt, solange sie sie erbringt?



Sorry, Du hast meinen Text aber nicht gelesen oder nicht verstanden. Ich rede von schwächerer Pro-MHz-Leistung als ein P3 oder K7. Dies ist eine rein theoretische Frage, wie auch die ganze Diskussion eine Theorie-Diskussion ist (nicht im negativen, sondern charakterierendem Sinne). Da hat die Feststellung, daß der P4 das durch Takt wieder ausgleicht, absolut nix zu suchen.

[Muh-sagt-die-Kuh]

Originally posted by Leonidas



Sorry, Du hast meinen Text aber nicht gelesen oder nicht verstanden. Ich rede von schwächerer Pro-MHz-Leistung als ein P3 oder K7. Dies ist eine rein theoretische Frage, wie auch die ganze Diskussion eine Theorie-Diskussion ist (nicht im negativen, sondern charakterierendem Sinne). Da hat die Feststellung, daß der P4 das durch Takt wieder ausgleicht, absolut nix zu suchen. Klar, allerdings stellt der Artikel das ganze so dar als ob der P4 ohne die "Limitierung" in der Lage wäre 9 µops parallel zu verarbeiten.

Um nochmal zusammenzufassen was an dem Artikel nicht ganz richtig ist:

1. Die niedrigere Pro-Mhz Leistung des P4 ist auf die geringere Anzahl an Funktionseinheiten sowie gewisse Limitierungen dieser zurückzuführen. Die Auslastung der einzelnen Funktionseinheiten dürfte mindestens auf dem Niveau eines Athlon wenn nicht sogar darüber liegen.

2. Die Schlussfolgerung aus dem "Unterauslastung" Abschnitt (thermisch orientiertes Design) ist demnach nicht mehr haltbar. Wenn dich interessiert was der P4 für seine Thermik tut musst du nur mal Transistorzahl und DIE-Size von einem Palomino und einem Willamette vergleichen.

3. Der folgende Abschnitt ist schlicht und einfach falsch: "In diese Strategie spielt auch die lange 20-stufige Pipeline hinein. Öfters ist zu jener zu lesen, dass sie für die hohen Taktfrequenzen notwendig sei oder sich aus diese bedingen würde. Leider fehlt zu dieser Aussage regelmässig eine Erklärung. Prinzipiell sei erst einmal gesagt, dass die Länge der Pipeline eine fast irrelevante Grösse ist. Wenn man es denn bewerten wollte, dann lässt sich mit einer 20-stufigen Pipeline eher mehr als weniger gleichzeitig erledigen."
Unter Ausschluss aller anderen Faktoren bedeutet eine doppelt lange Pipeline ca. eine doppelt so hohe erreichbare Taktfrequenz. Die Erklärung dafür ist auch ziemlich einfach:
Damit eine CPU funktioniert muss jede Pipelinestufe ihre Arbeit in einer Zeit (ich nenne sie einfach mal T-Stage) erledigen die kleiner als ein Taktzyklus (T-Taktzyklus) ist. Verdoppelt man die Anzahl der Pipelinestufen indem man die Arbeit von einer Stufe auf zwei aufteilt so halbiert sich T-Stage für jede Stufe und ebenso T-Taktzyklus, die erreichbare Frequenz verdoppelt sich.

[Muh-sagt-die-Kuh]

push it baby...

Was ist? Bekommt der Artikel eine dringend nötige Korrektur verpasst oder nicht?

[Leonidas]

aths?

[Endorphine]

Originally posted by Muh-sagt-die-Kuh
push it baby...

Was ist? Bekommt der Artikel eine dringend nötige Korrektur verpasst oder nicht? Verlangen kannst du's nicht, zumal der Aufwand beträchtlich wäre. Und wenn Leo an dem Artikel festhält oder in der Zeit lieber wichtigeres machen möchte als uralte Artikel zu korrigieren wird der Artikel wohl in der Form bestehen bleiben.

Als Leo letztens meinen alten PCI-Express Artikel bei den News verlinkte sind mir da auch wieder viele Dinge eingefallen, die ich da jetzt updaten sollte. Das Problem is aber, dass man ewig an einem Artikel schreiben kann, bis man eine Habilitation zusammen hat. Wenn man jeden Buchstaben und jede Formulierung 30x umgedreht hat sagt man sich dann mal, dass man genug nach Unstimmigkeiten, Fehlern etc. gesucht hat und den Artikel einfach rausbringt. Zumindest ist das bei mir so.

Wenn dann fundamentale Fehler in einem Artikel stecken hiesse das ja, nicht nur was zu korrigieren sondern praktisch den gesamten Artikel umzuschreiben und dann die gesamte Phase der Korrektur und des stundenlangen Feinschliffs noch einmal zu durchlaufen. Und das nur für einen jahrealten Artikel, der im Archiv vor sich hingammelt?

Ich kann Leo's Unlust da schon irgendwie nachvollziehen. Was anderes wäre es, wenn der Artikel noch richtig frisch ist und auch noch entsprechend oft gelesen wird. Wenn da dann nach der Veröffentlichung starke Konzeptfehler oder inhaltliche Fehler entdeckt werden, die sich durch den ganzen Artikel ziehen sollte man seine Arbeit fortsetzen und alles korrigieren bis 95 % aller Kritik in Verbesserungen umgesetzt sind. Oder bei schweren Fehlern den Artikel lieber offline setzen und ganz neu schreiben. Das ist bei dem Artikel nicht der Fall. Aufwand und Nutzen stehen bei dem alten Schinken einfach in nem denkbar schlechten Verhältnis zueinander...

[BlackBirdSR]

Originally posted by Muh-sagt-die-Kuh
push it baby...

Was ist? Bekommt der Artikel eine dringend nötige Korrektur verpasst oder nicht?

ich weiss nicht, ob eine Korrektur das Richtige ist.
Man sollte solche Artikel nicht im Nachhinein nach so langer Zeit ändern.
So lassen sich Wissensstand und eben auch Meinungen zu jener Zeit am besten archivieren.

Ich wäre verärgert wenn einige Artikel im Netz, jetzt plötzlich umgeändert werden, statt per Update am Ende, die Fehler anzumerken und es dabei sein zu lassen.

Natürlich kann Leo den Artikel ändern, aber irgendwie geht dann dieser Entwickungsflair verloren. Hört sich bestimmt idiotisch an, aber überleg dir nur, wenn man Geschichtsbücher immer auf den neuesten Stand bringen würde. Ist zwar Alles richtig, aber was sagt es uns dann über die Zeit zu der es geschrieben wurde?

Es würde ja schon reichen, am Ende ein Update an den Artikel zu hängen, oder einfach nicht mehr darauf zu verlinken... vorausgesetzt natürlich: man ist nicht überzeugt davon, immernoch im Recht zu sein.
Dann diskutieren wir eben weiter.

[Endorphine]

full ACK @ BlackBirdSR :)

[Muh-sagt-die-Kuh]

Originally posted by BlackBirdSR
Es würde ja schon reichen, am Ende ein Update an den Artikel zu hängen, oder einfach nicht mehr darauf zu verlinken... vorausgesetzt natürlich: man ist nicht überzeugt davon, immernoch im Recht zu sein.
Dann diskutieren wir eben weiter. OK, ein Update wäre wohl die besser Wahl. Mich persönlich stört es eben nur, dass immer noch auf diesen Artikel verlinkt wird (Prescott Artikel, eben diese News) ohne darauf hinzuweisen dass er Fehler hat, bzw von "bekannten Schwächen" gesprochen wird.

[Leonidas]

Originally posted by Endorphine
Verlangen kannst du's nicht, zumal der Aufwand beträchtlich wäre. Und wenn Leo an dem Artikel festhält oder in der Zeit lieber wichtigeres machen möchte als uralte Artikel zu korrigieren wird der Artikel wohl in der Form bestehen bleiben.





Ich denke, es wäre sinnvoller, anstatt was umzuschreiben, zu dem Artikel einen Hinweis zu geben, daß es zu diesen und jenen Punkten eine neue Meinung gibt. Alles umschreiben ist Wahnsinn.

[Leonidas]

Originally posted by BlackBirdSR


ich weiss nicht, ob eine Korrektur das Richtige ist.
Man sollte solche Artikel nicht im Nachhinein nach so langer Zeit ändern.
So lassen sich Wissensstand und eben auch Meinungen zu jener Zeit am besten archivieren.




1000% ACK. Ich überschreibe ungern Fehler, sondern mache lieber ein Update hintendran. Wenn man Fehler direkt überschreibt, tut man so, als wäre dieser nie passiert, was eine Täuschung des Lesers ist.

[aths]

Originally posted by Muh-sagt-die-Kuh
So aths, hier die versprochenen sicheren Quellen Lese ich, sobald ich den Kopf frei habe, mal genau durch.