News Neues Cache-Design soll Prozessoren beschleunigen

[dMopp]

PS: "Geht nicht" "Wird nie gehen" "Totaler Schwachsinn" sind Aussagen, von Leuten die keinen Pioniergeist haben oder Interesse daran die Welt weiter zu entwickeln. Mit der Einstellung gäbe es weder Reifen noch Feuer... (Selbst so Zufallsentdeckungen wären ungenutzt, da der groß dann mit verschränken Armen dasitzen würde und "Zufall" in seinen Bart brummelt)

...

Das es, "grob" so gemacht wurde ist mir doch klar. Man muss aber auch langsam einsehen, dass der Schritt davon weg zu gehen offenbar auch nicht die Lösung war. Ist das so schwer zu verstehen ?

 

[marco_f]

Man man man lauter Genies hier die solch triviale Ideen natürlich sofort sehen.
Das ganz ist doch unglaublich komplex. Wenn sich da jetzt sehr kluge Menschen eine Weile mit auseinander setzten und neue Konzepte entwerfen ist es schon logisch dass sie bessere Lösungen finden. Die Idee von Mantle ist ja auch "trivial" und trotzdem ist MS noch nicht drauf gekommen. Und Nvidia hat das Verhältnis der Elemente in ihren Rechenkernen für Maxwell verändert und ist auf einmal effizienter. Warum haben die das nicht früher so gemacht?
Weil das ganze Feld immer noch ziemlich jung ist.
Ein anderes Beispiel: Amazon forscht an Logistik, was ja nüchterm betrachtet auch nur ein Hin- und Herschieben von Waren ist, und bricht dabei seit Jahren neue Effizienzrekorde.

 

[Tobi4s]

Ist das mit den MIT-Ankündigungen nicht immer so ein Welt der Wunder Gedöns? So "Wissenschaftler entwickeln Todesstrahl" und am Ende ist es ein aufgebohrter Laser, der dann irgendwann 2030 in Benutzung geht?

 

[G00fY]

Es macht doch viel mehr Sinn die Vorteile des Cache (technisch bedingt) überflüssig zu machen, in dem man diese "Vorteile" auch extern nutzen kann.

Ja, entwickeln wir eben einen externen Speicher mit >400GB/s Bandbreite und einer Taktlatenz ~4.
Den L1 Cache bekommt man aktuell nicht ohne Grund nur wenige KB groß und sitze direkt auf dem Die.

 

[Arcturus]

Die Caches sitzen in der CPU, um die Wege und damit Latenzen so klein wie möglich zu halten.
Wenn du den Cache auslagerst, müsstest du mit extrem hohen Latenzen kämpfen.
Bei den heutigen Taktraten kommt man schnell an physische Grenzen, was die Signallaufzeiten angeht.

 

[Redirion]

hat sich jemand das Paper wenigstens mal flüchtig angeschaut? Die haben als Testszenario einen Prozessor mit 64 cores und ungewöhnlicher Architektur verwendet.
Der Prozessor basiert gar nicht auf einer Architektur wie aktuelle Intel, AMD oder gar ARM Prozessore. Stattdessen verwenden sie eine NoC-Multicore, was für mich so klingt, als sei das ein spezieller Chip für große Netzwerkswitche in Rechenzentren 0o

Außerdem schreiben sie, dass deren Protokoll mit der Anzahl der Kerne skaliert. (d.h. weniger Kerne, geringerer Vorteil). Wenn 15% erst bei 64 Kernen erreicht werden...

Zusätzlich wird mit der Cache-Architektur "R-NUCA" auch noch eine Architektur verwendet, die anscheinend nirgends im Einsatz ist. (habe zumindest nichts gefunden).

Das heißt, dass wir mit dem vorgestellten Protokoll ein simuliertes theoretisch besseres Ergebnis von 15% ab 64 speziellen NoC-Kernen mit einer theoretischen Cache-Architektur haben.

Meiner Meinung nach ist die News irreführend für den Großteil der Computerbase-Leser.

 

[scheichs]

ECHTE Pioniere kennen keine physikalischen Grenzen!!! Das sind doch nur Blockaden im Kopf...

 

[Jesaa]

[...]
Es ist nicht unmöglich in der gleichen Geschwindigkeit den Cache 5cm weiter links oder rechts zu positionieren (im Notfall sogar auf der Rückseite des Sockels, samt dezenter Kühlung). Machbar wäre es schon, auch wenn es "noch" nicht raus ist wie genau. Finde es nur schade das immer so viel Ressourcen in Problemkaschierung gesteckt wird, anstatt die Ursache zu beheben..
[...]

