Wieviel % in einem CPU sind Cache?

[2L4Y]

Wieviel Transistoren sind speicher in einem CPU und wieviel Arbeiten wirklich?
Mal angenommen ich habe ein Q6600, der hat 582 Millionen, aber wieviel arbeiten da wirklich?

[AnarchX]

65nm C2D mit 2MiB L2 Cache:
Die-Größe: 111 mm² bei 167 Millionen Transistoren

65nm C2D mit 4MiB L2 Cache:
Die-Größe: 143 mm² bei 291 Millionen Transistoren

http://de.wikipedia.org/wiki/Liste_der_Intel-Core-Prozessoren

-> ~ 43 Mio. Transitoren für beide Kerne und deren L1-Caches.

Wenn du an der flächenmässigen Verteilung interessiert bist:
http://www.chip-architect.com/news/2007_02_19_Various_Images.html

Also kann man sagen, dass bei den (x86-)CPUs doch der Cache einen großen Teil der Chipfläche und somit auch des Transitorbudgets einnimmt, zumal man hiermit recht einfach die Leistung steigern kann ohne, dass der Verbrauch sehr steigt.

[Spasstiger]

Klassischer SRAM benötigt 6 Transistoren pro Bit, also 50 Mio. Transistoren pro MiB. Hinzu kommen noch Transistoren für die Ansteuerung des Caches.
Aber wahrscheinlich hat Intel auch ein paar Tricks drauf, um den Transistorbedarf von Caches zu senken.

Der Unterschied zwischen dem Allendale (2 MiB L2-Cache) und dem Conroe (4 MiB L2-Cache) wird wohl auch nicht alleine die Cachemenge sein, sonst wären das ziemlich transistorraubende Caches mit 62 Mio. Transistoren pro MiB L2-Cache.

Vergleicht man den Wolfdale-3M (274 Mio. Transistoren) und den Wolfdale-6M (410 Mio. Transistoren), so fällt auf, dass für die 3 MiB an zusätzlichem Cache maximal 136 Mio. Transistoren benötigt werden, also 45,3 Mio. Transistoren pro MiB L2-Cache.

[BlackBirdSR]

Klassischer SRAM benötigt 6 Transistoren pro Bit, also 50 Mio. Transistoren pro MiB. Hinzu kommen noch Transistoren für die Ansteuerung des Caches.
Aber wahrscheinlich hat Intel auch ein paar Tricks drauf, um den Transistorbedarf von Caches zu senken.

Der Unterschied zwischen dem Allendale (2 MiB L2-Cache) und dem Conroe (4 MiB L2-Cache) wird wohl auch nicht alleine die Cachemenge sein, sonst wären das ziemlich transistorraubende Caches mit 62 Mio. Transistoren pro MiB L2-Cache.

Vergleicht man den Wolfdale-3M (274 Mio. Transistoren) und den Wolfdale-6M (410 Mio. Transistoren), so fällt auf, dass für die 3 MiB an zusätzlichem Cache maximal 136 Mio. Transistoren benötigt werden, also 45,3 Mio. Transistoren pro MiB L2-Cache.

Da kommt ne Menge an Redundanz, Steuerungslogik und Anbindung hinzu. Das macht schon was aus.

[Haarmann]

http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel3/4251/12029/00553582.pdf?temp=x

4T reichen auch - bei SRAM ein alter Hut.

Damit erklären sich imho die Intel Zahlen von alleine.

[Gast]

4T reichen auch - bei SRAM ein alter Hut.

intel verwendet allerdings 6T-technik, im nehalem sogar 8T.

[Haarmann]

Gast

Beziehst Du Dich zufällig auf diese Folie?

http://www.computerbase.de/bildstrecke/22569/13/

Ich lese nur was von Core Memory - es sei jedem Leser frei gestellt, ob er daraus allen Cache machen will - ich jedenfalls deute das nicht so.

[Acrylsäure]

