These: DRAM-Cache ist nicht effizient. Gegenbeispiel Direct Storage ?

[Micke]

Es gibt Laufwerke (SSD, NVME, etc. ) mit integriertem DRAM Cache. Die Größen gehen bis 4 GB.
Bsp: Kingston KC3000 SSD: PCIe-4.0-Debüt für die absolute Oberklasse
MS Windows verwendet freien RAM (des Mainboards) automatisch als Cache. Linux bietet sicherlich ähnliche Feature. Dieser RAM ist grundsätzlich größer als der LW-integrierte. Die Mehrheit der Datenströme fließt letztendlich über diesen RAM. D.h. während ein LW-integrierter Cache nur seinen Host unterstützt, cached der MB-RAM alle Laufwerke.
Die Mehrkosten für den Cache eines Laufwerkes erscheinen mir daher nicht sinnvoll bzw. sind in MB-RAM besser angelegt. Laufwerke für einen NetzwerkSpeicher sind m.M.n. übrigens kein Sonderfall, denn auch diese werden über ein OS im Netzwerk angebunden. Das Thema Netzwerk unterstreicht eher die Vorteile eines zentralen Caches für alle Datenquellen.

Eine mögliches Gegenbeispiel stellt DirectStorage dar.
Dieses soll (mit Windows 11) das Laden von GPU Daten direkt vom Datenlaufwerk ermöglichen. Da dabei der MB-RAM umgangen wird, könnte der LW-integrierte Cache dort relevant sein. Allerdings stellt sich dadurch die Frage, ob DirectStorage selbst überhaupt ein attraktives Feature werden wird. Denn genau dessen adressierter großer Datentransfer zur GPU, wird einen großen Cache zu schätzen wissen. Z.b. sind Texturen, da sich wiederholend, sehr Cache geeignet.
Den größten Cache bietet aber der Weg über die CPU. Je größer dieser ist, umso schwerer dürfte es DirectStorage fallen sich zu behaupten ... und damit auch einem integrierten LW-Cache.

Danke für's Lesen, ist meine Herleitung richtig oder wo irre ich ?

 

[wern001]

Bei Direct Storage umgeht man halt die CPU und die Daten (Texturen beim laden der Welt/Level) sind theoretisch schneller im VRAM der GPU. Was die latenz senkt. Ob man das wirklich merkt hmm. Ich schätze der unterschied in Spielen wird geringer sein wie zwischen einer SATA-SSD und einer m.2-SSD.

 

[tollertyp]

DirectStorage heißt ja nicht, dass die Texturen ständig von der SSD kommen. Nur möglichst an allem sinnlosen Zeugs vorbei genau dort hin, wo sie gebraucht werden, nämlich in den VRAM. Wiederholtes Lesen von Texturen passiert hoffentlich so gut wie nie, vollkommen egal ob mit ohne ohne DirectStorage... und deshalb lohnt es sich auch kaum, solche Daten irgendwo zu cachen.

 

[cvzone]

Danke für's Lesen, ist meine Herleitung richtig oder wo irre ich ?

Nicht der System RAM wird umgangen, sondern die CPU, siehe Bild. Der Artikel ist natürlich inzwischen veraltet, es wird auch mit Win10 gehen, aber darum geht es in dem Falle ja nicht.
https://www.igorslab.de/lang-erwartet-aber-directstorage-funktioniert-nur-mit-windows-11/

 

[Twostone]

Beim Lesen spielt der Laufwerkseigene Cache idR kaum eine Rolle. Bei Schreiboperationen hingegen ist er immens hilfreich, da das Laufwerk den Datenerhalt quittieren kann und das OS sich wieder anderen Dingen zuwenden darf (->iowait).

Letztlich ist der LW-Cache etwas gänzlich anderes als der FS-Cache.

 

[whats4]

nur ist cache ned cache.
der windows cache ist ein dateibasierter cache.
hardware raidcontroller, aber auch caching programme wie primocache sind blockbasiert.
und bei ssd´s hat der cache auch viel mit der verwaltung dee nand-zellen zu tun.

 

[Micke]

Wiederholtes Lesen von Texturen passiert hoffentlich so gut wie nie, vollkommen egal ob mit ohne ohne DirectStorage... und deshalb lohnt es sich auch kaum, solche Daten irgendwo zu cachen.

Wenn ein Bild erstellt wird, müssen auch die Texturen besorgt werden. Immer. Eventuell wurden einige der Daten bereits im VRAM gecacht, aber auch dieser ist begrenzt. Sodaß selbst gecachte Daten gelöscht werden, und dann von der Datenquelle wiederbesorgt werden müssen.

 