PS: "Geht nicht" "Wird nie gehen" "Totaler Schwachsinn" sind Aussagen, von Leuten die keinen Pioniergeist haben oder Interesse daran die Welt weiter zu entwickeln. [...]

Naja, du bekommst wenigstens Probleme mit der Lichtgeschwindigkeit und den Signallaufzeiten:

t = s/c = 0.05m/300 000 000 m/s = 1,66666666667e-10 s = 6*10^9Hz = 6GHz

Also die Zeit die das signal im Optimalfall von einem ende der 5cm zum anderen braucht. Dabei sind diverse andere sachen noch nicht berücksichtigt, die die Signallaufzeit weiter verschlechtern. Irgendwann wird es schwierig einen 3 GHz prozessor noch mit daten zu versoren wenn die soweit weg liegen. Deswegan hat man ich glaube den Cache eingeführt, der im Prozessor sitz, und nicht daneben, wie der RAM.

--Edit--

Ach ja @Topic: Simulation und Praxis sind immer 2 par Schuhe ;-)

Viele Grüße

Jesaa

 

[a97584]

Stattdessen verwenden sie eine NoC-Multicore, was für mich so klingt, als sei das ein spezieller Chip für große Netzwerkswitche in Rechenzentren 0o

NoCs sind der Nachfolger von On-Chip-Bussen. Man überträgt quasi die Architektur eines Netzwerks (mit Links und Switches/Router) auf den Chip weil es besser skaliert als ein Bus oder eine Crossbar. Die CPU-Cores (und RAM, Peripherie, etc.) sind dann an die Router des NoCs angebunden. Daten zwischen den Cores werden paketweise über das NoC übertragen so wie Rechner z.B. Daten über Ethernet austauschen.

Natürlich ist das in dem Paper wenig praxisrelevant... so ist das nunmal mit wissenschaftlichen Publikationen. Und beim Thema Cache Coherence geht das auch kaum anders weil kein "Großer" sich in die Karten schauen lässt. Also woher soll man wissen was Praxis ist...

 

[cirrussc]

@dMopp

viel sinnvoller wäre es doch, eine Transistor zu entwickeln, der schalten und Daten speichern kann, ganz nach belieben. Das halte ich mal für eine Revolution

Ist nicht dein Ernst?
"Daten speichern" kann man mit Transistoren, seit es sie gibt. Um seinen Zustand zu ändern, muss er entsprechend der Ansteuerung schalten. Was ist das also für ein Quatsch?
Übrigens wird die Gatekapazität von Feldeffekttransistoren längst zur Ladungsspeicherung genutzt, nennt sich dann DRAM.

PS: "Geht nicht" "Wird nie gehen" "Totaler Schwachsinn" sind Aussagen, von Leuten die keinen Pioniergeist haben oder Interesse daran die Welt weiter zu entwickeln. Mit der Einstellung gäbe es weder Reifen noch Feuer... (Selbst so Zufallsentdeckungen wären ungenutzt, da der groß dann mit verschränken Armen dasitzen würde und "Zufall" in seinen Bart brummelt)




Das es, "grob" so gemacht wurde ist mir doch klar. Man muss aber auch langsam einsehen, dass der Schritt davon weg zu gehen offenbar auch nicht die Lösung war. Ist das so schwer zu verstehen ?

Was ist so schwer daran zu verstehen, dass die bisherigen Caches ihre Eigenschaften erst durch die physikalischen Dimensionierungen, wie sie eben bestehen, bekommen - ja, es sind physikalische Bedingungen, die es erfordern, Caches so nah wie möglich dort zu halten, wo sie gebraucht werden. Und wie soll ein Rechenwerk ohne Register, ohne Speicher (Caches) funktionieren?

 

[Multithread]

Ist nicht dein Ernst?
"Daten speichern" kann man mit Transistoren, seit es sie gibt. Um seinen Zustand zu ändern, muss er entsprechend der Ansteuerung schalten. Was ist das also für ein Quatsch?
Übrigens wird die Gatekapazität von Feldeffekttransistoren längst zur Ladungsspeicherung genutzt, nennt sich dann DRAM.

