Gewinnt man performance, wenn man innerhalb seines eigenen Prozesses den Speicher selbst verwaltet?
-
Allesquatsch schrieb:
Was ist denn mit dem Einfluss der Objektgröße? (Hierzu habe ich hier noch gar nichts in der laufenden Diskussion gelesen.)
Deswegen bietet es sich an, daß new anders implementiert ist als malloc. malloc sollte effizient bei größeren Blöcken sein und kann durchaus abkacken, wenn man lauter 16 Byte große Mini-Dinge holt. new sollte die Mini-Dinge auch können zwecks polymorphen Objekten mit virtuellen Methoden in einem Zeiger-Container.
-
Ich glaube wir stoßen hier auf eine Gretchenfrage.
Wie sinnvoll ist es die Speicherverwaltung des Betriebssystems zu umgehen bzw. auszutricksen und durch eine andere zu ersetzen? Ist es sinnvoll eine bisher funktionierende Verwaltung durch eine eigene zu ersetzen, welche potenziell viele Fehler enthalten kann und definitiv weniger getestet ist? Und ist man bereit eine Speicherverwaltung auf Geschwindigkeit zu optimieren aber dafür im Gegenzug Sicherheitsabfragen (Overflow, Underflow,...) zu vermeiden?
Bei der Codierung von größeren Optimierungsproblemen war das üblich, sich größere Blöcke vom Betriebssystem zu holen und dann durch eigene Methoden und in Objektgröße aufgeteilt lokal zu verwalten.
Heutzutage würde ich eher Algorithmus mit besserer Komplexitätsklasse suchen.
-
Bitte ein Bit schrieb:
welche potenziell viele Fehler enthalten kann und definitiv weniger getestet ist?
Angst essen Seele auf.
-
Nein!
Ich bin da nur einfach faul. Denn Faulheit ist eine Tugend. Und nur faule Menschen entwickeln Dinge, die einem das Leben erleichtern.
Warum sollte ich mir also die Arbeit machen, eine neue Speicherverwaltung aufsetzen und diese gründlich testen, wenn ich eine bereits habe, welche vielleicht hier und da vielleicht nicht optimal ist, aber dafür bereits vielfach benutzt/getestet wurde?
Warum das Rad neu erfinden?
-
Bitte ein Bit schrieb:
Nein!
Ich bin da nur einfach faul. Denn Faulheit ist eine Tugend. Und nur faule Menschen entwickeln Dinge, die einem das Leben erleichtern.Naja, jedenfalls entwickeln sie keine small object allocators, die einem das Leben erleichtern.
-
Bitte ein Bit schrieb:
Warum das Rad neu erfinden?
Weil ein Autorad für die Straße als Zahnrad im Getriebe einfach nicht wirklich optimal funktioniert und auch nicht, als Antriebs-Zahnrad beim Fahrrad, die idealerweise eher oval sind, dass die unterschiedlichen Kräfte beim Antritt ausgleichen kann. Ein Rad für eine bogenförmige Fahrbahn ist übrigens quadratisch, quasi die Quadratur des Kreises.
Darum kann man operator new überladen. Nicht jedes Problem lässt sich optimal mit einem einzigen runden Rad lösen.
Außer man ist faul. Dann kann an der Software aber auch was faul sein.
-
Warum legt ihr dauernd soviel Speicher mit new an?
Schon mal was vom Stack gehört und davon, dass man in C++ nicht wie in Java programmiert?
Habt ihr eure Programme mit nem Profiler untersucht und festgestellt, dass new mehr als 5% der Laufzeit ausmacht? Wenn ja, was macht das Programm?
-
(k)einer? schrieb:
Warum legt ihr dauernd soviel Speicher mit new an?
Weil wir wissen, was im Hintergrund passiert, wenn wir einen Container der Standardbibliothek benutzen.
-
(k)einer? schrieb:
Warum legt ihr dauernd soviel Speicher mit new an?
Schon mal was vom Stack gehört und davon, dass man in C++ nicht wie in Java programmiert?Die Objekte auf dem Stack sind aber böse und holen sich ihren internen Speicher letztendlich vom Freispeicher, was jetzt? Naja, vielleicht benutzt du ja nie Strings oder Container, dann hast du das Problem nicht, aber könntest auch genauso gut in COBOL programmieren.
-
otze schrieb:
hustbaer schrieb:
new()ist lange nicht mehr so teuer wie es vor 15~20 Jahren war.Kommt auf das Betriebssystem an.
Ja, sicherlich. Und auf die C++ Implementierung. Denn die kann ja, wenn sie fürchtet dass der Allokator vom OS zu langsam ist, was eigenes machen.
kürzlich war ja Heartbleed ein wenig höher geschwappt und der Bug entstand durch eigene Speicherallokation, weil die Entwickler den langsamen allocator von OpenBSD umgehen wollten. Die Leute von OpenBSD haben sich darüber natürlich aufgeregt. Deren malloc ist nämlich so lahm, weil sie es extra gegen solche Angriffe abgesichert haben.
Nö. Der Exploit würde auf anderen Betriebssystemen auch funktionieren wenn kein eigener Allocator verwendet würde.
Die Ursache ist nicht der eigene Allocator, sondern dass der Programmierer einfach einen Range-Check "vergessen" hat. Was alleine schonmal total irre ist - jemand der sowas "vergessen" kann sollte gefälligst die Finger von Projekten lassen wo es um irgendwas geht.
Bzw. gibt es noch grundlegendere Probleme:
-
Warum wurde überhaupt eine (redundante) Längenangabe mitgeschickt?
Die Gesamtlänge des Pakets ist sowieso bekannt -- nur so kann der "Packetierungs" Layer überhaupt passend Speicher für das Paket anfordern. Der weiss nämlich noch nix davon wie bestimmte Paket-Typen zu interpretieren sind, und daher auch nicht dass da ne Payload-Länge in dem Keepalive Paket drin steht.
=> Die Payload-Länge ist redundant, die hätte man sich schön aus der Paket-Länge berechnen können. -
Warum überhaupt nen Payload mit variabler Länge mitschicken? Bzw. warum überhaupt irgend einen Payload?
-
-
hustbaer schrieb:
-
Warum wurde überhaupt eine (redundante) Längenangabe mitgeschickt?
Die Gesamtlänge des Pakets ist sowieso bekannt -- nur so kann der "Packetierungs" Layer überhaupt passend Speicher für das Paket anfordern. Der weiss nämlich noch nix davon wie bestimmte Paket-Typen zu interpretieren sind, und daher auch nicht dass da ne Payload-Länge in dem Keepalive Paket drin steht.
=> Die Payload-Länge ist redundant, die hätte man sich schön aus der Paket-Länge berechnen können. -
Warum überhaupt nen Payload mit variabler Länge mitschicken? Bzw. warum überhaupt irgend einen Payload?
Der Autor des fraglichen Protokolls (RFC 6520), das hier umgesetzt wurde, ist ein uebrigens gewisser "R. Seggelmann".
Den Namen kenne ich doch irgendwo her. Jetzt gehen die Verschwoerungstheorien erst richtig los...(Entschuldigung, falls das fuer euch ein alter Hut ist, aber das habe ich gerade selber gesehen, als ich nach einer Erklaerung fuer dieses komische Protokoll gesucht habe und war schwer ueberrascht. [Das Ergebnis war uebrigens, dass es keine gute Erklaerung gibt.])
-
-
(k)einer? schrieb:
Warum legt ihr dauernd soviel Speicher mit new an?
Erstens machen die Container das, zweitens lassen sich nicht alle Probleme mit Standard-Containern lösen.
(k)einer? schrieb:
Schon mal was vom Stack gehört und davon, dass man in C++ nicht wie in Java programmiert?
Es wäre möglich, dass Leute von RAII tatsächlich noch nichts gehört haben, aber andersrum man könnte auch überlegen, dass es Datenstrukturen gibt, die hier nicht funktionieren, zum Beispiel jede Form von Baum.
(k)einer? schrieb:
Habt ihr eure Programme mit nem Profiler untersucht und festgestellt, dass new mehr als 5% der Laufzeit ausmacht? Wenn ja, was macht das Programm?
Erstmal löst es mein Problem. Dafür brauche ich keinen Profiler.
Das eine Programm erstellt einen Abstract Syntax Tree. Das andere Constructive Solid Geometrie. Beides irgendwie blöd für RAII.
-
Bitte ein Bit schrieb:
Heutzutage würde ich eher Algorithmus mit besserer Komplexitätsklasse suchen.
Na, da kann ich ja froh sein, dass Du nicht gleich empfohlen hast, einfach einen schnelleren Rechner zu kaufen.
Bitte ein Bit schrieb:
Wie sinnvoll ist es die Speicherverwaltung des Betriebssystems zu umgehen bzw. auszutricksen und durch eine andere zu ersetzen? Ist es sinnvoll eine bisher funktionierende Verwaltung durch eine eigene zu ersetzen, welche potenziell viele Fehler enthalten kann und definitiv weniger getestet ist? Und ist man bereit eine Speicherverwaltung auf Geschwindigkeit zu optimieren aber dafür im Gegenzug Sicherheitsabfragen (Overflow, Underflow,...) zu vermeiden?
Diese Argumentation begegnet mir öfters. Am beeindruckendsten fand ich die Stellungnahme zu meinen Projektantrag vom CIO an den Vertriebsvorstand, der mich mit seiner IT-Strategie beauftragt hatte.
Der CIO widersprach der Dringlichkeit, mit der ich die bewährten, dezentralen WinNT-Installationen durch eine zentralen Installation (Datenbank auf 64-bit Unix) ersetzen wollte. Auf viele Jahre hin sei mit reibungslosem Betrieb zu rechnen:
Man müsse doch nur die Vertriebsgebiete so schneiden, dass die Anzahl von Kunden, Umsätzen und Kontakten je Vertriebsniederlassung nicht weiter stiege (... sondern in den Limits von MSAccess bliebe).Ciao, Allesquatsch
-
@Xin
Verwaltest du ne Freelist, oder verwendest du einen "Zeiger weiterschieben und zum Schluss alles auf einmal wegwerfen" Allokator?
-
Bashar schrieb:
(k)einer? schrieb:
Warum legt ihr dauernd soviel Speicher mit new an?
Schon mal was vom Stack gehört und davon, dass man in C++ nicht wie in Java programmiert?Die Objekte auf dem Stack sind aber böse und holen sich ihren internen Speicher letztendlich vom Freispeicher, was jetzt? Naja, vielleicht benutzt du ja nie Strings oder Container, dann hast du das Problem nicht, aber könntest auch genauso gut in COBOL programmieren.
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.)
Xin schrieb:
(k)einer? schrieb:
Habt ihr eure Programme mit nem Profiler untersucht und festgestellt, dass new mehr als 5% der Laufzeit ausmacht? Wenn ja, was macht das Programm?
Erstmal löst es mein Problem. Dafür brauche ich keinen Profiler.
Das eine Programm erstellt einen Abstract Syntax Tree. Das andere Constructive Solid Geometrie. Beides irgendwie blöd für RAII.Wie lange hat das gebraucht vor du deine eigene Speicherverwaltung verwendet hast und wie lange danach?
Und was ist ein Programm, dass nur einen AST erstellt? Das hört sich für mich nach einem kleinen Teil eines Programms an.
Und bei dem Programm das Constructive Solid Geometrie erstellt, interessiert mich auch die Gesammtzeit bis der Körper fertig ist und nicht nur die Zeit um den BSP tree aufzubauen oder sogar nur das einfügen von Objekten in diesen.
-
(k)einer? schrieb:
Bashar schrieb:
(k)einer? schrieb:
Warum legt ihr dauernd soviel Speicher mit new an?
Schon mal was vom Stack gehört und davon, dass man in C++ nicht wie in Java programmiert?Die Objekte auf dem Stack sind aber böse und holen sich ihren internen Speicher letztendlich vom Freispeicher, was jetzt? Naja, vielleicht benutzt du ja nie Strings oder Container, dann hast du das Problem nicht, aber könntest auch genauso gut in COBOL programmieren.
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.)
Das links neben den Postings sind die Namen von denen, die sie geschrieben haben. Scroll mal den Thread zu der Stelle, wo jemand sowas behauptet hat, und frag den dann.
-
Bashar schrieb:
(k)einer? schrieb:
Bashar schrieb:
(k)einer? schrieb:
Warum legt ihr dauernd soviel Speicher mit new an?
Schon mal was vom Stack gehört und davon, dass man in C++ nicht wie in Java programmiert?Die Objekte auf dem Stack sind aber böse und holen sich ihren internen Speicher letztendlich vom Freispeicher, was jetzt? Naja, vielleicht benutzt du ja nie Strings oder Container, dann hast du das Problem nicht, aber könntest auch genauso gut in COBOL programmieren.
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.)
Das links neben den Postings sind die Namen von denen, die sie geschrieben haben. Scroll mal den Thread zu der Stelle, wo jemand sowas behauptet hat, und frag den dann.
Und was wolltest du damit sagen? "Naja, vielleicht benutzt du ja nie Strings oder Container, dann hast du das Problem nicht" Ist doch schwachsinn, dass man sich eine eigene Speicherverwaltung schreiben muss, wenn man mal strings verwendet. Ich weiß schon, dass es hier besonders cool ist, nur einen Teil eines Postings zu nehmen und etwas zusammenhangsloses zu Antworten, was einzeln manchmal zwar stimmt, aber nicht mehr viel mit der eigentlichen Aussage zu tun hat. Darum hast du wahrscheinlich meine letzte Frage absichtlich weg gelassen und ich hat so getan, als ob du es nicht hättest.
Lies doch mal alle drei Fragen und denk über den zusammenhang nach.(k)einer? schrieb:
Warum legt ihr dauernd soviel Speicher mit new an?
Schon mal was vom Stack gehört und davon, dass man in C++ nicht wie in Java programmiert?
Habt ihr eure Programme mit nem Profiler untersucht und festgestellt, dass new mehr als 5% der Laufzeit ausmacht? Wenn ja, was macht das Programm?Für ca. 99% aller Programme die so entwickelt werden dürfte der Zeitanteil den new bei der Programmausführung* ausmacht deutlich unter 5% sein, auch wenn sie Container oder Strings verwenden.
*sogar ohne Idle Zeit, für die Schlaumeier.
-
(k)einer? schrieb:
Ich weiß schon, dass es hier besonders cool ist, nur einen Teil eines Postings zu nehmen und etwas zusammenhangsloses zu Antworten,
In dieser Kunst stehst Du uns aber in nichts nach.
(k)einer? schrieb:
Für ca. 99% aller Programme die so entwickelt werden dürfte der Zeitanteil den new bei der Programmausführung* ausmacht deutlich unter 5% sein,
Ähm, die Frage war mal, ob new solche Happen holen und zerlegen sollte oder alles schlicht ans BS weiterreichen.
-
(k)einer? schrieb:
Und was wolltest du damit sagen? "Naja, vielleicht benutzt du ja nie Strings oder Container, dann hast du das Problem nicht" Ist doch schwachsinn, dass man sich eine eigene Speicherverwaltung schreiben muss, wenn man mal strings verwendet.
Ist es auch. Einfache Grundregel: Wenn man etwas auf mehrere Arten interpretieren kann, von denen eine offensichtlich Schwachsinn ist, dann ist diese nicht gemeint.
Ich weiß schon, dass es hier besonders cool ist, nur einen Teil eines Postings zu nehmen und etwas zusammenhangsloses zu Antworten, was einzeln manchmal zwar stimmt, aber nicht mehr viel mit der eigentlichen Aussage zu tun hat.
Entschuldige bitte, ich habe dein Argument gegen eine eigene Speicherverwaltung so gelesen, als würdest du sagen, dass man das nicht braucht, weil man im Gegensatz zu Java in C++ nur selten new verwendet, wegen Stack usw. Ist das nicht so gemeint gewesen? 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.
-
Xin schrieb:
Es wäre möglich, dass Leute von RAII tatsächlich noch nichts gehört haben, aber andersrum man könnte auch überlegen, dass es Datenstrukturen gibt, die hier nicht funktionieren, zum Beispiel jede Form von Baum.
Falsch.