[peljotha]

@Micke, der DRAM cache hat mit Datenpufferung nichts zu tun. Dieser Cache dient dem Auffinden der Daten bei Anforderung an die SSD. Er enthält den File Allocation Table. Die Beschleunigung der Schreiboperationen erfolgt durch aus TLC oder gar QLC gebildeten pseudo SLC NAND. Dieser kann von der Größe festgelegt oder auch flexibel sein.

 

[Rickmer]

Löse dich von der Vorstellung, dass im DRAM-Cache von SSDs irgendwelche 'Nutzdaten' gespeichert werden.

Der DRAM-Cache in SSDs hat die Mapping-Tabelle (wo ist was gespeichert) drin, damit diese nicht immer vom Flash-Speicher gelesen werden muss bevor eine Datei gelesen oder geschrieben werden kann.

 

[evilhunter]

Zu Direct Storage:
Das Feature ist sehr attraktiv, denn damit wird bei der Menge an Operationen die durch eine schnelle SSD erst ermöglicht werden die CPU massiv entlastet.

Außerdem vergisst du dabei, dass Sony und Microsoft nicht umsonst da im Prinzip den gleichen weg gehen.
Das wird schon seine Vorteile bieten, dahinter sitzen ja keine Laien.
Ich bin mir sicher das ist nicht grundlos entstanden.

 

[Rickmer]

Ein sehr guten Beitrag dazu, wie und warum bei den Konsolen auf DirectStorage (bzw. äquivalent) gesetzt wird, gibt es hier:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

 

[Micke]

Bei Schreiboperationen hingegen ist er immens hilfreich, da das Laufwerk den Datenerhalt quittieren kann und das OS sich wieder anderen Dingen zuwenden darf (->iowait).

Moderne OS greifen asynchron auf Dateien zu, das wird eher nicht der Grund sein.
Allerdings dürfte das Laufwerk beim Schreiben den nächsten Block schneller aus dem Cache erhalten, statt auf das OS zu warten, bis es den nächsten Block liefert.
plausibel, danke.

 

[wern001]

Beim Lesen spielt der Laufwerkseigene Cache idR kaum eine Rolle. Bei Schreiboperationen hingegen ist er immens hilfreich, da das Laufwerk den Datenerhalt quittieren kann und das OS sich wieder anderen Dingen zuwenden darf (->iowait).

Letztlich ist der LW-Cache etwas gänzlich anderes als der FS-Cache.

das iowait war zu Festplatten Zeiten wichtig. Bei SSD nicht mehr so extrem wichtig.
Bestes Beispiel ist der geringe unterschied bei Spielen zwischen einer SATA-SSD und m.2-SSD
Ob ein Spiel/Welt/Instanz in 15 sek oder 14,8 sek läd hmm... zwischen pci-e 3 und 4 m.2-SSD gibt es aktuell und ich schätze auch in den nächsten paar Jahren keinen unterschied.

 

[h00bi]

Die Mehrkosten für den Cache eines Laufwerkes erscheinen mir daher nicht sinnvoll bzw. sind in MB-RAM besser angelegt.

Dein Ansatz ist schon falsch.
Der Windows Cache ist u.a. ein Vorhalte-Cache, also ein Lesecache. Aber er wird auch als Schreibcache verwendet.
Der SSD DRAM Cache ist primär ein Verwaltungscache.
Der SSD pSLC Cache primär ein Schreibcache.

Die Caches haben unterschiedliche Zwecke und ergänzen sich zum aktuellen Stand der Technik daher auch wunderbar.

 

[tollertyp]

Wenn ein Bild erstellt wird, müssen auch die Texturen besorgt werden. Immer. Eventuell wurden einige der Daten bereits im VRAM gecacht, aber auch dieser ist begrenzt. Sodaß selbst gecachte Daten gelöscht werden, und dann von der Datenquelle wiederbesorgt werden müssen.

Ja, und deshalb werden Texturen ins VRAM gelegt... meistens sogar pro-aktiv, noch bevor sie benötigt werden. Hier aber von Caching zu sprechen ist absurd und lässt nicht auf tieferes Verständnis schließen.

DirectStorage soll das Laden bei Bedarf deutlich beschleunigen. Heißt aber nicht, dass Texturen dann permanent von der SSD kommen. An der grundsätzlichen Arbeitsweise wird sich da nur wenig ändern.

 

[Micke]

