Athlon XP offenbar mit Schwächen beim Prefetching

Nero24

Administrator
Teammitglied
Mitglied seit
01.07.2000
Beiträge
24.066
Renomée
10.445
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2021
Auf <a href="http://www.aceshardware.com/read.jsp?id=50000304" TARGET="b">Ace's Hardware</A> ist ein aktueller und hochinteressanter Artikel zu lesen. Es geht um das Thema "Chipset Latency". Die Leser von Planet 3DNow! kennen das aus unseren Mainboard-Reviews. Dort testen wir, wie viele Takte ein Mainboard respektive dessen Chipsatz benötigt, um Daten vom RAM zur CPU zu schaffen. Je kürzer die Zeit, die von der Anforderung bis zur Ablieferung der Daten vergeht, desto besser. Nicht zu verwechseln mit der <a href="http://www.planet3dnow.de/artikel/diverses/viamem/index.shtml">Memory-Bandwidth</A>. Das ist der Durchsatz, den ein Chipsatz im Burst-Mode liefern kann, wenn die Daten bereits angefordert sind.

In unseren <a href="http://www.planet3dnow.de/archiv/index_mb.shtml">Mainboard-Reviews</A> kam bisher ein Athlon "Thunderbird" zum Einsatz (siehe <a href="http://www.planet3dnow.de/artikel/hardware/bestof1/index.shtml">Rückblick & Highlights</A>). Dieser Prozessor besitzt keine Prefetching-Unit, also keine Einheit, die Daten auf Verdacht im Voraus aus dem Speicher in den CPU-Cache holt, weil der Algorithmus "denkt", das Programm könne dies oder jenes eventuell gleich benötigen. Nein, ohne diese Einheit muß der Chipsatz die Daten in dem Moment aus dem RAM holen, wenn der Prozessor feststellt, daß sie sich nicht im Cache befinden (Cache Miss). Ein Test mit unserem Sciencemark mißt also die Latenz des Chipsatzes beim Zugriff auf das RAM.

Nicht so beim Athlon XP und beim Pentium 4, die beide mit einer Prefetch-Unit ausgestattet sind! Der selbe Test spuckt bei diesen Prozessoren natürlich auch einen Wert aus, allerdings sagt dieser weniger etwas über die Qualität des Chipsatzes aus, als vielmehr über die Güte der Prefetch-Unit. Und hier sieht es für den Athlon XP im Vergleich zum Pentium 4 nicht sehr gut aus! Während der P4 beim Zugriff auf einen 64 Byte Block nur 78 Zyklen verstreichen läßt, nimmt sich der Athlon XP satte 185 Zyklen Zeit! Bei 128 Byte Blockgröße herrscht immerhin Gleichstand mit 250:252. In Sachen Prefetch-Algorithmus hat AMD für kommende Prozessoren also noch deutlichen Verbesserungsspielraum.

Daß Unterschiede in der Qualität der Chipsatzes auch mit Prefetch-Unit nicht vollends verwässert werden, zeigt der Sockel-A-interne Vergleich VIA KT333 gegen den neuen nForce2. Während bei unseren bisherigen Tests der KT333 in Sachen Chipset-Latency stets im Vorderfeld zu finden war, AMD 761 und ALi MAGiK 1 deutlich hinter sich lassend, scheint nVidia beim nForce2 nun noch eine Schippe draufgelegt zu haben. 16% niedriger liegen die Latenzen des nForce2 gegenüber dem bisherigen Klassenprimus - und das auch noch bei 10% höherer gemessener Bandwidth. In unserem ersten Review eines Final-Boards für den Verkauf werden wir das Thema ganz sicherlich noch einmal detailliert aufrollen, auch im Vergleich mit dem SiS 745, der in Form des A7S333 ebenfalls noch in unserer TBred-B Warteschleife hängt...
THX @Jensibensi für den Hinweis :)
 
Die Frage ist aber auch, ob der Athlon vielleicht nur bei den verwendeten Zugriffsmustern schlechter ist. Könnte durchaus sein, dass das Ergebnis bei anderen Mustern genau umgekehrt ist.
 
