Archiv verlassen und diese Seite im Standarddesign anzeigen : Cache und Speed
Hallo,
warum bringt die Erweiterung von z.B. 1 auf 2 MB Chache bei einer CPU nur 5% Speed wenn überhaupt?
Eigentlich braucht doch eine Anwendung wie z.B. Cinema 4D 300MB RAM oder so und der Chache ist doch extrem viel schneller als der RAM....also könnte man doch denken das der doppelte Chache auch ein deutlichen Speed Bonus bringt?!
Es heißt Cache. Und der bringt nur was wenn immer wieder auf die gleichen Daten zugegriffen wird, nicht wenn kreuz-und-quer im Speicher gelesen werden soll.
Kommt auf die Anwendung an. Das hat was mit der Funktionsweise eines Cache zu tun. Beispiel: Die Vorhersage ist bei Applikationen, welche mit festen Algorithmen arbeiten ffektiver als bei denen mit schnell veränderndem oder nicht Algorithmusbasierenden. Dazu gehören VST-FX, Video-PostPro, Photoshop etc.
Die Effektivitität des Cache ist auch abhängig von der Gesamtarchitektur einer CPU. So bringen beispielweise 2MB Cache bei der Athlon64-Architektur mehr, als 2MB bei der NetBurst-Architektur a la Pentium 4 (bestes Beispiel Prescott; hier sollte es sogar Defiziten der Architektur gezielt entgegenwirken).
Am besten wäre natürlich ein L1 oder L2 Cache in der Grössenordnung des Arbeitsspeichers. Dann würde man applikationsunabhängig allgemein gravierende Leistungssteigerungen bemerken.
Wenn auf alle 300 Mb gleich wahrscheinlich zugegriffen wird bringt die Verdopplung von 1 auf 2 Mb eine Beschleunigung um etwa 1/299. Das ist noch viel weniger als 5%.
Wird aber nicht. Man liest immer Daten am Block. Die Wahrscheinlichkeit (baldiger) Wiedernutzung ist auch recht hoch. Ebenso, dass kürzlich geschriebene Daten bald wieder gelesen werden.
Übrigens, bitte: Größe mit ß.
Die Effektivitität des Cache ist auch abhängig von der Gesamtarchitektur einer CPU. So bringen beispielweise 2MB Cache bei der Athlon64-Architektur mehr, als 2MB bei der NetBurst-Architektur a la Pentium 4 (bestes Beispiel Prescott; hier sollte es sogar Defiziten der Architektur gezielt entgegenwirken).
wohl eher umgekehrt, die netburst-architektur profitiert deutlich mehr vom größeren cache als die K8-architektur.
selbst der sempron mit nur 256KB L2 bringt eine anständige performance zustande, während der celeron mit gleicher L2-größe geradezu lachhaft dagegen erscheint.
wobei der gewinn mit zunehmender größe natürlich immer kleiner wird, aber der ertrag nimmt nun mal mit gleichem aufwand ab.
Am besten wäre natürlich ein L1 oder L2 Cache in der Grössenordnung des Arbeitsspeichers. Dann würde man applikationsunabhängig allgemein gravierende Leistungssteigerungen bemerken.
bei jetziger cache-architektur würde nichtmal das wahnsinnig viel bringen, da bräuchtest du schon einen vollassoziativen cache um diese masse überhaupt vollzubekommen ;)
mapel110
2006-02-01, 00:07:01
wohl eher umgekehrt, die netburst-architektur profitiert deutlich mehr vom größeren cache als die K8-architektur.
selbst der sempron mit nur 256KB L2 bringt eine anständige performance zustande, während der celeron mit gleicher L2-größe geradezu lachhaft dagegen erscheint.
Das liegt aber auch daran, dass bei Intel der L1 Cache sehr klein ist.
Wenn auf alle 300 Mb gleich wahrscheinlich zugegriffen wird bringt die Verdopplung von 1 auf 2 Mb eine Beschleunigung um etwa 1/299. Das ist noch viel weniger als 5%.
wieviel würde denn ein cache von sagen wir 512MB bringen (der den RAM ersetzt sozusagen)?
mal als gedankenexperiment...ist ja garnichtmal SO weit weg..der Itanium hat ja auch 30MB oder so
Das liegt aber auch daran, dass bei Intel der L1 Cache sehr klein ist.Dafür ist er sehr schnell und speichert bereits dekodierte Instruktionen.
Da die Intel die Latenzen bei Cachevergrößerung (512kb Northwood 23Zyklen, 1MB Prescott 28 Zyklen, 2MB Prescott 31 Zyklen) erhöht hat, bringt der Speichergewinn je nach Anwendung wenig und gar nichts.
Bokill
2006-02-01, 09:58:09
An sich ist Cache auch nicht notwendig. Im theoretischen Idealfall reicht schlichter Arbeitsspeicher mit gleichem CPU Takt ...
In der Praxis ist Cache sehr wohl eine sinnvolle Krücke, da sich eine immer weiter klaffende Lücke zwischen CPU Takt und Speicherzellentakt auftut. Die langsamen Speicherzugriffe werden gleichsam hinter den schnellen Cachezugriffen versteckt.
Der Trend zeichnet sich zu L3 Cache ab, wenn das Transistorbudget dies zulässt.
Dafür ist er sehr schnell und speichert bereits dekodierte Instruktionen. Jo ... das ist der Trace Cache (http://www.orthy.de/modules.php?name=Encyclopedia&op=content&tid=40). An sich ist der Pentium 4 L1 Cache auch in etwa ähnlich gross (Cachespeicherzellen) wie der vom Athlon, Athlon 64. Allerdings nehmen decodierte Instruktionen wesentlich mehr Platz ein (und kommen auch doppelt und reifach vor). Intel spricht bei der Beschreibung des Trace Cache (http://www.intel.com/support/processors/pentium4/sb/cs-001649.htm) ja auch nicht von KByte, sondern von der Anzahl (12.000) der zwischengespeicherten "micro-ops".
Zu Zeiten von 8086/8088 mußte der Speicher noch auf die CPU warten, da gab die netten Waitstates.
Inzwischen hat sich das mehr als umgekehrt und Speichergeschwindigkeit ist der Flaschenhals.
Dafür ist er sehr schnell und speichert bereits dekodierte Instruktionen.Nein. Es gibt natürlich auch einen L1-Datencache und der ist eben sehr klein.
GloomY
2006-02-01, 18:43:51
Wird aber nicht. Man liest immer Daten am Block. Die Wahrscheinlichkeit (baldiger) Wiedernutzung ist auch recht hoch. Ebenso, dass kürzlich geschriebene Daten bald wieder gelesen werden.Das hängt ganz stark vom Zugriffsmuster ab. Einige Anwendungen haben fast gar keine Wiedernutzung. Deswegen gibt's ja extra Befehle, um am Cache vorbeizuschreiben, damit diese Daten nicht andere wichtige Dinge aus dem Cache rausschmeißen.
Am besten wäre natürlich ein L1 oder L2 Cache in der Grössenordnung des Arbeitsspeichers. Dann würde man applikationsunabhängig allgemein gravierende Leistungssteigerungen bemerken.Dann bräuchte man gar keinen Hauptspeicher mehr ;) Der Cache würde dann quasie zum Hauptspeicher, weil man in ihm ja eh sämtlichen Inhalt des Hauptspeicher unterbringen kann.
bei jetziger cache-architektur würde nichtmal das wahnsinnig viel bringen, da bräuchtest du schon einen vollassoziativen cache um diese masse überhaupt vollzubekommen ;)Für einen Cache dieser Größe spricht nichts dagegen, dass man diesen als direct-mapped implementiert. Vielmehr wäre es sogar die (von mir) präferierte Lösung, weil es bei gleicher Größe von Cache und Hauptspeicher keine Konkurrenz verschiedener Addressen um ein Cache-Set mehr gibt. Es kommt nie vor, dass Daten in gleichen Sets landen, woraus zwangsläufig folgt, dass die Conflict-Missrate garantiert Null ist.
Genauso wie sämtliche Tags. Die kann man sich dann nämlich auch sparen. Um genau zu sein gibt es auch nur dann noch Tags, wenn der Prozessor physisch mehr Speicher addressieren kann, also momentan als Hauptspeicher und Cache verbaut ist. Ansonsten bleiben für den Tag (Rest der Addresse nach Abzug von Offset und Index) Null Bits übrig.
Neomi
2006-02-01, 18:53:45
Dann bräuchte man gar keinen Hauptspeicher mehr ;) Der Cache würde dann quasie zum Hauptspeicher, weil man in ihm ja eh sämtlichen Inhalt des Hauptspeicher unterbringen kann.
Das wäre dann der Tod für Multi-CPU-Maschinen. Allerhöchstens eine einzelne MultiCore-CPUs mit gemeinsam genutztem "Cache" für alle Cores wäre dann noch betriebsfähig.
GloomY
2006-02-01, 19:52:01
Das wäre dann der Tod für Multi-CPU-Maschinen. Allerhöchstens eine einzelne MultiCore-CPUs mit gemeinsam genutztem "Cache" für alle Cores wäre dann noch betriebsfähig.Hmm, eigentlich habe ich gerade eben nicht an Systeme mit mehr als einer CPU gedacht, aber:
Ich denke, dass es auf das Cache-Kohärenzprotokoll ankommt. MESI wird wahrscheinlich nicht funktionieren, weil es zwingend den Hauptspeicher zum Zurückschreiben von Cachelines benötigt, die dirty sind und auf die ein anderer Prozessor zugreifen möchte. Der Austausch findet hier nicht direkt zwischen den beiden Prozessoren statt sondern zwischen Prozessor1 und Speicher und dann zwischen Speicher und Prozessor2.
Das ist bei MOESI nicht der Fall, bei dem üblicherweise kein Bus sondern für jeden Prozessor einzelne Punkt-zu-Punkt Verbindungen zum Chipsatz bestehen. Da können die Prozessoren direkt miteinander Daten austauschen, ohne auf den Hauptspeicher zurückzuschreiben.
Wenn der fehlt, stört das nicht wirklich.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.