Warum hat der Nothwood ...

[Radeonator]

... nur noch 8K 1st lv cache???

[zeckensack]

Weil die Intel-Ingenieure alle besoffen waren?

[Ikon]

... besoffen, zugekifft und vollkommen verrückt geworden. Einen anderen Grund kann es nicht geben.

[turboschlumpf]

scheiss doppelposts.

[turboschlumpf]

damit manche deppen blöde sprüche bringen können?

[Ikon]

HeHe, hast du eine bessere Erklärung? Ist immerhin einer der größten Designflaws beim P4 ...

[zeckensack]

Vielleicht haben die bei Intel auch einfach 'aus Versehen' alle fähigen Ingenieure gefeuert und die Marketingabteilung weiter am Chip basteln lassen *eg*

[grandmasterB]

Wegen dem Trace-Cach wird doch der L1 Cache massiv entlastet und spielt keine so große Rolle mehr. Außerdem ist der L2 Cache viel schneller angebunden als beim Athlon.
Wenn der Trace-Cache noch n Stück größer wäre als diese umgerechnet ca. 24kB (kA wieviele Micro-Ops das sind) würde der L1 Cache sowieso nur noch eine untergeordnete Rolle spielen. Außerdem kann man durch iese geringe Größe die Latenzen sehr niedrig halten.
Aber wenigstens so 32kB hätten se dem L1 schon spendieren können, da stimm ich euch zu. Aber wenn man nen Prozessor um ein paar Jahre vorzieht kann man eben nicht alles verwirklichen was man so geplant hat.
Aber mit dem Prescott scheint sich einiges zu tun. Aber da es momentan sowieso nen dicken Performance Overhead der Prozessoren für im Alltag benötigte Rechenleistung gibt, is mir das ganze eigentlich Wurscht. Ich bin mit meim XP 1,46 Ghz zufrieden.

[zeckensack]

Originally posted by grandmasterB
Wegen dem Trace-Cach wird doch der L1 Cache massiv entlastet und spielt keine so große Rolle mehr.Nein. Der Tracecache speichert nur Befehle, er kann den L1 Daten-Cache garnicht entlasten.

Diese Trennung gibt's auch bei allen anderen modernen Prozessoren (seit dem Pentium 1 bzw AMD K5, bei VIA/Cyrix AFAIK erst seit dem C3). Es ist aber gängige Praxis, für beides die gleiche Menge bereitzustellen. IMO wäre es sinnvoller, wenn man überhaupt einen kleiner machen will, dann den I-Cache, wobei dieser ein gesundes Maß (ca 16k, 32k sind besser, 64k wie bei AMD sind fast schon Overkill) auch nicht unterschreiten sollte.

[HOT]

Es gsht denk ich mal um die Geschwindigkeit. Wenn Intel mehr L1 Cache genommen hätte, hätte man vielleicht für einen unangenehmen Hotspot gesorgt. (ist natürlich reine Spekulation meinerseits)

[Unreal Soldier]

@zeckensack
tststs....and u are a moderator....tststs

MFG
Unreal Soldier

[Anárion]

Originally posted by Unreal Soldier
@zeckensack
tststs....and u are a moderator....tststs

MFG
Unreal Soldier

Du würdest niemals einen besseren abgeben! *eg*

[StefanV]

Originally posted by Unreal Soldier
@zeckensack
tststs....and u are a moderator....tststs

MFG
Unreal Soldier

warum??

Alles, was er in diesem Thread gesagt hat, dem kann ich nur zustimmen...

Und dabei hab ich selbst 2 P4s...

[Ikon]

Originally posted by Stefan Payne
Und dabei hab ich selbst 2 P4s...

HoHo, der erste Intel-User in diesem Thread, der es ertragen kann, dass der P4 auch Schwächen hat :lol:

@zeckensack
full Ack., besser könnte ich es auch nicht erklären.

[StefanV]

Originally posted by Ikon


HoHo, der erste Intel-User in diesem Thread, der es ertragen kann, dass der P4 auch Schwächen hat :lol:


Red bitte nicht weiter, sonst kommen mir noch die Tränen ;)

Wenn ich dann solche Dinge, wie zu lahmer Decoder und Trace Cache höre, dann können einem auch die Tränen kommen...

Der P4 ist halt einfach 'nur' auf hohe Taktraten ausgelegt, dazu wurde er noch in Eile fertiggestellt...

PS: ich sehe mich eigentlich als AMD'ler mit 'nem P4 ;)

[BlackBirdSR]

Originally posted by Stefan Payne


Red bitte nicht weiter, sonst kommen mir noch die Tränen ;)

Wenn ich dann solche Dinge, wie zu lahmer Decoder und Trace Cache höre, dann können einem auch die Tränen kommen...

Der P4 ist halt einfach 'nur' auf hohe Taktraten ausgelegt, dazu wurde er noch in Eile fertiggestellt...

PS: ich sehe mich eigentlich als AMD'ler mit 'nem P4 ;)

zu schade das einige noch immernich verstehen wollen, das ein Design das für hohe Taktraten ausgelegt is nicht einfach aus dem ärmel geschüttelt wird sondern massive innovation verlangt..

wenn ich lahme decoder und das Wort Trace Cache höre, fang ich an zu leuchten weil Intel zumindest da bewiesen hat das man nicht an traditionelles gebunden ist, und noch einiges an performance rausholen kann.

natürlich darf sich jeder weiter stark dafür machen den Trace Cache zu entfernen, mehr decoder ein zubauen die dann leider effektiv nicht mehr Befehle liefern aber es dann plötzlich weit mehr als 19 Srafzyklen bei fehlbranches gibt.

lasst uns doch den L1 DCache so groß machen dass man die Zugriffslatenz erhöhen muss um den L1 und L2 Cache bei diesen Takten noch zu synchronisieren..

und DANN: lasst uns mal sehen ob Intels P4 oder eurer schneller ist ;)

[MGeee]

IMO ist mir Pro/Mhz Leistung lieber wie Brute-Force-Mhz ala P4. Ab irgendeiner hohen Freq. (fürher lag die Grenze bei 10Ghz) gehen die Signale sowieso in rauschen über, und mit Intels Takterei werden wir´s wohl bald erleben ... ergo lieber mehr Pro/Mhz als viel Mhz!

[sun-man]

Hi,
also ich weiß wirklich nicht warum es immer Streitereien geben muß.
Selbst wenn der der Inhell auf MhZ ausgelegt ist, warum sollte das schlecht sein ?
Ich hab nen 1800+ gegen nen 1.6'er Northwood gewechselt und bin absolut zufrieden. Sicherlich kann der 1.6'er NICHt mit nem gleichgetakteten XP mithalten....da guckt der nur blöd hinterher.
ABER....ich bin jetzt bei +900MhZ angelangt (DDRAM Bord) und bin sicherlich sehr zufrieden damit. Noch dazu wird der Inhell dabei noch nichtmal annähernd so warm wie mein alten AMD. Also kann ne MhZ-Konstruktion nicht wirklich was schlechtes sein. Mit dem AMD bzw. dessen Bord konnte ich von 155MhZ FSB nur träumen (166 sind möglich, aber der Speicher kackt ab).

...und selbst wenn der XP noch immer mehr Leistung hat, so frag ich Euch was lustiger ist:
- Brücken malen um ein paar MhZ mit Monsterkühlung rauszuholen ?
- FSB hochsetzen und 900MhZ rausholen ?
Vermutlich hab ich Glück gehabt mit dem Proz, aber das reine Feeling da wirklich stabile 900MhZ rauszuholen ist einfach geiler als Multiplikatoren zu ändern um 100 oder 200MhZ rauszukitzeln.
Was denn nun schwieriger ist, bleibt Euch überlassen.

Naja, letztendlich ist nur eins wichtig :)
Der AMD ging geil, der Intel geht geil und ich brauch weder die MhZ bei AMD noch bei Intel wirklich um zu überleben.

MFG

[GloomY]

Um Mal auf die Ausgangsfrage zurückzukommen:

Der L1 Cache hat (etwa) eine Hit-Rate von 80% (+/- einige Prozent, je nach Prozessor, beim Athlon sicher mehr). Bei einem Cache-Miss (die restlichen 20%) kommt der L2 Cache zum Einsatz. Dieser hat etwa eine Hit-Rate von 60-70% (wieder je nach Prozessor).
Wenn die Daten wieder nicht im Cache zu finden sind, muss auf den Hauptspeicher zugegriffen werden. Das ist in etwa 1% der Fälle notwendig.
Aus obigen Überlegungen ergeben sich einige Fakten:

(a) Der L1 Cache wird viel häufiger benutzt, als der L2 Cache. Dementsprechend ist es sinnvoll, die L1 Latenz möglichst gering zu halten.

(b) Der Zugriff auf den L2 erfolgt erst, nachdem ein L1 Miss erfolgt ist (Ausnahme: Itanium, dort erfolgt L1 und L2 Zugriff gleichzeitig).
Daraus ergibt sich, dass die Latenz des L2 die von L1+L2 ist.
Eine niedrige L1 Latenz macht sich also auch bei der Latenz des L2 "nützlich".

(c) Es ist unmöglich einen großen Cache mit kleiner Latenz zu bauen. Man muss sich entscheiden. Entweder mit niedriger Latenz, dafür aber relativ klein, oder groß und hohe Latenz.

-> Intel hat den ersten Weg gewählt und den L1 klein, aber dafür schnell (2 Takte Latenz, Athlon hat mit 3 Takten 50% höhere Latenz).
die Hitrate ist dafür zwar längst nicht so hoch, dafür gibt es aber glücklicherweise den L2, der eine große Bandbreite (256 Bit Anbindung) und eine hohe Hitrate besitzt.

