Woher hast du das? Inklusive heisst doch, dass ein Cache niedrigerer Stufe immer im höherstufigen Cache verfügbar ist, zB mittels Write-Through. Bei exklusiven Caches wird dies eben nicht gemacht. Dh, sämtlicher Cache ist frei verfügbar. Deshalb kann ein Speicherbereich trotzdem in mehreren Caches vorhanden sein.
Ich habe bisher nur etwas davon gelesen, dass L1/L2 inklusive sind. Also der L1 befindet sich auch in L2. Der L3 soll hingegen weiterhin exklusiv sein. Wobei ich nicht ausschliessen möchte, dass der L1 auch im L3 hinterlegt wird. Fragt sich nur, inwiefern das wirklich Sinn macht.
Arikus83 schrieb:
mr. dude schrieb:
Hatte ich mal gelesen, dass ein AMD Athlon Daten nicht zweimal im Cache hat und man eigentlich die Caches addieren müsste. Die Wortbezeichnung 'exklusiv' ist dann wenig zutreffend gewählt, 'nicht-inklussiv' oder 'laissez-fair' wäre zutreffend.
woher?
Jo, da hat sich einer graphisch Mühe gegeben. Blöderweise hat der Fälscher aber das BD Manual nicht gelesen. Die L1D Assoziativität ist falsch, das muss 4fach statt 2fach heißen.
Quelle war die:
Nö, 3Dnow! ist wegggefallen. SSE4A kann komischerweise sogar Bobcat/Zacate ;-)
Haha, ja hoffentlich mußt Du basteln ;-)
Schon klar, "Kerne" können dann auf den L1 anderer "Kerne" zugreifen. Trotzdem nochmal die Frage, inwiefern macht das wirklich Sinn? Für die Kommunikation zwischen den zwei Integer Clustern eines Moduls sehe ich keinen. Die haben ja den L2. Und muss ein Modul nun den L1 eines anderen Moduls kennen? Was bringt es im Endeffekt in realen Szenarien? Der L3 ist ja weiterhin ein Victim Cache. Er dient also nicht primär zur Kernkommunikation, sondern ist sozusagen das "Auffangbecken" für die Daten, die aus dem L1 bzw L2 fliegen.
Ja, kann man.
Nicht so voreilig. Was bisher Fake war und was nicht, können wir schlecht nachprüfen. Cache und Assoziativität mittels CPUID auszulesen, ist jedenfalls nicht so trivial, wie man annehmen könnte. Da sich bei Bulldozer hier einiges geändert hat, könnte das auch noch am fehlenden CPU-Z Support liegen. Interessanter ist eigentlich, dass bei dem Screen Extended MMX fehlt. Wenn man den Befehlssatz bereinigt und 3DNow rausschmeisst, warum nicht auch Extended MMX, was von Intel nicht unterstützt wird? Wäre zumindest plausibel. Erst recht, da sich die Extended MMX Opcodes wohl teilweise mit SSE überschneiden und Bulldozer nun alle bisherigen SSE Versionen unterstützt. Auf der anderen Seite, wer die CPU-Z Versionsnummer unkenntlich macht, hat wohl irgendwas zu verbergen.
Was ist denn kompliziert dran ? Bisher klappte das auf alle Fälle ganz gut, und BD hat anscheinend laut aktuellem CPUID PDF mit XOP und AVX aber ohne SSE5 die gleichen Flags. Wenns anders wäre, würde sie es ja wohl angeben ;-)
Wenn also die Cachegröße richtig erkannt, wird, dann sollte die Abfrage ja wohl auch für die Assoziativität klappen, ist ja die gleiche Technik.
Hmm, stimmt das Enhanced MMX ist mysteriös. Schlimmstenfalls ein fake in beiden Fällen ;-)Da sich bei Bulldozer hier einiges geändert hat, könnte das auch noch am fehlenden CPU-Z Support liegen. Interessanter ist eigentlich, dass bei dem Screen Extended MMX fehlt. Wenn man den Befehlssatz bereinigt und 3DNow rausschmeisst, warum nicht auch Extended MMX, was von Intel nicht unterstützt wird? Wäre zumindest plausibel. Erst recht, da sich die Extended MMX Opcodes wohl teilweise mit SSE überschneiden und Bulldozer nun alle bisherigen SSE Versionen unterstützt. Auf der anderen Seite, wer die CPU-Z Versionsnummer unkenntlich macht, hat wohl irgendwas zu verbergen.
hoffentlich...
Ich kann mich an Fälle erinnern, wo es durchaus nicht klappte. Verlinke doch mal ein deiner Meinung nach aktuelles CPUID PDF. Ich habe hier nur Version 2.34 von September 2010. Und die Cache Infos stammen dort noch von Juli 2007. Ich glaube kaum, dass da Bulldozer schon eingearbeitet war. Und nicht trivial ist es zum einen deswegen, weil diese Cache Infos im herstellerspezifischen Funktionsbereich liegen. Man muss entsprechenden Support also separat für jeden Hersteller pflegen. Zum anderen sind die von CPUID zurückgelieferten Cache Infos nicht immer direkte Werte, sondern müssen teils über Tabellen interpretiert werden. Und wer sagt uns, dass sich hier mit Bulldozer nichts geändert hat? Zudem besitzt Bulldozer pro Modul nun zweimal L1D. Woher wissen wir, ob die Infos dazu nicht auch zweimal in CPUID hinterlegt werden? Man schreibt zwar zu Fn8000_0005 immer:
Das kann aber nicht mehr aufgehen, da L1D nun 1x pro (Integer) Kern, L1I jedoch 1x pro Modul vorhanden ist. Da müssen also Änderungen an den CPUID Spezifikationen vorgenommen werden.
Ist ja auch ok. Trotzdem halte ich es für verfrüht, es als Fake abzustempeln. Es gibt auch noch andere Sachen, neben Extened MMX, die ich am neuen Screen für authentischer halte. ZB sind beim neuen Screen die Bezeichner für nicht gefüllte Felder ausgegraut, so wie man es auch erwarten würde. Das ist bei deinem verlinkten alten und vermeintlich echten Screen nicht der Fall.
Hmm, ok das mit dem L1I$ könnte Problemchen geben, ich ging halt pauschal davon aus, dass sich an den Cacheeinträgen nichts ändern würde, nachdem in der von Dir genannten Version (ich hatte natürlich die gleiche) bereits der SSE5 -> XOP/FMA Schritt eingeführt wurde. Von der Sichtweise sollte das PDF damit auf den neuesten Stand sein. Aber mal schauen, was am Ende rauskommt, ist ja eigentlich egal, ob das Ding jetzt fake ist, oder nicht, da hat Duplex mal recht, was haben wir davon
Ok, aber was sagst Du zum "Package 942" ? Woher sollte CPUz das kennen ?
Jo, früher war high-k (zusammen mit ULK) auch schon bei 45nm mit eingeplant. War eventuell der springende Punkt, der den Unterschied machte. Das BD Design geht auf alle Fälle mehr über den Takt als der K10. Wenn man da nicht viel erreichen kann, weil der Großteil schon per Leakage drauf geht, hat man nicht viel von.Das glaube ich irgendwie nicht, 45nm ist nicht 65nm, ein gutes Beispiel ist Magny Cours mit 12x 2,4Ghz Basis Takt
Du willst mir sagen das der ursprüngliche BD mit 8 Kernen in 45nm keine 3Ghz Takt @140W TDP packen würde? aber MC schaft dagegen 12x 2,4Ghz bei gleicher Fertigung...
Vielleicht hat das Design damals bei Leistung pro Takt nicht überzeugt, z.b. 8 Kerne mit K8 IPC @3Ghz, das könnte ein Grund gewesen sein, in der zwischenzeit hat man auch die Cache Größen für L2 & L3 für 32nm neu angepasst, dann noch AVX Instruction statt SSE5 erweitert, mit High K Metall Gates & 32nm hat man dann zusätzlichen Takt Spielraum geschaft, zwischendurch noch Turbo 2.0 entwickelt und teilweise bei Thuban ausgetestet, Ultra LowK wurde bei Thuban auch eingesetzt, erstmal testen was es bringt, dann später bei BD einsetzen damit man mehr Potential hat....