Soweit ich weiss behält ein Transistor nur sollange seinen Zustand wie die ANsteuerung bestehen bleibt.
Für ein effektives Speichern braucht man also bereits mehrere Transistoren, denn ein einzelner kann sich nix merken.

 

[Wishbringer]

Man könnte so auf dem MB ein Cachemodulslot einfügen, so dass man sich passend zur CPU einfach den Cache kauft den man braucht (groß,klein,billig,schnell,...) So kann man selbst entscheiden wie viel einem das Wert ist (ggf erstmal im Serverbereich. Damit werden CPUs dann halt wirklich reine "Cores". Das gäbe einem die Möglichkeit sich die CPU selbst zusammen zu kaufen, indem man Core Module und Cache selbst kauft)

KEINE neue Idee, das Prinzip existierte bereits zu 486er Zeiten und früher, wo es extra Cache Speicher Bausteine auf den Mainboards gab.
Mein erstes 486er Board ASUS PCI/I-486SP3G (damals mit riesigen 256KB 15ns externen Cache) habe ich so durch Austausch der Bausteine auf 12ns und 512KB Cache aufgerüstet.
Es gibt nur ZWEI Probleme: Das sind die Leitungen. Zum einen die Länge der Verbindung zum Cache hin und die Anzahl der Verbindungen. Alles was extern ist macht hier Zugeständnisse.

 

[cirrussc]

Soweit ich weiss behält ein Transistor nur sollange seinen Zustand wie die ANsteuerung bestehen bleibt.
Für ein effektives Speichern braucht man also bereits mehrere Transistoren, denn ein einzelner kann sich nix merken.

Du hast es zwar zitiert, aber nicht ganz gelesen. Eben dies schrieb ich, bezüglich DRAM. Eine extreme Variante sind die Transistoren in Flash ROMs, welche diesen Zustand mehrere Jahre halten können (nutzt ja jeder seit Jahren).
Genau gesehen ist das auch kein idealer Transistor, denn man nutzt explizit parasitäre Effekte, wie eben die eigenen Kapazitäten.

 

[Daedal]

So hab ich das gerade auch herausgelesen ... Fragt sich nur, ob AMD und Intel das übernhemen. AMD war ja immer besonders schwach wenn es um das Cache-Design ging

Das Prinzip des privaten und öffentlichen Speichers einzelner Kerne setzt AMD mit HSA und aktuell mit Kaveri APUs schon um. Zwar noch im langsamem RAM, doch die Technik wird inkl. GPU genutzt. Das auf den Cache auszuweiten dürfte daher AMD leichter fallen als Intel.

 

[Cordless]

[...]
Außerdem schreiben sie, dass deren Protokoll mit der Anzahl der Kerne skaliert. (d.h. weniger Kerne, geringerer Vorteil). Wenn 15% erst bei 64 Kernen erreicht werden...
[...]
Das heißt, dass wir mit dem vorgestellten Protokoll ein simuliertes theoretisch besseres Ergebnis von 15% ab 64 speziellen NoC-Kernen mit einer theoretischen Cache-Architektur haben

Abgesehen davon, dass "skalieren" normalerweise eine andere Bedeutung als von dir angenommen hat, geht es hier vermutlich um was anderes. Zukünftige Systeme werden sehr stark auf Manycorearchitekturen bauen, und dafür braucht es (neben anderen Dingen) effizientere Cachearchitekturen. Man will hier also nicht zeigen, dass man eine gewisse Anzahl an Kernen braucht um einen gewissen Performancezuwachs zu bekommen, sondern die Anzahl der Kerne WIRD so groß sein und man muss bestehende Systeme verbessern. Für Prozessoren mit wenig Kernen ist das hier nicht gedacht. Caches für Multicoreprozessoren zu verbessern interessiert in diesem Forschungsbereich auch kaum jemanden, weil Multicoreprozessoren in Zukunft immer weniger Verwendung finden werden.

 

[Hito]

Was für euch hier nach wenig klingt kann einen großen Effekt bringen - Mantle verringert auch nur den Overhead aknn aber unter den passenden Umständen viel Performance rauskitzeln und das Prinzip hier mit dem CacheDesign weist Ähnlichkleiten auf, denn ebenso wei Mantle wird die Organisation optimiert.

jaja, stark verallgemeinert. na und?

 

[ottoman]