Ich lese nur was von Core Memory - es sei jedem Leser frei gestellt, ob er daraus allen Cache machen will - ich jedenfalls deute das nicht so.
hmm... ich denke schon dass der komplette cache dann in 8T designt wird/wurde...
schließlich soll der CoreI7 weniger strom verbrauchen...

[Gast]

Ich lese nur was von Core Memory - es sei jedem Leser frei gestellt, ob er daraus allen Cache machen will - ich jedenfalls deute das nicht so.


ich glaube das bezieht sich nur auf L1 und L2, nicht aber auf L3.

[Coda]

Gast

Beziehst Du Dich zufällig auf diese Folie?

http://www.computerbase.de/bildstrecke/22569/13/

Ich lese nur was von Core Memory - es sei jedem Leser frei gestellt, ob er daraus allen Cache machen will - ich jedenfalls deute das nicht so.
Intel verwendet in Atom 8T-Zellen und bei Desktop-CPUs 6T für Cache.

Ob sie bei Nehalem auch für den Desktop schon 8T-Zellen verwenden weiß ich nicht.

[Acrylsäure]

ich glaube das bezieht sich nur auf L1 und L2, nicht aber auf L3.
Der gehört ja auch nicht direkt zum core... "Core Memory" => L1 und L2-Cache, der direkt zum Core gehört...
den L3-Cache teilen sich ja die Cores

[Haarmann]

Wenn ich mal einfach dieses Bild in den Raum stelle, davon ausgehe, dass dies Bild korrekt ist mit den Angaben

http://chip-architect.com/news/Nehalem_at_1st_glance_.jpg

und es deute, dann ist Core Memory schlicht der L1 + Zugemüse, denn die anderen Caches sind nicht im Core und da der L2 wirklich 1/4 des L3 ausmacht, als Fläche, gehe ich auch davon aus, dass er mit der gleichen Anzahl T pro Zelle aufgebaut wurde.

Auch ein Nachrechnen ergibt mit 8T zuviele T für den Cache, wenn es wirklich nur 731 mio sein sollen.

[Acrylsäure]

Wenn ich mal einfach dieses Bild in den Raum stelle, davon ausgehe, dass dies Bild korrekt ist mit den Angaben

http://chip-architect.com/news/Nehalem_at_1st_glance_.jpg

und es deute, dann ist Core Memory schlicht der L1 + Zugemüse, denn die anderen Caches sind nicht im Core und da der L2 wirklich 1/4 des L3 ausmacht, als Fläche, gehe ich auch davon aus, dass er mit der gleichen Anzahl T pro Zelle aufgebaut wurde.

Auch ein Nachrechnen ergibt mit 8T zuviele T für den Cache, wenn es wirklich nur 731 mio sein sollen.
ich trau dem bild kein stück weit... der core i7 hat doch 256KB cache/core... und im Intel® Core™ i7 Processor Extreme Edition Series and Intel® Core™ i7 Processor Datasheet - Volume 2 steht: "Non-core — The portion of the processor comprising the shared cache, IMC and Intel QPI Link interface."
=> L2-Cache gehört zum Core und hat 8T/Zelle

[Haarmann]

Acrylsäure

Leider finde ich kein Bild vom Nehalem in der Qualität...

http://techreport.com/r.x/phenom/phenom-die.jpg

Da sähe man die Blocks wirklich genauer - nur isses die falsche CPU. Ich sehe in den Cores drum imho nicht genügend Blocks, als dass ich dort L2 Cache vermuten könnte. Dummerweise kann das auch der Aufnahme geschuldet sein - und eine Bessere hab ich nicht zur Hand.

Ich zähle dort einfach 5 Blocks quer und 8 hoch pro Einheit. Entweder wäre das L2 in Block 5, muss nicht sein, oder es ist 25% zuviel. Mit 25% zuviel ist es unmöglich 8T für L3 zu nutzen bei 731 mio T.

Ich denke mindestens L3 ist nicht in 8T aufgebaut.

Wo genau L2 ist... ich weiss und sehe es auf dem Bild schlicht nicht. Vielleicht hat wer ein besseres Bild?

[Acrylsäure]

