Rechenleistung stieg bisher 100 x schneller als Speicherdurchsatz

[Badesalz]

Moin.

Jack Dongarra stellt(e) fest (6min. bzw. 46min. Geduld bitte ;)), daß wir - egal bei welcher Skalierung - die Rechenleistung überhaupt nicht mehr auf die Straße bringen, weil uns sämtliches an Speichersubsystemen massiv ausbremst

https://www.youtube.com/watch?v=cSO0Tc2w5Dg

[#44]

CPU-Hersteller stellten das auch fest. Und bauten Caches um das Problem abzumildern. Erstmals vor über 50 Jahren.

Was genau willst du diskutieren?

[Badesalz]

Was genau interessiert dich an einem Thread dermassen nicht, daß du kurz darüber blubbern musst? Verstehe ich grad genauso wenig wie du das verlinkte Video.

[user77]

Was genau interessiert dich an einem Thread dermassen nicht, daß du kurz darüber blubbern musst? Verstehe ich grad genauso wenig wie du das verlinkte Video.

Warum so aggro? Du hast einfach ein YT Video gepostet, ohne Fragen, Diskussionsgrundlage und regst dich auf? :freak:

[Badesalz]

@user77
Wer regt sich auf? :) Die "Grundlage" ist eigentlich schon der Betreff.

Der Aufreger - früher, mittlerweile ist der Fundus an Erfahrungen ausreichend um es leider für normal zu halten - wäre eher, daß wenn man nicht alles in mundgerechte Häppchen schnippelt, immer weniger Leute die Fähigkeit besitzen in etwas selbst reinzubeißen. Und dann auch noch zu kauen,.
Für Leute wie mich die sich nicht mit der von heute, sondern noch gerne mit der "Normal (Gaussian) Distribution" von vor 20-30 Jahren messen, ist das stellenweise kleinwenig frustierend. Man lernt aber irgendwann damit zu leben. Es ist halt wie es ist...

[Exxtreme]

Ja, diese Problematik ist bekannt. RAM ist seit 1995 ca. 50% schneller geworden, der Rest mehrere hundert Prozent. Und deshalb ist RAM jetzt die Bremse schlechthin und man versucht das mit Caches etc. so halbwegs in den Griff zu bekommen.

[Sweepi]

früher [...]
Früher (TM) wäre es auch üblich gewesen, dem Eröffnungsbeitrag ein wenig mehr Substanz zu geben, als
- Überschrift
- ein Satz
- hier, schaut dieses Video

Zurück zum Thema: Die Aussage bezieht sich wohl(?) auf diesen Graphen im Video: https://www.youtube.com/watch?v=cSO0Tc2w5Dg&t=2905s

Eine schnelle Internetsuche gab die folgenden Graphen, konnte die besonders Schönen auf die schnelle nicht wiederfinden:

https://i.extremetech.com/imagery/content-types/05lWzvOWavFNjAtyflwwORU/images-10.png

https://www.researchgate.net/profile/Alberto-Jaspe-Villanueva/publication/329400858/figure/fig3/AS:806675019743232@1569337720975/Trend-of-processing-vs-memory-performance-on-time-Hardware-parallelism-eg-in.jpg

[Badesalz]

Ja, diese Problematik ist bekannt.
Ja schon klar. Ich hab das aber bisher nicht so verfolgt und DIESE ähh... Diskrepanzen trotz Cache hier und Cache da sind schon ziemlich gewaltig.

Das Heiland ist es auch nicht allgemein. X3D z.B. bringt manchmal bisschen Benefit, manchmal rockt es richtig, manchmal wird es aber auch langsamer (nicht rein auf stumpfe Zockerei bezogen)
Wogegen es mit schnellerem RAM immer nur einen Plus gibt.

CXL + CAMM2? :tongue: Es scheint aber auch, daß nicht nur Frequenzen, sondern grad Latenzen ein Problem sind. Dem wird man wohl mit einer nur besseren Kontaktierung nicht stark beikommen (??) Daß sie Stückchen näher an der CPU sind (LAtenzen) bringt jetzt nicht gleich den Schub oder?

Was Durchsatz angeht komm ich beim Stöbern nur auf eine quasi Verdopplung zu heute (?)

@Sweepi
Eigentlich hab ich da jetzt, in meiner Unwissenheit halt, egal welche Art von wenigstens kleinem Knick erwartet, "1995".

