Laufzeit OOP
-
Also diese pauschalen Aussagen von wegen "A ist schneller als B" sind aus meiner Sicht Blödsinn.
C kann schneller C++ sein und C++ kann schneller als C sein.
Das muss man schon an speziellen Beispielen belegen und vor allem nachweisen.Ich hatte das mal für STL-Strings gemacht und festgestellt, dass die ANSI-C-Variante in dem Fall deutlich schneller als die std::string-Variante war, was sich auch niemand erklären konnte, außer Volkard, der irgendwas unverständliches in seinen Bart brabbelte, was irgendwie niemand kommentieren wollte. Jedenfalls wurde nicht widersprochen
Aber pauschale Aussagen sind: buuuuh!
-
Ich glaube, der Grund dafür, dass C oft schneller ist, ist dass es darin schwieriger ist schwierige Dinge zu tun.
In C++ schreibt man gern mal string A + string B. Es ist so schön einfach. In C müsste man 2 mal strlen aufrufen, neuen Speicher+1 besorgen, 2 mal memcpy benutzen.... Das tut einfach keiner wenn er nicht unbedingt muss. Man würde sein Programm ändern, sodass die Zielfunktion auch mit 2 Strings klar kommt.
Wenn man in C dasselbe tut wie in C++, dann kommt auch das gleiche Ergebnis raus.
Ich meine aber, dass die Ersparnis bei der Programmierzeit die Laufzeit wert ist, denn man kann danach immernoch die kritischen Stellen optimieren und nicht seine Zeit an unkritischen Stellen verschwenden.Ich würde auch gern volkards Titel von "Moderator" in "Moderater Troll" ändern.
-
volkard schrieb:
hustbaer schrieb:
Also wieso dann erstmal anfangen mit der (IMO unsinnigen) Aussage dass handoptimiertes C "in etwa" schneller sei? Schneller als was? Als Python?
Schneller als in einer "echt objektorientierten" Sprache, und davon gibt es ja nur eine, also schneller als in Java.
Achwatt.
Smalltalk ist doch viel objektiger als Java.
:p
-
Vielen Dank für die vielen Antworten!
@seldon: Danke, diese Ausführung war genau das, was ich brauchte!
Für alle Interessierten, ich hab das Paper übrigens gefunden:
http://users.uom.gr/~achat/papers/IST2003.pdfLG
-
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