also die Intel-Webpräsenz ist ja mal sehr aussagekräftig by the way... hab dort nirgendwo gefunden wieviel L2-Cache jeder Core hat. Aber es scheinen 256 KB zu sein.

@Haarmann: Der L3 ist auch nicht in 8T aufgebaut. Der wird weiterhin in 6T sein. Nur L1 und L2 sind in 8T.

Edit: http://chip-architect.com/news/Shanghai_Nehalem.jpg

Das scheint "richtiger" zu sein... der L2 ist mit im Core drinne...

[Haarmann]

Acrylsäure

Vergleiche die L2 Fläche mit der L1 Fläche. Pi mal Daumen ist L1 fast so gross wie L2, also auf dem Bild als Fläche gesehen. Spräche gegen eine These, dass die beiden identisch aufgebaut wären.

Wieviel L2 es sein soll hab ich bei Intel leider eben auch nicht gefunden. Da bin ich ja beruhigt, wenn es nicht nur mir so geht.
Einen Versuchsprozessor habe ich auch nicht für Tests.

Der Speicherbus scheint 4 Einheiten aufzuweisen und nicht 3 - wenn der "Xeon" davon 4 Kanäle ansteuern wird, dann ergibt das auch Sinn imho.

Beim L3 sind wir ohnehin gleicher Ansicht - der ist nicht 8T.

[Acrylsäure]

@Haarmann: Also bisher hab ich überall gelesen dass der L2 auch in 8T aufgebaut ist. Beim Vergleich der Chipfläche auf dem Bild fällt das jedoch schwer zu glauben...
Aber wie gesagt trau ich diesen Bildern auch nicht sehr weit... schade nur dass man bei Intel alles mögliche findet, aber noch nicht einmal die Größe des L2-Caches geschweige denn der Aufbau von diesem...

[Gast]

Vergleiche die L2 Fläche mit der L1 Fläche. Pi mal Daumen ist L1 fast so gross wie L2, also auf dem Bild als Fläche gesehen. Spräche gegen eine These, dass die beiden identisch aufgebaut wären.

du kannst aus der fläche nicht auf die verwendeten transistoren schließen, die packdichte ist unterschiedlich.

[Coda]

Den Bildern von Chip Architect kannst du ruhig trauen.

[Acrylsäure]

du kannst aus der fläche nicht auf die verwendeten transistoren schließen, die packdichte ist unterschiedlich.
packdichte? 45nm sind 45nm... warum sollte man transistoren weiter auseinanderlegen? das macht physikalisch keinen sinn...
was sich ändern kann ist die größe des speichercontrollers etc.

[Haarmann]

Acrylsäure

Ich kann Dir nur zustimmen - meine Glaskugel ist leider auch recht trüb Heute...

Coda

Das Speicherinterface sieht imho falsch aus - sehr symetrisch und keineswes in 3 Teile geteilt. Beim Rest fische ich ohnehin im Trüben. Ein besseres Bild liesse die Sache schon viel klarer erscheinen - hab aber leider keines.

Ich denke eine Mischung aus beiden Bildern ergibt am meissten Sinn.

Gast

SRAM Feld ist SRAM Feld - so gleich gefertigt. Und Cache ist SRAM... Selbstverständlich is 4T nicht 6T und nicht 8T - aber 8T ist 8T.

[Coda]

packdichte? 45nm sind 45nm... warum sollte man transistoren weiter auseinanderlegen? das macht physikalisch keinen sinn...
was sich ändern kann ist die größe des speichercontrollers etc.
45nm sind NICHT 45nm. 45nm ist nur die Gatelänge, nicht die Breite. Und es kann durchaus sein, dass man um Hotspots zu vermeiden mit Absicht Transistoren weiter verstreut.

[Acrylsäure]

45nm sind NICHT 45nm. 45nm ist nur die Gatelänge, nicht die Breite. Und es kann durchaus sein, dass man um Hotspots zu vermeiden mit Absicht Transistoren weiter verstreut.
aber solch ein radikaler unterschied bei zwei speicher-feldern die nach der gleichen technik aufgebaut sind halte ich für unwahrscheinlich...

