Neuer Artikel: Doping für Prozessoren

Kollege D'Espice hat mal wieder zugeschlagen: auf insgesamt 20 Seiten beleuchtet unser aktueller Artikel alle relevanten Tricks der Chip-Designer, die Geschwindigkeit von Prozessoren in immer höhere Sphären zu treiben. Unter technischen Gesichtspunkten interessant ist dabei weniger die tumbe Erhöhung der Taktfrequenz, als vielmehr das Bemühen, pro Takt immer mehr an Leistung aus den Schaltungen zu kitzeln. Die Reise führt dabei von bekannten Features wie Branch-Prediction und Out-of-Order Execution über aktuelle Neuheiten wie HyperThreading bis hin zu zukünftigen Lösungen (OnChip-MP) und weniger bekannten Features (MOESI). Hier ein kurzer Auszug:<ul><i>Das Switch-on-event Multi-Threading (kurz SoEMT) gleicht größtenteils dem TSMT, jedoch mit der kleinen aber entscheidenden Ausnahme, dass die Rechenzeit nicht fix eingeteilt wird, sondern lediglich bei Auftreten von längeren Wartezeiten von einem Thread zum nächsten gewechselt wird. Hierbei muss jedoch der "Hauptthread" die höchste Priorität haben, bei Auftreten einer längeren Wartezeit wird zu Threads mit niedrigerer Priorität gewechselt, bis die Wartezeit für den Prozessor vorüber ist (als gutes Beispiel dient auch hier wieder ein Cache-Miss mit anschließendem Fetch der Daten aus dem Arbeitsspeicher).
Der Vorteil gegenüber TSMT ist, dass einzelne Threads höhere Prioritäten haben können als andere und somit der Programmfluss gezielt gesteuert und optimiert werden kann, wohingegen beim TSMT immer feste Rechenzeiten zugewiesen werden, nach denen der Prozessor, ungeachtet der Tatsache ob bereits eine Terminierung des aktuellen Threads vorliegt oder nicht, zum nächsten Thread schaltet.</i></ul>Wie üblich geht's hier also ziemlich zur Sache. Die obligatorische Cola samt Chips ist beim Studium dieses Artikels mal wieder schwer gefragt:<ul><li><a href="/artikel/diverses/doping/index.shtml">Doping für CPUs - Möglichkeiten der Leistungssteigerung</a></ul>Viel Vergnügen beim Lesen...

So versauern beispielsweise im Falle des Pentium 4 pro Taktzyklus sechs Recheneinheiten, da der Trace-Cache lediglich einen Durchsatz von 3 µOps/Sekunde erreicht.

Zum Vergrößern anklicken....

hmmmm... also der P4 ist ja langsam, aber sooo langsam nun auch wieder nicht

Aber nicht, das der wieder in so nem hochintelektuellen Kauderwelsch dahergeschrieben hat??

n´abend

1. wo sind eigentlich die "alten" artikel von d´espice? habe einen letztens vergebens gesucht

2. läuft rdram wirklich mit 400/533mhz? ich dachte, er liefe nur mit 100 bzw. 133, dafür aber eben qdr? der fsb des p4 dagegen läuft real mit dem angegebenen takt, dachte ich...

3. bei dem thema ram sollte unbedingt stehen, wie hoch die maximale bandbreite des jeweiligen rams ist (tabelle?). warum? um auch zu schreiben, daß rdram mit 2byte pro takt, ddr-sdram dagegen mit 64bit = 8 byte pro takt überträgt sonst haben am ende wieder alle in ihren köpfen, daß rambus auf jeden fall besser ist (533mhz vs 166mhz). desweiteren: ein hinweis auf die wichtige bedeutung verschieden hoher latenzzeiten des rams sowie die möglichkeit mit dual-channel hier nochmals was rauszukitzeln, wäre auch gut, denke ich.

