News Neues Cache-Design soll Prozessoren beschleunigen

[Tobi4s]

Da wir ja nun ausgiebig geklärt haben, dass es nicht geht, den Cache auszulagern, werfe ich mal meine Idee in den Raum: Prozessoren würfelförmig machen!

Mal völlig außer acht aller elektronischer Hindernisse, weil ich davon keine Ahnung habe, wie willst du das denn vernünftig kühlen? Dann hat der Chip an der Oberseite 50 Grad und drunter schmilzt dir das Silizium. Halte ich für kaum machbar...

Die haben als Testszenario einen Prozessor mit 64 cores und ungewöhnlicher Architektur verwendet.

Called it!

 

[Krik]

dann kam Athlon II und danach war zu wenig und Cache Probleme unter Windows Vista vorhanden, die sogar zu Abstürzen führten, musste man mit eine Softwareumgehung von Sektoren lösen.

Wat?
Davon habe ich noch nie gehört. Sicher, dass du da nicht etwas verwechselst?

Prozessoren würfelförmig machen! Da hat man maximal kurze Wege [...] und auch die Kühlung dürfte problematisch werden, aber für die Signallaufzeiten ist das doch besser, oder nicht?

Die Kühlung ist in der Tat das größte Problem an dieser Konstruktion. Moderne CPUs sind bereits mehrschichtig. Würde man aber so viele aufschichten, wie du es vorschlägst, würden sie leider verglühen.
Die Signallaufzeiten sind bei den momentanen Taktraten und Distanzen zwischen Cache und Funktionseinheiten völlig i. O. Daran muss man aktuell nichts drehen.


Ich hätte gerne über alle Cache-Level hinweg UMA. Also alle Cores sollen auf jeden Cache den gleichen Zugriff haben. Das macht zwar die Zugriffssteuerung kompliziert, aber dafür steht zB bei nur einem Thread einem Core der gesamte Cache in der CPU zur Verfügung. Die anderen Cores machen derweil Pause.
Kurz gesagt, ich frage mich, ob es etwas bringt, wenn man exklusive Caches abschafft und jedem Kern dieselben Zugriffsrechte erteilt.

 

[Haskell]

Der Artikel ist fehlerhaft. Anders als dargestellt handelt es sich mitnichten um ein Hardware-Design, sondern um ein Softwareprotokoll für die effektivere Nutzung des Cache für Multicore-Architekturen. Dennoch bin ich verwirrt warum ihr überhaupt diesen Artikel bringt. Anhand einiger Kommentare sieht man, dass ihr damit die falsche Zielgruppe anspricht.

 

[Mr.Seymour Buds]

Sollten die Chiphersteller tatsächlich nicht darauf gekommen sein, dass sich auf so relativ simple Art 15% Leistungssteigerung erreichen lassen?

Tja was soll man dazu noch sagen? 15% schnellere Zwischenspeicher bekommt man natürlich !1!! auf so "relativ simple Art" zusammen.

 

[r4yn3]

Der Artikel ist fehlerhaft. Anders als dargestellt handelt es sich mitnichten um ein Hardware-Design, sondern um ein Softwareprotokoll für die effektivere Nutzung des Cache für Multicore-Architekturen.

Vielen Dank für die Antwort, genau danach wollte ich eben fragen.

Um das als Laie zu verstehen, wollte ich dennoch meine Frage stellen. Was verwaltet denn Grundsätzlich den Speicherort vom Cache? Wenn es sich um Software handelt, dann müsste dieses Konzept Softwareentwickler, Microsoft etc. umsetzen, oder inwiefern müsste hier Intel/AMD deren Cachedesign umändern?
Geht aus dem Text im Paper hervor, ob es sich beim Projekt um eine bestehende, bekannte Architektur handelt?

Zum Cache selbst. Ich denke mal dass sich hier als LLC mal der Hybrid Memory Cube als nützlich erweiesn wird, kann das sein?

 

[Krik]

Ich begebe mich vermutlich auf's Glatteis, aber ich hoffe, größtenteils richtige Antworten zu geben. Das Thema ist ziemlich komplex.

Zunächst muss man zwischen Befehls- und Datencache unterscheiden. Im Befehlscache landet das auszuführende Programm, im Datencache die Daten, mit denen das Programm arbeiten soll.

