Gewinnt man performance, wenn man innerhalb seines eigenen Prozesses den Speicher selbst verwaltet?
-
Deiner Aussage entnehme ich dass wir uns in dem Gebiet der Treiber-Programmierung befinden.
---
Gleich mal vorweg: Ich habe wenig Ahnung in diesem Gebiet. Aber es interrresiert mich.
Die meisten Systeme sind halt einfach nur so aufgebaut, dass es nen (relativ langsamen) Syscall gibt mit dem man Speicher seitenweise in einen Prozess einblenden kann ("committen"), und dann Userland-Code (=erstmal kein direkter Sycsall) gibt der den Heap verwaltet. Und der Heap-verwaltende Userland-Code macht dann hin und wieder mal nen Syscall um gleich seitenweise neuen Speicher anzufordern.
Welchen Bezug hat das zu dem Working Set, den Private Bytes und zu der virtuellen Speicherverwaltung?
-
So, ich melde mich mal wieder und habe jetzt den ganzen Thread durchgelesen.
hustbaer schrieb:
Die meisten Systeme sind halt einfach nur so aufgebaut, dass es nen (relativ langsamen) Syscall gibt mit dem man Speicher seitenweise in einen Prozess einblenden kann ("committen"), und dann Userland-Code (=erstmal kein direkter Sycsall) gibt der den Heap verwaltet. Und der Heap-verwaltende Userland-Code macht dann hin und wieder mal nen Syscall um gleich seitenweise neuen Speicher anzufordern.
Und das macht wie gesagt das OS bzw. die Runtime-Library bereits selbst - gerade weil es eben so-gut-wie immer Sinn macht.
Das ist die Beste Antwort auf meine Frage, danke.
Im Prinzip ist es also so, dass jeder Prozess sowieso vom OS bzw. der Runtime Library eine prozesseigene Speicherverwaltung bekommt und daher die schwergewichtigen echten Syscalls kaum stattfinden.
Wenn das so richtig ist, dann macht es eigentlich nie Sinn, seinen Speicher selbst zu verwalten, es sei denn, man entwickelt für ein OS bzw. eine Runtime Library, die obiges nicht umsetzt.
Habe ich das so richtig verstanden?
Und dann noch eine kleine Frage aus historischer Neugierde nebenbei.
Ab welcher Version von Windows und dem Linux Kernel bzw. den entsprechenden Runtime Librarys wurde das so wie oben beschrieben umgesetzt?
Gab's das schon in Windows 95?
Oder noch früher, Windows 3.1 (auch wenn das wohl kein echtes OS ist)?Also wann hat man das zuletzt wirklich noch auf den viel genutzten Massenbetriebssystemen gebraucht?
-
Object Pools können immer noch sehr viel Sinn machen. Also das man Objekte recycled.
-
rtl. schrieb:
Object Pools können immer noch sehr viel Sinn machen. Also das man Objekte recycled.
Warum sollte man Objekte recyclen?
-
pro7 schrieb:
rtl. schrieb:
Object Pools können immer noch sehr viel Sinn machen. Also das man Objekte recycled.
Warum sollte man Objekte recyclen?
Um wertvolle Rohstoffe zu sparen.
-
SeppJ schrieb:
pro7 schrieb:
rtl. schrieb:
Object Pools können immer noch sehr viel Sinn machen. Also das man Objekte recycled.
Warum sollte man Objekte recyclen?
Um wertvolle Rohstoffe zu sparen.
Wie wahrscheinlich ist es denn, dass du ein Objekt mit gleichem Inhalt genau noch einmal benötigst, nach dem du das erstere verworfen hast, es aber noch irgendwo im Speicher liegt?
Und selbst wenn du eine hohe Wahrscheinlichkeit aufzeigen könntest, wie willst du dieses geeignete weggeworfene Objekt unter all den anderen in akzeptabler Laufzeit aufspüren?
Da dürfte es ja selbst dann schneller sein, das Objekt neu zu erzeugen.
-
sat1 schrieb:
SeppJ schrieb:
pro7 schrieb:
rtl. schrieb:
Object Pools können immer noch sehr viel Sinn machen. Also das man Objekte recycled.
Warum sollte man Objekte recyclen?
Um wertvolle Rohstoffe zu sparen.
Wie wahrscheinlich ist es denn, dass du ein Objekt mit gleichem Inhalt genau noch einmal benötigst, nach dem du das erstere verworfen hast, es aber noch irgendwo im Speicher liegt?
ca 100%, wenn man mit ein wenig Sinn rangeht. Nehmen wir Threads, die man recycled. Die frischen bzw arbeitssuchenden Threads sind alle gleich, alle mit gleichem Inhalt.
sat1 schrieb:
Und selbst wenn du eine hohe Wahrscheinlichkeit aufzeigen könntest, wie willst du dieses geeignete weggeworfene Objekt unter all den anderen in akzeptabler Laufzeit aufspüren?
Mittels einer geeigneten Datenstruktur. Doppelt verkettet intrusive Liste genehm?
sat1 schrieb:
Da dürfte es ja selbst dann schneller sein, das Objekt neu zu erzeugen.
Es ist eine Freude, von jemandem belehrt zu werden, der so viel Erfahrung hat wie Du.
-
Speicherverwaltung schrieb:
So, ich melde mich mal wieder und habe jetzt den ganzen Thread durchgelesen.
hustbaer schrieb:
Die meisten Systeme sind halt einfach nur so aufgebaut, dass es nen (relativ langsamen) Syscall gibt mit dem man Speicher seitenweise in einen Prozess einblenden kann ("committen"), und dann Userland-Code (=erstmal kein direkter Sycsall) gibt der den Heap verwaltet. Und der Heap-verwaltende Userland-Code macht dann hin und wieder mal nen Syscall um gleich seitenweise neuen Speicher anzufordern.
Und das macht wie gesagt das OS bzw. die Runtime-Library bereits selbst - gerade weil es eben so-gut-wie immer Sinn macht.
Das ist die Beste Antwort auf meine Frage, danke.
Im Prinzip ist es also so, dass jeder Prozess sowieso vom OS bzw. der Runtime Library eine prozesseigene Speicherverwaltung bekommt und daher die schwergewichtigen echten Syscalls kaum stattfinden.
Wenn das so richtig ist, dann macht es eigentlich nie Sinn, seinen Speicher selbst zu verwalten, es sei denn, man entwickelt für ein OS bzw. eine Runtime Library, die obiges nicht umsetzt.
Habe ich das so richtig verstanden?
Du hast husbaer richtig verstanden. Man hat schwere syscalls und spürbar leichtere prozesseigene Speicherverwaltung schon verfügbar.
Aber Du hast nicht recht, denn verschiedene Sprachen haben verschiedene Anforderungen, weshalb es trotzdem üblich ist, daß die Laufzeitumgebung einer Programmiersprache entweder auf die prozesseigene Speicherverwaltung noch was draufsetzt oder sie sprachangemessen reimplementiert.
"Es macht selten Sinn, seinen Speicher selber zu verwalten" als Anwendungsprogrammierer, denn von der Laufzeitumgebung das new/dim/malloc/gcnew paßt schon recht gut. Naja, wo fängt die Speicherverwaltung an, bei linksaufgefüllten Bäumen in einem Array, bei vector mit reserve, bei einer doppelt verketteten Liste mit Freispeicherliste, bei einem klassenlokalen new/delete was auch nur evbendiese Freispeicherliste ist?
-
Speicherverwaltung schrieb:
Wenn das so richtig ist, dann macht es eigentlich nie Sinn, seinen Speicher selbst zu verwalten, es sei denn, man entwickelt für ein OS bzw. eine Runtime Library, die obiges nicht umsetzt.
Es macht vorallem keinen sinn immer alles optimieren zu wollen.
http://en.wikipedia.org/wiki/Program_optimization#Bottlenecks90% of the execution time of a computer program is spent executing 10% of the code
Speicherverwaltung ist fast nie in diesen 10%.
-
sat1 schrieb:
SeppJ schrieb:
pro7 schrieb:
rtl. schrieb:
Object Pools können immer noch sehr viel Sinn machen. Also das man Objekte recycled.
Warum sollte man Objekte recyclen?
Um wertvolle Rohstoffe zu sparen.
Wie wahrscheinlich ist es denn, dass du ein Objekt mit gleichem Inhalt genau noch einmal benötigst, nach dem du das erstere verworfen hast, es aber noch irgendwo im Speicher liegt?
Und selbst wenn du eine hohe Wahrscheinlichkeit aufzeigen könntest, wie willst du dieses geeignete weggeworfene Objekt unter all den anderen in akzeptabler Laufzeit aufspüren?
Da dürfte es ja selbst dann schneller sein, das Objekt neu zu erzeugen.Es kommt auf das Objekt an. Es gibt Klassen, deren Instanzen auf der einen Seite sehr homogen sind aber deren Erzeugung aber sehr teuer ist.
Ich denke da beispielsweise an einen Pool von Datenbankconnections. Wenn ich einen Zugriff auf die Datenbank mache, dann hole ich mir eine Connection aus dem Pool, verwende ihn und schiebe ich wieder zurück in den Pool. Ein Datenbankconnect ist hier praktisch immer teurer als irgendeine Verwaltung des Pools. Der Pool kann meinetwegen ein std::vector sein, wo ich meine freien Objekte halte.