4. kann man eigentlich ipc und ram-speed so trennen, wie es der artikel anzudeuten scheint? erhöht sich der ipc des hammers selbst durch die integierte nb? nicht wirklich - der prozessor wird nur besser gefüttert. vielleicht sollte man von realer ipc sprechen? mit hyper-threading erhöht intel ja den ipc. mit fsb von 400 auf 533mhz real auch - wenngleich doch der ipc des prozessors selbst gleich bleibt. aber ich bin kein kantianer und mochte das "an sich" noch nie. also: die trennung von ipc gegenüber anderen "beschleunigungsmaßnahmen" empfinde ich ein wenig als zu künstlich... weiß aber auch noch keine lösung, außer, daß man vielleicht ein wenig darauf hinweist....

5. das feinste ist: nichts selbst davon geschrieben, aber immer schon kritisieren... neee, ich freue mich über den artikel und will ja nur zu verbesserungen anregen, wenn sinnvoll...

6. so, weiter lesen - dann kommt da noch noch mehr an vernichtender kritik

edit:

7. hmm, der ipc läßt sich also berechnen, also im sinne von (anzahl durchgeführter operationen)/takt. damit wäre der ipc immer nur die real gemessenen operationen pro takt?

8. hardware data prefetech ist doch was anderes als branch prediction, oder? wenn dies so ist, ist auch klar, warum in meinen augen dieser punkt noch eingefügt werden müßte.

AMD FSB Standartmäßig @133MHz (266DDR), die neuen Prozzies (XP2700/2800,..) haben aber schon 166 (333DDR)

Der PIV hatte 100 (400 QDR), es gibt nun aber auch eine Variante mit 133 (533QDR)

Wie das beim Rambus gleich is, da gibts PC800 (100MHz/QDR/x2 ) und PC1066 (133MH/QDR/x2 )

Also ich bin zwar nicht D'Espice, der weilt noch im Großstadt-Tschungel von München, aber einstweilen werde ich die Fragen mal so weit wie möglich beantworten

Original geschrieben von Treverer
1. wo sind eigentlich die "alten" artikel von d´espice? habe einen letztens vergebens gesucht

Zum Vergrößern anklicken....

Alle Artikel, die jemals auf Planet 3DNow! erschienen sind, stehen in der Rubrik "Arikel" oben in der Navigationsleiste, darunter auch D'Espices alte Artikel

2. läuft rdram wirklich mit 400/533mhz? ich dachte, er liefe nur mit 100 bzw. 133, dafür aber eben qdr? der fsb des p4 dagegen läuft real mit dem angegebenen takt, dachte ich...

Zum Vergrößern anklicken....

Nope, RDRAM läuft real mit 400/533 MHz und überträgt pro Takt 2 Datenpakete a 16-Bit, was zu einer effektiven Taktfrequenz von 800 MHz (1600 MB/s) oder 1066 MHz (2100 MB/s) führt (Werte gerundet ) Du meinst vermutlich den FSB des P4. Der läuft in der Tat nur mit 100 bzw. 133 MHz und überträgt im QDR-Verfahren 64-Bit pro Paket

3. bei dem thema ram sollte unbedingt stehen, wie hoch die maximale bandbreite des jeweiligen rams ist (tabelle?). warum? um auch zu schreiben, daß rdram mit 2byte pro takt, ddr-sdram dagegen mit 64bit = 8 byte pro takt überträgt sonst haben am ende wieder alle in ihren köpfen, daß rambus auf jeden fall besser ist (533mhz vs 166mhz). desweiteren: ein hinweis auf die wichtige bedeutung verschieden hoher latenzzeiten des rams sowie die möglichkeit mit dual-channel hier nochmals was rauszukitzeln, wäre auch gut, denke ich.

Zum Vergrößern anklicken....

Naja, hier geht's um Effizienzsteigernde Maßnahmen an Prozessoren, nicht um Vor- und Nachteile von Rambus ggü. DDR-SDRAM In einem anderen Artikel dann

4. kann man eigentlich ipc und ram-speed so trennen, wie es der artikel anzudeuten scheint? erhöht sich der ipc des hammers selbst durch die integierte nb? nicht wirklich - der prozessor wird nur besser gefüttert. vielleicht sollte man von realer ipc sprechen? mit hyper-threading erhöht intel ja den ipc. mit fsb von 400 auf 533mhz real auch - wenngleich doch der ipc des prozessors selbst gleich bleibt. aber ich bin kein kantianer und mochte das "an sich" noch nie. also: die trennung von ipc gegenüber anderen "beschleunigungsmaßnahmen" empfinde ich ein wenig als zu künstlich... weiß aber auch noch keine lösung, außer, daß man vielleicht ein wenig darauf hinweist....

