Laufzeit OOP
-
Hallo Lymogry,
die (leidige) Diskussion ob jetzt OOP langsamer ist als 'herkömmlicher C-Code' ist mindestens so alt wie OOP. Wie hier schon erwähnt wurde, kann man das gar nicht pauschal beantwortet.
Aus meiner Praxis kann ich folgendes dazu sagen. Es gibt Programme (mit OOP), wo eine bestimmte Funktion vielleicht 1sec benötigt. Dann kommt so jemand (so wie Du), der sich gut in C auskennt, der frisiert jetzt das letzte aus dem Code heraus und am Ende braucht die Funktion 0,95sec. Die 5% Beschleunigung werden dann als Sieg von C über C++ gefeiert. Das der normale Benutzer davon nichts merkt, spielt keine Rolle.
Dann gibt es Programme, die - wären sie mit 'Brut Force 'geschrieben - die Minuten, Stunden oder noch länger laufen würden, bis ein Ergebnis herauskommt. Lässt man hier den C-Progger ran, kann er dann aus 10h vielleicht 9,5h machen - dem User ist das in jedem Fall zu viel. Das Ergebnis ist u.U. Code, der schlecht zu warten ist, und evt. mehr Fehler enthält.
Wenn man es nun schafft, mit komplexen Algorithmen einen ganz anderen Weg zu beschreiben, dann kann man Laufzeiten drastisch verkürzen. Und hier hilft (nicht immer, aber oft) OOP. Denn damit wird man als Mensch zum Teil erst in die Lage versetzt, so ein komplexes Programm überhaupt zu stemmen.
Und plötzlich bleiben von den Stunden nur noch Sekunden - und wenn Du meinst ich übertreibe, dann lass Dir gesagt sein, dass ich das schon mehr als einmal erlebt habe.
Das Programm, welches dann entsteht, könnte man vielleicht noch durch Fine-Tuning um 5% drücken - nur das braucht keiner, das bezahlt Dir keiner und Du hast oft den Nachteil des erhöhten Wartungsaufwands.Lymogry schrieb:
Vollständige OOP Technik? Wie vollständig? Ab wann wird es kritisch??
Es gibt keine 'vollständige OOP Technik' - es gibt nur Probleme (nicht alle!), die man mit OOP sehr viel besser lösen kann als anders.
Lymogry schrieb:
Hängt das von der Tiefe der Vererbung ab?
Hat damit nichts zu tun, das sind statische Informationen.
Lymogry schrieb:
Oder ist jeder Klassenaufbau viel aufwendiger als eine Struct? Was frisst am meisten Leistung, was kann man einsparen?
class und struct ist das gleiche (s. Beitrag von seldon). Virtuelle Methodenaufrufe sind teuer als nicht virtuelle. Die zu vermeiden entspricht dem Beseitigen des Fliegendrecks an der Windschutzscheibe, dann wird das Auto auch schneller. In der Praxis wirst Du (vielleicht) im %-Bereich schneller (s.o.).
Lymogry schrieb:
Wenige Stdbibliotheken nutzen?
gehe einfach davon aus, dass der Code in Deiner Standard-Bibliothek von guten Programmieren geschrieben und schon ziemlich ausgereizt ist.
Ich will damit nicht sagen, dass OOP per se gut ist. Nutze OOP genau dann, wenn das Problem sich damit gut lösen lässt. Gute - und schnelle - Programme werden von guten und erfahrenen(!) Programmierern geschrieben. Wenn Du als OOP-Anfänger OOP anwendest, dann kannst Du vielleicht Fehler machen, die die Laufzeit Deines Programms nur ansteigen lässt - was Dich dann in Deiner Meinung 'OOP macht langsam' weiter bestärken wird.
Das sollte Dich aber nicht davon abhalten, Dich mit OOP zu beschäftigen. Das ist ein mächtiges Werkzeug.Gruß
Werner
-
Danke Werner. Du hast recht, ich bin OOP Anfänger, aber ich will wirklich keinen Streit entfachen, ob das eine oder andere besser ist.
Mich interessiert das, weil eben der original Algo, den ich implementiere, ab einer bestimmten Approximation mehrere Stunden braucht. Ich habe schon bessere Methoden gefunden, um ihn noch leistungsfähiger zu machen, da ist aber noch genug Luft nach oben. Ich war halt erschrocken über die 95% ... das kann ich ja gar nicht gebrauchen, würde meine Bemühungen nur zunichte machen!
Virtuelle Funktionen vermeiden *check*
-
Lymogry schrieb:
Virtuelle Funktionen vermeiden *check*
Bullshit.
-
Kellerautomat schrieb:
Lymogry schrieb:
Virtuelle Funktionen vermeiden *check*
Bullshit.
Die % sind gut ...
(ok ... wenns sein muss bleiben sie natürlich)
-
Lymogry schrieb:
Virtuelle Funktionen vermeiden *check*
Äh - nein (Du hast mich missverstanden).
wenn Du eine Virtuelle Methode brauchst, so schreibe sie.
Wenn Du sie 'vermeiden' möchtest und dazu große Kopfstände in Deinem Design machen musst, so lass es bleiben und behalte die virtuellen Methoden bei.Außerdem gilt immer - erst Laufzeiten messen und erst dann optimieren. Nach meiner Erfahrung geht die Zeit nie(!) dort verloren wo Du vorher geglaubt hast, dass es länger dauert!
Gruß
Werner
-
Kellerautomat schrieb:
Lymogry schrieb:
Virtuelle Funktionen vermeiden *check*
Bullshit.
Es ist halt Vererbung angewandt. Die Lehrbücher sagen ja auch dazu, dass Vererbung schlecht ist (weil statisch), und Komposition das einzige wahre ist. Gleichzeitig wird aber alles von allem abgeleitet.
Es ist halt alles eine Frage der richtigen Abstraktion, des guten Designs und der ordentlichen Anwendung.
Weil dann sind virtuelle Methoden nicht nur nicht schlecht, sondern fast schon der Himmel auf Erden. Bei falscher Anwendung werden die aber schnell zur Hölle auf Erden.
-
Ist OT, aber ich bin ja immer neugierig, mit was sich die Menschen hier so beschäftigen.
Worum geht's in dem Projekt eigentlich?
Und wenn's nicht zu geheim ist: nenn doch mal bitte Beispiele für diese Sonderfälle, die Dich so plagen.
-
weil eben der original Algo, den ich implementiere, ab einer bestimmten Approximation mehrere Stunden braucht
Du koenntest auch einfach mal Fakten schaffen, indem du das Problem als auch den Algorithmus nennst. Viele NP-Probleme lassen sich gut in andere transformieren, fuer die es bereits fertige und schnelle Bibliotheken gibt, bzspw. travelling sales man, integer linear programming oder 3sat.
-
knivil schrieb:
weil eben der original Algo, den ich implementiere, ab einer bestimmten Approximation mehrere Stunden braucht
Du koenntest auch einfach mal Fakten schaffen, indem du das Problem als auch den Algorithmus nennst. Viele NP-Probleme lassen sich gut in andere transformieren, fuer die es bereits fertige und schnelle Bibliotheken gibt, bzspw. travelling sales man, integer linear programming oder 3sat.
Tut mir leid. Die eidesstattliche Erklärung verbietet es mir, da konkret zu werden
Soviel kann ich ganz allgemein sagen:
http://de.wikipedia.org/wiki/Constraint-Satisfaction-ProblemIrgendein Problem aus dem Bereich mit irgendwelche Bedingungen, mit irgendwelche Algorithmen aus dem Bereich, damit beschäftige ich mich
-
Und deiner ist besser als uebrige CSP-Solver, e.g. CPLEX?
Und zum Thema: OOP ist grossartig fuer Softwarearchitekturen. Algorithmen in C++ sind selten OOP.
-
knivil schrieb:
Und deiner ist besser als uebrige CSP-Solver?
Du bist aber penetrant!
Ich habe ein Problem aus dem Raum der vielen SAT Probleme. Mit Sonderbedingungen, wo ich Suche im CSP vorher abbrechen kann. Je besser ich die Sonderfälle abgrenzen und früher abbrechen lassen kann, desto schneller wirds. Damit kann ich mein Problem behandeln, aber nicht alle!
-
Nun in Java gab es mal ein Paper, dass bei einer komplizierten Suche den Rueckgabewert ueber Exceptions transportierte, auch etwas womit man in C++ experimentieren kann.
Damit kann ich mein Problem behandeln, aber nicht alle!
Nun, es sollte trotzdem mit anderen Solvern getestet werden, auch wenn deine Sonderbedingungen nicht modeliert werden koennen. Leider habe ich die aktuelle Entwicklung nicht mehr verfolgt, deswegen kann ich dir keinen Rat geben. Minion Beispielweise nutzt auch OOP/virtuell, aber ich weiss nicht, wie stark es zum Tragen kommt. Schaut man sich MiniSAT an, so habe ich auf Anhieb keine virtuellen Funktionen ausmachen koennen.
-
knivil schrieb:
Nun in Java gab es mal ein Paper, dass bei einer komplizierten Suche den Rueckgabewert ueber Exceptions transportierte, auch etwas womit man in C++ experimentieren kann.
oh, ok. Literatur ist immer gut. (werd ich bei Gelegenheit mal danach suchen)
Nun, es sollte trotzdem mit anderen Solvern getestet werden, auch wenn deine Sonderbedingungen nicht modeliert werden koennen.
sowas in der Art habe ich hier liegen. Das wurde schon (teilweise) modelliert und implementiert. Meine Aufgabe ist, es noch zu verbessern und eine bessere Approximation zu erhalten. (Anm.: Die Aufgabe kommt von meinem Prof, der die erste Modellierung selber gemacht hat. Ich bin schon im Thema drin, hab schon einen ersten Algorithmus mit C. Aber ich kann das noch verbessern, ich werde da auch gut von ihm betreut. Bin ganz zufrieden.
)Leider habe ich die aktuelle Entwicklung nicht mehr verfolgt, deswegen kann ich dir keinen Rat geben, nur dass OOP eine schlechte Wahl ist.
Ich glaube, du stellst dir das gerade ganz falsch vor.
Die Objekte, die die Bedingungen erfüllen müssen, sind ganz ähnlich zueinander. Diese hatte ich vorher in Structs gefasst. Habe aber mehrere Structs verwalten müssen, weil die zwar ähnlich, aber etwas unterschiedlich waren. Und die Funktionsaufrufe waren furchtbar ....
Das kann ich jetzt mit Klassen und Vererbung besser gestalten.Ach ja ... noch eine Frage:
wie sieht es mit Funktionenüberladen aus? Wieviel Zeit frisst das? Ist das linear?
-
Das frisst gar keine Zeit, weil beim Compilen schon die richtige Funktion bestimmt wird. Das ist so, als wären beides unabhängige Funktionen
-
Marthog schrieb:
Das frisst gar keine Zeit, weil beim Compilen schon die richtige Funktion bestimmt wird. Das ist so, als wären beides unabhängige Funktionen
perfekt danke!
-
Lymogry schrieb:
wie sieht es mit Funktionenüberladen aus? Wieviel Zeit frisst das? Ist das linear?
konstant, wird ja zu compilezeit ausgewertet
-
Lymogry schrieb:
Ach ja ... noch eine Frage:
wie sieht es mit Funktionenüberladen aus? Wieviel Zeit frisst das? Ist das linear?Da deine Fragen nun recht allgemein in Richtung C vs. C++ gehen: Das meiste an C++ ist "nur" Syntaxzucker gegenüber C. Keine Kosten, einfachere Schreibweise. Wenn du etwas in C mit dem gleichen Effekt machen könntest wie ein C++-Feature, eventuell mit viel Schreibarbeit, dann kannst du davon ausgehen, dass in beiden Fällen der gleiche Code erzeugt wird. Die Übersetzungstabelle ist grob:
Klassen und Memberfunktionen -> structs und Funktionen und viel Schreibarbeit
(nicht-virtuelle) Vererbung -> structs und Funktionen und noch viel mehr Schreibarbeit
Templates -> Makros (und nicht void-Pointer! void-Pointer haben Laufzeitkosten. Templates nicht.) oder viel Schreibarbeit
Überladung -> Funktionen und viel SchreibarbeitWas interessant wird, sind "echte" C++-Features, wie Exceptions und dynamische Aspekte des Typensystems (virtuelle Funktionen, RTTI). Dies ist teilweise mit echten Kosten verbunden, aber dies sind Dinge, die man in C gar nicht oder nur schwer nachmachen kann. Eine entsprechende C-Lösung wird oft langsamer sein, weil du es nicht so gut hin bekommst wie die Compilerhersteller. Dies ist zum Beispiel bei Exceptions der Fall, wo bei vielen Implementierungen von C++ überhaupt keine(!) Kosten auftreten, so lange keine Exception fliegt, da man spezielle Eigenschaften der Architektur ausnutzen kann, auf die man in (streng standardkonformem) C keinen Zugriff hat.
-
Zusammengefasst: Es gibt praktisch nichts, was du in C machen kannst, was du nicht auch in C++ machen könntest, umgekehrt aber schon. C++ ist ausdrucksstärker und ermöglicht es, mit weniger Code die gleiche oder bessere Performance zu erreichen*.
=> Es gibt keinen vernünftigen Grund, heutzutage noch C zu benutzen, wenn C++ ebenfalls eine Option wäre...
* Vorausgesetzt, man weiß, was man tut; aber diese Voraussetzung muss generell erfüllt sein, damit ein solcher Vergleich überhaupt jemals irgendwie Sinn ergeben könnte. Schlechten oder sinnlosen C++ Code mit optimalem C Code zu vergleichen, oder umgekehrt – wie es in solchen Diskussionen meist getan wird – ist natürlich völlig wertlos.
-
sehr gut sehr gut sehr gut!
C++ ist ausdrucksstärker und ermöglicht es, mit weniger Code die gleiche oder bessere Performance zu erreichen.
wahnsinn ... ich hab grad die ersten Structs in Klassen umgewandelt, denen noch ein paar nette Funktionen und statische Werte gegeben und ich liebe diesen Konstruktor!
Meine 300 Zeilen Code, die damals den Speicher freigeräumt, den Input eingelesen und einige erste Werte berechnet haben ... die haben sich zu 30 Zeilen gekürzt.Und ich kann dank dem Konstruktor und den Default Werten mit nur einem Befehl auf alles zugreifen, was ich brauche!
ohne Laufzeitprobleme ... ! uiuiui *begeistert*
Ich liebe C++ jetzt schon!
-
Warte nur, bis du lernst, was ein Destruktor ist (das dürfte so ungefähr das nächste Kapitel nach dem Konstruktor sein). Damit kannst du richtig tolle Sachen machen (z.B. dies). Sag auf Wiedersehen zu sämtlichen Problemen und Fallstricken bei der SpeicherverwaltungRessourcenverwaltung!