Die Idee eines kleinen schnellen L1 ist weder neu, noch von Intel, sondern wurde schon früher beim RISE mp6 verwendet. Dieser hatte eine phänomenal niedrige L1 Latenz von einem(!) Takt. Dafür war der Cache aber auch nur 16 kb groß.
Das ganze hätte damals der Renner werden können, ja wenn da nicht das Problem gewesen wäre, dass der mp6 keinen on-die L2 hatte. Somit musste bei einem L1 Miss (der relativ oft vorkommt) auf den langsamen on-Board L2 Cache zugreifen, der auch nur im Bustakt lief. Kein Wunder, dass dass Teil so gut mit dem Bustakt skalierte...

Um mal wieder zu Thema zurück zu kommen:
Ich bin mir nicht sicher, aber AFAIK verwendet Intel beim P4 ein inklusives Cache Design. Somit befinden sich die Daten des L1 auch im L2 wieder. Die effektive L2 Größe ist somit L2 minus L1.
Ein großer L1 bringt in dieser Hinsicht auch nicht viel...

[Ikon]

Das Argument mit der kurzen Latenz des L1-Cache / dessen kleiner Große ist aber auf den P4 nicht gut anzuwenden, wenn wir uns mal das Verhältnis aus Latenz und Größe des L1-Caches ansehen:

Cachegröße / Latenzzeit -> Verhältnis
Rise mp6: 16KB / 1T -> 16
Athlon: 128KB / 3T -> 42,67
P4: 8KB / 2T -> 4

Wie man sieht bietet der P4 auch hier das schlechteste Verhältnis. Die L1-Latenzzeit ist zwar um ein Drittel (1T) niedriger als beim Athlon, dafür hat dieser aber einen 16mal größeren L1-Cache -> dadurch erhöht sich die Hit-Wahrscheinlichkeit um ein Vielfaches gegenüber dem P4. Ausserdem nutzt der Athlon bekanntlich exklusive Caches (L1 und L2 sowie beim Athlon XP die L1- und L2-TLBs), womit er auf insgesamt 384KB kommt (wobei der L2-Cache "nur" mit einen 64Bit-Bus angebunden ist).
Die Idee von Intel mit "kleiner Cache -> kleine Latenzen" ist im Prinzip ein gute Sache, das Problem beim P4 ist einfach, dass der L1-Cache nicht einfach nur "klein" sondern "zu klein" ist. Dadurch wird die L1-Hitrate ins Bodenlose gedrückt -> dies erklärt auch warum der Northwood überproportional stark an Speed zulegt mit seinem größeren L2-Cache (gegenüber dem Willamette). Die Prozentzahlen der Hit-/Miss-Wahrscheinlichkeit, die du angibst, mögen ja auf den Athlon und andere CPUs durchaus zutreffen, aber beim P4 mit 80% Hitrate ins Rennen zu gehen halte ich für reichlichst übertrieben.
Mein Verbesserungsvorschlag für das Cache-Design des P4 wäre:

- exklusive Caches
- größerer L1-Cache (zumindest 16 oder 32KB)

[HOT]

Hierbei sei noch erwähnt, dass der Cache des Athlon anders arbeitet, als der des P4. der Athlon ist nicht so Abhängig von niedrigen Latenzen, weil der L2 Cache exclusive ist und unabhängig vom L1 angesprochen wird. Hier bringt mehr Cache mehr; ich halte den 128kb L1 Cache nicht für Overkill. Man spart eine Menge Speicherzugriffe mit grösseren Caches; der Athlon braucht lange nicht so schnellen Speicher wie der P4 um ähnliche Performance zu erreichen. Auch das gefällt mir besser am Athlon.
Mit dam Hammer treibt AMD das Konzept auf die Spitze; der braucht noch weniger Speicherbandbreite und Takt um diese gewaltige Leistungen zu erzeilen.
Hier sehe ich auch das grosse Problem beim Prescott: wenn Intel es nicht schafft, die Speicherabhängigkeit des P4 in den Griff zu bekommen, hat der Nachfolger das Nachsehen und braucht teuren RAMBUS oder DDR/II Speicher um mit dem Hammer und DDR333 Speicher mithalten zu können.

[StefanV]

Originally posted by Ikon
Das Argument mit der kurzen Latenz des L1-Cache / dessen kleiner Große ist aber auf den P4 nicht gut anzuwenden, wenn wir uns mal das Verhältnis aus Latenz und Größe des L1-Caches ansehen:

Cachegröße / Latenzzeit -> Verhältnis
Rise mp6: 16KB / 1T -> 16
Athlon: 128KB / 3T -> 42,67
P4: 8KB / 2T -> 4

Wie man sieht bietet der P4 auch hier das schlechteste Verhältnis. Die L1-Latenzzeit ist zwar um ein Drittel (1T) niedriger als beim Athlon, dafür hat dieser aber einen 16mal größeren L1-Cache -> dadurch erhöht sich die Hit-Wahrscheinlichkeit um ein Vielfaches gegenüber dem P4. Ausserdem nutzt der Athlon bekanntlich exklusive Caches (L1 und L2 sowie beim Athlon XP die L1- und L2-TLBs), womit er auf insgesamt 384KB kommt (wobei der L2-Cache "nur" mit einen 64Bit-Bus angebunden ist).
Die Idee von Intel mit "kleiner Cache -> kleine Latenzen" ist im Prinzip ein gute Sache, das Problem beim P4 ist einfach, dass der L1-Cache nicht einfach nur "klein" sondern "zu klein" ist. Dadurch wird die L1-Hitrate ins Bodenlose gedrückt -> dies erklärt auch warum der Northwood überproportional stark an Speed zulegt mit seinem größeren L2-Cache (gegenüber dem Willamette). Die Prozentzahlen der Hit-/Miss-Wahrscheinlichkeit, die du angibst, mögen ja auf den Athlon und andere CPUs durchaus zutreffen, aber beim P4 mit 80% Hitrate ins Rennen zu gehen halte ich für reichlichst übertrieben.
Mein Verbesserungsvorschlag für das Cache-Design des P4 wäre:

- exklusive Caches
- größerer L1-Cache (zumindest 16 oder 32KB)

Du kannst auch noch weiter ausholen:

Deswegen ist der P4 auch so Bandbreitenhungrig, deswegen verliert er so viel bei SDR-SDRAM und profitiert von Dual Chan Interfaces.

Fazit:

Die Caches des P4s sind scheiße, da zu klein/zu lahm...

Der P4 hätte viel schneller sein können, dann hätte Intel aber auch Probleme mit Hot Spots, noch größerem DIE und so weiter (der P4 kam IMO 1-2 Jahre zu früh)...

[BlackBirdSR]

der P4 ist unter anderem so Bandbreiten hungrig weil er im Gegensatz zum Athlon 128Bit breite Cache lines hat, also viel größere Blöcke aus dem Speicher ausließt ob er sie nun braucht oder nicht

d.h er geht sehr verschwenderisch mit Speicher um.. allerdings hilft das die Latenzen zu maskieren was bei RDR Speicher ganz nützlich ist.




Zum Athlon..
er mag nicht so Bandbreitenabhängig sein, allerdings kämpft auch der K7 mit brachliegenden Funktionseinheiten, gerade die FPU kann oft nicht schnell genug gefüttert werden

[turboschlumpf]

full ack@ gloomy und blackbirdsr

Fazit:

Die Caches des P4s sind scheiße, da zu klein/zu lahm...


dass jetzt von irgendwem wieder so eine hammerscheisse kommt war ja klar!


fakt ist amd und intel verfolgen 2 grundverschiedene ansätze bei der architektur ihrer cpus.
über die vor- und nachteile eines konzepts zu diskutieren ist ja ok,
solange diese diskussion sachlich und fair abläuft.
aber es gibt auch immer wieder irgendwelche deppen die ein produkt schlecht machen wollen.
entweder weil eben dieses produkt neue, andere möglichkeiten der realisierung einer architektur aufgreift oder weil diejenigen einfach nicht die vorteile dieses lösungsweges verstehen. [edit] (natürlich gibt es auch nachteile, jede architektur hat nachteile, aber wenn die entwickler abwägen und sich für die eine variante entscheiden wird das schon seine gründe haben)
denn will man etwas schlecht machen findet man immer irgendwelche gründe.
sollte man nicht aber die leistung vergleichen die letztendlich herauskommt wenn man alle vor- und nachteile eines prozessors berücksichtigt?
und hier auch nur das was aktuell erhältlich ist?
denn eigentlich zählt auch nur das.
und von mir aus könnt ihr euch in ein ein paar monaten mit einem vielleicht sündhaft teuren hammer schlapplachen über intel,
aber dann braucht ihr euch auch nicht wundern wenn intel zurückschlägt mit prescott.
und dann braucht ihr nichtmehr versuchen euch mit irgend welchen lächerlichen argumenten oder schlechtmachversuchen herauszureden.

wenn Intel es nicht schafft, die Speicherabhängigkeit des P4 in den Griff zu bekommen, hat der Nachfolger das Nachsehen und braucht teuren RAMBUS oder DDR/II Speicher um mit dem Hammer und DDR333 Speicher mithalten zu können.


oder einfach ein dual channel pc333 interface.
und bis dahin sollte sich pc333 eigentlich druchgesetzt haben und zu vernünftigen preisen erhältlich sein.

[Ikon]

@Turboschlumpf
War ja klar, dass sowas von dir kommt - schau doch wieder vorbei, wenn du was Sinnvolles zur Diskussion beitragen kannst. In diesem Thread geht es um die Schwächen der Cache-Architektur des P4 und nicht um dein übliches "P4 ist viel besser als Athlon"-Geflame.

EDIT: Und das letzte Posting von Stefan Payne ist inhaltlich durchaus korrekt wenn auch etwas krass formuliert.