[Wuge]

L1 und L2 wird aus 8T SRAM gefertigt um für die Core ultra niedrige Spannungen zu ermöglichen in den C-States.

Der L3 wird in 6T SRAM hergestellt, da er ohnehin immer mit der Uncore-Spannung befeuert wird.

Quelle hab ich leider nicht mehr zur Hand :(

[turboschlumpf]

Hier ein besserer Die-Shot von Computerbase:

http://pics.computerbase.de/2/3/1/6/9/27.jpg

[Gast]

45nm sind NICHT 45nm. 45nm ist nur die Gatelänge, nicht die Breite. Und es kann durchaus sein, dass man um Hotspots zu vermeiden mit Absicht Transistoren weiter verstreut.

dazu kommen noch design kniffe

[Haarmann]

Danke für das bessere Bild

Wenn die L1 Bereiche wirklich stimmen, dann ist imho L2 mit Reserve gebaut und nutzt weit weniger Fläche, denn L1 für die gleiche Speichermenge. Wenn man die Reserve wegnimmt, dann ist L2 praktisch identisch zu L3 von der Fläche her.

[Flyinglosi]

@Acrylsäure: das dichteste Paket kann man doch gar ned erreichen...schließlich müssen die Transistoren ja irgendwie sinnvoll miteinander verschalten werden...und somit kann man ned einfach Transistor an Transistor packen... (ist nur ne Überlegung...beruht ned auf Wissen ;-))

mfg Stephan

[Acrylsäure]

Ja, das ist klar. Aber die sinnvolle Verschaltung sieht in Speicherbereichen immer gleich aus. Warum sollte dann ein Speicherbereich eine größere/kleinere Speicherdichte haben?

Hat jemand mal eine Skizze wie so eine 8T SRAM-Zelle aussieht?

[mekakic]

Werden Cache und Logik immer im gleichen Fertigungsverfahren gebaut ... wenn sie auf einem Die sind. Oder kann man auf einen Die auch irgendwie nachträglich den Cache draufbrutzeln; da sich die einfachen Cachestrukturen ja idR früher kleiner fertigen lassen.

[immi]

Hi,

hab mal nen vortrag gehoert bei dem es eben um platzverteilung ging....
ein grosser Teil ging dabei um die optimale Verbreitung des Taktsignals und auch des Stroms!
Demzufolge sind an die 20% der Chipflaeche (!!!) mit Leitungen fuer eben diese beiden Dinge verwendet! Wenn es also um die cm^2 geht, sollte das eingerechnet werden.... An der verwendeten Logik - zu der Taktsignal und Strom ja irgendwie nicht gehoert - aendert das natuerlich nix/kaum etwas.

Mich wuerde hingegen interessierren, wie das Verhaeltnis bei "richtigen" Arbeitstieren aussieht, also GPUs. Caches haben die ja auch irgendwo, irgendwie... Aber lesen tut man davon nie irgend etwas...

[Acrylsäure]

@Mekakic: Nein... Ein Chip wird immer als ganzes gefertigt...

Von GPU's hab ich nicht soviel Ahnung. Aber ich glaube die haben keinen Cache und arbeiten doch auch größtenteils mit Pipelining und da ist ein Cache doch nicht so sehr notwendig wie bei einer CPU... Korrigiert mich wenn ich falsch liege ^^

[BlackBirdSR]

@Mekakic: Nein... Ein Chip wird immer als ganzes gefertigt...

Von GPU's hab ich nicht soviel Ahnung. Aber ich glaube die haben keinen Cache und arbeiten doch auch größtenteils mit Pipelining und da ist ein Cache doch nicht so sehr notwendig wie bei einer CPU... Korrigiert mich wenn ich falsch liege ^^

GPUs, DSPs oder Vektorrechner haben alle ihre Caches und Puffer. Ohne geht es gar nicht.
Die Art und Größe der Auslegung ist dann natürlich ein Detail der µArchitektur. Allerdings dürfte die Größe der Caches und Puffer bei aktuellen GPUs ebenfalls einige hunder KB und mehr ausmachen.
Ein Verhältnis wie bei CPUs (gleich oder mehr Fläche ist Cache) wird sich aber nicht einfinden.