@intel_hasser

Wenn man dem Artikel glauben schenken darf, ist gerade bei Quake die Abfolge der Speicherzugriffe sehr logisch aufgebaut. Und gerade hier kriegt der Athlon ja immer Haue in den Benchmarks.

Und bei unlogischen Zugriffen wird keine Prefetching Unit der Welt was reißen, daß heißt ich glaube kaum, daß der Athlon bei anderen Mustern deutlich vorn liegen wird.

Beim Hammer wird jedenfalls die beste Latency auf der Chipsatzseite erreicht, durch die dirkte Anbindung an die CPU. Ich meine gelesen zu haben, daß auch eine verbesserte Prefetching Unit kommen soll.

Also hoffen wir mal wieder auf den Hammer.

Ciao Jensibensi
 
Zuletzt bearbeitet:
Ich hoffe jetzt nichts überlesen zu haben, aber ist es nicht so, dass der Benchmark die durchschnittliche Zugriffszeit auf Speicherblöcke misst und dadurch auch die Größe und Geschwindigkeit des Cache eine Rolle spielen. Dort hat der Northwood extreme Vorteile.

Und selbst wenn die Prefetch Einheit des Northwood schneller ist heißt das für mich noch lange nicht, dass sie automatisch besser ist. Ich denke vielmehr dass die Northwood Prefetch Unit viel verschwenderischer mit der Bandbreite umgeht als die des XP, d.h. sie könnte einfach mal grundsätzlich mehr Datenpakete prefetchen, was sich beim Athlon XP aufgrund der wesentlich mehr beschränkten Speicherbandbreite negativ auswirken könnte. Ich denke das schlechte Abschneiden des Pentium zusammen mit dem i845 und PC133 er Speicher ist damit zu erklären.
 
Hatte nicht bereits der originale NForce eine eigene Prefetching Unit?

Das die NForce2-Ergebnisse nicht vom Prefetching des Prozessors abhängen (man vergleiche auch Athlon C gegen XP Werte) wäre doch dann keine wirkliche Überraschung.
 
Ja, aber nur weil der TB keine hat. Damit wollte Nvidia seinem Chipsatz zu mehr Performance verhelfen, aber inzwischen bringt es ja wegen der Prefetching Unit im Xp keine Vorteile mehr. Das Limmitierende ist ja immernoch die Speicherbandbreite.
 
Hi,

meine auch, daß der nForce1 eine PrefetchUnit hat. Wenn sie nichts beim Palomino bringt heißt daß aber doch nur, daß die Prefetch Unit des Palomino besser ist, oder?

Ciao Jensibensi
 
Original geschrieben von Nero24
Während der P4 beim Zugriff auf einen 64 Byte Block nur 78 Zyklen verstreichen läßt, nimmt sich der Athlon XP satte 185 Zyklen Zeit! Bei 128 Byte Blockgröße herrscht immerhin Gleichstand mit 250:252.
Hat vielleicht schon mal jemand daran gedacht, daß das einfach dran liegen kann, daß der P4 128Byte (sectored) cache lines hat, während der Athlon 64Byte lange cache lines besitzt?
Das ist wohl die einfachste Erklärung. Anders ist auch der große Einbruch des P4 beim Schritt von 64Byte zu 128Byte strides nicht zu erklären.

Gipsel
 
Der Athlon hat 64 byte Cache Line Size, der P4 128, das ist korrekt. Aber sollte der Athlon nicht gerade deswegen schneller sein, weil ihm die 64 byte auf den Leib maßgeschneidert sind? Die überflüssigerweise geladene zweite Linehälfte beim P4 würde ja nur dann etwas bringen, wenn der Scienemark so "blöd" programmiert wäre, daß die zweite Hälfte zufällig den nächsten Blöck darstellen würde. Bei einem Benchmark, der die Latenzen messen soll und nicht Bandbreite - darf man da nicht davon ausgehen, daß die zweite Hälfte der 128 byte Line nur sehr unwahrscheinlich zufällig der gewünschte zweite 64 byte Block sein würde? Ansonsten hätte der Test seinen Einsatzzweck ja total verfehlt!