[Power]

Originally posted by Radeonator
... nur noch 8K 1st lv cache???

Er hatte nie mehr - Frage richtig formulieren will gelernt sein.

[turboschlumpf]

@ ikon
hast du irgendwelche komplexe?
du scheinst in ein posting alles hineinkommentieren zu können was du gerade willst.

auch ist die aussage es geht um die schwächen der p4 architektur mal wieder typisch.
hast du irgend welche beweise dass die cache architektur des p4 schlechter ist?

sie ist anderst, und das ganze prozessordesign ist anderst.
und nur weil das dir nicht passt, oder weil du es nicht verstehst, oder weil sie neu ist ... (siehe mein letztes posting) unterstellst du sie sei schlecht.

und auch wenn einige sachen schlechter sein mögen, sie ermöglichen eine höhere taktung und so eine bessere leistung der cpu.
denn was bringt mehr?
dass eine operation pro takt mehr ausgeführt werden könnte oder dass die cpu xxx mhz höher getaktet werden kann?

und ich bin gerade am überlegen ob es schon einen thread gab in dem amd (vorsätzlich) schlecht gemacht werden sollte wegen der architektur ihres prozessors.

ach ja, und wenn man es so sieht wie du könnte ich durchaus auch sagen:
"ein athlon ist scheisse da er viel zu heiss wird/zu lahm ist."
wäre das dann auch richtig und nur etwas krass formuliert?

noch was:
warum wird intel immer angekreidet der p4 hätte eine so schlechte pro mhz leistung?
genauso müsste man beim athlon unter 'cons' ein "architektur ermöglicht nur ziemlich niedrige takraten im gegensatz zum p4" notieren.

ein gutes beispiel dafür wie 'parteiisch' die meisten hardwareseiten eigentlich sind.

[BlackBirdSR]

Originally posted by turboschlumpf
genauso müsste man beim athlon unter 'cons' ein "architektur ermöglicht nur ziemlich niedrige takraten im gegensatz zum p4" notieren.

ein gutes beispiel dafür wie 'parteiisch' die meisten hardwareseiten eigentlich sind.

die meisten richtig angesehenen hardware seiten die ich kenne, schreiben das auch.
auch wenn dabei dann auch steht das der K7 trotzdem weitergekommen ist als man selbst, Intel und vielleicht sogar AMD gedacht hätten.

[GloomY]

Originally posted by Ikon
Das Argument mit der kurzen Latenz des L1-Cache / dessen kleiner Große ist aber auf den P4 nicht gut anzuwenden, wenn wir uns mal das Verhältnis aus Latenz und Größe des L1-Caches ansehen:

Cachegröße / Latenzzeit -> Verhältnis
Rise mp6: 16KB / 1T -> 16
Athlon: 128KB / 3T -> 42,67
P4: 8KB / 2T -> 4
Du vergisst, dass der L1 Cache in Daten- und Code-Cache unterteilt ist (Harvard Cache Architektur).
Der P4 hat 8 kb Daten- und 12 kb Trace-Cache (was auf Grund der geringeren Größe der dekodierten µ-ops mindestens 16 kb Code-Cache mit x86 ops entspricht). Also wäre das Verhältnis beim P4

24 KB / 2T -> 12

und damit gar nicht mal so schlecht.
Originally posted by HOT
Hier sehe ich auch das grosse Problem beim Prescott: wenn Intel es nicht schafft, die Speicherabhängigkeit des P4 in den Griff zu bekommen, hat der Nachfolger das Nachsehen und braucht teuren RAMBUS oder DDR/II Speicher um mit dem Hammer und DDR333 Speicher mithalten zu können. Der Prescott wird auf Grund seiner geringen L1 Latenz von einem Takt sehr gut performen. Man darf nicht vergessen, dass der L1 mehr als fünf mal häufiger angesprochen wird als der L2 Cache.
Die Frage ist viel mehr, wie teuer es wird, ein schnelles Speicherinterface dem Prozessor bereitzustellen.
Wenn es viel kostet, dann hat AMD mit ihrer großen Hitrate einen Vorteil. Wenn es billig ist, dann ist Intel mit ihren schnellen Caches vorne.Originally posted by BlackBirdSR
der P4 ist unter anderem so Bandbreiten hungrig weil er im Gegensatz zum Athlon 128Bit breite Cache lines hat, also viel größere Blöcke aus dem Speicher ausließt ob er sie nun braucht oder nicht
Hat der Athlon XP nicht auch 128 bit breite Cache lines?
Originally posted by BlackBirdSR
d.h er geht sehr verschwenderisch mit Speicher um.. allerdings hilft das die Latenzen zu maskieren was bei RDR Speicher ganz nützlich ist.

Zum Athlon..
er mag nicht so Bandbreitenabhängig sein, allerdings kämpft auch der K7 mit brachliegenden Funktionseinheiten, gerade die FPU kann oft nicht schnell genug gefüttert werden Volle Zustimmung.

[Ikon]

Originally posted by Power
Er hatte nie mehr - Frage richtig formulieren will gelernt sein.

Wahrscheinlich bezog er sich nicht auf den Willamette, sondern auf die Vorgänger (z.B. P2/P3).

Originally posted by turboschlumpf
auch ist die aussage es geht um die schwächen der p4 architektur mal wieder typisch.
hast du irgend welche beweise dass die cache architektur des p4 schlechter ist?

Lies den Thread durch, es wurden bisher einige gute Kontra-Punkte genannt.

Originally posted by turboschlumpf
sie ist anderst, und das ganze prozessordesign ist anderst.
und nur weil das dir nicht passt, oder weil du es nicht verstehst, oder weil sie neu ist ... (siehe mein letztes posting) unterstellst du sie sei schlecht.

Du wiederholst dich mit der ohnehin unbestrittenen Aussage, dass der P4 ein anderes Design als der Athlon hat. Aber ist dies Thema dieses Threads - nope!

Originally posted by turboschlumpf
und auch wenn einige sachen schlechter sein mögen, sie ermöglichen eine höhere taktung und so eine bessere leistung der cpu.
denn was bringt mehr?
dass eine operation pro takt mehr ausgeführt werden könnte oder dass die cpu xxx mhz höher getaktet werden kann?

Ist alles bekannt - aber was hat das mit dem Thema zu tun?

Originally posted by turboschlumpf
und ich bin gerade am überlegen ob es schon einen thread gab in dem amd (vorsätzlich) schlecht gemacht werden sollte wegen der architektur ihres prozessors.

Gibt/gab es sicher. Der Athlon bietet vom Design her aber auch etwas weniger Angriffsfläche als der P4, weil zumindest Desktop-CPUs bisher immer auf Leistung pro MHz optimiert wurden und nicht gebremst um höher getaktet werden zu können.

Originally posted by turboschlumpf
ach ja, und wenn man es so sieht wie du könnte ich durchaus auch sagen:
"ein athlon ist scheisse da er viel zu heiss wird/zu lahm ist."
wäre das dann auch richtig und nur etwas krass formuliert?

Wenn du das "lahm" durch "lässt sich nicht so hoch wie der P4 takten" erstetzt, dann unterschreib' ich das.

Originally posted by turboschlumpf
warum wird intel immer angekreidet der p4 hätte eine so schlechte pro mhz leistung?

Weil er sie hat.

Originally posted by turboschlumpf
genauso müsste man beim athlon unter 'cons' ein "architektur ermöglicht nur ziemlich niedrige takraten im gegensatz zum p4" notieren.

Müsste man genaugenommen auch, wird von Hardware-Seiten aber manchmal nicht getan. Das könnte daran liegen, das der P4 eben eine gewollt schlechte Pro-MHz-Leistung hat, viele Reviewer dies aber als Schwäche/Bug verstehen.

Originally posted by GloomY
Du vergisst, dass der L1 Cache in Daten- und Code-Cache unterteilt ist (Harvard Cache Architektur).
Der P4 hat 8 kb Daten- und 12 kb Trace-Cache (was auf Grund der geringeren Größe der dekodierten µ-ops etwa 16 kb Code-Cache mit x86 ops entspricht). Also wäre das Verhältnis beim P4

24 KB / 2T -> 12

und damit gar nicht mal so schlecht.

Guter Ansatz - würde aber nur stimmen, wenn der Trace-Cache exklusiv und nicht inklusiv wäre (und AFAIK ist er inklusiv)

Originally posted by GloomY
Der Prescott wird auf Grund seiner geringen L1 Latenz von einem Takt sehr gut performen. Man darf nicht vergessen, dass der L1 mehr als fünf mal häufiger angesprochen wird als der L2 Cache.
Die Frage ist viel mehr, wie teuer es wird, ein schnelles Speicherinterface dem Prozessor bereitzustellen.
Wenn es viel kostet, dann hat AMD mit ihrer großen Hitrate einen Vorteil. Wenn es billig ist, dann ist Intel mit ihren schnellen Caches vorne.

Wieso sollte der Prescott mit seiner geringen L1-Latenz besser als der Northwood performen - wenn er keinen größeren L1-Cache hat? Sonst ist da irgendwie kein Unterschied ...
Ausserdem bin ich mir nicht sicher, ob man ein ev. sehr schnelles Speichersubsystem beim Prescott mit der sehr viel höheren L1-Hitrate beim Athlon/Hammer aufwiegen kann - sicher beeinflusst beides die Leistung, aber was genau mehr bewirken wird kann man glaube ich jetzt noch nicht sagen (v.a. spielen da noch soooviele andere Umgebungsfaktoren mit ...).

Originally posted by GloomY
Hat der Athlon XP nicht auch 128 bit breite Cache lines?

Das würde wenig Sinn machen, weil der L2-Cache nur mit 64Bit angebunden ist.

*Monsterposting* *umkipp*