CPUs profitieren in diesem Fall einfach von der teils extrem zufällig Zugriffsstruktur von Daten und der großen Anzahl an (un)Conditionellen Sprüngen. Dazu kommt die große Kluft zwischen internem Takt und externer Speicheranbindung. Mehr Cache resultiert dabei fast automatisch in mehr Performance. Da sich Cache in der Regel auch noch günstiger auf Yield und Verbrauch auswirkt, als die meisten Logikschaltungen, ist es ein beliebtes Mittel für Leistungssteigerungen.

[Acrylsäure]

Also ist die Performancesteigerung bei einer GPU auf Grund des Caches nicht so stark wie bei einer CPU?

[immi]

Werden Cache und Logik immer im gleichen Fertigungsverfahren gebaut ... wenn sie auf einem Die sind. Oder kann man auf einen Die auch irgendwie nachträglich den Cache draufbrutzeln; da sich die einfachen Cachestrukturen ja idR früher kleiner fertigen lassen.

Kommt drauf an, wie man "im gleichen Fertigungsverfahren" versteht.
Natuerlich wird der Chip quasi in einem Rutsch gefertigt. Einfach ein Stueck frei lassen und nachher auf eine voellig andere Art den Speicher draufkleben is nich!
Allerdings besteht die chiphertellung aus sehr vielen, teils recht unterschiedlichen Schritten. Die Zeit, dass man sich durchweg fuer NMos, PMos, CMos oder wie auch immer entscheiden musste, sind wohl vorbei. Dennoch gibt es fuer Speicher angepasstere methoden als fuer Logikschaltungen, die gerne auch mal analog aufgebaut werden (wenn mans unter kontrolle kriegt.... voellig anderes thema...).
Wenn man sich Querschnittsbilder von chips anschaut kann man den unterschied sehr schoen erkennen....

GPU-Caches: also wenn ich ueberschlage... 1200 rechen/shadereinheiten mit je bestimmt 20 pipelineschritten... das ganze als "Vektorspeicher" in voller "Farbtiefe" (1200x20x8x8) ca 1.500.000 ?!?? mal ganz ins blaue spekuliert...
und da sind die speicherkontroller noch gar nicht dabei. So gesehen muesste man diese Rechnung fuer cpus auch aufmachen....

[samm]

Hat jemand eine Ahnung, ob in Zukunft Memristoren für Cache eingesetzt werden könnten? Das könnte Interessantes in Bezug auf Anbindung, Platzverbrauch (deswegen frage ich in diesem Topic) und auch sleep-modi etc. bedeuten :)

[BlackBirdSR]

Also ist die Performancesteigerung bei einer GPU auf Grund des Caches nicht so stark wie bei einer CPU?

Nä...
Kommt immer auf die Situation und die Cachegröße an, von der wir hier reden. Es macht wahrscheinlich keinen so großen Sinn einen zentralen 6MB Block auf das DIE einer GPU zu klatschen. AMD und Nvidia werden schon wissen, warum deren Caches näher an den Funktionsblocks liegen.

Auf der anderen Seite ist bei CPUs Cache immer noch eines der billigsten Performance-Features. Mehr Cache bedeutet in der Regel automatisch weniger RAM-Zugriff und damit mehr Performance. Abnehmender Grenzertrag...............

[Acrylsäure]

Also CPUs profitieren vom Cache weil die Wahrscheinlichkeit sehr gross ist dass benötigte Daten im Speicher meist dicht aneinander liegen und diese Speicherbereiche in den Cache geschrieben werden. Gibt natürlich auch Programme wo der Cache eher zu Performanceverlust führt weil die halt ungünstig programmiert sind.

Wie ist das bei GPUs? Was für Daten werden da im Cache abgelegt?

[Aquaschaf]

Was? So ein Programm würde ich aber mal gerne sehen das mit deaktiviertem Cache schneller läuft..