Was weiterhin irgendwo unlogisch ist, daß der P4 bei 128 byte Size dann plötzlich hinten liegt - und das obwohl der Athlon hier definitiv 2 Anforderungen braucht, der P4 aber nur eine.

Alles ein wenig Verworren das Ganze. Wahrscheinlich ist keine Begründung, die wir und Ace's Hardware abgegeben haben, zu 100% korrekt. Vielleicht liegt der Grund auch am zusätzlichen Datenpuffer im Chipsatz, dem mini-L3-Cache, den die i845 Plattform besitzt, wer weiß...
 
Original geschrieben von Nero24

Was weiterhin irgendwo unlogisch ist, daß der P4 bei 128 byte Size dann plötzlich hinten liegt - und das obwohl der Athlon hier definitiv 2 Anforderungen braucht, der P4 aber nur eine.


Könnte das nicht daran liegen, daß der P4 wegen seiner ultralangen Pipline viel kritischer auf unerwartete Verzweigungen reagiert. Wenn die Daten nicht so kommen wie die Prefetch Unit das prophezeit hat, muß der P4 doch erst wieder die lange Pipline leerräumen, oder mach ich jetzt nen Denkfehler? Ich meine mal gelesen zu haben, daß das zwei Takte dauern kann.

Ciao Jensibensi
 
Zuletzt bearbeitet:
Original geschrieben von Nero24
Der Athlon hat 64 byte Cache Line Size, der P4 128, das ist korrekt. Aber sollte der Athlon nicht gerade deswegen schneller sein, weil ihm die 64 byte auf den Leib maßgeschneidert sind? Die überflüssigerweise geladene zweite Linehälfte beim P4 würde ja nur dann etwas bringen, wenn der Scienemark so "blöd" programmiert wäre, daß die zweite Hälfte zufällig den nächsten Blöck darstellen würde. Bei einem Benchmark, der die Latenzen messen soll und nicht Bandbreite - darf man da nicht davon ausgehen, daß die zweite Hälfte der 128 byte Line nur sehr unwahrscheinlich zufällig der gewünschte zweite 64 byte Block sein würde? Ansonsten hätte der Test seinen Einsatzzweck ja total verfehlt!

Was weiterhin irgendwo unlogisch ist, daß der P4 bei 128 byte Size dann plötzlich hinten liegt - und das obwohl der Athlon hier definitiv 2 Anforderungen braucht, der P4 aber nur eine.
Um das zu verstehen, muß man wissen, wie die Zugriffsmuster sind. Die wurden alle in vor-Prefetch-Zeiten entwickelt, greifen also in linearer Weise auf den Speicher zu. Dies geschieht mit unterschiedlichen "strides", also Schritten bzw. Abständen zwischen den Speicheradressen auf die zugegriffen wird.
Traditionell greift man in 4, 8, 16, 32, 64, 128 usw. Byte Schritten auf den Speicher zu, wobei aber nur jeweils 4 Byte wirklich gelesen werden. Bei 64 Byte strides sind also die Adressen auf die nacheinander zugegriffen wird:
[base+0]
[base+64]
[base+128]
[base+196]
[base+256]
usw.

Dadurch liegt der zweite Zugriff beim Athlon außerhalb der Cacheline, die durch den ersten geladen wird, beim P4 aber innerhalb. Dadurch der große Unterschied.
Bei 128Byte strides müssen beide eine neue Cacheline laden, was für den Athlon nicht der große Unterschied ist, beim P4 aber einen gehörigen Einbruch produziert.

Dieser praktisch lineare Zugriff auf den Speicher mit festen strides stellt meiner Meinung nach eine recht starke Verfälschung der Latenzmessung bei CPUs mit prefetch dar. Man sollte sich daher überlegen, ob andere Methoden nicht geeigneter wären.

Gipsel
 
lässt sich 'ne Sinus berechnung im Cache machen? (sry, aber ich kenn den assemblercode dafür nicht)