[GloomY]

Originally posted by Ikon
Guter Ansatz - würde aber nur stimmen, wenn der Trace-Cache exklusiv und nicht inklusiv wäre (und AFAIK ist er inklusiv)Was hat die In-/Exklusivität damit zu tun?
Es ging um das Verhältnis von Größe und Latenz des L1 Caches. Da spielt es keine Rolle, wie und was sich im L2 befindet. Außerdem hat der mp6 auch nur ein inklusives Design. Man kann also nicht einfach beim Rise L1-Daten und L1-Code Cache zusammen zählen und es beim P4 nicht tun.
Originally posted by Ikon
Wieso sollte der Prescott mit seiner geringen L1-Latenz besser als der Northwood performen - wenn er keinen größeren L1-Cache hat? Sonst ist da irgendwie kein Unterschied ...
... weil nicht nur die Größe des Caches entscheidend ist, sondern eben auch andere Faktoren wie Latenz, Assoziativität, Schreib-Strategie, Anbindung und Taktung.
Der Prescott L1 Cache hat eine 50% geringere Latenz als die des NWs. Allein das wird für einen Performance-Schub sorgen, denn der L1 wird soooooo oft gebraucht (Ich kann mich immer nur wiederholen).
Originally posted by Ikon
Ausserdem bin ich mir nicht sicher, ob man ein ev. sehr schnelles Speichersubsystem beim Prescott mit der sehr viel höheren L1-Hitrate beim Athlon/Hammer aufwiegen kann - sicher beeinflusst beides die Leistung, aber was genau mehr bewirken wird kann man glaube ich jetzt noch nicht sagen (v.a. spielen da noch soooviele andere Umgebungsfaktoren mit ...).Denk' dran, dass letztendlich die Hitrate von L1 UND L2 bestimmen, wie oft auf den RAM zugegriffen wird. Nicht nur die Hitrate des L1...
Hier ist der P4 mit den 512 kB L2 sicher nicht schlecht ausgestattet (auch wenn er insgesamt nicht an die Hitrate der Athlon L1 und L2 Caches dran kommt).
Originally posted by Ikon
Das würde wenig Sinn machen, weil der L2-Cache nur mit 64Bit angebunden ist.Das ist richtig, allerdings sprach ich vom L1 Cache. Imho ist dort die Line Size von 64 Bit (TB) auf 128 Bit (XP) erhöht worden, wenn ich mich richtig erinnere...

[BlackBirdSR]

Originally posted by Ikon




Guter Ansatz - würde aber nur stimmen, wenn der Trace-Cache exklusiv und nicht inklusiv wäre (und AFAIK ist er inklusiv)





Wenn dann sind die L2 Caches exklusiv oder inklusiv, vom L1 Cache kann man das nicht behaupten.. (macht nix wohl einfach falsch gedreht der Satz, der Sinn kommt rüber)

Trotzdem glaube ich nicht das der L2 Cache des P4 den Trace Cache enthält.
macht auch keinen Sinn, immerhin geht im L2 Cache die Struktur des Trace Caches vollkomen verloren,
nicht umsonst werden im Trace Cache ausser dem Ordnen der Befehle noch ein zwei tricks angewandt.
und nichtzuletzt, liegt der Trace Cache innerhalb des eigentlichen Funktionscores, noch nach dem Dekoder..
es besteht keine direkte verbindung zwischen dem Trace Cache und dem L1 D-Cache bzw dem L2 Cache.

kann mich natürlich auch irren..

[GloomY]

BlackbirdSR,

der Code ist beim P4 im L1 Cache als µ-Ops gespeichert und im L2 als x86 Ops. Das ist aber egal. Denn letztendlich kommt es nicht drauf an, ob der code schon durch den Decoder durch ist, sondern, ob er doppelt in den beiden Caches drinnen ist, oder nicht.
Und das ist er beim P4 eben (imklusives Design), dadurch wird die effektive L2 Cache Größe verringert.

Allerdings möchte ich an dieser Stelle auch anmerken, dass es sowohl auch Nachteile eines exklusiven Cache-Designs gibt.
Z.B. kann es vorkommen, dass die CPU Daten benötigt, die gerade aus dem L1 rausgeschmissen wurden.
Diese kommen dann in einen speziellen Cache (bei AMD Victim-Cache genannt; nur 8 Cache-Lines à 64 Bytes groß). Dieser soll sicherstellen, dass beim Rausschmeissen keine Daten verloren gehen, wenn der L2 gerade beschäftigt ist.
Wenn sich die angeforderten Daten gerade im Victim Cache befinden, dann müssen diese erst in den L2 geschreiben werden (8 Clocks), eine Zeitspanne (4 Clocks, "Turnaround" genannt) gewartet werden und dann die Daten aus dem L2 Cache geholt werden (nochmal 8 Clocks).
Insgesamt sind das 8+4+8 = 20 Clocks, während ein normaler L2 Zugriff nur 11 Clocks braucht (L1 Zugriff von 3 Takten plus 8 beim L2).

Glücklicherweise ist der L2 beim Athlon längst nicht so beschäftigt, so dass die Daten, die aus dem L1 rausfliegen, sich nie lange im Viktim Cache befinden. Trotzdem kann es so eine Situation durchaus geben...

[Radeonator]

Originally posted by Power


Er hatte nie mehr - Frage richtig formulieren will gelernt sein.

[flamemodeon]
Sachlich diskutieren will auch gelernt sein...;)
[/flamemodeoff]

Wenn ich das richtig verstehe, hat intel also einen Notnagel produziert, der eigentlich mehr durch Bruteforce glänzt, denn durch sinvolle features.Kann man die theoretische Leistung eigentlich "einfach" mal hochrechnen???

Der große Vorteil vom Northwood, scheint ja in geringer Verlustleistung und extrem guten OC fähigkeiten zu liegen.Aber wenn es keine wirkliche Verbesserung gegeben hat und der L1 nur so klein ist, um möglichst hohe Hz zahlen zu erreichen, dann scheint es mehr ein Marketing Prozzi, denn eine Weiterentwicklung zu sein?

p.s.:Ich habe nix gegen Intel :)

[turboschlumpf]

das kannst du so nicht sagen.

der p4 ist eine weiterentwicklung.
ausserdem bietet er viele (teilweise etwas tiefergehendere) neuerungen, auch wenn die verbesserungen durch diese (das muss nicht unbedingt eine bessere pro mhz leistung sein) nicht so offensichtlich sind.
und es gibt eben, wie schon erwähnt, mehrere möglichkeiten den l1 und l2 cache zu realisieren.
vielleicht hat die design auslegung auch ein bischen die entscheidung beeinflusst.
aber intel setzt schon von beginn an auf ziemlich kleine l1 chaches mit extrem niedrigen latenzzeiten.

der kleine l1 cache hat wohl aber nur ziemlich wenig anteil daran dass der prozessor solch hohen taktraten erreicht. hierfür ist vielmehr das komplette design (vermeiden von hotspots --> sehr schwacher dekoder) verantwortlich.

wäre der p4 nur ein notnagel bzw. marketingprozessor wäre er wohl kaum in der lage einen athlon zu schlagen oder sogar abzuhängen.
natürlich hatte intel im hinterkopf dass sich hohe mhz zahlen sehr gut verkaufen, aber was ist denn an der brute force methode so schlecht?

naja, und die verlustleistung ist ja garnicht so gering. der vorteil ist hier vielmehr die viel grössere fläche im gegensatz zum athlon über die die abwärme abgegeben werden muss.

[BlackBirdSR]

Originally posted by GloomY
BlackbirdSR,

der Code ist beim P4 im L1 Cache als µ-Ops gespeichert und im L2 als x86 Ops. Das ist aber egal. Denn letztendlich kommt es nicht drauf an, ob der code schon durch den Decoder durch ist, sondern, ob er doppelt in den beiden Caches drinnen ist, oder nicht.
Und das ist er beim P4 eben (imklusives Design), dadurch wird die effektive L2 Cache Größe verringert.

Allerdings möchte ich an dieser Stelle auch anmerken, dass es sowohl auch Nachteile eines exklusiven Cache-Designs gibt.
Z.B. kann es vorkommen, dass die CPU Daten benötigt, die gerade aus dem L1 rausgeschmissen wurden.
Diese kommen dann in einen speziellen Cache (bei AMD Victim-Cache genannt; nur 8 Cache-Lines à 64 Bytes groß). Dieser soll sicherstellen, dass beim Rausschmeissen keine Daten verloren gehen, wenn der L2 gerade beschäftigt ist.
Wenn sich die angeforderten Daten gerade im Victim Cache befinden, dann müssen diese erst in den L2 geschreiben werden (8 Clocks), eine Zeitspanne (4 Clocks, "Turnaround" genannt) gewartet werden und dann die Daten aus dem L2 Cache geholt werden (nochmal 8 Clocks).
Insgesamt sind das 8+4+8 = 20 Clocks, während ein normaler L2 Zugriff nur 11 Clocks braucht (L1 Zugriff von 3 Takten plus 8 beim L2).

Glücklicherweise ist der L2 beim Athlon längst nicht so beschäftigt, so dass die Daten, die aus dem L1 rausfliegen, sich nie lange im Viktim Cache befinden. Trotzdem kann es so eine Situation durchaus geben...

schön und gut,
aber die generell Funktion des inklusiven Cache designs kann mich nicht davon übverzeugen das der Trace Cache Teil davon ist.
Wenn die Befehle aus dem Trace Cache im L2 Cache liegen müssen sie falls sie genutzt werden wie der durch den Dekoder, was den gnazen Sinn des Trace Cache in frage stellt.