Der Datencache ist relativ simpel. Da ist alles drin, womit das Programm gerade arbeitet. Fehlt etwas, werden Daten aus dem RAM nachgeladen. Oft ist es dabei so, dass mehr als eigentlich gerade benötigt wird, kopiert wird. Der Grund liegt darin, dass die "überflüssigen" Daten in einem der nächsten Programmschritte wichtig sein könnten (d. h. es gibt eine gewisse Wahrscheinlichkeit dafür).

Der Befehlscache ist etwas anders organisiert. Hier wirken Compiler-Optimierungen. Programme werden dadurch teils so "verpackt", dass zusammengehörige Funktionseinheiten zusammen in den Cache passen. Das macht die .exe zwar größer, weil Funktionen eventuell mehrfach vorhanden sind, beschleunigt aber die Ausführung, da die CPU weniger oft Zeugs aus der .exe nachladen muss.
Weiterhin gibt es da noch die Pipeline und die Sprungvorhersage. Die Pipeline beinhaltet die nächsten Programmschritte, die auszuführen sind. Stell dir das wie ein Fließband vor. Je nachdem, wie ein Programm arbeitet (Schleifen, Verzweigungen; beides wird durch Sprünge innerhalb des Programmcodes dargestellt), kann es passieren, dass der Inhalt der Pipeline ungültig wird, da jetzt etwas ganz Anderes zu verarbeiten ist. Die Pipeline muss dann aus dem Befehlscache neu gefüttert werden. Es gibt einen intelligenten Algorithmus in der CPU, die das Verwerfen und Neubeladen steuert: Die Sprungvorhersage. Die Compiler optimieren die Programme so, dass die Sprungvorhersage effektiver das Verhalten des Programms erkennen und Daten aus dem Cache rechtzeitig in die Pipeline kopieren kann.

Du siehst, das Thema ist nicht ganz so einfach. Offenbar haben die Wissenschaftler aus der News an der Firmware einer CPU geschraubt, sodass die Caches öfter die richtigen Daten parat halten, als es bisher der Fall war.

Softwareentwickler müssen eigentlich nicht viel tun, außer die Compiler an die veränderte Firmware anpassen.
Aber wie schon geschrieben wurde, wird hier eine ziemlich spezielle Architektur verwendet. Man muss erst mal schauen, ob man die Forschungsergebnisse auf x86-kompatible CPUs übertragen kann.

 

[DaZpoon]

Wenn das Wenige tatsächlich 15 und 25 % bringt, ist es doch viel?!

Die übliche Wirkung von Prozenten. Aber Prozente verschleiern einige Informationen, hier vor allem die Relation WOZU? Ich behaupte mal, dass die 15%/25% nur für dieses Szenario und diesen einen abgekapselten Vorgang gelten: Zu große Daten im Cache aufteilen. Wieviel dieser Vorgang im Gesamtsystem jedoch ausmacht, dazu äußert man sich nicht. Denn das ist natürlich auch stark softwareabhängig.

Allerdings begrüße ich natürlich auch Forschungen in diese Richtung. Wenn etwas dadurch schlanker und effizienter wird hat man doch seinen Teil dazu beigetragen. Aber der riesige Wurf ist es nun auch nicht.

 

[KL0k]

Geht es hier um Steuerung.? Also Software seitig, sprich durch firmware Updates? Oder um die Hardware seitige, sprich Herstellungsprozesse? Das wird für mich aus dem Text nicht ganz deutlich

 

[cirrussc]

Geht es hier um Steuerung.? Also Software seitig, sprich durch firmware Updates? Oder um die Hardware seitige, sprich Herstellungsprozesse? Das wird für mich aus dem Text nicht ganz deutlich

CPU Architektur Design.

 

[Haskell]

@Kl0k Es wird in der Tat aus dem Artikel nicht deutlich, weil mal von Hardware, mal von Software gesprochen wird. Letzteres wäre korrekt.