Zum Vergrößern anklicken....

Nun, es kommt immer darauf an, ob man den Core als solchen betrachtet oder das System im allgemeinen. Bei letzterem ist die Trennung natürlich nicht möglich. Dennoch existieren genügend Features im Core, die für sich nicht auf die Infrastruktur angewiesen sind und trotzdem den IPC verbessern. Im Grunde könnte man das bis zur Festplatte ausdrehnen, schließlich kann ein Prozessor auf die Swapdatei mit einer schneller HDD flotter zugreifen, wenn sich Daten, die gerade benötigt werden, darin befinden, als mit einer langsamen. Aber irgendwo muß man mal den Strich ziehen. D'Espice kann Dir sicher später noch erläuert, warum er gerade hier getrennt hat

super, jetzt weiß ich endlich, was es bei dem amd-hammer-papier mit dem "kohärenten cache" auf sich hat. danke!!!

und ist nun beim hammer mesi oder moesi protokoll geplant?

edit:

@d´espice: kennst du dieses http://www.hotchips.org/archive/hc14/program/28_AMD_Hammer_MP_HC_v8.pdf "papier"? ich hatte vor zwei wochen im forum daruf hingewiesen und mir eine diskussion erhofft. es kam nur ein "ist doch alles bekannt". fand ich nicht...

Der Zugriff auf den Arbeitsspeicher läuft bei allen heute verfügbaren Prozessoren über den Chipsatz, ergo über den Front Side Bus, kurz FSB

Zum Vergrößern anklicken....

Ehm, FSB != Speicheranbindung !!!!!!!!

Original geschrieben von Nero24
Also ich bin zwar nicht D'Espice, der weilt noch im Großstadt-Tschungel von München, aber einstweilen werde ich die Fragen mal so weit wie möglich beantworten Alle Artikel, die jemals auf Planet 3DNow! erschienen sind, stehen in der Rubrik "Arikel" oben in der Navigationsleiste, darunter auch D'Espices alte Artikel

Nope, RDRAM läuft real mit 400/533 MHz und überträgt pro Takt 2 Datenpakete a 16-Bit, was zu einer effektiven Taktfrequenz von 800 MHz (1600 MB/s) oder 1066 MHz (2100 MB/s) führt (Werte gerundet ) Du meinst vermutlich den FSB des P4. Der läuft in der Tat nur mit 100 bzw. 133 MHz und überträgt im QDR-Verfahren 64-Bit pro Paket

Naja, hier geht's um Effizienzsteigernde Maßnahmen an Prozessoren, nicht um Vor- und Nachteile von Rambus ggü. DDR-SDRAM In einem anderen Artikel dann

Nun, es kommt immer darauf an, ob man den Core als solchen betrachtet oder das System im allgemeinen. Bei letzterem ist die Trennung natürlich nicht möglich. Dennoch existieren genügend Features im Core, die für sich nicht auf die Infrastruktur angewiesen sind und trotzdem den IPC verbessern. Im Grunde könnte man das bis zur Festplatte ausdrehnen, schließlich kann ein Prozessor auf die Swapdatei mit einer schneller HDD flotter zugreifen, wenn sich Daten, die gerade benötigt werden, darin befinden, als mit einer langsamen. Aber irgendwo muß man mal den Strich ziehen. D'Espice kann Dir sicher später noch erläuert, warum er gerade hier getrennt hat

Zum Vergrößern anklicken....

na, ich bestehe ja nicht auf meine meinung aber ich gebe auch nicht gleich auf

es geht einfach um den punkt, "Erhöhung des Bus- und Speichertakts". die erhöhung bringt ja nun nichts, wenn sie mit einer minderung der bytes pro takt einhergeht. anders ausgedrückt: so wie bei einer cpu der ipc und nicht die mhz entscheidend sind, sind beim ram latenz und maximale bandbreite entscheidend. daher wäre es vielleicht besser - in meine augen - den absatz umzubenennen in "erhöhung der speicherbandbreite" (und latenz ) dies wäre eben auch getreu dem motto "mhz ist nicht alles"... nur darum ging es mir hier.