[immi]

Wie ist das bei GPUs? Was für Daten werden da im Cache abgelegt?

ich denke nicht, dass es da "kleine" bereiche gibt, die relativ zeitnah wiederverwendet werden muessten... hat ja schon seinen grund, warum ne graka heutzutage 1gig drauf hat.....

vielmehr wuerde ich als designer caches eher so handhaben wie den sinn der integer-einheiten bei der EPIC-architektur. Da sind die auch dafuer zustaendig, Daten von ausserhalb nachzuladen und bereitzuhalten - also eher als Zwischenspeicher um wartezeiten wegen texturnachladen o.ae. zu verringern. Bei Epic heisst sowas dann speculative-load, waer bei texturen dann schon gar nicht mehr so spekulativ...

groessere Caches zwischen den Pipelinestufen macht m.e. kaum sinn, oder?

[Acrylsäure]

Was? So ein Programm würde ich aber mal gerne sehen das mit deaktiviertem Cache schneller läuft..
Theoretisch gesehen möglich... Cache lohnt ja nur weil statistisch gesehen oft auf den gleichen Speicher zugegriffen wird...
Wenn aber immer auf Speicherbereiche zugegriffen wird die nicht im Cache sind, sondern diese immer nachgeladen werden müssen, dann aber nicht mehr wieder benutzt werden, dann ist das sehr unoptimal.

[Gast]

Theoretisch gesehen möglich...Bist du auch der Meinung, dass es theoretisch auch Programme geben könnte, die noch schneller laufen, wenn wir diesem Computer auch noch den Hauptspeicher wegnähmen und dabei natürlich die Festplattentechnologie als nächste Ebene in der Speicherhierarchie unverändert ließen?

[Coda]

Er hat schon recht. Der Cache erzeugt ein paar Zyklen zusätzliche Latenz beim Zugriff auf den Hauptspeicher.

[haifisch1896]

Ich will nochmal ohne Hintergrundwissen zum Cache der GPU spekulieren:

Ich gehe davon aus, da werden solche Daten vorgehalten wie von den Intel-CPUs seinerzeit in den Befehlscaches.
Also z.B. bestimmte, wiederkehrende Shaderoperationen und dergleichen.

Verschiedene Daten von Pixeln dürften schwierig vorauszusagen sein...

[Acrylsäure]

Bist du auch der Meinung, dass es theoretisch auch Programme geben könnte, die noch schneller laufen, wenn wir diesem Computer auch noch den Hauptspeicher wegnähmen und dabei natürlich die Festplattentechnologie als nächste Ebene in der Speicherhierarchie unverändert ließen?
Nein... der Hauptspeicher arbeitet ja ganz anders als der Cache ;)

[Acrylsäure]

Was? So ein Programm würde ich aber mal gerne sehen das mit deaktiviertem Cache schneller läuft..
Muss da nochmal was zu schreiben... Kompilier mal mit einem Compiler, der noch keinen Cache unterstützt (muss schon ein sehr alter sein). Dann kannst du das gut und gern haben dass das Prog ohne Cache schneller laufen würde ;)

[mekakic]

Welcher Compiler unterstützt denn keinen Cache? :confused: Das macht die CPU doch autark, ob sie eine Speicheradresse im Cache vorhält oder nicht.

[haifisch1896]

Und ist es nicht sowieso schneller, zu prüfen, ob Programmdaten im Cache sind und diese von da zu laden als gleich auf die Speicheradresse im RAM zuzugreifen?
Die Latenzen sind doch viel, viel kürzer. Und wenn Du entsprechend alte Programme hast, ist doch auch absehbar, dass viel Code bzw. Daten davon in die mittlerweile sehr großen Caches aktueller CPUs passen.

[Acrylsäure]

Welcher Compiler unterstützt denn keinen Cache? :confused: Das macht die CPU doch autark, ob sie eine Speicheradresse im Cache vorhält oder nicht.
Alte Compiler unterstützen keinen Cache => der Code wird nicht auf Cachenutzung optimiert. Der Cache wird dann natürlich auch verwendet, aber er bringt nicht den Geschwindigkeitszuwachs den ein auf Cache optimierter Code bringen würde.