hat sich jemand das Paper wenigstens mal flüchtig angeschaut? Die haben als Testszenario einen Prozessor mit 64 cores und ungewöhnlicher Architektur verwendet.
Der Prozessor basiert gar nicht auf einer Architektur wie aktuelle Intel, AMD oder gar ARM Prozessore. Stattdessen verwenden sie eine NoC-Multicore, was für mich so klingt, als sei das ein spezieller Chip für große Netzwerkswitche in Rechenzentren 0o

Außerdem schreiben sie, dass deren Protokoll mit der Anzahl der Kerne skaliert. (d.h. weniger Kerne, geringerer Vorteil). Wenn 15% erst bei 64 Kernen erreicht werden...

Zusätzlich wird mit der Cache-Architektur "R-NUCA" auch noch eine Architektur verwendet, die anscheinend nirgends im Einsatz ist. (habe zumindest nichts gefunden).

Das heißt, dass wir mit dem vorgestellten Protokoll ein simuliertes theoretisch besseres Ergebnis von 15% ab 64 speziellen NoC-Kernen mit einer theoretischen Cache-Architektur haben.

Meiner Meinung nach ist die News irreführend für den Großteil der Computerbase-Leser.

Ich wollte eigentlich selbst etwas ähnliches schreiben, aber Redirion hat das schon bestens beschrieben. Wenn man sich das Paper anschaut, wird da von 64 Kernen etc. ausgegangen und die 15 bzw. 25% haben dementsprechend wenig mit der Praxis bei Desktop CPUs in den nächsten Jahren gemein.

 

[Cr4y]

PS: "Geht nicht" "Wird nie gehen" "Totaler Schwachsinn" sind Aussagen, von Leuten die keinen Pioniergeist haben oder Interesse daran die Welt weiter zu entwickeln. (

In dem Fall ist es halt schon nicht so clever.
1. Die höhere Entfernung zur CPU kann hinsichtlich Latenzen aus physikalischen Gesetzmäßigkeiten nicht gleichwertig zu internen Caches sein.
2. Eine Steckverbindung hat deutlich schlechtere Signalqualitäten als eine direkt auf der CPU geätzte Lösung. Da kann man physikalisch auch nichts verbessern - es sei denn man lötet, aber dann wäre der Vorteil der Flexibilität weg. Und diese Limitierung führt zu einer limitierten Frequenz im Vergleich zu Caches auf der CPU.
3. Unterschiedliche CPUs für gleiche Sockel haben z.T. deutlich unterschiedliche Cache-Strukturen. Hier würde man eine Baustelle auf machen, wie diese CPUs dann den unterschiedlichen externen Cache anbinden können.
4. Aus Produktsicht hätten die CPUs dann eine Komponente weniger für die Preisfindung und Marktpositionierung.

Fazit:
Technische und kaufmännische Gründe sprechen eindeutig gegen die Sinnhaftigkeit externer Steck-Caches auf dem Mainboard.

 

[Kaiserjäger]

So hab ich das gerade auch herausgelesen ... Fragt sich nur, ob AMD und Intel das übernhemen. AMD war ja immer besonders schwach wenn es um das Cache-Design ging

Das war erst nach der Athlon XP und Athlon Serie, sogar Phenom Cache war in Ordnung, 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. Wie man sieht, hat sich aber seit Jahren höchstens die Menge des Caches geändert, Geschwindigkeit und Größe sollte man stärker verbessern und nicht die kleinen Performanceschübe durch aufwendige Algorithmen langsam erarbeiten.

 

[ukulele]

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! Da hat man maximal kurze Wege (wenn man die Kugelform mal außer acht lässt) und hat gleichzeitig mehr Platz. Die Verdrahtung im Chip wird dadurch natürlich nicht weniger komplex und auch die Kühlung dürfte problematisch werden, aber für die Signallaufzeiten ist das doch besser, oder nicht?

@dMopp: Glaub mir, es geht wirklich nicht, den Cache räumlich woanders hinzulegen. Siehe jessa's Rechnung, und da kommt nochmal allerhand dazu (z.B. Schaltzeiten der Transistoren).

@topic: Warum wundert ihr euch denn alle über 15-25% Zuwachs, selbst unter idealen Bedingungen? Ist doch auch nichts neues mehr, wenn ein neuer Graka-Treiber(!!) die Leistung um 20% anhebt. Führt euch doch mal vor Augen, wie viele Möglichkeiten es gibt, mehrere Milliarden Transistoren auf einem Chip zu verbauen und zu verdrahten... Chip-Design-Tools sind nicht ohne Grund sauteuer und komplex