die ausführungen über hyper-threading waren super. aber sogelich stellen sich viele fragen :

1. ich meine in ct war ein hinweis, daß das ht beim p4 gegenüber dem des p4 verbessert wurde. weiß jemand mehr? der zuwachs ist nämlich teilweise doch enorm, z.b. seti falls dies stimmt, bedeutet dies nicht, daß der compiler auch verschiedenen code für p4 und xeon basteln müßte?

2. es wird - auch in diesem forum - immer wieder behauptet, ht nütze auch schon bei normalen anwendungen, die nun mal in einem multitasking-system laufen. die ausführungen über das ausschalten von ht während des laufenden betriebes bei single-thread-anwendungen, müßten dem doch widersprechen? oder wird eine single thread-anwendung gar nicht erkannt, sondern muß das os bzw. der programmierer explizit "sagen", der folgende code hat als single-prozessor-code zu gelten (was ich vermute,denn wie soll das die cpu sonst erkennen)?

3. ich meine, es war auch in der ct, in der stand, daß smt und smp optimierung nicht identisch sind. d.h. z.b., daß nicht jeder code, welcher für smp systemen optimiert wurde, gleich bei smt systemen ebenfalls profitiert. (ist ja auch klar, der zweite virtuelle prozzi ist ja kein vollwertiger). gilt dies andersherum auch, nämlich, daß smt optimierte programme auf smp systemen nicht so gut laufen? und wie ist es mit der gegenseitigen kompatibilität? ich habe den gedanken, als würde der gewinn, den man durch smp und smt haben kann, immer geringer werden, je mehr programme darauf optimiert werden, weil sie - die vielen threads der wenigen programme - dann ALLE wieder miteinander konkurrieren um cpu-zeit und ressourcen (cache, ram, bandbreite etc.). unterm strich kommt zwar dennoch ein gewinn heraus - aber die steigerungsrate sinkt. ebenso scheint es mir, als würden sich manche ipc steigerungsarten gegenseitig im wege stehen...gerade auch bei den software-maßnahmen..

Original geschrieben von Mond


Ehm, FSB != Speicheranbindung !!!!!!!!

Zum Vergrößern anklicken....

Das steht dort ja auch nicht Dort steht, daß alle Daten, die vom Speicher zum Prozessor sollen, auch über den Frontside-Bus müssen: vom Speicher über den Speicherbus zum Memory-Controller in der Northbridge und dann weiter über den Frontside-Bus zum Prozessor. Und damit hat der FSB auch seine Relevanz, was die Bandbreite Prozessor<->Speicher betrifft, die unter dem Strich herauskommt. Siehe auch http://www.planet3dnow.de/artikel/diverses/viamem/index.shtml

OK Nero, da hast Du vollkommen Recht. Aber: Für den Laien ist der Satz allerdings leicht verwirrend bzw. läßt falsche Schlußfolgerungen zu.

Original geschrieben von Treverer
die ausführungen über hyper-threading waren super. aber sogelich stellen sich viele fragen :

1. ich meine in ct war ein hinweis, daß das ht beim p4 gegenüber dem des p4 verbessert wurde. weiß jemand mehr? der zuwachs ist nämlich teilweise doch enorm, z.b. seti falls dies stimmt, bedeutet dies nicht, daß der compiler auch verschiedenen code für p4 und xeon basteln müßte?

2. es wird - auch in diesem forum - immer wieder behauptet, ht nütze auch schon bei normalen anwendungen, die nun mal in einem multitasking-system laufen. die ausführungen über das ausschalten von ht während des laufenden betriebes bei single-thread-anwendungen, müßten dem doch widersprechen? oder wird eine single thread-anwendung gar nicht erkannt, sondern muß das os bzw. der programmierer explizit "sagen", der folgende code hat als single-prozessor-code zu gelten (was ich vermute,denn wie soll das die cpu sonst erkennen)?