Die Befehle werden normal über den L2 Cache aus aus dem Speicher geholt und durch den Dekoder in die Exekution Pipeline eingebracht.
Sobald ein (nicht komplexer) Befehl durch ist der wieder benötigt wird, kommt er in den Trace Cache und bildet mit den restlichen Befehlen in einer Gruppe ein Trace Segment
Er kann dann sofort wieder ausgelesen werden (innerhalb der bekannten 20 Pipelines).
der Befehl fliegt erst raus wenn de Trace Cache voll ist, oder der Befehl nicht mehr gebraucht wird.

Dann muss er wieder aus dem L2 Cache/Speicher gelesen durch den Dekoder was dann so ca 28 Pipeline Stufen ergeben soll.
Aber ein Abbild des Trace Cache im L2 Cache gibt es meines wissens nach nicht, da die Struktur des Trace Caches verloren geht, und der P4 die Arbeit gleich nochmal machen darf.

so jetzt muss mir nur noch einer sagen ob ich mich gewaltig irre ??

[zeckensack]

Ikon, gilt auch für dich:
Originally posted by GloomY
Das ist richtig, allerdings sprach ich vom L1 Cache. Imho ist dort die Line Size von 64 Bit (TB) auf 128 Bit (XP) erhöht worden, wenn ich mich richtig erinnere... Das ist nicht richtig. Die Cachelines sind beim Athlon 64 Bytes lang und 64bit breit angebunden. Sowohl im L2, als auch im L1.

Zum Vergleich: P3 (ab Coppermine) 32 Byte lines in L1/L2, der L2 hat eine 256 bittige Anbindung (L1 weiß ich nicht)

P4 hat im L2 128 Byte lines, im L1 (Daten) sind's 64 Byte. Breite der Anbindung weiß ich nicht, würde aber zumindest beim L2 von den bekannten 256 bit ausgehen.


@all: Ich habe nichts gegen den Trace-Cache. Der scheint mir ausreichend dimensioniert zu sein (meine Schätzung beläuft sich auf ca 24kB Äquivalenter 'echter' Codecache). Aber der Daten-Cache (um den's hier schließlich ging), der ist einfach zu klein. Da muß man als Progger echt durch 'ne Menge brennender Reifen springen, um da noch was rauszuholen. Nur mal so als Anhaltspunkt: In einer 1024er Auflösung bei 32bit Farbtiefe ist der L1-D-Cache des P4 mit zwei Zeilen Pixeln bereits voll. Das reicht nicht mal für JPEG-Dekodierung (Blöcke sind 8 Pixel hoch), es sei denn, man macht sein Programm mit Absicht P4-tauglich, was gleichzeitig die Leistung auf Prozessoren mit 'richtigen' Caches wieder verringert ....
Und das finde ich unfein. Intel (und auch dem P4) hätte es IMO wenig wehgetan, den Cache zumindest bei 16kB zu halten, mir kann keiner erzählen, daß sich dadurch die erreichbare Taktrate nennenswert reduziert hätte.

32kB wären natürlich besser, aber dann müsste ich mir das Gegenargument "Verträgt sich nicht mit dem hohen Takt/der niedrigen Latenz" wirklich gefallen lassen.

[Ikon]

*zustimm* Aber wie darf ich bitte dieses "Ikon, gilt auch für dich" verstehen?

[zeckensack]

Originally posted by Ikon
Aber wie darf ich bitte dieses "Ikon, gilt auch für dich" verstehen? Sollte nur heißen, daß ich das nicht nur GloomY erzählen wollte, sonder auch dir. Sorry, hatte wohl ein paar davon vergessen:

;) :) =)

???

;)

[BlackBirdSR]

Originally posted by zeckensack
Ikon, gilt auch für dich:
Das ist nicht richtig. Die Cachelines sind beim Athlon 64 Bytes lang und 64bit breit angebunden. Sowohl im L2, als auch im L1.

Zum Vergleich: P3 (ab Coppermine) 32 Byte lines in L1/L2, der L2 hat eine 256 bittige Anbindung (L1 weiß ich nicht)

P4 hat im L2 128 Byte lines, im L1 (Daten) sind's 64 Byte. Breite der Anbindung weiß ich nicht, würde aber zumindest beim L2 von den bekannten 256 bit ausgehen.


@all: Ich habe nichts gegen den Trace-Cache. Der scheint mir ausreichend dimensioniert zu sein (meine Schätzung beläuft sich auf ca 24kB Äquivalenter 'echter' Codecache). Aber der Daten-Cache (um den's hier schließlich ging), der ist einfach zu klein. Da muß man als Progger echt durch 'ne Menge brennender Reifen springen, um da noch was rauszuholen. Nur mal so als Anhaltspunkt: In einer 1024er Auflösung bei 32bit Farbtiefe ist der L1-D-Cache des P4 mit zwei Zeilen Pixeln bereits voll. Das reicht nicht mal für JPEG-Dekodierung (Blöcke sind 8 Pixel hoch), es sei denn, man macht sein Programm mit Absicht P4-tauglich, was gleichzeitig die Leistung auf Prozessoren mit 'richtigen' Caches wieder verringert ....
Und das finde ich unfein. Intel (und auch dem P4) hätte es IMO wenig wehgetan, den Cache zumindest bei 16kB zu halten, mir kann keiner erzählen, daß sich dadurch die erreichbare Taktrate nennenswert reduziert hätte.

32kB wären natürlich besser, aber dann müsste ich mir das Gegenargument "Verträgt sich nicht mit dem hohen Takt/der niedrigen Latenz" wirklich gefallen lassen.

der DCache hält dich auch keine JPG Daten ;)
die Hit Rate des L1 D Caches soll ca 96% betragen, also die missrate nur ca 2mal höher als beim Athlon,
ich denke so übel ist das gar nicht.. zumal der D Cache schneller angebunden ist.

[GloomY]

Originally posted by zeckensack
Das ist nicht richtig. Die Cachelines sind beim Athlon 64 Bytes lang und 64bit breit angebunden.
Ja natürlich. :bonk: Hatte ich ja auch im ersten Posting ja auch geschrieben. Wie komm' ich nur auf Bits? :bonk:
Originally posted by zeckensack
Sowohl im L2, als auch im L1.
Hmm, 64 Bits sind für den L1 aber nicht gerade viel. Sicher, dass du dich nicht geirrt hast?
Originally posted by BlackBirdSR
schön und gut,
aber die generell Funktion des inklusiven Cache designs kann mich nicht davon übverzeugen das der Trace Cache Teil davon ist.
Also noch mal zur Erklärung: ein Design ist inklusiv, wenn der L2 Daten des L1 enthält. Andernfalls ist er exklusiv.
Das hat, wenn man den L1 alleine betrachtet, dann nix mehr mit in-oder exklusivität zu tun.
Originally posted by BlackBirdSR
Wenn die Befehle aus dem Trace Cache im L2 Cache liegen müssen sie falls sie genutzt werden wie der durch den Dekoder, was den gnazen Sinn des Trace Cache in frage stellt.
Nein, allein dadurch dass man mit dem Trace Cache Platz sparen kann (12 kb Größe, entspricht aber 24kb x86-Ops), bringt er was.
Außerdem ist man mit einem Trace Cache von der Anzahl der Decoder unabhängig, was die maximale Anzahl an Befehlen pro Takt angeht.
Originally posted by BlackBirdSR
Die Befehle werden normal über den L2 Cache aus aus dem Speicher geholt und durch den Dekoder in die Exekution Pipeline eingebracht.
Sobald ein (nicht komplexer) Befehl durch ist der wieder benötigt wird, kommt er in den Trace Cache und bildet mit den restlichen Befehlen in einer Gruppe ein Trace Segment
Er kann dann sofort wieder ausgelesen werden (innerhalb der bekannten 20 Pipelines).
der Befehl fliegt erst raus wenn de Trace Cache voll ist, oder der Befehl nicht mehr gebraucht wird.

Dann muss er wieder aus dem L2 Cache/Speicher gelesen durch den Dekoder was dann so ca 28 Pipeline Stufen ergeben soll.
Aber ein Abbild des Trace Cache im L2 Cache gibt es meines wissens nach nicht, da die Struktur des Trace Caches verloren geht, und der P4 die Arbeit gleich nochmal machen darf.

so jetzt muss mir nur noch einer sagen ob ich mich gewaltig irre ?? Imho holt der Prozzi die Befehle nicht in den L2, dekodiert sie dann bevor ein sie ausführt, und speichert die komplexen Befehle im L1 Trace, sondern holt sie aus dem Speicher, dekodiert sie und bringt sie in den Trace Cache, der nach und nach abgearbeitet wird.
Ein Befehl wird ja (ausser bei Schleifen) nur einmal verwendet und ist dann abgearbeitet. Er wird nicht (wie bei Daten), mehrmals verwendet.

[zeckensack]

Originally posted by GloomY
Ja natürlich. :bonk: Hatte ich ja auch im ersten Posting ja auch geschrieben. Wie komm' ich nur auf Bits? :bonk:
Hmm, 64 Bits sind für den L1 aber nicht gerade viel. Sicher, dass du dich nicht geirrt hast?Ziemlich sicher. Es macht auch nicht sonderlich viel Sinn, ihn breiter zu machen. Ein L1-Cache hat eine bestimmte Anzahl von Ports, die die maximale Breite eines Lesezugriffs unterstützen müssen (bei FPU/MMX 64bit, SSE 128bit). Der L2 kann durchaus breiter angebunden sein, denn er dient eigentlich nur dazu, den L1 zu füllen.

