Gewinnt man performance, wenn man innerhalb seines eigenen Prozesses den Speicher selbst verwaltet?

volkard

(k)einer? schrieb:

volkard schrieb:

(k)einer? schrieb:

Bashar schrieb:

Um dein Argument anzugreifen, brauche ich dir nur die Prämisse wegzuschießen. Dazu muss ich exakt gar nichts über eigene Speicherverwaltungen sagen, vielleicht gibt es ja andere Argumente dagegen.

Ja, das habe ich gemeint. Hier wird ein Text immer wie ein mathematischer Beweis gelesen. Man tut immer so, als ob jeder Satz für sich in 100% aller Fälle korrekt sein muss. Wenn man dann einen Satz(teil) findet der irgendwo in einem zusammenhangslosen Kontext nicht stimmt, dann gilt das Argument als widerlegt. Sprache funktioniert aber nicht wie Mathematik.

Du willst damit sagen, daß Du behaupten kann, in C++ würde wegen RAII new nicht gebraucht werden, und trotz totaler Falschheit dieser These damit beweisen können, daß new nicht schnell sein muss. Verschone mich mit deiner Sprache, die nicht wie Mathematik funktioniert.

Keine Ahnung warum ich etwas über RAII gesagt haben soll. Xin hat was von RAII angefangen, warum RAII irgendwas damit zu tun haben soll, dass man Objekte statt mit new auch nur auf dem Stack anlegen kann, verstehe ich auch nicht.

Das ändert ja nichts, wenn ich hier was verwechsle oder mißinterpretiere, denn nicht jede Prämisse muss zu 100% korrekt sein.

(k)einer? schrieb:

Außerdem habe ich nicht eine Behauptung aufgestellt, sondern nur ein paar Fragen gestellt damit die Leute sagen können warum sie eine eigene Speicherverwaltung brauchen.

Wenn dann als Antwort kommt, dass Objekte die auf dem Stack angelegt werden intern auch wieder Speicher mit new anfordern können und man deshalb new optimiert werden muss, ist das doch quatsch. Nur weil man widerlegt, dass ein Objekt das auf dem Stack angelegt wird nicht zwingend nur Speicher auf dem Stack verwendet (was ich sowieso nie behauptet habe), ist damit doch nicht bewiesen, dass man ein Problem mit der Performance von new hat.

Deine logische Argumentation ist irrelevant, weil Du selber angemeldet hast, beliebig von der Logik abzuweichen, ja sogar den anderen vorwirfst, logisch zu argumentieren.

volkard schrieb:

jede Prämisse muss zu 100% korrekt sein.

volkard schrieb:

nicht jede Prämisse muss zu 100% korrekt sein.

Was den jetzt?

volkard

(k)einer? schrieb:

volkard schrieb:

jede Prämisse muss zu 100% korrekt sein.

volkard schrieb:

nicht jede Prämisse muss zu 100% korrekt sein.

Was den jetzt?

Beides natürlich. http://de.wikipedia.org/wiki/Ex_falso_quodlibet

Allesquatsch

(k)einer? schrieb:

Und wieviel Prozent ist dein Programm mit den vielen Strings und Containern mit deiner eigenen Speicherverwaltung schneller geworden? (Ich glaube ich kenne die Antwort schon. Es gibt gar keines.)

Hallo (k)einer,

auch wenn ich bei Deinem Diskussionsstil nicht so recht weiß, ob Du Sachargumenten zugänglich bist, versuche ich es noch einmal.

Sicherlich hast Du recht, dass der Vorteil erprobter Standardmethoden nicht zu unterschätzen ist und der Nachteil geringerer Performance nur in ganz seltenen Fällen bemerkt wird.

Doch eine Menge von Anwendungsproblemen fallen einfach in diese Kategorie, wo man mit begrenzten Ressourcen primär Richtung Speicher- oder Zeitperformance optimieren muss.
Bezeichnenderweise ist das auch der Grund, wieso noch immer in C oder C++ entwickelt wird, obwohl es doch eine Menge Sprachen und Werkzeuge gibt, die die Fehlermöglichkeiten für Entwickler einschränken und nicht viel Performance kosten.

Und auf die Frage des TE lautet die Antwort: Ja, es gibt solche Aufgabenstellungen, wo es sinnvoll ist.

Es mag sein, dass manche Entwickler in ihrem Leben niemals auf solche Anforderungen stoßen, aber es gibt sie. Gerade im Bereich von Optimierungen kommt es auf Performance an und das Erzeugen und Verwerfen von kleinen Objekten nimmt einen erheblichen Anteil ein.

Eine eigene Verwaltung nimmt da nur wenige Zeilen Quell- bzw. Maschinen-Code in Anspruch und ist signifikant effizienter.
Beispiel für solche Anwendungen wären Branch-and-Bound-Verfahren für logistische Probleme, bei denen man oft tausende von offenen Enden beisammen halten muss.

Ciao, Allesquatsch

hustbaer

@Allesquatsch, aber nicht nur:

Allesquatsch schrieb:

Und auf die Frage des TE lautet die Antwort: Ja, es gibt solche Aufgabenstellungen, wo es sinnvoll ist.

Ich finde es lustig wie die Frage des OP hier von vielen (mMn.) falsch interpretiert wird.

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.

Beantwortet wurde von den meisten aber die Frage ob es Sinn macht eine spezialisierte, auf eine bestimmte Anwendung zugeschnittene Speicherverwaltung selbst zu implementieren. Und das macht dann schon nur mehr relativ selten Sinn. (Abhängig davon in welchem Bereich man arbeitet kann man solche Fälle natürlich sehr oft haben. Aber viele andere Programmierer haben sie dafür sehr selten bis nie.)

Allesquatsch

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).

Wobei es die kombinierte Frage auch recht schwer macht, eine klare Antwort zu geben. Denn der Aspekt der Speicherverwaltung hat erst mal nichts damit zu tun, ob der Speicher vom Heap oder vom Stack kommt.

Problematisch an der Frage ist auch, dass einerseits davon die Rede ist, dass der Speicher schon beim Programmstart bereit sein soll, andererseits aber angenommen wird, dass der Prozess mehr Speicher benötigt.

Du hast natürlich recht, dass ich nur auf den ersten Aspekt der Speicherverwaltung eingegangen bin. Den zweite Aspekt halte ich für die Performance aber auch nicht relevant.

Ciao, Allesquatsch

Bashar schrieb:

Die Objekte auf dem Stack sind aber böse und holen sich ihren internen Speicher letztendlich vom Freispeicher, was jetzt?

Falsch. Eine Klasse class foo{ int x; int y;} liegt komplett auf dem Stack, wenn sie dort erzeugt wird.

SeppJ

Speicherverwaltung schrieb:

Bashar schrieb:

Die Objekte auf dem Stack sind aber böse und holen sich ihren internen Speicher letztendlich vom Freispeicher, was jetzt?

Falsch. Eine Klasse class foo{ int x; int y;} liegt komplett auf dem Stack, wenn sie dort erzeugt wird.

Du hast es nicht verstanden. Ein Klasse kann schnell auch so aussehen:

class Foo
{
  char *data;
 public:
 // Die großen Fünf
};

Was jetzt?

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.

hustbaer

@Allesquatsch
Sagmal hast du meinen Beitrag überhaupt gelesen?
Da steht kein Wort von Stack.

Zusammenhängende Texte lesen ist hier nicht so wichtig.

otze

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/211963

Die 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

hustbaer

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/211963

Woher 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.

Bitte ein Bit

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.

hustbaer

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.

Bitte ein Bit

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?

SeppJ

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.