Der einzige scheint da aber 1987-1988 zu sehen :|

[#44]

Der einzige ist da aber 1987-1988 zu sehen :|
Die Skala ist nicht linear. Gibt wohl noch ein bisschen was zu kauen.

[Gast]

Moin.

Jack Dongarra stellt(e) fest (6min. bzw. 46min. Geduld bitte ;)), daß wir - egal bei welcher Skalierung - die Rechenleistung überhaupt nicht mehr auf die Straße bringen, weil uns sämtliches an Speichersubsystemen massiv ausbremst

https://www.youtube.com/watch?v=cSO0Tc2w5Dg

Fabrics haben seit ein paar Jahrzehnten das gleiche Skalierungsproblem, nur gerade im Hinblick auf Latenz noch verschärfter wegen c. Da tut sich seit ~15 Jahren in größeren Clustern quasi nix mehr. Dongarra redet da eigentlich bei jeder ISC drüber. Die zugrundeliegenden Trends sind natürlich schon viel älter, wie hier festgestellt.

[Badesalz]

#44
Spielt nicht wirklich irgendeine Rolle für den Kontext. Schade :wink: Vielleicht beim nächsten Mal :up:

edit @gast
Grad gesehen nextplatofrm hatte das auch schon auf dem Radar
https://www.nextplatform.com/2022/12/13/compute-is-easy-memory-is-harder-and-harder/

[#44]

Ich denke schon.

Meine Interpretation wäre, dass wir ja schon seit geraumer Zeit damit kämpfen die Moorsche Transistorflut in tatsächliche Performance umzusetzen. Dazu werden immer mehr und ausgefeiltere Tricks angewendet.
Diesen Aufwand betreibt man sicher nicht, weil es so einfach ist, Tansistoren in Performance zu verwandeln.

Wenn die Tricks also nur dafür sorgen, dass die Performance irgendwie im Verhältnis zu den Transistoren bleibt, können eben jene Tricks nicht dafür sorgen, dass der Compute überproportional zu den Transistoren wächst.

Man "sieht" im Graph also nur, dass die Tricks bisher einen Knick nach unten verhindern - der Unweigerlich kommen müsste, wenn einfach mehr Transistoren nicht auch mehr Performance bedeutet.

Wenn man sich ST vs MT ansieht, wird sehr deutlich wie sich solche Faktoren überlagern.

https://www.researchgate.net/figure/Moores-Law-The-number-of-transistors-and-power-consumption-is-constantly-increasing_fig1_266083753

So genug vorgekaut für heute.

[Exxtreme]

Ja schon klar. Ich hab das aber bisher nicht so verfolgt und DIESE ähh... Diskrepanzen trotz Cache hier und Cache da sind schon ziemlich gewaltig.


Ja, mich interessiert das Thema weil selbst die Java Leute anfangen die Sprache um diesen Umstand herum umzubauen. :freak:

https://openjdk.org/projects/valhalla/design-notes/state-of-valhalla/01-background

Und das wird leider auch nicht besser. Die RAM-Bandbreite geht zwar immer wieder stark nach oben, die Latenzen aber bleiben so wie sie sind.

[Badesalz]

Ich denke schon.Ich nicht. Ich hab einen Knick mit dem L2-Cache erwartet. Nicht davor. Ob die Skala logarithmisch oder nicht ist, ist dafür erstmal wumpe. Reicht mal mit dem Wiederkäuen.

@Exxtreme
Jou. Guter Schrieb. Danke.

Dongarra sieht das aber auch aus seiner Sicht der Supercruncher. Das ist natürlich auch erschreckend was HPCG das aufzeigt.
Ich weiß aber nicht, ob das gängig ist, daß solche Kisten 2-3 Jobs fahren. Imho sind das schon paar mehr und wenn 60 Stück gleichzeitig mit jeweils für sich "14" Petaflops laufen, dann ist das halt was anderes.

Allgemein war er ja schön am meckern, daß man dafür Serverhardware nimmt. Was ihm halt Recht gibt, wenn man sich nur anschaut wie Cerebras mit NV den Boden aufwischt.

[BlacKi]

Und das wird leider auch nicht besser. Die RAM-Bandbreite geht zwar immer wieder stark nach oben, die Latenzen aber bleiben so wie sie sind.


man könnte speicherbandbreite und latenzen mitskalieren lassen. aber die konsequenzen will niemand tragen. eigentlich sind nur die kosten unterschiedlich, die skalieren anders. der rest ist lediglich designsache.

[joe kongo]

Ist SRAM eigentlich noch im Zugriff schneller als DRAM?
Ich fand den diskreten Cache auf 486er Boards immer so sexy. :)
Der hatte doch damals schon nur rund um die 20ns Zugriffszeit, iirc.