Zu Direct Storage:
Das Feature ist sehr attraktiv, denn damit wird bei der Menge an Operationen die durch eine schnelle SSD erst ermöglicht werden die CPU massiv entlastet.

a) die CPU ist seltenst der Flaschenhals in Spielen
b) eine Entlastung der CPU führt zu einer Belastung der GPU. Auch wenn Nicht-CPU Komponenten stellenweise effizienter sind, gemacht werden muss die Arbeit trotzdem.

Außerdem vergisst du dabei, dass Sony und Microsoft nicht umsonst da im Prinzip den gleichen weg gehen.
Das wird schon seine Vorteile bieten, dahinter sitzen ja keine Laien.
Ich bin mir sicher das ist nicht grundlos entstanden.

Von Hörigkeit halte ich nicht viel. Wenn Argumente nicht so dein Ding sind - du musst nicht unbedingt was schreiben.

 

[Rickmer]

a) die CPU ist seltenst der Flaschenhals in Spielen

Beim aktuellen Technologiestandard, ja.

Aber:
1) Komprimieren von Spiel-Daten war schon immer beliebt, um mehr Daten von der HDD abrufen zu können.
2) 100 MB/s von einer HDD dekomprimieren ist eine Sache aber mehrere GB/s? Auf einmal entsteht eine erhebliche CPU-Belastung
3) Bevor du sagst, dass kein Spiel der Welt mehrere GB/s von der SSD lesen will: next-gen Titel eben doch. Genau dafür sind die NVMe SSDs auf der Xbox und insbesondere der PS5 gedacht. So können komplett andere Welten 'on the fly' geladen werden oder auch die Texturen die hinter deiner Spielfigur sind aus dem Speicher geschmissen werden und während man sich umdreht nachgeladen werden.

Die Konsolen können hier Dekomprimierung der Daten über dedizierte Hardware abwickeln. Im PC ist das... schwieriger.

b) eine Entlastung der CPU führt zu einer Belastung der GPU. Aufwand verschwindet nicht.

Eben doch.

Beispiel GPU: Wo dachtest du, dass die Performance-Verbesserungen in Titeln die DX12 und Vulkan unterstützen herkommen?
Das reduzieren von Overhead spielt da eine erhebliche Rolle.

 

[Micke]

@Rickmer
Ich geh bei allem mit, außer

1) Komprimieren von Spiel-Daten war schon immer beliebt, um mehr Daten von der HDD abrufen zu können.
2) 100 MB/s von einer HDD dekomprimieren ist eine Sache aber mehrere GB/s? Auf einmal entsteht eine erhebliche CPU-Belastung

Also natürlich hat Komprimieren seinen Zweck. Und eine GPU kann grundsätzlich schneller dekomprimieren.
Bei einem großen Cache, kann ich allerdings das ganze Dekomprimat vorhalten. D.h. ab dem 2. Zugriff hat die CPU keinen Aufwand mehr, die GPU bleibt aber bei ihrem. Natürlich bleibt die Frage, wieviele wiederholte Zugriff anfallen, damit sich das Cachen rechnet.

 

[Rickmer]

Bei einem großen Cache, kann ich allerdings das ganze Dekomprimat vorhalten.

Der ganze RAM und VRAM kostet auch einiges an Geld. Je weniger und kürzer die Daten im Cache vorgehalten werden müssen, desto mehr bleibt für andere Zwecke übrig - z.B. höher auflösende Texturen.

 

[evilhunter]

a) die CPU ist seltenst der Flaschenhals in Spielen
b) eine Entlastung der CPU führt zu einer Belastung der GPU. Auch wenn Nicht-CPU Komponenten stellenweise effizienter sind, gemacht werden muss die Arbeit trotzdem.

Wenn du dir die Präsentation von Sony und Microsoft anschauen würdest, dann würdest du wissen, dass bei den Mengen und Kompressionen die CPU sehr wohl zum Flaschenhals wird.
Nicht umsonst gibt sind dort extra Chips genau dafür verbaut.

Nvidia bewirbt auch deshalb RTX IO ->weil eben die Belastung auf der CPU extrem ist und auf der GPU zumindest in dem Fall für Nvidia minimal.

Von Hörigkeit halte ich nicht viel. Wenn Argumente nicht so dein Ding sind - du musst nicht unbedingt was schreiben.

Wenn du Argumente und Fakten ignorierst dann ist das dein Problem. Und mit so einem Ton bist du fehl am Platze. Wenn du was missverstehst darfst auch Nachfragen, wir sind nicht im Kindergarten.