Dann hätte ich noch das hier als 'Beweis' anzubieten:wait ...
Hello there!
reference CPU clock is 1.203 GHz btw ...
measured writeNTQ bandwith was 1.75568e+009 bytes per second
measured writeQ bandwith was 5.70607e+008 bytes per second
measured writeNTPS bandwith was 1.7454e+009 bytes per second
measured writeAPS bandwith was 5.69687e+008 bytes per second
measured readQ bandwith was 1.04252e+009 bytes per second
measured readQ_cached bandwith was 1.61573e+010 bytes per second
measured readAPS bandwith was 9.90205e+008 bytes per second
measured readAPS_cached bandwith was 9.02787e+009 bytes per second
have a fast day!64bittige MMX-Zugriffe sind schneller als 128bittige SSE-Zugriffe, was Readports mit mehr als 64 bit Breite widersprechen würde.

Ein Befehl wird ja (ausser bei Schleifen) nur einmal verwendet und ist dann abgearbeitet. Er wird nicht (wie bei Daten), mehrmals verwendet. Oooch, sicher? ;)
Wie heißt es doch so schön, ein durschnittliches Programm verbringt 90% seiner Laufzeit in 10% des Codes ... "ausser Schleifen" ist nicht unbedingt eine sinnvolle Ausnahmebedingung. Schleifen sind nämlich so gut wie überall ;)

[BlackBirdSR]

Originally posted by GloomY
Also noch mal zur Erklärung: ein Design ist inklusiv, wenn der L2 Daten des L1 enthält. Andernfalls ist er exklusiv.
Das hat, wenn man den L1 alleine betrachtet, dann nix mehr mit in-oder exklusivität zu tun.

ist schon klar, allerdings hab ich gar nichts anderes gesagt,
nur das eben die Definition von Inklusiv/Exklusiv die ihr geliefert habt nichts aussagt ob der Trace Cache nun im L2 Cache entahlten ist.
IMHO ist der Trace Cache eben nicht teil des L1 Caches sondern arbeit als eigenständiger Segment Cache innerhalb des Cores.

[B]
Nein, allein dadurch dass man mit dem Trace Cache Platz sparen kann (12 kb Größe, entspricht aber 24kb x86-Ops), bringt er was.
Außerdem ist man mit einem Trace Cache von der Anzahl der Decoder unabhängig, was die maximale Anzahl an Befehlen pro Takt angeht.
Imho holt der Prozzi die Befehle nicht in den L2, dekodiert sie dann bevor ein sie ausführt, und speichert die komplexen Befehle im L1 Trace, sondern holt sie aus dem Speicher, dekodiert sie und bringt sie in den Trace Cache, der nach und nach abgearbeitet wird.
Ein Befehl wird ja (ausser bei Schleifen) nur einmal verwendet und ist dann abgearbeitet. Er wird nicht (wie bei Daten), mehrmals verwendet.

Das man mit dem Trace Cache platz sparen kann ist nicht wirklich der Sinn.
Nochmal.. der Trace Cache arbeitet im Segment Build mode, die Befehle kommen durch den Dekoder und durchlaufen beim erstenmal ca 28 Pipeline Stufen.
Ist der Befehl durch die Execution Engine, und gehört er nicht zur Sorte der komplexen Befehle die den Trace Cache verstopfen würden, landet der Befehl im Trace Cache.
Die interne Logik des Trace Cache baut nun Segmente aus 6 Befehlen auf, die geornet im Trace Cache leigen.
Wird während des Aufbauens des Segments ein Befehl schon wieder gebraucht kann er auch ohne im Trace Cache zu verbleiben gleich wieder an die Funktionseinheiten durchgereicht werden.
Ist das Trace Segment für eine Gruppe aus Befehlen erstmal komplett kann diese ohne viel Aufwand, und ohne die Dekoder sofort wieder in den Funktionsablauf eingeschläußt werden.
Und wie Zechensack schon sagt werden einige Befehle 100 bis tausendmal kurze Zeit hintereinander aufgerufen.

Was dein Kommentar über die abhängikeit des Trace Caches von dem Throughput des Dekoders angeht, weiss ich nicht wo der Zusammenhang steht.
Der Trace Cache sorgt dafür das man die Pipeline Stufen um den Dekoder übersprigen kann, und ausserdem die Befehle geordnet für die Funktionseinheiten zur verfügung hat.
Was das holen aus dem Speicher geht.. das Zeug muss nunmal über den L2 Cache eingelesen werden und wir dann an den Dekoder weitergegeben.
ich wüsste nicht wie man die Daten direkt aus dem Speicher in den Core laden sollte.

[GloomY]

Originally posted by BlackBirdSR
ist schon klar, allerdings hab ich gar nichts anderes gesagt,
nur das eben die Definition von Inklusiv/Exklusiv die ihr geliefert habt nichts aussagt ob der Trace Cache nun im L2 Cache entahlten ist.
IMHO ist der Trace Cache eben nicht teil des L1 Caches sondern arbeit als eigenständiger Segment Cache innerhalb des Cores.Aber wenn der P4 ein inklusives Design hat, dann muss der L2 doch per Definition den Inhalt des L1 beinhalten (und dazu gehört doch auch der Trace Cache).
Oder hab' ich da was nicht richtig verstanden?
Originally posted by BlackBirdSR
Das man mit dem Trace Cache platz sparen kann ist nicht wirklich der Sinn.Was ist denn dann deiner Meinung nach der Sinn des Trace Caches?
btw: Ein weiterer Vorteil: Beim Trace Cache werden die Instructions nach dem Programmablauf angeordnet und nicht nach der physikalischen Lage im Speicher (so wie es ein normaler I-Cache machen würde).


Originally posted by BlackBirdSR
Nochmal.. der Trace Cache arbeitet im Segment Build mode, die Befehle kommen durch den Dekoder und durchlaufen beim erstenmal ca 28 Pipeline Stufen.
Ist der Befehl durch die Execution Engine, und gehört er nicht zur Sorte der komplexen Befehle die den Trace Cache verstopfen würden, landet der Befehl im Trace Cache.
Das tut er doch schon vorher. Direkt nach dem x86 Decoder kommt der Trace Cache und vom Trace Cache gehen die "Bündel" von bis zu 6 Befehlen an die Execution Units weiter. (siehe Bild weiter unten)
Originally posted by BlackBirdSR
Die interne Logik des Trace Cache baut nun Segmente aus 6 Befehlen auf, die geornet im Trace Cache leigen.
Wird während des Aufbauens des Segments ein Befehl schon wieder gebraucht kann er auch ohne im Trace Cache zu verbleiben gleich wieder an die Funktionseinheiten durchgereicht werden.
Ist das Trace Segment für eine Gruppe aus Befehlen erstmal komplett kann diese ohne viel Aufwand, und ohne die Dekoder sofort wieder in den Funktionsablauf eingeschläußt werden.
Und wie Zechensack schon sagt werden einige Befehle 100 bis tausendmal kurze Zeit hintereinander aufgerufen.
Richtig.
Originally posted by BlackBirdSR
Was dein Kommentar über die abhängikeit des Trace Caches von dem Throughput des Dekoders angeht, weiss ich nicht wo der Zusammenhang steht.Ich sagte nur, dass ohne Trace Cache die maximale Anzahl an µ-Ops pro Takt durch die Anzahl der Decoder begrenzt ist.
http://www.realworldtech.com/includes/images/articles/Willamette-pt2-fig1.gif
Hier sind eben nur maximal 3 µ-Ops pro Takt möglich, weil es eben nur drei Decoder gibt.


http://www.realworldtech.com/includes/images/articles/Willamette-pt2-fig2.gif
Hier sind (zumindest theoretisch) beliebig viele µ-Ops pro Takt möglich, da durch den Trace Cache eben schon decodierte µ-Ops für die Execution Units verfügbar sind.

Oder um mal von hier (http://www.realworldtech.com/page.cfm?AID=RWT040400000000&p=2) zu quoten:
"The degree of program parallelism available for the execution engines is limited only by the number of uops that can be fetched from the trace cache per clock cycle, rather than by the number of x86 instruction decoders present."
Originally posted by BlackBirdSR
Der Trace Cache sorgt dafür das man die Pipeline Stufen um den Dekoder übersprigen kann, und ausserdem die Befehle geordnet für die Funktionseinheiten zur verfügung hat.Yep.
Originally posted by BlackBirdSR
Was das holen aus dem Speicher geht.. das Zeug muss nunmal über den L2 Cache eingelesen werden und wir dann an den Dekoder weitergegeben.
ich wüsste nicht wie man die Daten direkt aus dem Speicher in den Core laden sollte. Hmm, wieso soll das nicht gehen? Immerhin hat der L2 ja auch Latenzen...
Das würde das Laden der Daten aus dem Speicher doch nur verzögern, oder?

[BlackBirdSR]

irgendwie reden wir immer über das selbe und kommen doch nicht zum ergebnis..

PS: ürbigens schön das es noch ein paar Leute gibt die z.B Realworldtech und Paul Demone lesen(ich hoffe du hast nicht nur die Bilder kopiert ;) ), und nicht nur Tom Pabst und sein Geflügel, ähm gefolge.

Der Sinn des Trace Cache ist es, Pipeline Stufen zu sparen,
Die Branch Prediction zu erleichtern und wie du schon gesagt hast, (was aber in meinem Post war, die Befehle im Trace Cache zu ordnen, branches zu finden und oft benutze Befehle sofort wieder in den Kreislauf einzuspeisen)

der Trace Cache selbst belegt mehr Platz als ein 16-18K L1 ICache und braucht eine ausgefeilte Logik
ich glaube somit erübrigt sich der Sinn des Platzsparens.


Und nun nochmal zum Inklusiven L2 Cache.
bis mir einer erklärt welchen Sinn es hat, den Trace Cache im L2 Cache zu spiegeln, glaube ich nicht das er enthalten ist.
So geht im L2 Cache alles verloren was den Trace Cache auszeichnet.
Die Befehle sind nicht mehr geordnet, bilden keine Segments mehr, enthalten keine Branch Prediction und müssen aufwendig durch die Fetch/Dekoderstufen.

