Hatte eine Diskussion mit einem Freund, der behauptete, dass man durch Speichervirtualisierung mehr Speicher nutzen kann, als physisch tatsächlich vorhanden ist. Ist da was dran?
Das hat ja schon einen jahrzehnte langen Bart. Z.B.: https://support.microsoft.com/de-de/help/2160852/ram-virtual-memory-pagefile-and-memory-management-in-windows
Dein Artikel beschreibt die virtuelle Speicherverwaltung. Kann man das mit Speichervirtualisierung gleichsetzen? Speichervirtualisierung: https://www.itwissen.info/Speichervirtualisierung-storage-virtualization.html
Trump schrieb: > Dein Artikel beschreibt die virtuelle Speicherverwaltung. Kann man > das > mit Speichervirtualisierung gleichsetzen? Nu klar.
Trump schrieb: > Hatte eine Diskussion mit einem Freund, der behauptete, dass man durch > Speichervirtualisierung mehr Speicher nutzen kann, als physisch > tatsächlich vorhanden ist. > > Ist da was dran? Ja und nein, abhängig von der Definition von "nutzen". Man kann es so einrichten dass nur soviel Plattenplatz belegt wird wie momentan tatsächlich gebraucht wird, während man soviel als Maximum konfigurieren kann wie man denkt dass es mal werden könnten. Dieses Maximum kann mehr sein als man physisch hat. Z.B. auf einer 1 TiB Festplatte 10 virtuelle Maschinen zu je 500 GiB (konfiguriert) und in jede erstmal nur ein Linux/Windows installiert - kein Ding. Wenn man aber dann versucht jede der VMs mit 200 GiB Daten "aufzufüllen" wird das natürlich nicht gehen. Kannst Du mit sowas wie Virtualbox selber ausprobieren, ähnlich wäre das mit irgendwelchen Enterprise Storages. There ain't no such thing as a free lunch.
Trump schrieb: > Hatte eine Diskussion mit einem Freund, [...] Is kla. > Ist da was dran? Ja, solange du mit "Speicher" nur den Arbeitsspeicher meinst und du dich auf den verfügbaren Adressraum beschränkst. Wenn tatsächlich weder Speicher noch Adressraum verfügbar ist, ist Schluss.
Wenn der RAM nicht reicht, wird oft ausgelagert. Haken ist nur, daß RAM schneller ist, als irgendwelche Platten.
> Wenn der RAM nicht reicht, wird oft ausgelagert. > Haken ist nur, daß RAM schneller ist, als irgendwelche Platten. Diese Aussage stimmt zwar, aber man sollte das mal über PC-Generationen vergleichen. Also testen wie schneller ein Swappen auf SSD (Stand 2020) gegenüber einen Speicherzugriff auf SDRAM (Stand 2000) oder ein Swappen auf HDD ist. Die Transferraten von HDD auf ATA/SATA/PCIe unterscheiden sich doch erheblich und mit Buffer/cache lässt sich einiges abfängen. Könnte sein, das man im realen Betrieb heute den tatsächlichen Unterschied zwischen RAM und Swap-space kaum bemerkt. https://www.enterprisestorageforum.com/imagesvr_ce/8869/SSD-HDD-speed.jpg
Alter Sack schrieb: > Kannst Du mit sowas wie Virtualbox selber ausprobieren, ähnlich wäre das > mit irgendwelchen Enterprise Storages. Deduplication gibts nicht nur im Enterprise, sondern mittlerweile teilweise auch in Allerwelts-NAS. Das ist auch im PC verfügbar, wenn ZFS oder btrfs zum Einsatz kommen. Im Zusammenhang mit VMs wird das so richtig lohnend, wenn viele praktisch gleiche VMs zusammen kommen. Besonders krass ist das dann bei virtualisierten Desktops (vgl Citrix) mit Hunderten gleicher VMs.
:
Bearbeitet durch User
Schtromäkspärte schrieb: > Könnte sein, das man im realen Betrieb heute den tatsächlichen > Unterschied zwischen RAM und Swap-space kaum bemerkt. Wobei man bei Storage nicht nur den Durchsatz betrachten sollte, sondern auch die Zugriffszeit. Auch da sind SSDs zwar in früher gänzlich ungewohnte Dimensionen vorgestossen, aber zum einzelnen Byte in einem SSD-Block ist der Weg schon noch länger, als der zum DRAM.
:
Bearbeitet durch User
Trump schrieb: > Hatte eine Diskussion mit einem Freund, der behauptete, dass man durch > Speichervirtualisierung mehr Speicher nutzen kann, als physisch > tatsächlich vorhanden ist. Besonders, wenn man dann auch noch die Page Tables des virtuellen Speichers selber in den virtuellen Speicher verlagert, und somit auslagern kann. Da kommt man dann notfalls auch komplett ohne RAM für Anwenderprozesse aus. Anno DEC VAX war RAM sauteuer. ;-)
Schtromäkspärte schrieb: > Die Transferraten von HDD auf ATA/SATA/PCIe unterscheiden sich > doch erheblich und mit Buffer/cache lässt sich einiges abfängen. Ein XT-IDE mit CompactFlash-Karte auf einem PC/XT oder AT ist exakt so schnell wie der RAM im gleichen System, d.h. SmartDrive und ähnliche Cache-Algorithmen sind der Leistungsfähigkeit grundsätzlich abträglich. Damit hätte vermutlich damals niemand gerechnet.
S. R. schrieb: > Ein XT-IDE mit CompactFlash-Karte auf einem PC/XT oder AT ist exakt so > schnell wie der RAM im gleichen System, d.h. SmartDrive und ähnliche > Cache-Algorithmen sind der Leistungsfähigkeit grundsätzlich abträglich. Dieser Logik entsprechend könnte man eigentlich auch Magnetband statt RAM verwenden, ohne an Leistungsfähigkeit zu verlieren. ;-)
Vielen Dank für die hilfreichen Antworten, wenn ich das, was bisher gesagt wurde, zusammenfasse, dann komme ich zu dem Ergebnis, dass es nicht die Speichervirtualisierung gibt, sondern unterschiedliche Arten von Speichervirtualisierungen. Ich habe mitgenommen, dass man sowohl RAM als auch Festplattenspeicher virtualisieren kann und dass man zwischen der Speichervirtualisierung auf einem lokalen Destop-PC und der Speichervirtualisierung im Server- und Cloud-Umfeld unterscheidet. Ich habe mal eine grobe Unterscheidung hinsichtlich Speichervirtualisierung auf dem lokalen Desktop-PC, dem physischen Server und bei Cloud-Providern (Virtuelle Maschinen) getroffen. Ist diese Einteilung denkbar und unsinn? a) Auf dem Desktop besteht die Möglichkeit, z. B. RAM mithilfe einer Auslagerungsdatei, die sich auf der Festplatte befindet, zu virtualisieren. Die Auslagerungsdatei wird so verwendet, dass es sich um Arbeitsspeicher handelt. Festplattenspeicher könnte auf lokalen Desktop-PCs mithilfe eines RAID-Verbundes virtualisieren werden. b)Bei einer Server-Client-Architektur (physikalisch nicht virtuell) muss der Server über ausreichend RAM und Festplattenspeicher verfügen, z. B. um Streaming zu ermöglichen. RAM könnte ebenfalls in Form einer Auslagerungsdatei virtualisiert werden. Festplattenspeicher ebenfalls über einen RAID-Verbund. Zusätzlich könnte man den Server auch über ein SAN mit Speicher versorgen. b) Dann gibt es möglicherweise auch in Rechenzentren und bei Cloud-Provider (z. B. Desktop as a Service-, Infrastructure as a Service-, V-Server- oder Webserver-Provider), umfangreiche Speichervirtualisierungen. Hier gehe ich mal davon aus, dass mit virtuellen Maschinen gearbeitet wird. Im Hintergrund befindet sich womöglich ein großangelegtes SAN, das enorme Menge an Speicher für die Verwendung als RAM und/oder Festplattenspeicher in virtuellen Maschinen konsolidiert. Bei allen oben genannten Alternativen, davon gehe ich jetzt mal aus, kann doch nicht mehr Speicher adressiert und belegt werden, als rein physikalisch zur Verfügung steht, oder? Wegen des ganzen Begriffswirrwarrs bin ich mir langsam nicht mehr sicher, was Virtualisierung eigentlich ganz konkret bedeutet. Entweder wird ein großer physischer Speicher in z. B. mehrere kleine logische Speicherbreiche unterteilt oder viele einzelne physische Speicher werden konsolidiert und erscheinen dem Anwender als einzelne logische Einheit. Ich Danke Euch!
Trump schrieb: > Festplattenspeicher könnte auf lokalen > Desktop-PCs mithilfe eines RAID-Verbundes virtualisieren werden. Ein RAID Verbund ist keine Virtualisierung.
Trump schrieb: > Bei allen oben genannten Alternativen, davon gehe ich jetzt mal aus, > kann doch nicht mehr Speicher adressiert und belegt werden, als rein > physikalisch zur Verfügung steht, oder? Doch, kann es wohl. Wird unter gängigen Betriebssystemen wie Linux auch gemacht. Heißt dann KSM (Kernel Samepage Merging). Dabei wird dann genau wie bei der Storage-Deduplizierung dieselbe Speicherseite in verschiedenen Prozessen eingeblendet. Insbesondere bei Virtualisierungs-Hosts mit vielen VMs derselben Distribution und idealerweise gleichen Diensten bringt das viel. Kostet allerdings ein bisschen Performance und ist schwächt unter Umständen die Sicherheit (Timing-Attacken, etc.).
Trump schrieb: > wenn ich das, was bisher gesagt wurde, zusammenfasse, dann komme ich zu > dem Ergebnis, dass es nicht die Speichervirtualisierung gibt, sondern > unterschiedliche Arten von Speichervirtualisierungen. Besser treffend: Es gibt mehrere Ebenen der Speichervirtualisierung (kann es zumindest geben). Bei praktisch jedem aktuellen OS gibt es folgende Mechanismen: - virtueller Speicherzugriff (im Sinne von: address remapping zwischen einem virtuellen Adressraum und dem Addressraum des physischen Speichers) - Auslagerung (selten oder nie benutzte Teile des virtuellen Adressraums werden auf Massenspeicher ausgelagert oder erst garnicht mit physischem Speicher hinterlegt) - Datenträgercache (ungenutzter physischer Speicher wird als Cache für Datenträger-Blöcke verwendet) Diese drei Mechanismen laufen ständig parallel. Der erste ist nur eine reine Übersetzung, zieht also außer einem Lookup in der Übersetzungstabelle (die immer im physischen Speicher ist) keine weiteren Folgen nach sich. Die anderen beiden Sachen konkurrieren hingegen schon in einem gewissen Umfang. Es ist also sehr leicht möglich, dass umfangreiche Zugriffe auf Massenspeicher Teile des Programmcodes aus dem physischen Speicher verdrängen. Aber das ist nur die OS-Ebene der Virtualisierung. Darüber kann dann noch die Virtualisierung des OS selber durch einen Hypervisor sitzen. Dann wird das alles noch einen Zacken komplexer.
(prx) A. K. schrieb: > Alter Sack schrieb: >> Kannst Du mit sowas wie Virtualbox selber ausprobieren, ähnlich wäre das >> mit irgendwelchen Enterprise Storages. > > Deduplication gibts nicht nur im Enterprise, sondern mittlerweile > teilweise auch in Allerwelts-NAS. Das ist auch im PC verfügbar, wenn ZFS > oder btrfs zum Einsatz kommen. Wobei Deduplication (oder auch Datenkompression) nicht wirklich mit Virtualisierung vom Storage zu tun hat, das ist eher so zufällig zusammen aufgetreten weil es eben praktisch und gut machbar war. > Im Zusammenhang mit VMs wird das so richtig lohnend, wenn viele > praktisch gleiche VMs zusammen kommen. Besonders krass ist das dann bei > virtualisierten Desktops (vgl Citrix) mit Hunderten gleicher VMs. Ja, da bringt das richtig Punkte. Wobei man streng genommen immer noch nicht mehr Speicher benutzen kann als man wirklich hat - man benutzt den vorhandenen nur auf schlauere Weise.
Alter Sack schrieb: > oder auch Datenkompression Die existiert im gewöhnlichen NTFS bereits seit NT 3.51. Ist allerdings auch etwas einfacher machbar als Deduplication, was die interne Struktur des Filesystems angeht. Bei COW Filesystemen gibts Dedup fast von alleine, aber auch NTFS hat das mittlerweile beim Server drauf. Beides zusammen soll allerdings bei NTFS ein prima Weg ins Desaster sein.
:
Bearbeitet durch User
@c-hater, danke für die Rückmeldung. Wirft bei mir aber folgende Frage auf: Was passiert im Hintergrund, wenn man einen Desktop in einer Cloud bucht und sich irgendwann entscheidet, den Arbeitsspeicher von 16 auf 32 GB aufzurüsten? Ist das dann so, dass der Hypervisor aus einem Pool bestehend aus Platten, den Speicher ähnlich wie bei der Auslagerungsdatei zur Verfügung stellt?
Planloser schrieb: > Doch, kann es wohl. Wird unter gängigen Betriebssystemen wie Linux auch > gemacht. > Heißt dann KSM (Kernel Samepage Merging). @Planloser muss man nicht Kernel same-page merging als Sondefall betrachten? Die Technik bezieht sich ja nur auf den Fall, dass VMs identische Inhalte teilen. Grundsätzlich kann man doch aber nicht sagen, dass man durch Speichervirtualisierung wie aus Zauberhand aus 8 GB z.B 16 GB macht, wovon dann 8 GB nur virtuell sind. Die ausgelagerten Speicherwörter sind ja trotzdem physikalisch irgendwo vorhanden z. B. auf einer Platte. Virtuell ist doch nur der Adressraum oder etwa nicht?
Trump schrieb: > Wirft bei mir aber folgende Frage auf: Was passiert im Hintergrund, wenn > man einen Desktop in einer Cloud bucht und sich irgendwann entscheidet, > den Arbeitsspeicher von 16 auf 32 GB aufzurüsten? Bei VMs, Cloud oder nicht, fängt RAM schon zunächst beim RAM an. Disk kommt viel später. Aber erst einmal nur in der Definition der VM. Was zwar aus Sicht der VM dann entsprechend mehr wird, aber so lange OS und Anwendungen in der VM nicht darauf zugreifen, gibt es dieses zusätzliche RAM nicht wirklich. Erst beim Zugriff wird es real zugewiesen, nicht schon bei der Definition. So lange der real beanspruchte Speicher aller VMs auf einem Hypervisor dessen reales RAM nicht übersteigen, bleibt es dabei. Da kann für die VMs zusammen 2 TB verbucht sein, obwohl der Host nur 1 TB RAM hat. Dazu kommt, dass gleicher Speicherinhalt gemeinsam genutzt wird. Den Code von zigmal dem gleichen Windows und Office brauchts im RAM nur einmal, nicht zigmal. Wenn es da doch mal eng wird, ist nicht zwangsläufig gleich Disk fällig. Alternativ kann nämlich der Hypervisor versuchen, der VM wieder RAM wegzunehmen. Indem ein spezieller Treiber beim Betriebssystem in der VM exklusiven Speicher anfragt und an den Hypervisor durchreicht. Ist die billigste Methode, hauptsächlich zu Lasten vom Disk-Cache in der VM. Reicht das immer noch nicht, dann lagert der Hypervisor auf Disk aus. Da kann einiges zusammenkommen, ohne dass es die VMs gross merken, denn der Hypervisor hat einen guten Blick dafür, welcher Speicher in letzter Zeit überhaupt verwendet wurde. Meistens ist das aktive RAM aus seiner Sicht nur ein Bruchteil des zugewiesenen RAMs.
:
Bearbeitet durch User
Solche Systeme profitieren von der Masse der VMs und zeitlich gestreuter Nutzung. Wenn alle VMs auf einem Hypervisor gleichzeitig voll ins RAM gehen, und davon weniger real vorhanden als definiert ist, dann läuft das ungefähr so, als ob alle Kunden gleichzeitig ans Geld auf der Bank wollen. Weshalb es im Verbund solcher Hypervisor noch einen weiteren Mechanismus gibt: Die transparente Verlagerung von Last zwischen einer Gruppe von Hosts, egal ob CPU- oder Speicherlast. Wird es auf einem Host eng, verschiebt der Hypervisor die eine oder andere VM auf einen anderen Host. Die VM merkt davon praktisch nichts, bei Pings im Netz wird einer mal ein wenig verzögert. Es kann dann allerdings passieren, dass sie auf einmal auf einer anderen CPU läuft als beim Start - und das ist feststellbar, wenn man will.
:
Bearbeitet durch User
Trump schrieb: > @Planloser muss man nicht Kernel same-page merging als Sondefall > betrachten? Die Technik bezieht sich ja nur auf den Fall, dass VMs > identische Inhalte teilen. Das ist einfach nur einer von etlichen Mechanismen. Ein fester Faktor kommt dabei nicht raus., keine 16 GB aus 8 GB. Die Masse machts, aber das ist ein statistisches Spiel, kein deterministisches.
Trump schrieb: > Planloser schrieb: >> Doch, kann es wohl. Wird unter gängigen Betriebssystemen wie Linux auch >> gemacht. >> Heißt dann KSM (Kernel Samepage Merging). > > @Planloser muss man nicht Kernel same-page merging als Sondefall > betrachten? Die Technik bezieht sich ja nur auf den Fall, dass VMs > identische Inhalte teilen. Die Technik wurde ursprünglich für KVM (Virtualisierung) entwickelt, funktioniert aber natürlich generell, da es nur um den Inhalt der Speicherseiten geht, und der ist ja unabhängig vom besitzenden Prozess. Ein Webserver mit haufenweise Apache-Instanzen profitiert also genauso davon.
Wurden eigentlich schon einmal CPUs entwickelt, die vor dem Lesen und dem Schreiben in das RAM die Daten erst einmal komprimieren? Ich dachte da an eine Hardwarekomprimierungseinheit die zwischen Cache und RAM liegt. Und da es thematisch zusammenpasst. Wurde auch schon einmal eine CPU gebaut, die die Daten dann vorher auch noch verschlüsseln bevor sie ins RAM abgelegt werden, bzw. entschlüsselt, wenn sie gelesen werden? Falls ja, welche CPUs unterstützen das? Und was bringt es effektiv? Wie hoch ist der Preis zwischen Latenz und eingespartem Speicherplatzersparnis wenn der Komprimierungsalgorithus auf eine hohe Geschwindigkeit und auf eine geringe Latenz ausgelegt ist zu Kosten der Speicherplatzersparnis?
Nano schrieb: > Falls ja, welche CPUs unterstützen das? Geht bei AMD ab Zen, was die RAM Verschlüsselung angeht. Nutzbar in Red Hat seit 7.5, in VMware seit 7.0U1. https://www.kernel.org/doc/html/latest/x86/amd-memory-encryption.html Darf man als wohl ziemlich wirksame Massnahme gegen die diversen Side Channel Angriffe wie Spectre&Söhne sehen, ebenfalls bei DRAM-Manipulation. Komprimierung wäre in ähnlicher Weise natürlich problematisch.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Nano schrieb: >> Falls ja, welche CPUs unterstützen das? > > Geht bei AMD ab Zen, was die RAM Verschlüsselung angeht. > Nutzbar in Red Hat seit 7.5, in VMware seit 7.0U1. > https://www.kernel.org/doc/html/latest/x86/amd-memory-encryption.html > > Darf man als wohl ziemlich wirksame Massnahme gegen die diversen Side > Channel Angriffe wie Spectre&Söhne sehen, ebenfalls bei > DRAM-Manipulation. Naja: https://www.youtube.com/watch?v=7AIwe3YbaK8
Nano schrieb: > die vor dem Lesen und > dem Schreiben in das RAM die Daten erst einmal komprimieren? Damit wurden in der Frühzeit der PC-Technik schon viele Millionen verdient: https://de.wikipedia.org/wiki/SoftRAM Interessant daran ist die Tatsache, dass das Programm völlig funktionslos war (ausser die Anzeige des Speichers zu manipulieren), dass aber die Benutzer davon überzeugt waren, dass sie mehr Speicher haben und der Rechner viel schneller ist. Fazit, auch für heutige Systeme: das kann ein Notbehelf sein, wenn einfach nicht genug RAM da ist, aber ein Ersatz für reales RAM ist es nicht. Georg
Nano schrieb: > Wurden eigentlich schon einmal CPUs entwickelt, die vor dem Lesen und > dem Schreiben in das RAM die Daten erst einmal komprimieren? Das ist schwachsinn weil man die daten im RAM zur weiteren Verarbeitung unkomprimiert braucht und/oder sich Opcode nicht gut komprimieren lässt. Ein sinnvoller Ansatz ware andersrum, RAM der rechnet: https://www.datacenter-insider.de/was-ist-in-memory-computing-a-890591/
NurIdiotenHier schrieb: > Nano schrieb: >> Wurden eigentlich schon einmal CPUs entwickelt, die vor dem Lesen und >> dem Schreiben in das RAM die Daten erst einmal komprimieren? > > Das ist schwachsinn weil man die daten im RAM zur weiteren Verarbeitung > unkomprimiert braucht Dafür wäre ja abstrahierende Hardwarezwischenschicht da, die das transparent für die CPU macht und der Direktzugriff würde dann auf der logischen Ebene über den Cache erfolgen, der deutlich schneller ist als RAM. RAM ist nämlich mit ca. 70 ns ziemlich langsam. Beim Zugriff auf den Cache sind es nur ca. 10 ns. Macht also 60 ns Differenz. Dazu kommen noch Unterschiede in der Anbindung. Damit es keine Performancenachteile gibt, müsste das Packen durch die Hardwareeinheit (obiges SoftRAM ist ne Softwaregeschichte) natürlich in weniger als 60 ns funktionieren. Anderseits kommts natürlich auch darauf an, ob einem Performance überhaupt wichtig ist, es gibt sicherlich Fälle, wo die bei der gestellten Anforderung ausreicht und die Arbeitsplatzersparnis wichtiger wird. Da es hier keine nennenswerten Entwicklungen zu geben scheint, dürfte man das Problem bisher einfach mit mehr RAM erschlagen haben. > und/oder sich Opcode nicht gut komprimieren lässt. Das ist Unsinn. Nimm eine EXE deiner Wahl und komprimiere sie, dann wirst du schon sehen, dass man Programme durchaus komprimieren kann. > Ein sinnvoller Ansatz ware andersrum, RAM der rechnet: > https://www.datacenter-insider.de/was-ist-in-memory-computing-a-890591/ Der Artikel ist irreführend, da hier nichts "computed" wird. Das Datenbanken das RAM nutzen ist jetzt auch nichts neues. Die Wikipedia nennt es übrigens In-Memory-Datenbank und diese Bezeichnung macht weitaus mehr Sinn. https://de.wikipedia.org/wiki/In-Memory-Datenbank
Georg schrieb: > Nano schrieb: >> die vor dem Lesen und >> dem Schreiben in das RAM die Daten erst einmal komprimieren? > > Damit wurden in der Frühzeit der PC-Technik schon viele Millionen > verdient: > https://de.wikipedia.org/wiki/SoftRAM Ne Softwarelösung ist überhaupt nicht vergleichbar.
(prx) A. K. schrieb: > Nano schrieb: >> Falls ja, welche CPUs unterstützen das? > > Geht bei AMD ab Zen, was die RAM Verschlüsselung angeht. > Nutzbar in Red Hat seit 7.5, in VMware seit 7.0U1. > https://www.kernel.org/doc/html/latest/x86/amd-memory-encryption.html > > Darf man als wohl ziemlich wirksame Massnahme gegen die diversen Side > Channel Angriffe wie Spectre&Söhne sehen, ebenfalls bei > DRAM-Manipulation. > > Komprimierung wäre in ähnlicher Weise natürlich problematisch. Danke für den Link.
Nano schrieb: >> und/oder sich Opcode nicht gut komprimieren lässt. > > Das ist Unsinn. Nimm eine EXE deiner Wahl und komprimiere sie, dann > wirst du schon sehen, dass man Programme durchaus komprimieren kann. aber schlecht, weil Code zufälligverteilt ist und eine Abfolge gleicher codes sehr unwahrscheinlich ist. Hinzukommt kommt das Architekturen auch auf kompakten Instruction set optimiert sind, RISC, THUMB https://de.wikipedia.org/wiki/Arm-Architektur#Thumb-Befehlssatz Und dann wäre noch die Frage wieviel an einer .exe code und was Header ist: https://en.wikipedia.org/wiki/Portable_Executable#/media/File:Portable_Executable_32_bit_Structure_in_SVG_fixed.svg https://en.wikipedia.org/wiki/Executable_and_Linkable_Format#/media/File:ELF_Executable_and_Linkable_Format_diagram_by_Ange_Albertini.png Nano schrieb: > RAM ist nämlich mit ca. 70 ns ziemlich langsam. Na da haste aber ein paar Speichergenerationen verschlafen, DDR Ram wird inzwischen mit 400 MHz und schneller getaktet.
NurIdiotenHier schrieb: > aber schlecht, weil Code zufälligverteilt ist und eine Abfolge gleicher > codes sehr unwahrscheinlich ist. 70% Reduktion sind aber alles andere als schlecht. nomen est omen
Jemand schrieb: > 70% Reduktion sind aber alles andere als schlecht. Die Summe aller Übel bleibt meist gleich. Wer reduziert, muß mehr organisieren. Entweder braucht das Zeit oder wird später unübersichtlich bei der Fehlersuche.
Jemand schrieb: > NurIdiotenHier schrieb: >> aber schlecht, weil Code zufälligverteilt ist und eine Abfolge gleicher >> codes sehr unwahrscheinlich ist. > > 70% Reduktion sind aber alles andere als schlecht. Doch sind sie. Zumal die 70% ne Luftnummer sind, wenn sie Header und initialisierten datasegmente umfasst, die einen Cpu eher nicht interessieren. Falls du Dich mit CPU-Architekturen nicht so auskennst, kannst das ja auch mit Dateien und Cluster vorstellen, da nutz es auch nicht, wenn eine datei von 16k auf 1k eingedampft wird, wenn sie immer noch einen Cluster belegt. Und ich frag mich grad was mit den relativer Addressierung passiert bei der Komprimierung. Bspw. stösst die CPU auf einen relativen sprung PC+31415 und weis jetzt nicht welchen Block sie entkomprimierensoll, weil durch die Komprimierung sich die speicheraddressen verschoben haben. Das kann man natürlich umgehen wenn man die Wörter einzeln komprimiert, also die Wort-Länge kürzt. Das bring aber nichts, weil ja trotzdem alle 32/64 bits einer Zelle geschpeichert werden müssen, auch wenn ein teil davon lediglich durch die Komprimierung entstandene 0-Folgen sind. Eine pauschale Komprimierung bringt nichts, man kann aber Algorithmen entwickeln die besonders auf sparsame Daten-speichernutzung ausgelegt sind, Stichwort sparse matrix https://en.wikipedia.org/wiki/Sparse_matrix
Eine Frage, die sich mir aber noch aufdrängt und für die ich noch keine Antwort gefunden habe, ist, ob sowas wie das Aufteilen eines großen physischen Speichers in mehrere logische Einheiten oder das Zusammenfassen mehrerer kleiner physischer Speichermedien zu einer großen logischen Einheit auch unter Speichervirtualisierung fällt.
Trump schrieb: > Eine Frage, die sich mir aber noch aufdrängt und für die ich noch keine > Antwort gefunden habe, ist, ob sowas wie das Aufteilen eines großen > physischen Speichers in mehrere logische Einheiten oder das > Zusammenfassen mehrerer kleiner physischer Speichermedien zu einer > großen logischen Einheit auch unter Speichervirtualisierung fällt. Das zielt wohl eher auf Disk als RAM. Tut man zunächst nicht, jedenfalls nicht auf der direkten Ebene. Eine von vielen Methoden der Aufteilung ist die vom PC her bekannte Partitionierung. Andersrum gibt es viele verschiedene Verfahren, die beispielsweise mehrere Disks zu einem Storage Pool zusammenfassen, der dann wiederum in diverse logische Volumes oder Filesysteme aufgeteilt wird. Es gibt den Begriff aber auch bei vernetzten Speichersystemen, etwa VMwares Virtual SAN. Besonders geeignet für Fans von Buzzword Bingo.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.