[Exxtreme]

man könnte speicherbandbreite und latenzen mitskalieren lassen.

Die Latenzen kannst du jetzt kaum noch drücken. Denn die Leitungen vom RAM bis zum RAM-Controller in der CPU sind zu lang. Und das ist auch der Grund warum die CPU-Caches in der CPU sind und nicht extern wie früher beim 486er. Und es ist so: je größer der Speicher desto höher die Latenzen. Auch das ist prinzipbedingt so. Ansonsten gäbe es die Einteilung in Level 1, Level 2 beim Cache nicht. Da gäbe es einen riesigen Level 1-Cache und das war's.

[Badesalz]

COAST gabs imho auch noch beim Pentium 1 ;)
https://de.wikipedia.org/wiki/Cache_on_a_stick

[Gast]

Hat der Typ die letzten 50 Jahre auf der Rückseite des Mondes verbracht?

Das kennt man schon seit den 80er Jahren des letzten Jahrhunderts.

Und das ist auch der Grund warum man schon seit Ewigkeiten komplexe CISC-Befehle im Microcode zerlegt, und alles erdenkliche mit Caches ausstattet.

[Fusion_Power]

Wann merkt man denn schon im Alltag, dass der RAM langsam ist? Ehr merkt man es wenn die CPU oder die GPU langsam ist. Ich denke mit DDR5 sind wir ausreichend aufgestellt. Mit der großen Ausnahme einer integrierten GPU in der APU, da kann der RAM halt nicht schnell genug sein wenn er auch noch als VRAM her halten muss. Das merkt man z.B. bei mobilen Geräten mit gesteckten SO-DIMMs und iGPU, da ist der RAM wohl auf so 5600MHz bis 6200irgendwas limitiert, während verlöteter RAM auch mal über 8000MHz gehen darf. Was sich direkt auf die Grafikleistung auswirkt.
CAMM2 wäre wohl eine Möglichkeit als Mittelweg in konkretem Fall, aber ob sich das je durchsetzt?
Aber ja, schnellerer RAM ist allgemein nie verkehrt.

[Platos]

Die Latenzen kannst du jetzt kaum noch drücken. Denn die Leitungen vom RAM bis zum RAM-Controller in der CPU sind zu lang. Und das ist auch der Grund warum die CPU-Caches in der CPU sind und nicht extern wie früher beim 486er. Und es ist so: je größer der Speicher desto höher die Latenzen. Auch das ist prinzipbedingt so. Ansonsten gäbe es die Einteilung in Level 1, Level 2 beim Cache nicht. Da gäbe es einen riesigen Level 1-Cache und das war's.

Soll nicht CAMM2 den RAM näher an die CPU bringen? könnte sowas nicht helfen?

[Exxtreme]

Soll nicht CAMM2 den RAM näher an die CPU bringen? könnte sowas nicht helfen?

Ja. Das ist wahrscheinlich auch der Hauptzweck von CAMM2: die Leitungslänge bissl verkürzen und die Signalqualität erhöhen damit man niedrigere Latenzen hat.

[Nightspider]

Die Thematik ist wirklich uralt.
Deswegen wird ja auch echtes 3D Stacking schon seit Ewigkeiten als die Lösung angesehen.

AMD ist mit dem V-Cache vor 2 jahren ja schon den ersten Schritt gegangen.

Ja. Das ist wahrscheinlich auch der Hauptzweck von CAMM2: die Leitungslänge bissl verkürzen und die Signalqualität erhöhen damit man niedrigere Latenzen hat.
Wie viel Latenz kommt denn vom DRAM selber und wie viel von der Leitungslänge?

Gibts da Prognosen zu CAMM2 ?

Der eDRAM damals bei Broadwell machte die CPU Kerne in einigen Spielen auch bedeutend schneller.
Allerdings scheint es nicht so viel zu bringen, als das Intel oder AMD bestrebt wären eine größere Menge an eDRAM / RAM o.ä. direkt aufs Package zu setzen.