Wo ist da der Sinn?, dann kann ich die Befehle gleich einfach aus dem L2 Cache auslesen wie der sie aus dem Hauptspeicher ausgelesen hat, und sie dann zur weiteren Bearbeitung im Trace Cache lassen.
Ausserdem ist der Core eben nur an den L1 Cache angebunden, ich frage mich wie er die Daten da direkt aus dem Hauptspeicher golen soll, besonders da es dort Latenzen bis zu 140zyklen gibt..


PS: vielleicht hast dus gelesen, der Trace Cache kann momentan auch nur 6µ-Ops liefern, und das bei jedem 2ten takt, also 3µ-ops pro Takt.

[zeckensack]

Originally posted by BlackBirdSR
PS: vielleicht hast dus gelesen, der Trace Cache kann momentan auch nur 6µ-Ops liefern, und das bei jedem 2ten takt, also 3µ-ops pro Takt. ... wobei der K7 drei x86-Ops pro Takt verarbeiten kann, die durchaus zu mehr als 3 internen Ops werden können. Auch das geht noch, denn das Backend kann mindestens sechs Ops pro Takt fressen (definitive Zahlen sind mir nicht bekannt). Wollte ich nur anmerken, da er wohl für die Vergleichsbilder herhalten mußte. ;)

[GloomY]

Originally posted by BlackBirdSR
irgendwie reden wir immer über das selbe und kommen doch nicht zum ergebnis..Doch, wir kommen uns schon näher, was die Meinungen angeht...
Originally posted by BlackBirdSR
PS: ürbigens schön das es noch ein paar Leute gibt die z.B Realworldtech und Paul Demone lesen(ich hoffe du hast nicht nur die Bilder kopiert ;) ), und nicht nur Tom Pabst und sein Geflügel, ähm gefolge.Ich bin eigentlich nur aus Zufall auf die Seite gestossen.
Tom Pabst = Tomshardware? ???
Originally posted by BlackBirdSR
Der Sinn des Trace Cache ist es, Pipeline Stufen zu sparen,
Kannst du mir das bitte noch mal erklären?
Originally posted by BlackBirdSR
Die Branch Prediction zu erleichtern und wie du schon gesagt hast, (was aber in meinem Post war, die Befehle im Trace Cache zu ordnen, branches zu finden und oft benutze Befehle sofort wieder in den Kreislauf einzuspeisen)Zustimmung.
Originally posted by BlackBirdSR
der Trace Cache selbst belegt mehr Platz als ein 16-18K L1 ICache und braucht eine ausgefeilte Logik
ich glaube somit erübrigt sich der Sinn des Platzsparens.Zeckensack meinte, es passen 24 kb x86-Ops in die 12 kB Trace Cache. Ich glaube nicht, dass die Logik so viele Transistoren verbrät...
Originally posted by BlackBirdSR
Und nun nochmal zum Inklusiven L2 Cache.
bis mir einer erklärt welchen Sinn es hat, den Trace Cache im L2 Cache zu spiegeln, glaube ich nicht das er enthalten ist.
Es gibt keinen Sinn ;) Es ist einfach so bei einem inklusiven Design.
Ich probier's mal so zu erklären:
Jeder Cache hat eine bestimmte Strategie, die in etwa so aussieht: Das was am längsten im Cache drinnen ist und nicht benötigt wurde, fliegt als nächstes raus (weil die Wahrscheinlichkeit, dass dies als nächstes angefordert wird, am kleinsten ist).
Anders herum bleibt alles das, was gerade neu in den Cache gekommen ist und benötigt wurde (nur das kommt ja auch in den Cache hinein) erst einmal drinnen.
Diese Vorgehensweise gilt sowohl für L1 als auch für den L2.
Wenn der Prozessor die Befehle nach und nach abarbeitet und die Bus Interface Unit damit nach und nach das Programm aus dem RAM holt, bleiben eben die gerade erst geholten Daten und Code im L2 Cache drinnen (getreu dem Motto: was als letztes benötigt wurde, bleibt).
Das macht der L1 natürlich genau so.
Es liegt einfach in der Natur der Sache (bzw. den gleichen Strategien von L1 und L2), dass sich der komplette Inhalt des L1 auch wieder im L2 wiederfinden lässt.
Die einzigste Möglichkeit, das zu verhindern, ist dem L2 explizit zu verbieten, Daten des L1 zu enthalten (womit wir beim exklusiven Design wären).
Da Intel aber ein inklusives gewählt hat, sind die Daten des L1 nunmal auch im L2 zu finden. Das ist (wie von dir weiter unten ausgeführt) natürlich komplett sinnlos.
Bei jedem inklusiven Design ist die effektive Größe des L2 die von L2-L1. (Bei einem L3 mit inklusivem Design wäre die effektive Größe des L3 = L3 - eff. Gr. von L2 - eff Gr. L1 = L3 - L2)
Originally posted by BlackBirdSR
So geht im L2 Cache alles verloren was den Trace Cache auszeichnet.
Die Befehle sind nicht mehr geordnet, bilden keine Segments mehr, enthalten keine Branch Prediction und müssen aufwendig durch die Fetch/Dekoderstufen.

Wo ist da der Sinn?, dann kann ich die Befehle gleich einfach aus dem L2 Cache auslesen wie der sie aus dem Hauptspeicher ausgelesen hat, und sie dann zur weiteren Bearbeitung im Trace Cache lassen.
Wie gesagt: Deine Ausführungen sind durchaus alle richtig.
Allerdings wird der Teil des L2, in dem sich der Inhalt des L1 befindet, nie ausgelesen, denn der L1 wird ja vor dem L2 gefragt, ob er die Daten/Code enthällt.
Dieser Teil ist bei einem inklusiven Design komplett nutzlos.
Originally posted by BlackBirdSR
Ausserdem ist der Core eben nur an den L1 Cache angebunden, ich frage mich wie er die Daten da direkt aus dem Hauptspeicher golen soll, besonders da es dort Latenzen bis zu 140zyklen gibt..
Ich meinte eigentlich nur, dass Daten/Code die/der (sowieso) aus dem RAM geholt werden müssen, nicht erst im L2 zwischengespeichert werden müssen, sondern direkt in die Prozessorregister gelangen können.
Originally posted by BlackBirdSR
PS: vielleicht hast dus gelesen, der Trace Cache kann momentan auch nur 6µ-Ops liefern, und das bei jedem 2ten takt, also 3µ-ops pro Takt. AFAIK kann der Trace Cache 6 µ-Ops pro Takt liefern, wenn auch nur über 3 Leitungen (zwei getrennte Übertragungen; so was wie DDR? ???)
Mal wieder ein Quote:
"My conclusion is that the Willamette trace cache outputs 6 uops every clock cycle using two separate transfers of three uops each. (i.e. the output path is double pumped)."

[GloomY]

Originally posted by zeckensack
... wobei der K7 drei x86-Ops pro Takt verarbeiten kann, die durchaus zu mehr als 3 internen Ops werden können. Auch das geht noch, denn das Backend kann mindestens sechs Ops pro Takt fressen (definitive Zahlen sind mir nicht bekannt). Wollte ich nur anmerken, da er wohl für die Vergleichsbilder herhalten mußte. ;) Danke für den Hinweis. (Hätte ich doch glatt mal wieder übersehen.)

Weisst du, wie groß das Verhältnis zwischen der Anzahl der µ-Ops pro x86-Op ist?
Edit: Hab's grad' selber gefunden: etwa 1,5 µOps pro x86-Ops (beim P6 Design, dann wird's beim Williamette auch nicht anders sein...)

[BlackBirdSR]

B]Originally posted by GloomY [/B]
Doch, wir kommen uns schon näher, was die Meinungen angeht...
Ich bin eigentlich nur aus Zufall auf die Seite gestossen.
Tom Pabst = Tomshardware? ???[/B]

ja genau der ;)


AFAIK kann der Trace Cache 6 µ-Ops pro Takt liefern, wenn auch nur über 3 Leitungen (zwei getrennte Übertragungen; so was wie DDR? ???)
Mal wieder ein Quote:
"My conclusion is that the Willamette trace cache outputs 6 uops every clock cycle using two separate transfers of three uops each. (i.e. the output path is double pumped)." [/SIZE][/QUOTE]

Paul hat den Artikel damals auf Basis der verfügbaren Informationen geschrieben als das Design P7 noch nicht erschienen war.
Was er eben nicht wissen konnte ist das der Trace Cache nur 3µOps pro Takt liefern kann, da er auf halben Prozessortakt läuft, und keine 2 auslese ports hat, bzw mit doppeltem CPU takt läuft.