[Gast]

Und ist es nicht sowieso schneller, zu prüfen, ob Programmdaten im Cache sind und diese von da zu laden als gleich auf die Speicheradresse im RAM zuzugreifen?

cache arbeitet für die anwendung transparent, diese weiß nichtmal dass der cache existiert.

ein programm greift immer auf eine virtuelle adresse zu, die von der MMU in eine hauptspeicheradresse umgerechnet wird, dabei sieht die cpu dann nach ob die daten bereits im cache sind oder eben nicht.

[Coda]

Ich will nochmal ohne Hintergrundwissen zum Cache der GPU spekulieren:

Ich gehe davon aus, da werden solche Daten vorgehalten wie von den Intel-CPUs seinerzeit in den Befehlscaches.
Also z.B. bestimmte, wiederkehrende Shaderoperationen und dergleichen.

Verschiedene Daten von Pixeln dürften schwierig vorauszusagen sein...
Sind sie auch in der Tat. Deshalb sind die Texture-Caches auch relativ klein und es gibt bei NVIDIA z.B. auch immer noch keine vollassoziativen Caches.

Intel macht bei Larrabee Tiling um wenigstens die Framebuffer-Daten im Cache halten zu können.

Alte Compiler unterstützen keinen Cache => der Code wird nicht auf Cachenutzung optimiert. Der Cache wird dann natürlich auch verwendet, aber er bringt nicht den Geschwindigkeitszuwachs den ein auf Cache optimierter Code bringen würde.
Das halte ich für ein Gerücht, dass ein Compiler auf "Cache" optimieren kann und das so einen großen Unterschied macht. In C/C++ ist schließlich immer noch der Programmierer dafür verantwortlich von welcher Speicheradresse er mit welchem Muster liest.

Der Rest wird völlig transparent von der CPU behandelt, da braucht man keine speziellen Befehlssequenzen erzeugen oder ähnliches. Selbst die Prefetch-Instructions von SSE sind heute fast wirkungslos.

[Acrylsäure]

Das halte ich für ein Gerücht, dass ein Compiler auf "Cache" optimieren kann und das so einen großen Unterschied macht. In C/C++ ist schließlich immer noch der Programmierer dafür verantwortlich von welcher Speicheradresse er mit welchem Muster liest.

Der Rest wird völlig transparent von der CPU behandelt, da braucht man keine speziellen Befehlssequenzen erzeugen oder ähnliches. Selbst die Prefetch-Instructions von SSE sind heute fast wirkungslos.
Ich halte das für kein Gerücht. Hab das auch direkt aus meiner Rechnerarchitektur-Vorlesung gepostet als wir gerade das Thema Cache behandelt haben. ;)
Du musst aber bedenken dass wir da von einer Zeit reden in der der Cache extrem klein war und so der Effekt sicherlich noch größer war bei unoptimiertem Code.
Also wenn ich C programmiere dann überlasse ich das Speichermanagement doch schon dem Compiler. Oder benutzt du statt Variablennamen Speicheradressen?

[Coda]

Ich halte das für kein Gerücht. Hab das auch direkt aus meiner Rechnerarchitektur-Vorlesung gepostet als wir gerade das Thema Cache behandelt haben. ;)
Ich habe schon einen vollassoziativen, synthetisierbaren Cache in SystemC implementiert, sowie die unterschiedlichen Parameter dessen an reellen memory Zugriffsmustern untersucht. Und jetzt?

Der Compiler muss darauf aufpassen, dass er die Daten an die Cache-Lines aligned. Das war's dann im Wesentlichen schon was Optimierung angeht. Es ist ganz sicher nicht so, dass auf einmal der Cache wie nicht vorhanden ist, nur weil man einen älteren Compiler verwendet. Das ist sicher Blödsinn.

Also wenn ich C programmiere dann überlasse ich das Speichermanagement doch schon dem Compiler. Oder benutzt du statt Variablennamen Speicheradressen?
Als ob man große Datenmengen auf dem Stack verwalten könnte.

