Da hier ein Moderator nicht möchte, dass ich einen Beitrag aus dem Heiseforum hier zitiere, bitte ich dich, selbst dort nachzulesen, hier ist der Link:
http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=14024795&forum_id=128506
Und nun sag mir bitte ohne rot zu werden, dass du mehr Ahnung hast als die versammelte Kommentatorenschaft im Heiseforum, die diesem Beitrag nicht widersprach.
Achso, du hast einfach nur aus dem Heiseforum abgekupfert, ohne wirklich Ahnung davon zu haben? Müsstest du dann nicht rot werden?
Btw, aus dem Alter, dass ich auf Heise Beiträge etwas gebe, bin ich schon lange raus.
Aber nochmal für dich zum mitschreiben.
Das was auf Heise steht, mag ja durchaus richtig sein, entspricht aber nicht der konkreten Situation.
Ich habe dir schon mal gesagt, du gehst davon aus, dass eine Instruktion mit eben einer solch falschen Adresse noch zur Ausführung kommt. Genau das passiert aber nicht, denn scheinbar kommt der Fehler viel früher zum tragen und riegelt das System dann ab.
Dazu folgende Informationen:
The processor operation to change the accessed or dirty bits of a page translation table entry in the L2 from 0b to 1b may not be atomic. A small window of time exists where other cached operations may cause the stale page translation table entry to be installed in the L3 before the modified copy is returned to the L2.
In addition, if a probe for this cache line occurs during this window of time, the processor may not set the accessed or dirty bit and may corrupt data for an unrelated cached operation.
The system may experience a machine check event reporting an L3 protocol error has occurred. In this case, the MC4 status register (MSR 0000_0410) will be equal to B2000000_000B0C0F or BA000000_000B0C0F. The MC4 address register (MSR 0000_0412) will be equal to 26h.
Zum Verständnis: Die "translation table" (TLB) befindet sich im L2, und darin gibt es Bits, welche dafür zuständig ist, die Aktualität des jeweiligen Eintrages festzuhalten, neu (Bit 0) oder alt (Bit 1, accessed or dirty). Wird nun ein neuer Eintrag geschrieben oder ein vorhandener verarbeitet, muss dieses Bit aktualisiert werden. Dies geschieht offenbar nicht atomar, also gleichzeitig, ohne dass etwas anderes dazuwischen funken kann. Wer sich mit Multithread Programmierung auskennt, weiss, was dort alles passieren kann, wenn entsprechende Lese- oder Schreibzugriffe nicht atomar sind. Es gibt also ein Zeitfenster, wo eine gecachte Instruktion dafür sorgen kann, dass ein inkonsistenter Eintrag vom L2 in den L3 kopiert wird, bevor eine gültige Version im L2 ist. Dadurch wird eine gecachte Instruktion "beschädigt". Daraus resultiert ein L3 Protokoll Error.
Nochmal, dass eine solche beschädigte Instruktion auch zur Ausführung kommt, ist noch lange nicht gegeben. Das halte ich aufgrund dieser Informationen auch eher für unwahrscheinlich.
bin der meinung das der K7 Kern dringend ausgemustert werden sollte, den selbst der barcelona basiert im grunde noch auf der K7 architektur.
Dieser Rechenkern ist aber im vergleich zum Core veraltet bzw. zu langsam.
Nope. Die Rechenkerne von AMD sind immer noch i.O., und können mit Core problemlos mithalten. Selbst der K8 ist immer noch gut. Was Intel so schnell macht, ist im Grunde der L2 Cache. Im Vergleich zum K8 war es zudem noch die SSE Pipeline, das ist mit dem K10 aber Geschichte. Und so abgedroschen das klingt, die Software selbst spielt ebenfalls eine entscheidende Rolle. Daher lässt sich oft nicht wirklich sagen, wie gut nun eine Architektur auch ausgenutzt wird oder nicht.
Btw, AMD hat sich auf gar nichts ausgeruht. Neue Kerne, also nicht nur überarbeitete, wird es mit dem Bulldozer geben. Die Voraussetzungen dafür, also eine funktionierende Infrastruktur für x-beliebige Kerne, mussten aber erstmal geschaffen werden. Genau das ist der K10.
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1197025871
Jetzt sind wir schon bei 137Watt...
Was AMD da abzieht ist einfach nur noch lächerlich, die sollten den K10 Flop lieber gleich einstellen...
Der QX9775 (S771) hat eine TDP von 150W. So viel zum Thema TDP.
Übrigens, falls es dir entgangen ist, die ACP hat sich _nicht_ geändert. Es ist daher anzunehmen, dass man für die Server Modelle mehr Spielraum nach oben hin einräumt. So wie das auch bei Intel üblich ist, QX9770 (S775) 136W TDP. Sry, so leid es mir tut, aber das sind typische Flame Kommentare mit Intel Brille. Das hat nichts mehr mit Information oder freier Meinungsäusserung zu tun, sondern ist einfach nur Provokation. Zudem bist du im falschen Thread.
Wie kommt es das Speicherbenchmark so gut ist?
War es nciht so, dass der Phenom da auch abschmierte?
Nein, die Speicherdurchsatz scheint beim K10 vollkommen i.O. zu sein. Nur scheinbar können einige Anwendungen mit dem K10 noch nichts anfangen, siehe auch Sandra. Beim PCMark05 scheint es ähnlich zu sein. Unganged wird z.B. nur ausgeschöpft, wenn auch mehrere Kerne, und damit beide Kanäle, belastet werden.
Hier ist es wieder anders. Also könn wir grundsätzlich die Benchmarks immer in die Tonen werfen ...
Sozusagen.
Naja, ganz so dramatisch ist es nicht. Ich kann es aber nicht oft genug betonen, wie viel Bedeutung der Software mittlerweile zukommt. Wer sich von irgendwelchen Benchmarkzahlen blenden lässt, und damit zu Schlussfolgerungen kommt, was für ein Flop eine CPU ist, und davon scheint es ja jede Menge Leute zu geben, auch hier, wird ewig im Land der Ahnungslosen bleiben.
Die Architektur des K10 ist vollkommen i.O. und absolut auf Augenhöhe mit der Konkurrenz. Intel hat weiterhin den L2 Cache Vorteil, auch wenn dieser etwas geringer geworden ist (verbesserter L2 + L3). AMD hat weiterhin den Vorteil der RAM Anbindung, welche weiter verbessert wurde. Beim Quadcore kommt letzteres noch stärker zum tragen als beim Dualcore. Auch den Vorteil von AMD in 64 Bit Umgebungen und die Mehrkerninfrastruktur sollte man nicht unbeachtet lassen. Da verliert der Core relativ gesehen einiges an Leistung.
AMD's Probleme liegen vielmehr bei der Fertigung. 65nm scheint mittlerweile recht gut zu laufen und das sollte sich in den nächsten Wochen und Monaten auch auf den K10 übertragen. 45nm ist ja auch nicht mehr in all zu weiter Ferne.
Aber intressant ist auf Seite 11 des Tests die Leitsungausfahme. so schlecht ist der Phenom gar nicht.
Yep, das halte ich erstmals für wirklich aussagekräftige Ergebnisse bezüglich der Leistungsaufnahme. 5W mehr bei zwei zusätzlichen Kernen gegenüber dem K8 G2 Stepping im Idle Betrieb. Das klingt auf jeden Fall plausibel, denn das ist ca. die Leistungsaufnahme, die ein K8 Dualcore im Idle Betrieb hat. Interessant ist auch, dass man unter Last auf Intel Niveau liegt, bzw. hier sogar leicht besser. Sonst war es eher umgekehrt, also Intel maximal leicht besser. Auf jeden Fall in Indiz, dass es mit 65nm vorwärts geht und in Zukunft sicherlich noch einiges kommen wird.