Kurz zur Erläuterung worum es hier überhaupt geht (ich ignoriere hierbei, dass der Cache in der Regel hierarchisch aufgebaut ist, sprich es gibt verschiedene Caches): Man hat einen kleinen schnellen Speicher (CPU-Cache) und einen großen, langsamen Speicher (Arbeitsspeicher). Alles was an Daten und Befehlen für die Ausführung eines Programms gebraucht wird, passt in der Regel nicht in den kleinen Speicher rein. Wenn für den nächsten Ausführungsschritt Daten benötigt werden, die nicht im Cache vorhanden sind, spricht man von einem Cache-Miss. Ist der Cache noch nicht voll, lädt man einfach das Nötige in den freien Platz nach. Viel interessanter und warscheinlicher ist allerdings, dass der Cache bereits komplett belegt ist. Es stellt sich nun die Frage, was man verwirft. Der schlimmste Fall wäre, dass man etwas aus dem Cache schmeißt, was im nächsten Ausführungsschritt wieder gebraucht wird. Die CPU wäre dann nur noch damit beschäftigt auf den RAM zu warten wodurch CPU-Zyklen verloren gingen. Der beste Fall wäre, dass man Daten verwirft, die man nie mehr braucht.

Das Ziel ist es also möglichst selten auf den Arbeitsspeicher zuzugreifen. Die beste – aber leider nicht praktikabele – Strategie wäre in die Zukunft der Programmausführung zu schauen und das verwerfen, was als Letztes (oder gar nicht mehr) gebraucht wird. Wie eine praktische Lösung für Many-Core-Architekturen aussehen könnte, ist Thema dieses wissenschaftlichen Papiers. Die Heuristik wurde auf bestehender Hardware implementiert, von einem neuen Hardware-Design kann keine Rede sein.

@r4yn3 Was in den Cache geladen/verworfen bzw. wo überhaupt (L1, L2 etc.) ist Sache der CPU. Ein Compiler-Entwickler (z.B. Microsoft) muss sich aber der Architektur bewusst sein, weil andernfalls durchaus Code generiert werden kann der Cache-Misses (und viele andere Stolperfallen) provoziert. Genauso muss der Software-Entwickler (wenn Performance sehr wichtig ist) sich dessen bewusst sein, da die Intelligenz eines Compilers begrenzt ist. Das ist aber schon eher lowlevel, weswegen die meisten Entwickler selten über sowas nachdenken müssen. Wenn es dann doch notwendig ist, stehen verschiedene Werkzeuge zur Verfügung, die die Verwendung des Caches dokumentieren.

 

[r4yn3]

Vielen Dank an e-Laurin und Haskell für die Erläuterungen.

 

[M.B.H.]

die 15% werden bestimmt nur in ganz wenigen seltenen Fällen erreicht, irgendwelche Sonderfälle, die vllt sogar speziell programmiert werden müssen. und im Normalfall, für den normalen PC-User ändert sich wahrscheinlich garnichts ^^ Aber ich hoffe, dass es trotzdem was bringt.

Wird echt zeit für schnellere CPUs, seit jahren hängen wir fest, es gibt kaum Geschwindigkeitszuwachs.

Ich hoffe der Flaschenhals wird geöffnet werde.

Wir sind gerade mal am Anfang der Wissenschaft. Irgendwann in 500 Jahren wird ein kleiner mm^2 grosser Chip 1000 mal so schnell sein wie alle Rechenzentren der welt zusammen. wenn nicht sogar noch viel schneller. Mit dem Speicher sicherlich genauso, dann kann man bestimmt auf so einem kleinen Chip das komplette Internet weltweit kopieren. Aber das werden wir nicht mehr erleben

 

[Daedal]

Ich hätte gerne über alle Cache-Level hinweg UMA. Also alle Cores sollen auf jeden Cache den gleichen Zugriff haben. Das macht zwar die Zugriffssteuerung kompliziert, aber dafür steht zB bei nur einem Thread einem Core der gesamte Cache in der CPU zur Verfügung. Die anderen Cores machen derweil Pause.
Kurz gesagt, ich frage mich, ob es etwas bringt, wenn man exklusive Caches abschafft und jedem Kern dieselben Zugriffsrechte erteilt.

AMDs Jaguar basierende APUs sind so aufgebaut.
http://www.hotchips.org/wp-content/.../HC25.26.111-Kabini-APU-Bouvier-AMD-Final.pdf