3. ich meine, es war auch in der ct, in der stand, daß smt und smp optimierung nicht identisch sind. d.h. z.b., daß nicht jeder code, welcher für smp systemen optimiert wurde, gleich bei smt systemen ebenfalls profitiert. (ist ja auch klar, der zweite virtuelle prozzi ist ja kein vollwertiger). gilt dies andersherum auch, nämlich, daß smt optimierte programme auf smp systemen nicht so gut laufen? und wie ist es mit der gegenseitigen kompatibilität? ich habe den gedanken, als würde der gewinn, den man durch smp und smt haben kann, immer geringer werden, je mehr programme darauf optimiert werden, weil sie - die vielen threads der wenigen programme - dann ALLE wieder miteinander konkurrieren um cpu-zeit und ressourcen (cache, ram, bandbreite etc.). unterm strich kommt zwar dennoch ein gewinn heraus - aber die steigerungsrate sinkt. ebenso scheint es mir, als würden sich manche ipc steigerungsarten gegenseitig im wege stehen...gerade auch bei den software-maßnahmen..

Zum Vergrößern anklicken....

zu 1) <ul>Ich habe keine Ahnung was mit dem C Step verbessert wurde, allerdings kann ich mir auch gut vorstellen, dass der Vorteil durch das Betriebssystem ermölicht wurde. Während HT auf den Xeons mit max. Windows XP getestet wurde, konnte man nun auf SP1 zurückgreifen, was ev. besser auf HT optimiert wurde (beispielsweise mit dem netten halt Befehl)</ul>

zu 2) <ul>Wenn bei einem System viele Hintergrundprozesse ablaufen, dann kann ein Single Threaded Programm auf einem HT System schn schneller sein, da dann der Hauptthread nicht ständig unterbrochen wird, sondern diese andere Prozesse auf dem zweiten log. Prozessor abgearbeitet werden.</ul>

zu 3) <ul>Eine auf SMP optimierte Anwendung bedeutet nicht automatisch, dass diese auch auf einem SMT System schneller läuft. Dies ist der Fall, wenn beide Threads auf die gleichen Resourcen zugreifen, beispielsweise wenn beide die FPU ständig gleichzeitig voll belasten würden. Bei Seti scheint die FPU durch einen Thread noch nicht voll belastet zu sein, sodass ein zweiter Thread hier immernoch Rechenzeit nutzen kann. (Wahrscheinlich während den vielen Speicheranfragen)</ul>

So ich hoffe, ich hab jetzt keinen Mist verzapft

Edit: Ich meine gelesen zu haben, dass auch die Opterons M<b>O</b>ESI nutzen

zitat: "Der L1 Trace Cache ist der Ersatz für den ursprünglich L1 Instruction Cache genannten Teil der L1 Cache Struktur. Im Gegensatz zu diesem, speichert der Trace Cache jedoch die bereits decodierten µOps ab. Prinzipiell ein hervorragendes Vorgehen, jedoch aufgrund der kleinen Größe des L1 Trace Cache (Intel spricht von 12.000 Einträgen, was etwa 8 KB entspricht; zum Vergleich: Der AMD Athlon XP hat 64KB L1 Code Cache) stark ausgebremst. Bei zwei logischen Prozessoren sieht die Situation noch deutlich drastischer aus, schließlich stehen hier jedem logischen Prozessor nur noch 6.000 Speicherplätze für µOps im wichtigsten aller Caches zu. Jeder der logischen Prozessoren verfügt über einen eigenen, vom anderen unabhängigen Zeiger in den Trace Cache, so dass Konflikte von Haus aus vermieden werden."

wenn einer cpu tatsächlich nur noch der halbe l1 trace cache zur verfügung steht, dann müßte eine anwendung, der man eine cpu fest zuteilt, ja voll einbrechen gegenüber einem p4 ohne ht. kann es nicht sein, daß der l1 trace cache doch anders (irgendwie dynamisch eben) zugeteilt wird?

p.s.: noch ein link um thema: http://arstechnica.com/paedia/h/hyperthreading/hyperthreading-1.html