Ebenfalls gibts ja auch noch genug Anwendungen, die gar nicht von eDRAM oder V-Cache profitieren.

[BlacKi]

Die Latenzen kannst du jetzt kaum noch drücken. Denn die Leitungen vom RAM bis zum RAM-Controller in der CPU sind zu lang. Und das ist auch der Grund warum die CPU-Caches in der CPU sind und nicht extern wie früher beim 486er. Und es ist so: je größer der Speicher desto höher die Latenzen. Auch das ist prinzipbedingt so. Ansonsten gäbe es die Einteilung in Level 1, Level 2 beim Cache nicht. Da gäbe es einen riesigen Level 1-Cache und das war's.du kannst die latenzen nur mit geld drücken, ja, aber es geht. mit mehr cache steigen die bandbreiten, mit mehr bandbreiten leider auch die latenzen. aber viel viel geld hilft auch dort. ibms power 8 und 9 haben 128mb L3 cache PER CORE! und selbst dort muss man lediglich aufs geld achten, mit mehr geld wären noch weitere bandbreiten und mehr cache vorhanden.


Allerdings scheint es nicht so viel zu bringen, als das Intel oder AMD bestrebt wären eine größere Menge an eDRAM / RAM o.ä. direkt aufs Package zu setzen.

das ist am ende nicht das hauptproblem. siehe apples hauptspeicheranordnung. oder lunarlake zb. noch näher kann man ram nicht bringen bevor man ihn cache nennen könnte^^

[mboeller]

https://en.wikipedia.org/wiki/Computational_RAM

erfordert halt eine komplette Änderung der Computer-Architektur.
Ist aber wirklich SEHR alt und angestaubt.

Wird aber anscheinend gerade wieder für neurale Netzwerke angedacht.
Siehe u.a. hier:

https://research.ibm.com/projects/in-memory-computing

[Gast]

Wann merkt man denn schon im Alltag, dass der RAM langsam ist?

Immer. Nachdem es keinen schnelleren RAM gibt ist es unmöglich nicht zu merken wie langsam er ist.

[Badesalz]

Ja. Das ist wahrscheinlich auch der Hauptzweck von CAMM2: die Leitungslänge bissl verkürzen und die Signalqualität erhöhen damit man niedrigere Latenzen hat.Damit kriegt man übrigens auch direkt und ohne Reue, QuadChannel hin.

Richtig. Latenzen hängen halt auch mit der Kontaktierung zusammen -> Signalqualität. Auch das will CAMM2 angehen.

@Nightspider
Ohne das irgendwie gleich abzuwerten, aber immer wenn ich was von dir sehe blinkt hier die "Spielen Spielen Spielen" Leuchte... Damit fängt an und endet gefühlt jede Betrachtungsweise bei dir ;)

V-Cache verlangsamt eingies sogar feststellbar (nicht nur messbar). Das ist also kein prinzipiell allgemeines Mittel gegen alles was hier besprochen ist. Durchsatz und Latenzen zum "Hauptspeicher" sind das. Immer.

[Platos]

das ist am ende nicht das hauptproblem. siehe apples hauptspeicheranordnung. oder lunarlake zb. noch näher kann man ram nicht bringen bevor man ihn cache nennen könnte^^

Also ich habe keine Lust, dass ich Ram nur noch verlötet und nicht mehr am freien Markt kaufen kann. Dann kommen so Preise wie überall dort eben, wo es so umgesetzt wird.

Nein danke.

[Milchkanne]

Wann merkt man denn schon im Alltag, dass der RAM langsam ist?

Es gibt durchaus Anwendungen, die 100% nur Bandbreitenlimitiert sind. LLMs zum Beispiel, für jedes Token wird einmal das komplette Modell durchgenudelt. Ganz grob gilt also Modellgröße/Speicherbandbreite = Token pro Sekunde.

