Gewinnt man performance, wenn man innerhalb seines eigenen Prozesses den Speicher selbst verwaltet?
-
Nein er hat Recht. Um das Argument anzugreifen, braucht man nur die Prämisse wegzuschießen. Dazu muss man exakt gar nichts über Klassen mit Pointern sagen, vielleicht gibt es ja andere Argumente dagegen.
-
@Allesquatsch
Sagmal hast du meinen Beitrag überhaupt gelesen?
Da steht kein Wort von Stack.
-
Zusammenhängende Texte lesen ist hier nicht so wichtig.
-
hustbaer schrieb:
Nö. Der Exploit würde auf anderen Betriebssystemen auch funktionieren wenn kein eigener Allocator verwendet würde.
Der Punkt war, dass es auf OpenBSD *nicht* passiert wäre, genauer wird das hier beleuchtet (eigentlich ein angry rant...)
http://article.gmane.org/gmane.os.openbsd.misc/211963Die Ursache ist nicht der eigene Allocator, sondern dass der Programmierer einfach einen Range-Check "vergessen" hat.
Aber auch das ist eigentlich kein großes Problem. Das ist dann untargeted reading. Da kriegt man alles und weiß nicht, welcher prozess das wann geschrieben hat, oder ob das gar nur irgendein random fill-in ist. Was en Bug mit eigenem Allokator so gefährlich macht ist, dass man 64KB OpenSSL-Only daten kriegt.
Naürlich ist es kacke, dass jemand diesen Bug übersehen hat, aber Fehler passieren. Es ist daher völlig Kafkesk, in einem Security Produkt eine Architektur zu beevorzugen, die in wenig schneller ist, aber bei der jeder Fehler fatale Konsequenzen hat.
Die Frage des Protokolls ist eine Metafrage, das ist natürlich völlig bescheuert. Aber wenn es teil des SSL-Protokolls ist, braucht man gute Gründe, um es nicht zu implementieren. Wir beschweren uns ja auch andauernd, dass irgendein Compiler irgendwelchen C++ Features nicht kann
-
otze schrieb:
hustbaer schrieb:
Nö. Der Exploit würde auf anderen Betriebssystemen auch funktionieren wenn kein eigener Allocator verwendet würde.
Der Punkt war, dass es auf OpenBSD *nicht* passiert wäre, genauer wird das hier beleuchtet (eigentlich ein angry rant...)
http://article.gmane.org/gmane.os.openbsd.misc/211963Woher soll ich wissen dass das dein Punkt war, wenn du schreibst "der Bug entstand durch eine eigene Speicherverwaltung"?
Was halt nicht stimmt, worauf ich hingewiesen habe.
Dass es auf OpenBSD nicht passiert wäre hab ich auch nicht bestritten. Ist aber relativ uninteressant, da der grossteil der betroffenen Systeme vermutlich nicht auf OpenBSD laufen.Die Frage des Protokolls ist eine Metafrage, das ist natürlich völlig bescheuert. Aber wenn es teil des SSL-Protokolls ist, braucht man gute Gründe, um es nicht zu implementieren. Wir beschweren uns ja auch andauernd, dass irgendein Compiler irgendwelchen C++ Features nicht kann
Du weisst schon dass die Heartbeat Erweiterung von dem selben Herrn "erfunden" wurde, der sie dann auch gleich in OpenSSL implementiert hat?
Also nein, ist keine Metafrage.
-
hustbaer schrieb:
Er fragt, ob es Sinn machen kann Syscalls zu vermeiden, indem man das verwendet/umsetzt was man üblicherweise als "Heap" bezeichnet (auch wenn die Datenstruktur namens "Heap" dabei oft nicht zum Einsatz kommt).
Das macht natürlich so-gut-wie immer Sinn, und es wird auch so-gut-wie überall gemacht. Vom OS selbst, bzw. von der Standard-Library. Man muss dazu keinen Finger krumm machen damit man das bekommt.
Eine echt verwirrende Antwort.
Ich nehme mal an, dass du mit Syscalls, speicherspezifische Syscalls meinst.
Nehmen wir mal an, wir haben ein einigermaßen sauber programmiertes Projekt. Warum sollte ich auf Syscalls verzichten wollen? Geschweige denn warum sollte ich auf Syscalls achten?
Worauf läuft deine "Das macht natürlich so-gut-wie immer Sinn, und es wird auch so-gut-wie überall gemacht." Aussage hinaus? Typischen Java Code zu vermeiden? In STL Containern ab und zu ein .reserve zu streuen um ein ständiges Allokieren zu vermeiden?
Scheint mir mehr ein Problem mit einem schlechten Programmierstil zu handeln.
Wenn ich in einem O(n^3) Block bei jeder Iteration Daten allokiere, sollte ich mich nicht über das Ergebnis wundern.
-
Bitte ein Bit schrieb:
hustbaer schrieb:
Er fragt, ob es Sinn machen kann Syscalls zu vermeiden, indem man das verwendet/umsetzt was man üblicherweise als "Heap" bezeichnet (auch wenn die Datenstruktur namens "Heap" dabei oft nicht zum Einsatz kommt).
Das macht natürlich so-gut-wie immer Sinn, und es wird auch so-gut-wie überall gemacht. Vom OS selbst, bzw. von der Standard-Library. Man muss dazu keinen Finger krumm machen damit man das bekommt.
Eine echt verwirrende Antwort.
Ich nehme mal an, dass du mit Syscalls, speicherspezifische Syscalls meinst.
Ich meine mit Syscalls Syscalls. In diesem Fall - wo es nur um Speicherverwaltung geht - natürlich nur speicherspezifische. Und mit "vermeiden" meine ich natürlich die Anzahl zu verringern.
Nehmen wir mal an, wir haben ein einigermaßen sauber programmiertes Projekt. Warum sollte ich auf Syscalls verzichten wollen? Geschweige denn warum sollte ich auf Syscalls achten?
Siehe oben: ich meinte nicht komplett verzichten, sondern die Anzahl verringern. Und warum das Sinn macht? Na weil Syscalls langsamer sind als normale Aufrufe.
Wobei der Knackpunkt natürlich weniger ist ob es sich um einen Syscall handelt oder nicht, sondern ob die Speicheranforderung schnell oder langsam ist (SO irre langsam sind Syscalls auf den meisten Systemen nämlich auch nicht mehr).
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.
Was das mit sauber geschriebenen Programmen etc. zu tun haben soll weiss ich nicht. Davon profitieren sowohl sauber geschriebene als auch unsauber geschriebene Programme.
-
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.