Es hängt wohl einfach damit zusammen dass Intel sonst das Design nicht schnell genug takten konnte.
Paul Demone folgert danach auch dass der P7 ca 1.5mal schneller sein sollte als ein P3 bei selbem Takt. (ich denke wir wurden alle entäuscht.

Allerdings kann der P4 auch in den besten fällen selten mehr als 4µOps wirklich nutzen,
genau wie auch der Athlon seine 9 Funktionseinheiten nicht auslasten kann. (dessen FPU liegt zu oft brach)


die meisten X86 Ops lassen sich in 1-3µOps übersetzen,
die großen Brummer mit mehereren hundert µOps lässt der P4 wie auch der thlon über den Microcode laufen.
-> über der Stelle an der Paul das mit den 1.5µOps beim P3 geschrieben hat, steht auch dass der Trace Cache sehr viel Platz braucht. Von Platz sparen kann also keine Rede sein.

[zeckensack]

Originally posted by GloomY
Zeckensack meinte, es passen 24 kb x86-Ops in die 12 kB Trace Cache. Ich glaube nicht, dass die Logik so viele Transistoren verbrät...Vorsicht! Intel hat die wahre Größe des Trace Cache nie bekanntgegeben, lediglich, daß 12kOps reinpassen. Und zwar P4-interne Ops, nicht x86-Ops. Von 12kByte war nie die Rede. Deswegen sollte man auch nicht von "Platzersparnis durch Trace-Cache" reden.

IMO ist es sogar sehr wahrscheinlich, daß der Trace Cache rein von der physikalisch zu speichernden Bit-Anzahl die Größe des K7-Codecaches erreicht oder übersteigt! Dazu müsste eine einzige Op 'nur' 48bit belegen. (Obacht: auch der K7 Code-Cache ist in Wirklichkeit 72kBytes groß, da auch hier einige Scan- und Predecode-Bits dazugespeichert werden. Wenigstens hat AMD die reale Größe in Whitepapers angegeben).

Wie gesagt, erstens "IMO" und zweitens "wahrscheinlich". Intel hat den Mantel des Schweigens bisher leider nicht gelüftet.

Bei meinen 'effektiv 24kB' bin ich übrigens davon ausgegangen, daß eine x86-Op im Schnitt 3 Bytes lang ist, und zu 1,5 Ops zerlegt wird.

12k / 1,5 * 3 = 24k

[GloomY]

Originally posted by zeckensack
Vorsicht! Intel hat die wahre Größe des Trace Cache nie bekanntgegeben, lediglich, daß 12kOps reinpassen. Und zwar P4-interne Ops, nicht x86-Ops. Von 12kByte war nie die Rede. Deswegen sollte man auch nicht von "Platzersparnis durch Trace-Cache" reden.

IMO ist es sogar sehr wahrscheinlich, daß der Trace Cache rein von der physikalisch zu speichernden Bit-Anzahl die Größe des K7-Codecaches erreicht oder übersteigt! Dazu müsste eine einzige Op 'nur' 48bit belegen. (Obacht: auch der K7 Code-Cache ist in Wirklichkeit 72kBytes groß, da auch hier einige Scan- und Predecode-Bits dazugespeichert werden. Wenigstens hat AMD die reale Größe in Whitepapers angegeben).

Wie gesagt, erstens "IMO" und zweitens "wahrscheinlich". Intel hat den Mantel des Schweigens bisher leider nicht gelüftet.

Bei meinen 'effektiv 24kB' bin ich übrigens davon ausgegangen, daß eine x86-Op im Schnitt 3 Bytes lang ist, und zu 1,5 Ops zerlegt wird.

12k / 1,5 * 3 = 24k :bonk: Ok, mal wieder was übersehen. Was würde ich ohne Zeckensack machen ? ;)

Also gut, dann zieh' ich das Argument mit dem Platz sparen natürlich zurück...

btw: Wenn wir gerade beim P4 sind, fällt mir ein, dass irgendjemand mal erwähnt hatte, dass der P4 keine Shift-Befehle ausführen kann und dies über die normale Multiplikation machen muss.
Ist das war?

[[fu]121Ah]

der decoder wurde vollkommen verkrüppelt.

klar, der tracecache macht das decodieren der instructions pro takt eigentlich sinnlos, da ja das resultat des decoders abgelegt wird. das problem daran ist, es geht nur wenn der code der grad ausgeführt wurde schon decodiert wurde und im trace ist. wenn jetzt ein codeteil bearbeitet wird das nicht im trace decodiert ist und dort liegt, muss das ding bis auf den l2 oder ram zurückgreifen... das wären dann jeweils 64byte.

wenn wir das jetzt mal umrechnen, wie zeckensack gesagt hat (?) ist ne normale x86 ins 3 byte lang... 64byte sind dann 21 maschinencode ins.

das sind jetzt natürlich 21 taktzyklen die der p4 braucht um die 64byte zu übersetzen... der athlon braucht dafür max 11.

der p4 ist eigentlich eine super architektur, jedoch wurde er einfach beschnitten und auf den markt geworfen... der L3 cache fehlt, der L1 cache ist zu klein, der decoder scheisse, der tracecache ist auch nicht der hammer:

der trace cache kann nen wert von dem decoder zwischenspeichern, also einen wret einer m.op. wie gesagt kann der trace 3 microops pro takt an die recheneinheiten weitergeben. merken wir uns das mal...

3 microops...

wir haben aber 7 recheneinheiten die 9 mikroops durchführen können...

mach das sinn? da haben wir nen flaschenhals... das heisst nämlich dass nur 33% der rechenleistung des p4 auch genutzt werden!

ich könnte noch weitererzählen, aber das bringts nicht...

aja, meine speku:

der p4 hat zuviele transistoren um noch kühl gehalten werden zu können... deshalb der schwache trace... das ist kühlend da ja nichtmal die beiden 2x takt alus gleichzeitig arbeiten können!

[turboschlumpf]

der dekoder ist doch absichtlich so schwach um hot spots und eine zu starke wärmeentwicklung bei diesen hohen taktraten zu vermeiden und eben diese zu ermöglichen.
auch sind die vielen transistoren da nicht hinderlich, denn ein p4 hat auch keine grössere verlustleistung als ein athlon, aber eben durch die vielen transistoren eine grössere fläche um diese an den kühler abzugeben.

es sei mal dahingestellt ob dieses vorgehen intels nun wirklich besser ist, imo ist es zumindest nicht schlechter.

[BlackBirdSR]

Ich denke Hot SPots zu verhindern war sicherlich ein Grund nur einen Dekoder zu nutzen.
allerdings lassen sich durch den Trace Cache eben 8! Pipeline Stufen überspringen und das ist schon einiges.
Dass der Trace Cache bei halbem Core Takt läuft liegt wohl einfach auch daran dass man sicherstellen wollte den Takt der CPU hochgenug schrauben zu können.
Ausserdem wird auf Befehle im Trace Cache sehr sehr oft zugegriffen, so dass sich der Trace Cache gegenüber dem einen Dekoder auf jedenfall bezahlt macht.

Was die Funktionsuasführung und Auslastung ausgeht:
Der P4 und der Athlon (oder auch P3) kommen bei weitem nicht an die max. Auslastung.
Wir (nein ich bin keine CPU :D) haben nämlich nicht nur einen Mangel an Registern sondern auch Abhängigkeiten der Funktionseinheiten, so dass der P4 im Durchschnitt auf ca 4 µOps für die Ausführung kommt.

Hinzu kommt, dass sich vor den Ausführungseinheiten die Befehle Ansammeln, da nicht jeden Takt einer fertig wird.
AN Stellen wie den Fast-ALUs die Befehle innerhalb eins "halben" Takts abarbeiten können, ist sowieso nicht viel los, da ein sehr großer Teil des Integer Codes durch die Slow ALU muss.


Man kann sicherlich am Design noch optimieren, nicht umsonst ist es ein wichtiges Gebot beim CPU Design dass man die zukünftige Erweiterung mit in das Design einbezieht,
aber zu sagen der P4 wäre jetzt verkrüppelt weil er seine FUnktionseinheiten nicht auslasten kann und nur 1 Dekoder hat ist nicht wahr.
Dem Athlon sagt schließlich auch keiner nach dass er verkrüppelt wäre, dabei leigen seine FPUs oft brach, und seine Dekoder schaffen auch nicht das Optimum (siehe K8).
Gnaz zu schweigen dass der Athlon auch keine 9 Funktionseinheiten gleichzeitig beschäftigen kann.

[[fu]121Ah]

ich sag ja nicht dass das design scheisse ist. ich sag nur dass der p4 halt nicht das ist was er sein könnte.

wie schon gesagt geht es wohl um diese hotspots, die man verhindern muss, genau darum wird auch nur 1 decoder vorhanden sein und der tracecache so langsam sein... und darum werden auch die ALB einheiten (oder wie die heissen sollten) nicht vorhanden sein...

das design selber ist eigentlich gut, jedoch ist es für uns nutzer halt nicht optimal.

aja, ich denke nicht dass die grösse der fläche was ausmacht... ein grosser teil nimmt ja der 512kb cache ein... ich kenne die transistorzahlen nicht, aber ich denk nicht dass die fläche was auf die kühlung ausmacht... höchstens der IHS...

[BlackBirdSR]

Der Heatspreader hilft nicht die Abwärme schneller von der CPU wegzubringen.
Im Gegenteil, der Heatspreader bringt nochmal zusätzlich eine Schicht Metall ein, wodruch die Wärmeableitung wieder verschlechtert wird.

Ob man jetzt Abwärme von der DIE direkt auf den Kühler bringt, oder zuerst auf den Heatspreader und dann auf den Kühler, die Übertrag von der DIE zum nächsten Medium bleibt gleich, wobei der Heatspreader sicherlich nicht so gut leitet wieder z.B Kupfer.

Er verhindert Schaden an der DIE, aber die Wärme führt er nicht schneller ab.
War schon beim K6 so.

[turboschlumpf]

wie schon gesagt geht es wohl um diese hotspots, die man verhindern muss

nicht verhindern muss, sondern verhindern will damit man höhere taktraten erreicht.

das design selber ist eigentlich gut, jedoch ist es für uns nutzer halt nicht optimal.
was ist daran nicht optimal?? das desig des athlon ist auch nicht optimal. jedes design hat seine macken bzw. eigenheiten.

aja, ich denke nicht dass die grösse der fläche was ausmacht... ein grosser teil nimmt ja der 512kb cache ein... ich kenne die transistorzahlen nicht, aber ich denk nicht dass die fläche was auf die kühlung ausmacht...

oh doch, siehe thoroughbread. da wird es schon so langsam heikel mit der verlustleistung die pro cm² fläche abgegeben werden muss. deshalb sind jetzt ja auch kühler mit kupferkern vorgeschrieben.