Der L2 Cache des P4 ist ja nicht gerade langsam, ich meine, dass der nur 9 Takte Latenz hat, gut dann dürfte das noch ein paar Takte zum dekodieren brauchen, bis man die Befehle, die im L1 waren, wieder drin hat.
Alledings musst du überlegen, wieviel Zeit man verliert, wenn man von einem Thread auf den einen Hintergrundthread wechselt und wieder zurück zum Hauptthread. Dank Register Renaming gelingt heute das bereitstellen der Register schneller als früher, allerdings müssen die Befehle genauso vom RAM über den L2 in den Trace Cache, ich könnte mir gut vorstellen, dass man vor dem Threadwechsel noch die Pipe flushen muss (<b>@Nero oder D'Espice</b>: liege ich da richtig?)--> 20+x Takte Verlust mal 2.
Effektiv wird man wohl mehr Zeit verlieren, wenn man den ganzen Prozessor auf den einen anderen Thread umstellt, als wenn man nur Teilbereiche übergibt.

wärs da ned fast naheliegend das man den trace cache größer macht ? also mit anderen worten zb 64kb groß aber dort gleich dekodiert abspeichert ? oder würde das nichts bringen ...
könnte man das dem athlon "beibringen" ?

mfg eaglo

Ein größerer Cache heißt AFAIK auch immer, dass es schwieriger ist diesen schnell zu betreiben. Vergrößert sich dadurch auch die Latenz, dann wirkt man dem Prizip des Trace Cache eigentlich voll entgegen. Der Trace Cache soll die Latenzen verkürzen, ist der Cache nun ein paar Takte langsamer, dann ist dieser Vorteil schon wieder hinüber.
IMHO braucht ein schneller Cache auch eine recht große Diefläche (im Gegensatz zum langsamen), sprich der P4 würde extrem wachsen und müsste auch entsprechen umdesigned werden.

Das Trace Cache Design müsste eigentlich auch beim Athlon gehen, vielleicht kommts ja auch irgendwann. Chip-Architect hat in einem spekulativen Artikel über mögliche Verbesserungen im K8 (Anfang Oktober 2001) von einem ähnlichen Ansatz berichtet. Demnach wäre ein Level 0 Cache zur Diskussion gestanden, der zwar extrem klein sein sollte, dafür aber auch extrem schnell. Vielleicht gibts ihn ja im K9.

Ich bin immernoch nicht mir der Aussage zufrieden dass beim P4 die Funktionseinheiten versauern weil der Trace Cache nur 3µOps/Takt liefern kann.

viele Befehle dauern mehr als einen Takt, in dieser Zeit können die Scheduler mit 3µOps / Takt aufgefüllt werden...
DAzu kommt dass niemals alle 6 FUnktionseinheiten ausgelastet werden.. ein Durchschnitt von 4 ist schon sehr gut, und da käme der Trace Cache wirklich gut weg wären alle Befehle in 1 Takt vollzogen.

Und es wäre ja nicht so, dass dem Athlon das gleiche Problem nicht auch heimsuchen würde. Gerade der hat stark damit zu kämpfen dass nicht genug Befehle und Daten im Backend ankommen, die sich auf die Funktionseinheiten verteilen lassen.

So, nun bin ich aus dem Großstadtjungel München wieder aufgetaucht, nach einem langen und schlauchenden Tag... und da bisher alle Fragen soweit ich sehen kann kompetent beantwortet wurden, werde ich nicht zu allen nochmal meinen Senf ablassen

Original geschrieben von Treverer
zitat: "Der L1 Trace Cache ist der Ersatz für den ursprünglich L1 Instruction Cache genannten Teil der L1 Cache Struktur. Im Gegensatz zu diesem, speichert der Trace Cache jedoch die bereits decodierten µOps ab. Prinzipiell ein hervorragendes Vorgehen, jedoch aufgrund der kleinen Größe des L1 Trace Cache (Intel spricht von 12.000 Einträgen, was etwa 8 KB entspricht; zum Vergleich: Der AMD Athlon XP hat 64KB L1 Code Cache) stark ausgebremst. Bei zwei logischen Prozessoren sieht die Situation noch deutlich drastischer aus, schließlich stehen hier jedem logischen Prozessor nur noch 6.000 Speicherplätze für µOps im wichtigsten aller Caches zu. Jeder der logischen Prozessoren verfügt über einen eigenen, vom anderen unabhängigen Zeiger in den Trace Cache, so dass Konflikte von Haus aus vermieden werden."

wenn einer cpu tatsächlich nur noch der halbe l1 trace cache zur verfügung steht, dann müßte eine anwendung, der man eine cpu fest zuteilt, ja voll einbrechen gegenüber einem p4 ohne ht. kann es nicht sein, daß der l1 trace cache doch anders (irgendwie dynamisch eben) zugeteilt wird?

p.s.: noch ein link um thema: http://arstechnica.com/paedia/h/hyperthreading/hyperthreading-1.html

Zum Vergrößern anklicken....

Es ist in der Tat so, wie in meinem Artikel beschrieben. Ich habe die Informationen direkt aus den Technischen Datasheets von Intel zur Hyper-Threading Technologie entnommen,
Der L1 Trace Cache steht jedem Prozessor lediglich exklusiv zur Verfügung, was bedeutet dass jeder logische Prozessor lediglich über den halben Cache sowie die halbe Bandbreite verfügen kann. Der logische Prozessor 0 kann nicht auf die Daten des logischen Prozessors 1 zurückgreifen und umgekehrt.

Die Leistung bricht im MT-Betrieb nicht ein, da ja an zwei Threads parallel gearbeitet wird und die Ressourcen effektiv somit besser ausgenutzt sind. Sollte jedoch im ST-Mode ebenfalls nur der halbe Cache zur Verfügung stehen, so würde die Leistung dramatisch einbrechen.

Original geschrieben von BlackBirdSR
Ich bin immernoch nicht mir der Aussage zufrieden dass beim P4 die Funktionseinheiten versauern weil der Trace Cache nur 3µOps/Takt liefern kann.

viele Befehle dauern mehr als einen Takt, in dieser Zeit können die Scheduler mit 3µOps / Takt aufgefüllt werden...
DAzu kommt dass niemals alle 6 FUnktionseinheiten ausgelastet werden.. ein Durchschnitt von 4 ist schon sehr gut, und da käme der Trace Cache wirklich gut weg wären alle Befehle in 1 Takt vollzogen.

Und es wäre ja nicht so, dass dem Athlon das gleiche Problem nicht auch heimsuchen würde. Gerade der hat stark damit zu kämpfen dass nicht genug Befehle und Daten im Backend ankommen, die sich auf die Funktionseinheiten verteilen lassen.

Zum Vergrößern anklicken....

Prinzipiell hast du Recht, auf diesen Umstand habe ich im Artikel ja auch hingewiesen. Es ist jedoch so, dass der Pentium 4 deutlich leistungsfähiger wäre, würde der Trace Cache schneller laufen und eine höhere Bandbreite haben.

Und ich bleibe bei meiner Aussage, dass der Trace Cache speziell für den HT-Betrieb deutlich zu langsam ist.

Original geschrieben von KingInge2000
Aber nicht, das der wieder in so nem hochintelektuellen Kauderwelsch dahergeschrieben hat??

Zum Vergrößern anklicken....

Ich hab mir wirklich und sehr ernsthaft größte Mühe gegeben, diese komplexen Sachverhalten möglichst so darzustellen, dass auch wirklich jeder mit gewissen PC Grundkenntnissen sie verstehen kann... ich hoffe es ist gelungen, aber selber kann man so etwas niemals beurteilen, weshalb ich ja auf euer Feedback angewiesen bin.

Original geschrieben von Treverer
n´abend

1. wo sind eigentlich die "alten" artikel von d´espice? habe einen letztens vergebens gesucht

...

8. hardware data prefetech ist doch was anderes als branch prediction, oder? wenn dies so ist, ist auch klar, warum in meinen augen dieser punkt noch eingefügt werden müßte.

Zum Vergrößern anklicken....

1. Alle meine Artikel, die hier auf Planet 3DNow! erschienen sind, sind auch hier über das Artikelarchiv zu finden. Desweiteren gibt es noch einige ältere Artikel von mir auf www.taktsucht.de.
Einen vollständigen Index aller meiner Publikationen (von urururalt bis heute) wird demnächst in der Review/Article - Sektion auf www.ocparadise.de zu finden sein, kann sich allerdings noch ein paar Tage hinziehen. Wenn es soweit ist, werde ich dir per PN oder E-Mail Bescheid geben.

4. Die IPC erhöht sich in der Tat, aber ich denke du hast die Sache mittlerweile durchblickt

8. Ja, das ist absolut korrekt. Data Prefetch ist jedoch im Artikel erwähnt, wenn auch nicht als eigene prozessorinterne Logik sondern als Technik von Server-Anwendungen.

Original geschrieben von eaglo
wärs da ned fast naheliegend das man den trace cache größer macht ? also mit anderen worten zb 64kb groß aber dort gleich dekodiert abspeichert ? oder würde das nichts bringen ...
könnte man das dem athlon "beibringen" ?

mfg eaglo

Zum Vergrößern anklicken....

Ja, in der Tat würde es enorm viel bringen, wenn man die Kapazität des L1 Trace Caches erhöhen würde. Doch ist es, wie mtb][sledgehammer schon sagte eine Frage der DIE-Größe, Wärmeverbrauch und diverser anderer Faktoren, wie eben auch der Zugriffsgeschwindigkeit.

Wobei ich in diesem Punkt allerdings nicht zu 100% mit ihm übereinstimme. Der Trace Cache wäre auch bei höherer Kapazität noch schneller als ein gewöhnlicher L1 Cache (zumindest im Gesamtkonzept betrachtet), da die bereits decodierten µOps gespeichert werden und im Falle einer Schleife wiederverwendet werden können. Solange die Bandbreite des L1 Trace Cache nicht signifikant unter der eines normalen L1 Instruction Cache liegt, braucht man sich keinerlei Gedanken zu machen.

Zum Cache habe ich grad noch ein Bildchen gesucht:
Das ist zwar ein Xeon MP mit 2MB L3 Cache (rechte Drittel) aber das ist im Prinzip jetzt mal egal. Schön ist, dass der Trace Cache markiert erkennbar ist (der uniforme Bereich unterhalb des Trace Cache Fill Buffer). Der Bereich ist nicht gerade klein, ich würde sagen annähernd so groß wie der halbe L2. Wollte man den Trace Cache i dieser Form verachtfachen (ensprechend 64 KB) würde der Die wie leicht zu erkennen ist förmlich explodieren.

Original geschrieben von D'Espice
So, nun bin ich aus dem Großstadtjungel München wieder aufgetaucht, nach einem langen und schlauchenden Tag... und da bisher alle Fragen soweit ich sehen kann kompetent beantwortet wurden, werde ich nicht zu allen nochmal meinen Senf ablassen


Es ist in der Tat so, wie in meinem Artikel beschrieben. Ich habe die Informationen direkt aus den Technischen Datasheets von Intel zur Hyper-Threading Technologie entnommen,
Der L1 Trace Cache steht jedem Prozessor lediglich exklusiv zur Verfügung, was bedeutet dass jeder logische Prozessor lediglich über den halben Cache sowie die halbe Bandbreite verfügen kann. Der logische Prozessor 0 kann nicht auf die Daten des logischen Prozessors 1 zurückgreifen und umgekehrt.

Die Leistung bricht im MT-Betrieb nicht ein, da ja an zwei Threads parallel gearbeitet wird und die Ressourcen effektiv somit besser ausgenutzt sind. Sollte jedoch im ST-Mode ebenfalls nur der halbe Cache zur Verfügung stehen, so würde die Leistung dramatisch einbrechen.

Zum Vergrößern anklicken....

also erstmal muß ich dazu sagen: daß ist ja schön doof. '8{ spätestens hier sollte tatsächlich der trace cache vergrößert werden. ne schlaue lösung wäre doch - davon ausgehend, daß der cache-speicher auch linear angesprochen wird - einfach einen zeiger auf die "trennstelle" des caches, welche variabel/dynamisch ist. d.h. abhängig vom bedarf wird mal der einen mal der anderen cpu ein größerer anteil des caches zu verfügung gestellt. vielleicht ruf ich mal bei intel an

aber das jede cpu nur über die halbe bandbreite zum tace cache verfügt, glaube ich nicht. zumindest hier wird doch die vorhandene bandbreite je nach bedarf einer cpu zum "füttern" zur verfügung gestellt und eben nicht von vornherein festgelegt.

morgen dann hoffentlich mehr, will wissen wissen wissen....