Gewinnt man performance, wenn man innerhalb seines eigenen Prozesses den Speicher selbst verwaltet?
-
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.
-
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.
-
(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.
-
Wow! Wehr dich mal als Mathematiker gegen den Vorwurf, dass du mathematisch argumentierst. Ich glaube, näher an der Gürtellinie, ohne eindeutig drunter zu sein, geht es fast nicht. Deshalb ist die Diskussion für mich hier beendet.
-
hustbaer schrieb:
@Xin
Verwaltest du ne Freelist, oder verwendest du einen "Zeiger weiterschieben und zum Schluss alles auf einmal wegwerfen" Allokator?Bin zwar nicht Xin, kann aber berichten, wie ich es gelernt habe.
Während des Optimierungsvorgangs sind die verworfenen Objekte immer wieder in eine freelist gekommen. War auf Grund der Randbedingungen (Zeitlimit, ausreichende Güte usw.) eine Lösung für den nächsten Bearbeitungsschritt gefunden, wurde diese in eine persistenten Form kopiert.
Die Freigabe des allokierten Speichers hätte man vielleicht auch gezielt vorbereiten und am Ende machen können, wir haben stattdessen aber meist die Optimierung als eigenen Prozess laufen gehabt.Ciao, Allesquatsch
-
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.
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.
-
(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?
-
(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
-
(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
-
@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.)
-
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.
-
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.
-
@Allesquatsch
Sagmal hast du meinen Beitrag überhaupt gelesen?
Da steht kein Wort von Stack.
-
Zusammenhängende Texte lesen ist hier nicht so wichtig.
