Nachdem Word meinen bereits geschriebenen Text aus dem Clipboard entfernt hat, hier mal der zweite Versuch… -.- Jaja eigene Dummheit, ich weiß.
Herdware schrieb:
Wie viel RAM hast du denn? Belegt Windows in Idle wirklich (annähernd) alles davon?
Ich hab 8 GiB RAM in Gebrauch und davon wird alles ausgenutzt. 2 GiB fallen davon auf die RAMDisk, effektiv sind also 6 GiB nutzbar.
Herdware schrieb:
Bei mir nutzt Windows inklusive SuperFetch wie gesagt nur einen winzigen Bruchteil des freien Speichers. Warum cacht es nicht viel mehr Daten?
Windows cached nur ausführbare Anwendungen und Bibliotheken und Assemblies (DLLs). Ich geh weiter unten drauf ein, warum nicht mehr im Cache gelagert wird.
Herdware schrieb:
Allein z.B. mit den WoW-Verzeichnissen wären meine 32GB schon fast voll. Warum sind nur gut 6GB belegt, wenn ich (mit 64Bit-Client) es spiele?
Das frag bitte Blizzard, Microsoft hat damit reichlich wenig zu tun und kann dies theoretisch auch nicht beeinflussen. Selbst wenn sie es können, warum sollte sich Firma A um Firma B scheren? Es ist Arbeit genug das OS zu schreiben.
Herdware schrieb:
Auch bei den Zugriffszeiten und Random-Zugriffen ist RAM deutlich schneller als eine SSD.
Nenn mir einen Menschen, der den Unterschied zwischen 25 ns und 0,2 ms bemerkt. Der Unterschied ist in der Praxis gleich Null. Das verhält sich genauso wie unterschiedliche Bandbreiten beim RAM bzgl. Single-/Dual-/Triple-/Quad-Channel. Auf dem Papier und in Benchmarks fällt dieser Wert gern auf und lässt so manches Herz höher schlagen, im Desktopbetrieb ist es aber vollkommen egal, ob der RAM nun vielleicht mit 666 MHz DDR Single- (Bandbreite: 10,41 GiB/s) oder Dual-Channel (Bandbreite: 20,81 GiB/s) taktet, denn diese wird nie ausgenutzt. Anders sieht es hier bei Servern aus, welche ihre Datenbanken komplett im RAM liegen haben (mehrere hundert MiByte bis GiByte). Hierbei entstehen u.a. tausende oder Zugriffe pro Sekunde, weshalb die Daten schnell gefiltert und geliefert werden können (stellen wir uns einfach mal Google dabei vor). Dass hierbei ohne große Speicherbandbreite von Nöten ist, lässt sich wohl sehr gut nachvollziehen. Ein kleines Spiel dagegen benötigt faktisch gar keine Bandbreite.
Ein paar Benchmarks dazu hat
Tomshardware parat: Seite 10 ff. Es macht im Desktopbetrieb praktisch keinen Unterschied und man muss sich keineswegs auf Dual-Channel fixieren. Benchmarks zeigen natürlich wieder das Gegenteil dieser Aussage auf.
Herdware schrieb:
Genau. Aber warum nicht? Was spricht dagegen statt nur ein paar MB, im besten Fall die ganze Festplatte/SSD automatisch ins ansonsten freie RAM zu spiegeln, oder zumindest die gesamten einigermaßen regelmäßig genutzen Anwendungen/Spiele, wenn der Speicher gerade sonst für nichts anderes gebraucht wird?
Es spricht der erforderliche Aufwand dagegen jegliche Art von Daten im RAM abzulegen.
Kurz zur Auslagerung ins Pagefile:
Ausgehende Situation:
Dein RAM beinhaltet jegliche Arten an Daten, egal welcher Größe, egal welcher Dateityp. Gehen wir von folgender Situation aus: 4 GiB sind durch Anwendungen ausgelastet, die restlichen 28 GiB durch Musik, Bilder, Filme, Texturen u.ä. Als beispielhaftes Szenario, haben wir eine Anwendung, die plötzlich 2 GiB anfordert und zugesprochen bekommen will und kein einziges Byte ist mehr frei.
Szenario 1 (Priorität Dateisystem-Cache):
Ein OS lagert hierbei nun die entsprechend große Datei aus und schreibt sie in den nächst größeren Massenspeicher (SSD/HDD). Dabei wird nicht zufällig irgendwie ausgelagert, sondern immer in 4 KiB großen Seiten – auch Pages genannt (deshalb Pagefile). Eine SSD hat hierbei natürlich einen enormen Vorteil einer HDD gegenüber: Sie hat praktisch keine Zugriffszeit und hohe Transferraten. Eine HDD hat momentan im Optimalfall 30 % (150 MB/s) dieser und die Zugriffszeit ist bauartbedingt (Lese-/Schreibköpfe über den Plattern) schlecht. Die Datei wird nun also ins Pagefile à 4 KiB großen Seiten geschrieben. Gehen wir also mal von der Auslagerung einer 4 GiB großen Datei aus und berechnen wir mal kurz den Optimalfall [1]: Die Auslagerung auf die HDD benötigt 43 Sekunden, auf die SSD 34 Sekunden. In dieser Zeit kann die Anwendung wiederum nicht weiterarbeiten (bzw. eben entsprechend langsamer), da die angeforderte Menge noch nicht bereitgestellt ist und zugewiesen werden kann. Wurde dies nun erledigt, die Aufgabe abgearbeitet und kann es nun wieder zurück in den Cache, benötigen wir bei der HDD 35 Sekunden und bei der SSD 14 Sekunden, eh die Datei wieder im Cache liegt. Dieser Vorgang stört natürlich niemanden, da dies nebenbei erledigt werden kann.
Hier muss genauso noch der Lärm, die Wärme und der Energiebedarf betrachtet werden, der entsprechend der Hardware ausfällt (HDD: ~ 10 W, SSD: ~ 2 W).
Szenario 2 (Priorität ausführbare Dateien/Bibliotheken):
Hierbei wird die Datei einfach vom Cache gelöscht (bzw. einfach die Referenz auf diese Datei freigelassen) und der somit freie Speicher der Anwendung zugewiesen. Der Vorgang geschieht praktisch sofort, wodurch die Anwendung direkt weiterarbeiten kann. Die Zeitersparnis hierbei liegt also bei maximal 43 Sekunden, in der nicht auf die HDD ausgelagert werden muss.
[1] Ich hab eine 1,46 GiB große Datei in eine RAMDisk geschoben:
Transferrate: lesen, schreiben
HDD (Western Digital RE4 2 TB, NTFS) <-> RAMDisk (QSoft, NTFS): 115 MiB/s, 95 MiB/s
Die einer SSD kann ich gerade schlecht testen, da ich noch eine alte Intel M-25 G2 drin hab. Diese macht schon bei 80 MB/s dicht. Hier geh ich somit nun mal vom aktuellen
CB-Test und der gleich getesteten Plextor M5 aus.
SSD <-> RAMDisk (4k 64): 287,54 MiB/s, 119,70 MiB/s
Entsprechend zum Fallenlassen von Daten (Cache) ohne ins Pagefile auszulagern: Hierbei kommt logischerweise natürlich Szenario 2 in Betracht.
Aber um das Caching weiter zu treiben. Nicht nur das, was im Taskmanager steht, steht als Cache zur Verfügung. Ich denke dir ist schon mal die
Thumbs.db Datei in einem Verzeichnis mit Bildern und/oder Filmen aufgefallen. In dieser werden jegliche Vorschaubilder jeder Datei gespeichert, die in diesem Verzeichnis liegt. Somit muss nicht dauerhaft jedes einzelne Bild geöffnet, entsprechend verkleinert und angezeigt werden, sondern dies geschieht einmalig, wird abgespeichert und in der
Thumbs.db hinterlegt. Beim nächsten Öffnen dieses Ordners, sind die Thumbnails also praktisch sofort verfügbar.
Das Gleiche gibt es auch unter dem Namen Iconcache.db (zu finden in
%LOCALAPPDATA%), welches für alle Icons und Anwendungen gilt.
Ein weiteres prominentes Beispiel ist die Windows-Suche, die seit Vista indexiert ist und in
%PROGRAMDATA%\Microsoft\Search untergebracht ist. Die Daten einer Suche stehen also nach kurzer Zeit zur Verfügung und zwar von allen Dateien, die indexiert werden dürfen.
Es gibt also nicht nur einen Cache, sondern viele dieser irgendwo auf der Festplatte verstreut. Genauso tun dies auch installierte Anwendungen.
Alles also simpel zu cachen, ist zweckfrei, Redundanz dieser ebenso.
Weiterhin gilt folgende Sache:
Praktisch alle großen Dateien werden nur gestreamt, selbst lokal. Ein Film wird nicht in einem Stück in den RAM geladen (wie soll das auch gehen bei bspw. 4 GiB, wenn man nur 512 MiB besitzt), sondern Stück für Stück. Musik ebenso nicht, sondern on-the-fly gelesen, dekodiert und wiedergegeben. Bei Texturen in Spielen geschieht dies ebenso. Es wird nur das geladen, was benötigt wird, nicht das, was evtl. irgendwann benötigt wird. Beim Brennvorgang ist es die gleiche Geschichte.
Geprüft werden kann dieser Vorgang, wenn man eine extrem hohe Auslastung auf einer HDD erzeugt. Wenn nun von dieser gleichzeitig gelesen werden soll, fängt das Video irgendwann an zu ruckeln, die Musik zu unterbrechen. Genau das ist das Phänomen, wenn man Daten streamt und nicht am Stück liest bzw. komplett puffert. Früher gab es beim Brennvorgang auch gern mal Abbrüche, weil der Puffer eben nicht voll wurde – weshalb der Buffer Underrun „erfunden“ wurde. Heutzutage natürlich kein Problem mehr, da genügend RAM vorhanden ist, die Transferraten gestiegen sind und viele weitere Sachen (weiter-)entwickelt wurden.
Deshalb werden auch nur hauptsächlich Bibliotheken und ausführbare Dateien im RAM geparkt, damit sich Programme sofort öffnen und nicht Dateien, die man evtl. öffnen will. Diese sind klein, liegen schnell im Cache, sind schnell ausgelagert und auch fix verworfen.
Herdware schrieb:
Lesezugriffe schaden auch einer SSD nicht. Da könnte Windows im Hintergrund eigentlich so viel Daten ins RAM schaufeln, wie es will.
Es benötigt aber wiederum Zeit für eine Sache, welche evtl. nicht benötigt und gleich danach wieder verworfen wird.
Herdware schrieb:
Das Problem liegt darin, dass es den zusätzlichen freien Speicher eben nicht für Caching oder andere sinnvolle Zwecke nutzt. Er bleibt einfach nur frei.
Welche anderen sinnvollen Zwecke als Caching gibt es denn?
Herdware schrieb:
Wie gesagt brüstet sich Microsoft sogar damit, dass jetzt viel noch viel mehr Speicher ungenutzt bleibt, als bei Windows 7. Das ist offensichtlich genau das, was die meisten Leute wollen. Möglichst viel ungenutzten freien Speicher. Vista wurde irrationalerweise dafür in der Luft zerrissen, dass es durch SuperFetch ein paar hundert MB mehr belegt hat.
Hier geht es aber nicht primär um freien RAM, sondern einzig um verringerten Speicherverbrauch und Geschwindigkeit. Mehr RAM bedeutet mehr Speicher für andere Anwendungen, mehr Speicher für den Cache und eine höhere Geschwindigkeit.
Wenn wir dieses Ziel sogar übertreffen können, stehen mehr Ressourcen für Anwendungen zur Verfügung, auch wenn die offiziell genannten Anforderungen gleich bleiben.
Wir erwarten aufgrund unserer Erfahrungen mit älteren Computern, die wir für Leistungstests verwenden, dass Windows 8 sogar auf vielen Computern ausgeführt werden kann, die vor der Veröffentlichung von Windows 7 hergestellt wurden.
Eine wichtige Aufgabe war es, unter Windows 8 Platz für neue Funktionen zu schaffen und gleichzeitig die Speicheranforderungen vorhandener Funktionen sowie jene des Gesamtsystems zu reduzieren.
Wie kommt es zu dieser Redundanz? Anwendungen belegen mitunter Speicher für eine künftige Verwendung. Hierbei wird der gesamte Speicher mit demselben Wert initialisiert. Möglicherweise kommt es jedoch nie zur Verwendung des Speichers durch die Anwendung, da dieser für eine Funktion reserviert wurde, die der Benutzer nicht aufruft. Wird dieser Vorgang für mehrere Anwendungen ausgeführt, enthält das System redundante Speicherkopien.
Bei der Speicherzusammenfassung handelt es sich um eine Technik, bei der Windows im normalen Betrieb auf den Systemarbeitsspeicher zugreift und Dubletten im gesamten Systemspeicher ermittelt. Diese Dubletten werden anschließen von Windows gelöscht – nur eine einzige Kopie bleibt erhalten. Versucht eine Anwendung anschließend, in den Speicher zu schreiben, stellt Windows eine spezifische Kopie bereit. All dies erfolgt im Hintergrund im Speicher-Manager, ohne Auswirkungen auf Anwendungen. Hierdurch lässt sich Speicher im zwei- bis dreistelligen MB-Bereich freigeben (abhängig von der Anzahl der gleichzeitig ausgeführten Anwendungen).
Ausführen derselben Aufgaben mit weniger Speicher
Damit ist denke ich Vieles gesagt (hab den Text nur kurz überflogen).
Den Geschwindigkeitsvorteil anhand eines Beispiels erklärt:
Bei der Programmierung werden viele Variablen genutzt, welche zum Teil nur einen einzigen Zustand beherbergen (boolean). Trotz dass diese Variablen im Prinzip nur den Inhalt Ja und Nein speichern, belegen diese ein ganzes Byte (256 verschiedene Zustände) im RAM. Sind also 254 Zustände übrig, die einfach überflüssig sind. Ein Byte besteht aus acht Bit, im Prinzip könnten also acht unterschiedliche Zustände (zuverlässig unterschieden und) zugewiesen werden. Dazu behilft man sich einfach dem zugewiesenen Byte, indem man einen unsigned char (ein Zeichen) reserviert.
Veranschaulicht:
Code:
Statusbits: 1 2 4 8 16 32 64 128
Wert: 0 0 0 0 0 0 0 0
Speichern wir also Zustand 1, welcher beschreibt, dass wir auf eine Datei öffnen und wir Lesezugriff erhalten wollen.
Code:
Statusbits: 1 2 4 8 16 32 64 128
Wert: 1 0 0 0 0 0 0 0
Weiterhin wollen wir in die Datei schreiben, was wieder einen neuen Zustand beschreibt.
Code:
Statusbits: 1 2 4 8 16 32 64 128
Wert: 1 1 0 0 0 0 0 0
Nun wollen wir aber noch einen dritten Zustand, mit welchem wir dem OS signalisieren, dass wir binär lesen und schreiben wollen und nicht im Textmodus.
Code:
Statusbits: 1 2 4 8 16 32 64 128
Wert: 1 1 1 0 0 0 0 0
Wir haben nun also drei verschiedene Zustände in einem einzigen Byte hinterlegt. Natürlich kann man das Spiel noch weiter treiben, aber die Beispiele werden dafür natürlich immer komplexer.
Gegenübergestellt ist der „herkömmliche“ Weg:
Wir speichern erneut drei Zustände, nutzen aber nicht die Kompakte Art, sondern den traditionellen Weg von drei Variablen. Pro Zustand benötigen wir (wie bereits geschrieben) ein Byte. Kommen wir in Summe hierbei also auf drei Bytes.
Der Gewinn der kompakten Methode: Es benötigt zwei Bytes weniger und ist zudem noch schneller, da nur einmal auf dem RAM zugegriffen werden muss. Weiterhin sind einfach Bit-Shifts (Schieben der Bits um x Stellen) möglich, welche auch weniger Zeit benötigten, als simple Arithmetik. Natürlich liegen die Daten danach im Cache der CPU, bei 1000 Vorgängen dieser Art aber, macht sich der Unterschied deutlich bemerkbar in besserer Performance.
Auch ist dies ein Indikator für erhöhten Speicherverbrauch und „schlechter“ Programmierung, wobei man dies aber nicht prinzipiell darauf schieben kann. Die Wartbarkeit des Codes muss zwangsweise beibehalten werden, sonst sieht bald keiner mehr durch oder es lässt sich schlecht erweitern. Diese Art ist aber auch eine gute Darstellung für die Optimierung von JIT-/Compilern, welche dies zur Runtime/Compiletime optimieren könnten und somit den Speicherverbrauch und die Performance automatisch senken und steigern.
Herdware schrieb:
Deshalb wimmelt es auch im Internet von Tipps und Tricks, wie man SuperFetch und Co. deaktiviert. Auch heute noch, wo bestimmt 99% der PC-Anwender, dank 4 oder 8GB und noch mehr, gar keine Probleme mit zu wenig RAM mehr haben.
Das liegt aber nicht am frei verfügbaren RAM, sondern rührt daher, dass SSDs ihre Daten praktisch sofort ausliefern. Wie gesagt: Zeig mir einen Menschen, der den Unterschied zwischen 25 ns und 0,2 ms spürt.
Herdware schrieb:
Ich finde jedenfalls, dass es ein Armutszeugnis für Windows ist, dass es z.B. überhaupt noch Bedarf an RAM-Disk-Tools gibt. (Und obendrei bringt Windows, im Gegensatz zu MS-DOS, nicht mal selbst eins mit...)
Eine RAMDisk hat immer ein spezielles Anwendungsgebiet, welches bei jedem unterschiedlich ist. Als Cache wird diese aber nie genutzt (zumindest nicht beim bedarften User), von daher bringt es nichts dies hier als Argument zu nutzen. Ein Linux nutzt afaik auch keine RAMDisk im normalen Betrieb, außer wenn es auf einer Live-CD gebootet wird. /tmp wird bei Linux bei jedem Boot oder Shutdown automatisch geleert, hier könnte man eine RAMDisk einsetzen (so wie ich es auch unter Windows mache). Vorteile daraus zu ziehen, halte ich aber für begrenzt, da dies eben nur temporäre Daten sind, die für laufende Anwendungen genutzt werden. Dass der Ordner kaum geleert wird, liegt an schlecht programmierten Programmen, welche zwar Daten anlegen, diese aber nicht entfernen, nachdem sie mit ihren Sachen fertig sind.
Herdware schrieb:
Eigentlich sollte das Speichermanagment des OS so gut sein, dass es im Idelafall ständig den gesamten Arbeitsspeicher ausnutzt.
Wie in deinem Link beschrieben, wurde das Speichermanagement extrem verbessert. Ein OS geht nicht dann effektiv mit dem RAM um, wenn es alles cached, was es zu cachen gibt (was extrem dumm ist), sondern dann cached, wenn etwas oft genutzt wird (Bibliotheken), verwendet werden kann (ausführbare Dateien, Bibliotheken) oder es merkt, dass ein Arbeitsvorgang durch etwas extrem beschleunigt werden kann (was noch in ferner Zukunft liegen wird). Letzteres ist bspw. schon bei heutigen hybriden Festplatten der Fall, wo häufig genutzte Dateien durch Analyse (im Prinzip eine einfache Zugriffsliste) auf dem Flash-Cache verweilen, während andere Daten weiterhin auf dem Platter liegen.
PS: 'Nough said, hoffe das reicht.