Man könnte auch vorher einen komplexen Algorithmus schreiben, der eine Liste für zugriffe erstellt, die dann in den Cache geladen wird.
 
@Gipsel

Wenn ich dich richtig verstehe widerspricht das aber nicht der Aussage, daß Intel ein besseres Prefetch hat oder? Es heißt lediglich, daß bei zu großen Strides die Cachegröße der limitierende Faktor ist, oder lieg ich falsch???

Was macht Prefetch eigentlich genau (zugegeben ein bissel blöd das jetzt zu fragen nachdem man schon munter mitdiskutiert hat :])?

Ich dachte Dataprefetch versucht die nächstwahrscheinlichen Daten in den Cache zu laden, bevor die CPU sie eigentlich braucht. (Mir ist jetzt schon klar das die Prefetcheinheit Teil der CPU ist, ich kann grad nich besser formulieren:-[ )

Ciao Jensibensi
 
Original geschrieben von jensibensi
Wenn ich dich richtig verstehe widerspricht das aber nicht der Aussage, daß Intel ein besseres Prefetch hat oder? Es heißt lediglich, daß bei zu großen Strides die Cachegröße der limitierende Faktor ist, oder lieg ich falsch???
Nein, das widerspricht nicht dem besseren prefetch seitens Intel, es erklärt lediglich den großen Vorteil des P4 bei 64Byte strides und den starken Einbruch des P4 beim Schritt zu 128Byte.

Die Cachgröße spielt nur eine untergeordnete Rolle. Bei großen Strides soll eigentlich direkt die Latenz des Hauptspeichers gemessen werden, also ohne Einfluß des Caches (bei kleinen wird die Messung ja wie gesehen durch die Caches beeinflußt). Das klappt heutzutage eigentlich nur, wenn man irgendwie die prefetch units austricksen kann (beim P4 durch strides mit 4kB oder mehr möglich), oder sich andere Zugriffsverfahren ausdenkt. Sonst mißt man mehr die Bandbreite, bzw. die Speicherlatenz von Streaming-Anwendungen. Ohne Streaming ist das Zugriffsmuster auf den Speicher sonst eher zufällig (bei kleineren Datenmengen), da die geordneten Zugriffe durch die Caches abgefangen werden.

Original geschrieben von jensibensi
Was macht Prefetch eigentlich genau [..]?
Tja, prinzipiell versucht es benötigte Daten schon in die Caches zu laden, bevor sie angefordert werden und so die scheinbare Speicherlatenz zu vermindern.
Praktisch kann man nur lineare Zugriffe vorhersagen, also Zugriffe in den jetzt ausführlich besprochenen Strides.
Beim reinen Streaming werden alle Daten aus einem zusammenhängendem Speicherblock (linear, d.h. der Reihe nach) ausgelesen. Der Prozessor fordert vom Chipsatz (Speichercontroller) die Daten immer in cache lines an. Ohne prefetch (sowohl Soft- und Hardware) führt das dazu, daß der Speichercontroller in der Zeit der Datenbearbeitung durch die CPU Däumchen dreht, da die CPU ja die Daten bekommen hat, die sie angefordert hat. Erst wenn die Daten der kompletten cache line bearbeitet sind, sendet die CPU die Anforderung für die nächste line. Das ist natürlich sehr ineffizient.
Daher lädt man mit prefetch immer schon die nächste(n) cache lines, bevor sie wirklich gebraucht werden, was die genutzte Bandbreite und die Abarbeitungsgeschwindigkeit deutlich erhöhen kann.

Per Software kann man prefetch mit beliebigen (unregelmäßigen) Zugriffsmustern betreiben. Hardware prefetch dagegen kann nur Zugriffe in strides erkennen, z.B. wenn man auf jede vierte cache line zugreift. Solche Muster sind recht einfach zu erkennen und nach wenigen Zugriffen fängt die prefetch unit an, das erkannte Zugriffsmuster einfach fortzusetzen.

Gipsel
 
@Gipsel

Thx.

Bleibt mir als Laien nur die Frage, was macht Intel denn dann soviel besser als AMD, wenn man per Hardwareprefetch nur einfache Muster wie z.B. jedes vierte Cache Line erkennen kann. Das werden die AMD'ler ja wohl auch wissen.

Und Prefetch per Sotware geht doch nicht bei der CPU, (außer vielleicht beim Transmetachip, da wird doch ein Teil in Software ausgelagert, wenn's auch nicht hierhergört), oder ???

Außer bei Streaming müsste Prefetch doch auch bei jeder programmierten Schleife funktionieren (unvorhergesehen Verzweigungen mal außenvorgelassen), oder ist das auch schon streaming?.

Ciao Jensibensi
 
Original geschrieben von jensibensi
was macht Intel denn dann soviel besser als AMD, wenn man per Hardwareprefetch nur einfache Muster wie z.B. jedes vierte Cache Line erkennen kann. Das werden die AMD'ler ja wohl auch wissen.

Und Prefetch per Sotware geht doch nicht bei der CPU, (außer vielleicht beim Transmetachip, da wird doch ein Teil in Software ausgelagert, wenn's auch nicht hierhergört), oder ???

Außer bei Streaming müsste Prefetch doch auch bei jeder programmierten Schleife funktionieren (unvorhergesehen Verzweigungen mal außenvorgelassen), oder ist das auch schon streaming?
Der prefetch-Algorithmus kann sich trotzdem stark unterscheiden, z.B. wie weit voraus er prefetched, wie lange er braucht, um ein Muster zu erkennen und anderes. Und dann kommt da auch noch die höhere FSB-Bandbreite des P4 ins Spiel, die einfach auch ein exzessives prefetching verträgt. Bei AMD-CPUs muß man ein wenig mehr mit prefetches haushalten.

Der Software-Prefetch geht seit der Einführung des SSE-Befehlssatzes (bei AMD seit original K7 mit enhanced 3DNow!). Das sind einfach zusätzliche Befehle, die dem Prozessor sagen, hole mal die cache line aus dem Hauptspeicher in den Cache, die werde ich später mal brauchen. Damit kann der Programmierer das prefetching steuern. Die muß man jeweils während der Programmentwicklung einbauen, das geht also nicht über einen nachträglich zu ladenden Treiber oder so.

Bei kleinen Schleifen spielt das prefetch nur eine Rolle, wenn bei jedem Durchlauf auf eine andere Speicheradresse zugreift. Wennman nur einen kleinen Speicherblock (ein paar kB) millionenmal durchnudelt, liegt sowieso alles im Cache, dann ist der prefetch egal. Greift man auf größere Datenmengen zu, kann es streaming oder ein Zugriff mit strides sein, wo prefetch helfen kann. Bei zufälligem Zugriff auf große Datenmengen, ist er wieder egal, da die Speicheradressen nicht vorhergesagt werden können.

Gipsel
 
@Gipsel

Nochmals Thx.

Jetzt hast du mich restlos befriedigt. Keine weiteren Fragen mehr, außer vielleicht einer eher privaten, woher weißt du sowas... Du arbeitest nicht zufällig in der Nähe von Dresden.;D

Ciao Jensibensi
 
Original geschrieben von jensibensi
woher weißt du sowas... Du arbeitest nicht zufällig in der Nähe von Dresden.;D
Nein, ich bin Physik-Student in Rostock.
Nur nebenbei beschäftige ich mich ab und zu mal mit Prozessorarchitekturen und optimierter Programmierung dieser. Daher auch mein Wissen über die Latenzmessungen per strides, das habe ich selbst schon gemacht.

Gipsel
 
Noch ein Physiker, meine Wenigkeit hat Physik in Münster studiert, wenn auch mit relativ bescheidenem Erfolg.

Viel Spass beim Studium, vielleicht trifft man sich ja mal wieder hier im Forum.

Ciao Jensibensi

P.S. Du machst nicht zufällig bei Seti@Home mit, Planet nimmt gerne noch Mitcruncher auf. Infos im Link

http://www.planet3dnow.de/vbulletin/showthread.php3?s=&threadid=29173
 
Zurück
Oben Unten