[Acrylsäure]

Ich habe schon einen vollassoziativen, synthetisierbaren Cache in SystemC implementiert. Und jetzt?
Ja und? :D Musst dich ja nicht gleich persönlich attackiert fühlen o.O

Ich kann hier auch nicht mehr als von den Erfahrungen meines Profs berichten, der mit Sicherheit schon ein wenig länger programmiert als wir beiden ;)

Heutzutage treten solche Effekte nunmal nicht mehr auf...

[Acrylsäure]

Der Compiler muss darauf aufpassen, dass er die Daten an die Cache-Lines aligned. Das war's dann im Wesentlichen schon was Optimierung angeht. Es ist ganz sicher nicht so, dass auf einmal der Cache wie nicht vorhanden ist, nur weil man einen älteren Compiler verwendet. Das ist sicher Blödsinn.
Hat auch keiner behauptet...
Es geht hier schließlich um eine Zeit in der der Cache noch extrem klein(!) war und da ist es dann schon wichtig was hineingeladen wird...

[Coda]

Ja und? :D Musst dich ja nicht gleich persönlich attackiert fühlen o.O
Ich fühle mich nicht persönlich attakiert, ich will nur darlegen warum ich nicht der Meinung bin.

Ich kann hier auch nicht mehr als von den Erfahrungen meines Profs berichten, der mit Sicherheit schon ein wenig länger programmiert als wir beiden ;)
Was genau Null zu sagen hat meiner Erfahrung nach. Bei allem Respekt. Vor allem sind Professoren oft etwas der Zeit hinterher, wenn es nicht genau ihr Forschungsgebiet ist.

Manche sind auch praktisch eher nicht so sehr im Bilde. Aber es kann natürlich auch sein, dass er einer der wenigen ist bei denen das nicht so ist. Gibt es bei uns auch.

Hat auch keiner behauptet...
Es geht hier schließlich um eine Zeit in der der Cache noch extrem klein(!) war und da ist es dann schon wichtig was hineingeladen wird...
Das beeinflusst allein der Prozessor selber, außer man benutzt Prefetch-Instructions. Die gab es aber erst mit SSE oder sogar SSE2.

[Acrylsäure]

Ich fühle mich nicht persönlich attakiert, ich will nur darlegen warum ich nicht der Meinung bin.
Wirkte so, vor allem weil da im Posting nur der eine Satz stand...


Was genau Null zu sagen hat meiner Erfahrung nach. Bei allem Respekt. Vor allem sind Professoren oft etwas der Zeit hinterher, wenn es nicht genau ihr Forschungsgebiet ist.
Von irgendwem muss ich ja lernen. Viele Professoren sind was aktuelle Technik angeht nicht mehr sehr gut im Bilde, das stimmt, aber wovon wir hier reden liegt nun schon so einige Jährchen zurück, da wird er sich hoffentlich noch richtig dran erinnern.

[Coda]

Okay um den Kreis zu schließen: Was glaubst du was genau Compiler tun könnten um den Cache besser auszunützen?

Mir fällt nämlich spontan nichts ein außer korrektes Alignment.

[Acrylsäure]

Ich will jetzt auch nix mehr falsches posten... Werd einfach meinen Prof nochmal fragen... der muss mir das ja genau erklären können. Er hatte es nur kurz angerissen und nicht genau erklärt woher dieser Effekt kam.

[Coda]

Ja tu das. Überhaupt wird eh der meiste Speicher den eine Anwendung anfordert auf dem Heap dynamisch angelegt. Darauf hat der Compiler überhaupt keinen Einfluss mehr.

[Gast]

Ich halte das für kein Gerücht. Hab das auch direkt aus meiner Rechnerarchitektur-Vorlesung gepostet als wir gerade das Thema Cache behandelt haben. ;)

nur was soll der compiler da großartig machen? der cache ist für das programm transparent, außerdem bräuchte man dann für jede cpu ein unterschiedliches kompilat.