Ich hätts auch nicht geglaubt, aber FluidX3d (https://github.com/ProjectPhysX/FluidX3D), ein CFD solver, ist auch rein Bandbreitenlimitiert. Ich weiß nicht, ob das beim Wissenschaftlichen Rechnen öfters der Fall ist. Sehr interessant finde ich auch seine Aufschlüsselung:

Without extensions, a single lattice cell requires:

a memory capacity of 93 (FP32/FP32) or 55 (FP32/FP16) Bytes
a memory bandwidth of 153 (FP32/FP32) or 77 (FP32/FP16) Bytes per time step
363 (FP32/FP32) or 406 (FP32/FP16S) or 1275 (FP32/FP16C) FLOPs per time step (FP32+INT32 operations counted combined)

[Badesalz]

WOW. Danke.
Irre was die MI300X da ballert.

https://www.reddit.com/r/OpenCL/comments/12zb5h7/in_the_next_5_years_what_do_you_think_can_push/?rdt=37105

[mboeller]

und wie aufs Stichwort:

20 Jahre alte Idee steigert Effizienz von KI um das 1.000-fache (https://www.notebookcheck.com/20-Jahre-alte-Idee-steigert-Effizienz-von-KI-um-das-1-000-fache.873465.0.html)

Computing RAM für ne KI Anwendung

[Platos]

Und hat das denn auch einen Vorteil abseits von speziellen Machine-Learning Zeugs ?

Also so für Heimrechner z.B beim Rendering oder beim Gaming ?

Ist diese Technologie beispielsweise schnell genug, um auch als Grafikspeicher eingesetzt zu werden, anstatt als RAM? Oder so schnell, um gewisse Caches (Siehe X3D bei AMD) damit zu ersetzen?

[Fusion_Power]

Immer. Nachdem es keinen schnelleren RAM gibt ist es unmöglich nicht zu merken wie langsam er ist.
Äh, ok. Wenn man es so herum betrachtet dann ist schneller immer besser. Aber ich wollte nur andeuten dass du ne lahme Festplatte schon sehr merkst oder ne lahmende Grafikkarte. Auf lahmen RAM kommt man im Normalfall ehr selten. Scho0n gar nicht der Normalo der mal bissl im Web surft, YouTube guggt und ab und zu mal Office macht.

Es gibt durchaus Anwendungen, die 100% nur Bandbreitenlimitiert sind. LLMs zum Beispiel, für jedes Token wird einmal das komplette Modell durchgenudelt. Ganz grob gilt also Modellgröße/Speicherbandbreite = Token pro Sekunde.

Ich hätts auch nicht geglaubt, aber FluidX3d (https://github.com/ProjectPhysX/FluidX3D), ein CFD solver, ist auch rein Bandbreitenlimitiert. Ich weiß nicht, ob das beim Wissenschaftlichen Rechnen öfters der Fall ist. Sehr interessant finde ich auch seine Aufschlüsselung:
Hab nie bestritten dass es viele Szenarien gibt, die von schnellem RAM extrem profitieren können. Im Alltag ist das meist aber halt nicht so wild, moderner DDR5 RAM ist schnell für den Durchschnitts User. Außer halt deine iGPU ist beim Zocken auf den RAM angewiesen, dann hilft mehr Speed auch direkt deinen FPS.

[Badesalz]

und wie aufs Stichwort:

20 Jahre alte Idee steigert Effizienz von KI um das 1.000-fache (https://www.notebookcheck.com/20-Jahre-alte-Idee-steigert-Effizienz-von-KI-um-das-1-000-fache.873465.0.html)
Nur gegenüber NV BH100. Gegenüber Cerebras nur um das 100fache :wink:

Im Alltag ist das meist aber halt nicht so wild, moderner DDR5 RAM ist schnell für den Durchschnitts User.Mir fehlen grad die Infos anhand von was man das behaupten könnte. (wobei zuerst die Frage im Raum hängt was im Gegensatz dazu unmoderner DDR5 RAM ist)

Erfahren, werden wir das erst, wenn CAMM2 kleinwenig aufdreht. Dann haben wir wenigstens einen Vergleich mit vorher/nachher um sagen zu können wie wichtig sowas gewesen war (oder halt nicht)

(lahme "Platte") passt immernoch nicht. Du hast da einen Vergleich. Beim RAM hast du keinen. WEIL, die Leistung und die notgedrugene Nottrickserei der CPU-Bauer mit jeder DDR-Generation auch wieder weiter ist.

[Skysnake]

Das mit dem Websurfen ist doch bullshit. Die heutigen Rechner erledigen halt einen Großteil der Aufgaben in Echtzeit. Da hilft mehr nur auf dem Papier, aber nicht in der Wahrnehmung. Deswegen bremst der RAM aber nicht trotzdem massig aus....

Die Sache ist halt, daß gerade bei sequenziellen Problemen oft der RAM mit seinen Latenzen limitiert. Macht aber im Consumerbereich nichts aus, weil die Probleme klein genug sind um trotzdem schnell fertig zu sein oder eben weil Sie sogar in den Cache passen und man dann eben nicht am RAM hängt.


Die ganze Problematik hat schon soooooooooooooo nen Bart, wie man aus den bereits geposteten Grafiken erkennen kann.

Wie auch immer. RAM ist im wissenschaftlichen und oder Kommerziellen Bereich oft ein Flaschenhals. Es gibt zwar auch Algorithmen die weniger Bandbreite benötigen das verbreitet sich aber alles nur extrem langsam.

Am Ende muss man halt bedenke , das Latenzen vom RAM die sequenzielle Performance drücken und nach Amdahl begrenzt das halt den maximalen Speedup durch Parallelisierung und das ist oft genug win ernstes Problem.

Und da es mehr Performance zu einem Großteil nur noch durch mehr Parallelität gibt, wird das Problem immer schlimmer.

Heute ist es absolut normal das man selbst im industriellen Umfeld auf 500+ cores rechnet. Sind ja auch nur noch ca 6 Maschinen.

Vor keinen 10 Jahren waren das noch Jobs die auf den Top10 der Top500 liefen. Da hat du eher max 4k cores überhaupt bekommen.

[Badesalz]

Das mit dem Websurfen ist doch bullshit. Die heutigen Rechner erledigen halt einen Großteil der Aufgaben in Echtzeit. Da hilft mehr nur auf dem Papier, aber nicht in der Wahrnehmung. Deswegen bremst der RAM aber nicht trotzdem massig aus....
Die Fragestellung ist auch eher allgemeiner Natur. Ein gut gemachter 3300X System (!) erledigt den Großteil der Aufgaben auch schon in Echtzeit.

Consumerbereich hin oder her. Wenn man sich anschaut wie MacbookAir Gen2 oder ein Zenbook S16 365 den Großtel seiner Aufgaben erledigt, ist das mit dem RAM ebenfalls auch schon peng.

Ja. Wir hätten schon zu 3300X Zeiten aufhören können :tongue:

[mboeller]

Und hat das denn auch einen Vorteil abseits von speziellen Machine-Learning Zeugs ?

Also so für Heimrechner z.B beim Rendering oder beim Gaming ?

Ist diese Technologie beispielsweise schnell genug, um auch als Grafikspeicher eingesetzt zu werden, anstatt als RAM? Oder so schnell, um gewisse Caches (Siehe X3D bei AMD) damit zu ersetzen?

<Schulterzuck>

bei den neueren Sachen findet man eigentlich nur was zu LLMs

Dieses PDF habe ich auch noch gefunden, da geht es auch um andere Formen des Rechnens, aber ins. ist CIM soweit weg vom normalen PC, dass es wahrscheinlich nie dafür verwendet werden wird.

PDF (9MB): https://safari.ethz.ch/architecture/fall2020/lib/exe/fetch.php?media=y2020_ethz_sebastian_vff.pdf

[Badesalz]

Vom Gefühl her befinden wir uns am Anfang einiger... Scheidewege :rolleyes:

Die HPC Typen wollen keine Serverhardware mehr. Das skaliert bei denen von 1 bis 4 Racks (als ganzes), danach sinkt die Ausbeute gegenüber theoretischen Peaks kontinuierlich. CIM ist nur eine Form davon. Cerebras zeigt schon direkt was da möglich ist indem es mit NV den Boden aufwischt (auch wenn bisher nur bei KI).

Serverhardware dagegen scheint nicht mehr so richtig im SoHo zu funktionieren. Erzählt einem jedenfalls der erste dieser Art, der 9700X :wink:

Die HPCs würden lieber auf sich zugeschnittene custom designs nutzen. Workstation-ähnliche Desktops für Soho werden wohl bei APUs landen.

[Sweepi]

Hat jemand eine ähnlichen Graph für RAM?:


https://github.com/karlrupp/microprocessor-trend-data/blob/master/50yrs/50-years-processor-trend.png?raw=true

https://github.com/karlrupp/microprocessor-trend-data


Aktueller Graph von Seite 1:
https://www.forrestthewoods.com/blog/memory-bandwidth-napkin-math/assets/img/01.png
Scheint aus diesem offentliche Paper zu sein, aber das kam 2011 raus...?
https://dl.acm.org/doi/pdf/10.5555/1999263

[Gast]

Es gibt durchaus Anwendungen, die 100% nur Bandbreitenlimitiert sind. LLMs zum Beispiel, für jedes Token wird einmal das komplette Modell durchgenudelt. Ganz grob gilt also Modellgröße/Speicherbandbreite = Token pro Sekunde.

Ich hätts auch nicht geglaubt, aber FluidX3d (https://github.com/ProjectPhysX/FluidX3D), ein CFD solver, ist auch rein Bandbreitenlimitiert. Ich weiß nicht, ob das beim Wissenschaftlichen Rechnen öfters der Fall ist. Sehr interessant finde ich auch seine Aufschlüsselung:

Die meisten Solver im Bereich CFD sind bandbreitenlimitiert, einfach weil der grundlegende Rechenmodus quasi eine 3D-Faltung ist, und da wird halt fast nichts gerechnet pro Speicherzugriff. CFD hat daher eine niedrige arithmetische Intensität. Eine Portierung auf GPGPU macht die Solver zwar schneller relativ zur CPU (vorausgesetzt, die Volumen passen in den Grafikspeicher), aber weil GPGPU auf hohe arithmetische Intensität ausgelegt ist (also sehr viele Berechnungen pro Speicherzugriff), idlen die Recheneinheiten noch viel mehr rum. Schneller ist es nur, weil mehr Speicherbandbreite rumliegt.

Ein Gegenbeispiel wären Solver für nichtlineare FEM-Simulationen. Die Skalieren wenig über Speicherbandbreite und Cache, hämmern stattdessen sehr stark auf dem Core rum. Eignen sich prima als Burn-In-Test.

Äh, ok. Wenn man es so herum betrachtet dann ist schneller immer besser. Aber ich wollte nur andeuten dass du ne lahme Festplatte schon sehr merkst oder ne lahmende Grafikkarte. Auf lahmen RAM kommt man im Normalfall ehr selten.

Für durchschnittliche Applikationen ist "auf RAM/Cache warten" für so ca. 90% der Arbeitsausfälle vom CPU-Core verantwortlich.

[Gast]

Wie viel Latenz kommt denn vom DRAM selber und wie viel von der Leitungslänge?

Gibts da Prognosen zu CAMM2 ?


Das kannst du dir doch ausrechnen, Verkürzungsfaktor ist ungefähr 0.6.

Meter ab wie weit die RAM-Slots von der CPU weg sind (10cm) und wie nah die CAMM-Sockel dran sein könnten (nicht 0cm). Maximale Ersparnis also so 0.5ns.

Der Vorteil kommt eher dadurch zustande, dass CAMM bessere Signalintegrität liefert und damit höhere Frequenzen ermöglicht. Zu einem nicht unwesentlichen Teil, weil CAMM endgültig multi-drop begräbt.

[Gast]

du kannst die latenzen nur mit geld drücken, ja, aber es geht. mit mehr cache steigen die bandbreiten, mit mehr bandbreiten leider auch die latenzen. aber viel viel geld hilft auch dort. ibms power 8 und 9 haben 128mb L3 cache PER CORE! und selbst dort muss man lediglich aufs geld achten, mit mehr geld wären noch weitere bandbreiten und mehr cache vorhanden.


Das ist ein Missverständnis. Die 128MB oder so L3 sind natürlich für alle Cores und nicht per Core. Weiterhin sind sie partitioniert, d.h. eine Slice L3 hängt an einem Core, der bevorzugten Zugriff auf eben jene hat. Zugriffe auf entfernte Slices dauern entsprechend länger. Das Design ist von x86 CPUs bekannt.

Insgesamt ist POWER nirgends auf Latenzen getrimmt, im Gegenteil. Es handelt sich um eine CPU-Linie, die auf Durchsatz für OLTP entwickelt wird. Daher haben die Kerne auch 4x/8x SMT aber gar nicht mal viele Recheneinheiten, weil die Zielanwendungen gar nicht viel rechnen. Deswegen haben diese Systeme auch komplexe Speicherhierarchien (L1-L3 on chip/on module, separate Speichercontroller mit L4 usw.). Die sind ja sehr abträglich für die Latenz. Liefern aber Bandbreite.

Der typische Alltag einer POWER-CPU sieht etwa so aus, dass da sehr viele Threads laufen und die beschäftigen sich hauptsächlich damit irgendwelche Baumstrukturen der Datenbank abzuklappern. Das ist sehr schlecht für die ganzen Vorhersagemechanismen einer CPU, deswegen packt man einfach ganz viele Threads auf einen Kern und die meiste Zeit warten die eben darauf, dass Daten nachgeladen werden. Daher auch die eher großen und dafür langsamen Caches.

[Skysnake]

Ein Power Kern braucht normal 2 Threads um alle HW Ressourcen des cores nutzen zu können wenn er HTx8 hat und wenn er HTx4 hat dann einen. Die sind einfach nur logisch geteilt meines Wissens.

Und ja Power ist da einfach mit einer etwas anderer Workload im Hinterkopf Designed.

Noch eine Sache zu CFD. Es gibt dann noch die (Dis)Continous Galerkin Methoden. Da hängst du dann komplett in den ALUs. Sollte auch recht gut auf GPUs rennen.

[Badesalz]

Für durchschnittliche Applikationen ist "auf RAM/Cache warten" für so ca. 90% der Arbeitsausfälle vom CPU-Core verantwortlich.Keller meinte mal der absolute Star im aktuellen Przessordesign wäre halt branch prediction.

PS:
Itanium :rolleyes:

edit:
CAMM löst das Prob der Signalreflexionen "endgültig"?

[basix]

Keller meinte mal der absolute Star im aktuellen Przessordesign wäre halt branch prediction.

Ist ein sehr wichtiger Teil und ein wenig Black Magic. Schlussendlich wird Prefetching, Reordering, Execution usw. davon beeinflusst, also alles was Downstream im Core gemacht wird. Ist man dort ineffizient, macht man alles andere im Core ebenfalls ineffizienter. Mittlerweile empfinde ich aber, dass das ganze Caching und Daten-Handling Subsystem (L0, L1, L2, uOP, Register-Files, Renaming / Move Elimination, Reorder-Buffer) mindestens gleichwertig wenn nicht fast wichtiger ist als die Branch Prediction und limitieren die Performance mehr als ein moderner und guter Branch Predictor. Der Chipsandcheese Artikel zu Zen 5 zeigt das sehr schön auf: https://chipsandcheese.com/2024/08/14/amds-ryzen-9950x-zen-5-on-desktop/

Beispiel aus dem Artikel, was die Performance limitiert: "Bad Speculation" ist deutlich weniger die Ursache als z.B. "Backend Memory Bound". Note: Retiring = Effektive Auslastung des Cores (hier wird also ~30% der maximal möglichen Ressourcen verwendet). Man sieht auch schön, das Backend Memory Bound inkl. V-Cache reduziert wird.
https://i0.wp.com/chipsandcheese.com/wp-content/uploads/2024/08/z4_z5_libx264_topdown_slots.png?w=1050&ssl=1



CAMM löst das Prob der Signalreflexionen "endgültig"?
Das behauptet ja niemand. Multi-Drop ist was ganz anderes und wenn man das weglässt und via CAMM noch die Anschlüsse vs. DIMM optimiert, sind schnellere Speeds möglich (siehe aufgelöteter DRAM / LPDDRx).

[Gast]

Spekulative Ausführung ist ja gerade primär in der Langsamkeit von Speicher begründet und daher sind diesbezügliche Bottlenecks dem hier diskutierten Problem zuzuschreiben.

[Skysnake]

Das ist halt genau für die Lib so. Wald und wiesen Buisness Logic Code ist von der Branch prediction aber stärker limitiert.

Was erwartest du bei.libx264 also Video Codec Lib? Das sollte relativ gutartige Code sein.

[Gast]

Spekulative Ausführung ist ja gerade primär in der Langsamkeit von Speicher begründet und daher sind diesbezügliche Bottlenecks dem hier diskutierten Problem zuzuschreiben.

Nicht nur, spekulative Ausführung ist erstmal im Pipelining begründet.
Der Speicher ist viel zu langsam, als dass die paar 100 Microps die man spekulativ ausführen kann ausreichen würden um die Latenzen im großen Stil zu überbrücken.