Performancemythen?

Undertaker

Shade Of Mine schrieb:

@Undertaker: Themenverfehlung.

ja, hast recht. mit performancemythen hatte das nichts zu tun.

Xin

Mr. N schrieb:

Xin schrieb:

Klassenbasiert ist alles, was mit Datenstrukturen zu tun haben, die ausschließlich auf den aktuell verwendeten Datentyp - eben die Klasse - fixiert sind und Daten eben klassifizieren. Du könntest Dir in dem Zusammenhang kurz Gedanken machen, warum das Schlüsselwort in allen gängigen Sprachen "class" heißt und nicht "object".

Weil die Instanz das Objekt ist.

Richtig. Ein Objekt für das ich mich bei klassenorientierter Programmierung nicht die Bohne interessiere, es ist mein Datensatz und wenn das Vieh in Wirklichkeit ein Auto muss das Auto eben ab sofort Traubenzucker verbrennen.
Ich orientiere mich nicht am Objekt, sondern an dem Datentyp mit dem ich grade dahin referenziere.

Tier * tier = new Katze();
tier->NichtVirtuelleFunktion();

Hat Katze NichtVirtuelleFunktion überladen, interessiert keine Sau, dass das Objekt tier eine Katze ist. Man orientiert sich an der Referenz-Klasse, nicht am Objekt => nicht objektorientiert.

Fällt Dir auf, wie der sich der Begriff objektorientiert, der in OOP abgekürzt wird, hier wieder findet?
Wenn wir von OOP sprechen, heißt das eben nicht OOPUVVKMDHUVM. (objektorientierte Programmierung unter Verwendung von Klassen mit DataHiding und vielem mehr). Wenn wir den OOPUVVKMDHUVM definieren wollen, dann würde ich Dir uneingeschränkt reicht geben. Der Punkt heißt aber nur und ausschließlich "objektorientiert".

Mr. N schrieb:

Xin schrieb:

Katzen gehören zur Klasse der Tiere, welche zur Klasse der Lebewesen gehören. Bis hierhin gibt es noch nichtmal ein Objekt, keine existierende Katze, kein existirendes Tier, lediglich die Feststellung, dass derartige Objekte - sollten sie irgendwann existieren - irgendwie klassifiziert werden und dass zwischen Katzen und Tieren eine gerichtete Verbindung besteht.
Beim Zugriff auf die Objekte orientiert sich die Sprache an der Klasse, die man zur Zeit betrachtet. Ein Tier ist eine andere Klasse als eine Katze und Tiere machen alles wie Tiere und Katzen machen alles wie Katzen. Katzen sind Tiere und eine Objekt, das als Tier aufgefordert wird etwas zu tun, interessiert sich nicht die Bohne, dass Katzen das lieber anders machen würden.
Alles statisch, eben nicht objektorientiert, aber eben mit 'class'es klassifiziert.

Objektorientiert wird das ganze in dem Moment, wo es eben nicht mehr um die Klasse, sondern um die Klasseninstanz - das Objekt - geht. Eine Katze ist eine Instanz der Klasse Tier und genauso eine Instanz der Klasse Lebewesen. Da jedoch nicht mehr alleine auf die Klassifizierung Wert gelegt wird, sondern man sich am wirklichen Typ der Datenstruktur - des Objektes - orientiert, verhält sich ein Objekt Katze der Klasse Tier wie eine Katze, genauso wie ein Objekt Katze der Klasse Lebewesen sich wie eine Katze verhält.
Man arbeitet objektorientiert und damit sich das von klassenorientierter Programmierung unterscheidet, nehme man in C++ das Schlüsselwort "virtual".

Ich stimme deiner Definition nicht zu. Encapsulation geht auch ohne Polymorphie und ist doch sehr objektorientiert. Aber da möchte ich dir nochmal den Link von oben ans Herz legen. In diesem Link wird OOP zunächst in mehrere Aspekte aufgeteilt und verglichen, welche der existierenden Varianten von OOP welche Aspekte beherrscht. Meine Konsequenz aus dem Artikel war, OOP möglichst breit zu fassen. Du hingegen definierst OOP als "virtual-Methoden", und das halte ich für gefährlich und falsch.

Meine Konsequenz aus dem Artikel ist, dass Paul Graham hier Dinge, die notwendig sind, um OOP zu betreiben, wie zum Beispiel Klassifizierung aber auch unnötige Techniken wie Überladung als OOP verkauft. Ohne Klassifizierung gibt's kein OOP, aber ohne OOP gibt Klassifizierung. Klassifizierung geht auch ohne "class", aber "class" ist praktisch, weil es wie geschaffen dafür ist, Datenstrukturen einfach zu klassifizieren. Das wiederum könnte daran liegen, dass "class" dafür geschaffen wurde...
Das ist eine Frage der Abhängigkeit von Techniken, aber kein Grund alles in einen Topf zu werfen, OOP auf den Deckel zu stempeln und das als die Wahrheit zu verkaufen.
Die Sichtbartkeit von Daten ist ein gutes Feature. OOP funktioniert problemlos, wenn alle Informationen public sind. Die Möglichkeit es einzuschränken ist also keine Vorraussetzung für OOP und DataHiding funktioniert auch problemlos mit Objekten, wo sich der Programmablauf nicht am Objekttyp orientiert.
DataHiding ist einfach eine andere Baustelle.

Mr. N schrieb:

Xin schrieb:

Eine "class" ist eine Struktur mit einem eigenen Namensraum und beim Aufruf von Methoden steht das erste Argument links vom Methodennamen. Mehr ist das nicht und solange da kein virtual drin steht, ist es problemlos und ohne Aufwand in C abzubilden, weil man keine OOP Unterstützung benötigt.

Man kann auch in C, sogar mit structs, objekt-orientiert programmieren, aber wir haben da ja einen definition-mismatch.

Haben wir in dem Punkt nicht, weil das genau das ist, was ich grade geschrieben habe.
In C gibt es keine Klassen (aber dennoch die Möglichkeit zur Klassifizierung) und es gibt kein DataHiding und Du stimmst grade zu, dass OOP unabhängig davon geht, was bedeutet, dass DataHiding und Klassen für OOP nicht erforderlich sind.
Wir sind uns also einig und Du widersprichst Deiner vorherigen Aussage.

Mr. N schrieb:

Xin schrieb:

Mr. N schrieb:

Xin schrieb:

Es ist nicht langsamer, weil es eine Technik ist, sondern weil eine der Aufruf einer virtuellen Funktion bedeutet, dass man Dereferenzieren, Addieren und nochmals Dereferenzieren muss. Das kann man nicht in einer einzigen Assembleranweisung abhandeln, das kostet also etwas Zeit. Nicht viel, aber eben etwas.

In gewissen Fällen muss der Compiler die virtuelle Methode nicht indirekt aufrufen.

Wenn nach dem übersetzen sicher ist, dass es keine Ableitung von einer Klasse gibt, dann kann man darauf verzichten.
Ansonsten bin ich neugierig, was jetzt kommt.

Geballte Kompetenz kommt jetzt.
Katze ichbineinekatze;
ichbineinekatze.rufe_virtuelle_methode_auf(); //hier muss kein virtueller Methodenaufruf stattfinden, vielmehr wird die Methode direkt aufgerufen

Wenn nach dem übersetzen sicher ist, dass es keine Ableitung von einer Klasse gibt, dann kann man darauf verzichten.
Wenn Du mir widersprechen willst, solltest Du nicht wiederholen, was ich einen Satz dadrüber geschrieben habe.
Aber Du bist ja nicht der einzige in dem Thread mit einem derartigen Argumentationsstil.

Deine geballte Kompetenz ist ein Plagiat und damit ein Griff ins Klo. Wenn das alles war, war das als Argument wirklich beeindruckend. Deine geballte Kompetenz reichte leider nicht, um korrekt abzuschreiben, denn Du hast leider die Zusatzbedingung vergessen, dass sichergestellt sein muss, dass von der Klasse keine Ableitung existiert. Damit hat sich Deine geballte Kompetenz leider als doppelter Griff ins Klo erwiesen.
Herzlichen Glückwunsch.

Mr. N schrieb:

Xin schrieb:

Mr. N schrieb:

Besteht für dich alles nur aus Implementierungsphilosophie? Doch, wenn ich eine Zahlen-Klasse habe, würde ich das meistens OOP nennen. (Wobei in C++ die Grenzen verwischen.)

Meistens? Mal ja, mal nein? Natürliche Zahlen haben nur ein bißchen OOP, Komplexe sind kompliziert, deswegen müssen die in OOP geschrieben werden?
Wovon hängt das ab? Uhrzeit? Tagesform? Wetter?

Der Witz ist, dass meine Zahlenklasse (nennen wir sie rational) sich wie eine Zahl verhält, nach außen hin, die Implementierung aber austauschbar und egal ist.

Das ist ja klasse! Und man braucht noch nichtmals OOP dafür, da die Überladung des operator int() rein statisch abläuft. Klassenbasiert und eben nicht objektorientiert.

Mr. N schrieb:

Xin schrieb:

In C++ verwischen Grenzen? Ist OOP in C++ was anderes als in Simula, Java, oder warum verwischen Grenzen grade in C++?

C++ is a Multi-Paradigm Language.

Und weil C++ mehr als nur OOP kann, ist OOP in C++ etwas vollkommen anderes als in anderen Sprachen oder wie soll ich das verstehen?

Mr. N schrieb:

Xin schrieb:

Wenn ich eine Klasse habe, würde ich von einer Klasse sprechen. Darum heißen die Dinger Klassen, vermute ich.
Ein Instanz einer Klasse ist ein Objekt - wie auch ein Array, ein Integer und alles, was aus mehr als void besteht.

Er benutzt schon selber das wort Objekt. (Ja, ich habe den nächsten Abschnitt gelesen. )

Yepp, und zwar bewußt, da alles ein Objekt ist. Daher das Wort "Objekt". Nur mal kurz überlegen, was "Objekt" bedeutet. Objekte hat man im Schrank stehen: Bücher, Kerze, Uhr, Teelicht. Oder in der Kunstausstellung: Bild, Statue, Teebeutel. Objekt ist ein hübscheres Synonym für "irgendein Ding".

Nochmals: Egal, selbst wenn ein Paul Graham behaupten würde, dass ein Objekt nur etwas sein kann, was mit class definiert ist (was er nicht tut!), ist das Quatsch. Ein Datensatz - egal, wie er entstanden ist, ob als Struct, als Integer, als Array von Chars oder als Class ist ein Objekt.

Ein int[4] ist exakt das Gleiche wie ein

class FooBar
{
  int Eins, Zwei, Drei, Vier;
};

Es sind vier Zahlen, die etwas repräsentieren. Bei einer Klasse oder einem Struct darf den einzelnen Elementen auch noch Namen geben. Dem Datentyp könnte man notfalls mit typedef einen Namen geben.

Da kommt Java an und macht den OOP-Hype und erklärt alles, was nicht von "class object" abgeleitet ist, steht für böse Magie, weil das darf ja kein Objekt mehr sein und auf einmal stellt jeder das Denken ein.
Was in Java nicht von "object" abgeleitet ist, ist keine Instanz von "class Object", das ist nicht gleichbedeutend mit "ist kein Objekt". Das sprechen eure Profs vielleicht nicht sauber aus, vielleicht glauben sie sogar, dass ein int kein "irgendein Ding" ist, aber mit ein wenig gesunden Menschenverstand, kapiert man doch, das alles, was nicht nichts (void) ist, eben "irgendein Ding" (Objekt) ist.

Wenn man nun das Denken eingestellt hat und merkt, dass man zwischen Klassenorientiert und Objektorientiert nicht mehr unterscheiden kann, dann kann man entweder das Denken wieder anwerfen oder Sonderbedingungen suchen, z.B. Ein Objekt ist irgendein Ding, dass aber kein char, kein int, kein Array, kein Struct, kein was auch immer ist, sondern eine Klasseninstanz ist.

Hätte man so gedacht, als OOP erfunden wurde, hätte man es klasseninstanzorientiertes Programmierung genannt.
Ist es denn wirklich so schwer, sich die Bedeutung der Worte 'objekt orientiert' mal bewußt zu machen?

Programmiert man objektorientiert, arbeitet man weiterhin mit Objekten, die allerdings zusätzlich eine Typinformation enthalten im Datensatz enthalten, an der sich die Algorithmen orientieren können. In dem Fall ist int[4] eben mehr nicht identisch mit

class FooBar
{
  int Eins, Zwei, Drei, Vier;
  virtual ~FooBar();
};

Mr. N schrieb:

Xin schrieb:

Wenn sich das Programm am Datentyp der Klasse orientiert, nenne ich das klassenorientiert.
Wenn sich das Programm am Datentyp des Objektes orientiert, nenne ich das objektorientiert.

Ich stimme nicht zu.

Ja, wenn Du nicht zustimmst, dann muss ich mich geirrt haben.
Dagegen gibt's auch nichts mehr zu sagen, schließlich ist neben der Allwissenheitsvermutung ansonsten weit und breit kein Argument zu sehen.

Mr. N schrieb:

Wenn ich eine andere Definition habe als du bringt das nix. (Und meine ist von mehreren Links gedeckt, falls dir mein Wort nichts bedeutet.)

Mir bedeutet Logik etwas. Daran halte ich mich. Solange Du nicht mehr zu bieten hast als "Ich stimme nicht zu" und in Deinen Quellen nicht das "Warum" zitieren kannst, bedeutet mir Dein Wort genausowenig wie die Links.

Ich ärgere mich ehrlich gesagt darüber, dass ich mir viel Mühe gebe, das "Warum" zu erklären und dann kommen Argumentationen, die meinen Text abschreiben und behaupten, dass wäre ein Gegenargument oder ein "Ich stimme nicht zu". Wenn Du diskutieren willst und etwas behaupten willst, mach Dir wenigstens die Mühe das "Warum" zu Deiner Behauptung mitzuliefern. Ansonsten kann ich auch die Bildzeitung aufschlagen.

Es ist für mir nicht wichtig, Dich zu überzeugen, Du darfst glauben, was immer Du möchtest. Du darfst mir auch gerne etwas neues beibringen. Aber das funktioniert nicht allein mit Behauptungen oder Behauptungen anderer. Quotes konnte ich genauso beibringen und eine Zitateschlacht hilft nichts, denn wir werden nach belieben Behauptungen für jeden Mist finden, die wir zitieren können. Du vermutlich mehr als ich.

Aber weiterbringen wird uns das wirklich nicht, denn ohne eine klare Erklärung des "Warums", wirst Du meine Ansicht nicht kippen können. Was ich hier erläutere, habe ich genauso schon mit Stroustrup belegen können, der das "Warum" von C++ einen Wälzer ausführlich in 550 Seiten, von denen ich jede einzelne Seite gelesen und nachvollzogen habe. Für mich ist die Frage, des "Warums" wirklich sehr erschöpfend beantwortet.
Aber ich kann Dir auch sagen, dass ich vor acht, neuen Jahren vermutlich noch genauso argumentiert hätte wie Du.
Ich sehe, dass ich mit meinem Verständnis einen Schritt weiter gekommen bin. Ich bin den Schritt bewußt gegangen und solange Du nicht wirklich extremst gute Argumente bringst, die ich noch nicht kenne, weiß ich, dass richtig liege. Das wird Dir nämlich nicht gelingen.
Ich liege richtig, unabhängig davon, was in Wikipedia steht, unabhängig davon, wieviele Leute das in diesem Forum anders sehen. Das hat auch nichts mit Sturheit zu tun, sondern eben mit der Tatsache, dass ich von Deinem Point of View mich in den letzten Jahren durch die Entwicklung meines Compilers und das Lesen von entsprechender Fachliteratur auf meinen Point of View bewegt habe.

tntnet schrieb:

ok - ich habe mir das nochmals durchgelesen. Ich wollte der ersten Aussage wiedersprechen, daß Arrays schneller sind. In vielen Fällen stimmt das, aber nicht immer. Daher kann man das so global nicht sagen. Das wollte ich durch ein Beispiel erläutern.

Das ist soweit löblich, aber was mich hier - genauso wie jetzt bei MrN - wirklich nervt ist die Tatsache, dass sich so ein Pulk aufbaut, wo jeder meint, dass ich Unfug schreibe, obwohl Dein Argument in meiner Aussage längst berücksichtigt ist.

Hier haben wir den nächsten Kandidaten:

Shade Of Mine schrieb:

@Xin: ich brauchte zB keine Klassen für ein OOD und genau da scheitert dein Ansatz.

Wiederhole ich mich darin, wenn ich schreibe, dass man nicht gegen mich Argumentiert, wenn man meine Argumentation abschreibt?

Damit sind jetzt drei Leute, die meine Aussage abschreiben und behaupten, sie würden mich damit widerlegen.
Wozu erkläre ich es eigentlich so deutlich, wahrscheinlich, um mir als nächstes anzuhören, dass weil ich es erkläre, hat keiner Bock es zu lesen und widerspricht einfach mal, weil andere widersprechen ja auch.

Sorry, aber wenn die Dinge so diskutiert werden, da frage ich mich doch, in welchem Kindergarten ich gelandet bin.

Das Resultat ist dann sowas, wo jemand feststellt, dass ja alle gegen mich argumentieren, die breite Masse wirds ja wissen, also muss, was ich schreibe ja Unfug sein...

scrub schrieb:

Deine Definition von OO klingt sehr merkwürdig und ich habe sie auch noch nie gehört (da scheine ich ja nicht der einzige zu sein).

...statt sich davon zu Befreien, was irgendwer definiert und sich selbst Gedanken zu machen, was denn eigentlich logisch ist. Für OOP reichen Objekte allein eben nicht. Man muss sich halt auch wirklich darum kümmern, um welchen Objekttypen es sich handelt, darum steht das zweite O für Orientierung. Dafür braucht man keine Klassen, kein Encapsulation und keine DataProtection, dafür braucht man Vererbung und das geht genausogut mit Structs oder Arrays - nur halt nicht so komfortabel wie mit Klassen.

lieber Xin,

dein(e) post(s) auf seite 8 sind leider von vorne bis hinten grober unfug (dein letzter post vor meinem hier ist nur reines rumgetrolle darum werde ich auf den nicht eingehen)
wenn ich mich richtig erinnere bist du auch derjenige, der damals felsenfest den standpunkt "Phantasie ist wichtiger als Wissen" vertreten hat. Offentsichtlich lebst du diesen standpunkt hier mit vergnügen aus. Dennoch wär es von vorteil wenn du dir mal ein bisschen *Wissen* über Objektorientierte Programmierung aneignest, denn OOP ist *definiert*. /deine/ definition ist leider nur *phantasie*. deshalb brauchst du dich auch nicht wundern dass hier alle außer dir eine andere (nämlich *die*) definition von oop anwenden. wenn du deine oop-definition als "das wahre" verkaufen willst schreib ein buch oder werd priester.

gruß,
gurkenesser

PS: warum du hier versuchst mit Bjarne Strostrup zu argumentieren verstehe ich übrigens auch nicht.

Alan Kay schrieb:

I invented the term Object-Oriented, and I can tell you I did not have C++ in mind.

.filmor

Zuersteinmal möchte ich Xin ein wenig beipflichten (auch wenn er das bei seinem Auftreten wohl nicht für nötig erachtet).

Seine Definition von Objektorientierung ist durchaus schlüssig und kann mit der zugehörigen Argumentierung eine allgemeine Definition sein. Wenn man diese so annimmt (also der Einsatz von virtuellen Methoden OOP ausmacht), dann muss man auch zugestehen, dass dann OOP sehr viel langsamer ist. Beispielsweise kann nicht ge-inlined werden und es gibt eine Indirektion (wobei ersteres bei kleinen Methoden wohl gravierender ist). Damit kommt man sicherlich auf Faktoren >5, bei noch dilletantischerem Einsatz (wie ich es mal bei einer GoL-Implementierung gemacht habe ;)) sogar >20. Bei behutsamen Einsatz (sprich recht lange, eh nicht sinnvoll zu Inlinende Methoden) macht es dagegen praktisch nichts aus, da die Ausführungszeit deutlich über die Aufrufzeit dominiert.

Und Mr.N und Xin, bitte kommt das nächste Mal schneller und ohne Beleidigungen oder Kollateralbeleidigungen zum Punkt. Solche Lappalien kann man auch mit weniger Postings abgehakt bekommen.

Mr.N.: Kann es sein, dass du eine andere Definition
       von OOP hast als ich? Wenn ja, welche?
Xin:   Ja die habe ich. Für mich ist OOP die Benutzung von
       virtuellen Methoden, da sich nur dann ein
       entsprechender Ausdruck tier->iss () am Objekt und
       nicht an der Klasse orientiert.
Mr.N.: Ah, okay. Dann hast du Recht. Für mich reicht schon
       die Nutzung von Datenkapselung. Und damit hat man
       noch keinen Performanceverlust.
Xin:   Das stimmt natürlich. Verbleiben wir also bei den
       verschiedenen Auffassung aber den jeweils selben
       Ergebnissen.

Ende.

Und bitte setzt euch jetzt nicht schon wieder in Flammen, falls ich einen der Standpunkte nicht korrekt dargestellt habe. Es ist sehr schwer in diesem Wirrwarr den Überblick zu behalten.

PPS: was mich noch wundert ist warum du für 3 zeilen unfug trotzdem so lange beiträge schreiben musst. willst du von dem unfug ablenken oder steigert das dein selbstwertgefühl?

gurkenesser schrieb:

... denn OOP ist *definiert*.

Wer definiert das? Wo kann ich das nachlesen?

Jester

Im Wikipedia-Artikel und diversen Veröffentlichungen aus Mitte der 80er, als das ganze aufkam. (Gibt natürlich auf jede Menge neuerer Veröffentlichungen).

Xin

.filmor schrieb:

Zuersteinmal möchte ich Xin ein wenig beipflichten (auch wenn er das bei seinem Auftreten wohl nicht für nötig erachtet).

Auch wenn ich häufig und gerne andere Wege gehe als die Masse, freue ich mich, wenn gelegentlich jemand bemerkt, dass es nicht der Holzweg ist, nur weil die Masse das glaubt.

.filmor schrieb:

Und Mr.N und Xin, bitte kommt das nächste Mal schneller und ohne Beleidigungen oder Kollateralbeleidigungen zum Punkt.
[...]
Xin:   Das stimmt natürlich. Verbleiben wir also bei den
       verschiedenen Auffassung aber den jeweils selben
       Ergebnissen.

*lach* ;-))

Die Idee dahinter ist natürlich, Mr.N auch mal verbal in den Hintern zu treten, um die Hirnwindungen in Bewegung zu setzen, nachdem erstmal ein 'Das ist Unfug' ohne irgendeine Begründung kam. Mit etwas Glück machen MrN und/oder andere durch Denken diesen Schritt schneller, statt wie ich erst das eine oder andere dicke Buch lesen zu müssen.

DEvent

Man geht davon aus, dass ein C++ Programm 5-10mal langsamer läuft als ein entsprechndes C Programm.
Das ist aber sehr programmabhängig, die Zahlen sind also bestenfalls wage Anhaltspunkte, ich habe sie aber schon in verschiedenen Büchern zu dem Thema gesehen. Es liegt auch nicht vorrangig an OOP, sondern an der Tatsache, dass C++ Compiler aufwendiger sind als C-Compiler, entsprechend auch die Optimierung aufwendiger wird. Doch auch die C++ Compiler werden immer besser. Die Qualität der C++-Übersetzungen wird sich mehr und mehr an C annähern, genauso wie sich C an Assembler weiter annähern wird. Trotzdem kann man davon ausgehen, dass C++-Programme langsamer bleiben als C-Programme, weil irgendeine Ungeschicktheit findet sich vermutlich in jedem C++-Programm.

Wieso interessiert das einen? Diese 5 oder 10 ist doch eine Konstante und hat damit bei der Laufzeit absolut keine Bedeutung.

O(k * n) = O(n)
O(k * n^p) = O(n^p)
O(k * p^n) = O(p^n)
usw.

Was sind eigentlich CPU-Limitierte Spiele??

scrub

Xin schrieb:

Das Resultat ist dann sowas, wo jemand feststellt, dass ja alle gegen mich argumentieren, die breite Masse wirds ja wissen, also muss, was ich schreibe ja Unfug sein...

Mach mal den Knick aus Deiner Optik. Ich habe nirgends geschrieben, daß das, was Du schreibst, Unfug sei. Du hast nur wieder mal geglaubt, zu wissen, was ich mir dabei gedacht habe- reichlich riskant.

Eigentlich wollte ich nur mal einwerfen, wie ein Anfänger das sieht, und ansonsten mitlesen und lernen. Aber bei dem geballten Sendungsbewußtsein hier ist das anscheinend nicht möglich. Schade.

Daher wird für mich OOP bleiben, daß man Klassen schreibt und sie dann zum Bau von Objekten benutzt. Vielleicht habe ja, wie ich Deinem Großvatergeschwätz entnehmen kann, in 8 oder 9 Jahren "richtigere" Ansichten davon.

Mr. N

Xin schrieb:

Mr. N schrieb:
Geballte Kompetenz kommt jetzt.
Katze ichbineinekatze;
ichbineinekatze.rufe_virtuelle_methode_auf(); //hier muss kein virtueller Methodenaufruf stattfinden, vielmehr wird die Methode direkt aufgerufen
Wenn nach dem übersetzen sicher ist, dass es keine Ableitung von einer Klasse gibt, dann kann man darauf verzichten.

class KleineKatze : public Katze {
  void rufe_virtuelle_methode_auf();
};
Katze ichbineinekatze;
ichbineinekatze.rufe_virtuelle_methode_auf(); //hier muss kein virtueller Methodenaufruf stattfinden, vielmehr wird die Methode direkt aufgerufen
// er ist naemlich total schlau und weiss: das ist eine Katze, und nichts anderes, auch wenn es eine abgeleitete Klasse gibt

Ich habe nirgendwo geschrieben, dass es keine Ableitung von der Klasse gibt.

michba

DEvent schrieb:

Man geht davon aus, dass ein C++ Programm 5-10mal langsamer läuft als ein entsprechndes C Programm.
Das ist aber sehr programmabhängig, die Zahlen sind also bestenfalls wage Anhaltspunkte, ich habe sie aber schon in verschiedenen Büchern zu dem Thema gesehen. Es liegt auch nicht vorrangig an OOP, sondern an der Tatsache, dass C++ Compiler aufwendiger sind als C-Compiler, entsprechend auch die Optimierung aufwendiger wird. Doch auch die C++ Compiler werden immer besser. Die Qualität der C++-Übersetzungen wird sich mehr und mehr an C annähern, genauso wie sich C an Assembler weiter annähern wird. Trotzdem kann man davon ausgehen, dass C++-Programme langsamer bleiben als C-Programme, weil irgendeine Ungeschicktheit findet sich vermutlich in jedem C++-Programm.

Wieso interessiert das einen? Diese 5 oder 10 ist doch eine Konstante und hat damit bei der Laufzeit absolut keine Bedeutung.

O(k * n) = O(n)
O(k * n^p) = O(n^p)
O(k * p^n) = O(p^n)
usw.

Diese "Konstante" hat sehr wohl eine Bedeutung für die Laufzeit des Programms (mal abgesehen davon, dass ich diesem "5-10mal langsamer" nicht zustimme). Oder findest du, dass es "absolut keine Bedeutung" hat, wenn das Programm 50 statt 5 Sekunden braucht?

Kann es sein, dass du das Thema Komplexität nicht richtig verstanden hast?

hustbaer

DEvent schrieb:

Was sind eigentlich CPU-Limitierte Spiele??

Ein Spiel ist genau dann auf einem System CPU limitiert, wenn die einzige Änderung am System die dazu führen würde dass das Spiel merklich schneller läuft die wäre eine schnellere CPU zu verwenden.

Viele Spiele sind auf den meisten Systemen "Grafikkarten limitiert", d.h. eine schnellere CPU bringt garnix, weil der Flaschenhals die Grafikkarte ist.

Als "CPU limitiertes Spiel" würde ich ein Spiel bezeichnen welches auf den meisten Systemen wo es gespielt wird CPU limitiert ist. Eben z.B. X³.

michba schrieb:

DEvent schrieb:

Wieso interessiert das einen? Diese 5 oder 10 ist doch eine Konstante und hat damit bei der Laufzeit absolut keine Bedeutung.

O(k * n) = O(n)
O(k * n^p) = O(n^p)
O(k * p^n) = O(p^n)
usw.

Diese "Konstante" hat sehr wohl eine Bedeutung für die Laufzeit des Programms (mal abgesehen davon, dass ich diesem "5-10mal langsamer" nicht zustimme). Oder findest du, dass es "absolut keine Bedeutung" hat, wenn das Programm 50 statt 5 Sekunden braucht?

Kann es sein, dass du das Thema Komplexität nicht richtig verstanden hast?

sorry das ist blödsinn, offentsichtlich hast du das thema zeitkomplexität nicht verstanden.
zuerst mal ist es infantil anzunehmen, dass ein in c++ geschriebener algorithmus langsamer läuft als in c, da der selbe code zuerst einmal gleich assembliert wird.
b) angenommen man hat für den algorithmus template methoden gebaut, so dass sich tatsächlich der "overhead" vom virtuellen methodenaufruf auf jede iteration niederschlägt ist eine zahl von 5-10mal so langsamer noch immer weltfremd.
aber zum thema komplexität:
c) die algorithmus wird nicht langsamer dadurch dass ich wie in b implementiere. ein algorithmus "dauert" immer "gleich lang". auch mit einem Sleep(1000) in jeder schleife. also vor dem große töne spucken lieber nochmal erstes semester wiederholen.

michba

Mr. O schrieb:

zuerst mal ist es infantil anzunehmen, dass ein in c++ geschriebener algorithmus langsamer läuft als in c, da der selbe code zuerst einmal gleich assembliert wird.
b) angenommen man hat für den algorithmus template methoden gebaut, so dass sich tatsächlich der "overhead" vom virtuellen methodenaufruf auf jede iteration niederschlägt ist eine zahl von 5-10mal so langsamer noch immer weltfremd.
aber zum thema komplexität:
c) die algorithmus wird nicht langsamer dadurch dass ich wie in b implementiere. ein algorithmus "dauert" immer "gleich lang". auch mit einem Sleep(1000) in jeder schleife.

Äh, du hast aber schon gelesen, was ich geschrieben habe, insbesondere das in der Klammer?

Mr. O schrieb:

sorry das ist blödsinn, offentsichtlich hast du das thema zeitkomplexität nicht verstanden.

Dann erklär mir doch bitte, was genau ich falsch gemacht habe, nachdem du meinen Post nochmal in Ruhe durchgelesen hast.

Jester

Mr. O schrieb:

die algorithmus wird nicht langsamer dadurch dass ich wie in b implementiere. ein algorithmus "dauert" immer "gleich lang". auch mit einem Sleep(1000) in jeder schleife.

Aha? Wenn ich also 5000 Werte in ne Liste packe dauert das genauso lange wie wenn ich 5000 Werte in ne Liste packe und nach jedem Wert sleep(1000) aufrufe?

Xin

Mr. N schrieb:

class KleineKatze : public Katze {
  void rufe_virtuelle_methode_auf();
};
Katze ichbineinekatze;
ichbineinekatze.rufe_virtuelle_methode_auf(); //hier muss kein virtueller Methodenaufruf stattfinden, vielmehr wird die Methode direkt aufgerufen
// er ist naemlich total schlau und weiss: das ist eine Katze, und nichts anderes, auch wenn es eine abgeleitete Klasse gibt

Ich habe nirgendwo geschrieben, dass es keine Ableitung von der Klasse gibt.

Um zu belegen, dass OOP nicht langsamer ist als kein OOP, entferne man OOP aus der Basisklasse.
EDIT: Basisklasse bezieht sich auf KleineKatze, von der ja noch abgeleitet werden soll.

michba schrieb:

michba schrieb:

Wieso interessiert das einen? Diese 5 oder 10 ist doch eine Konstante und hat damit bei der Laufzeit absolut keine Bedeutung.

O(k * n) = O(n)

Diese "Konstante" hat sehr wohl eine Bedeutung für die Laufzeit des Programms (mal abgesehen davon, dass ich diesem "5-10mal langsamer" nicht zustimme). Oder findest du, dass es "absolut keine Bedeutung" hat, wenn das Programm 50 statt 5 Sekunden braucht?

Kann es sein, dass du das Thema Komplexität nicht richtig verstanden hast?

Was die Komplexität angeht, hat michba schon recht... das Problem wird nicht komplexer. Aber das interessiert den Anwendert nicht, der trotzdem länger warten muss, die Laufzeit ist vom Faktor eben doch abhängig.

Du stimmst dem Faktor "5-10" mal nicht zu? Im gleichen Postings, wo ich die Zahlen angegeben habe, schrieb ich auch, dass sie vermutlich veraltet sind und die Optimierung inzwischen dafür sorgt, dass der Faktor kleiner wird.
Fakt ist aber auch, dass die Faktoren im Jahr 2000 belegt wurden und keiner Zustimmung bedürfen.

Die Optimierung von Compilern hat man nicht im Jahr 2000 erfunden, sicherlich wird sich seitdem einiges verbessert haben. Weg ist der Faktor aber in keinem Fall.

Ich war aber trotzdem neugierig und habe die in "Programmierpraxis" beschriebenen Testbedingungen erstellt:

morpheus:/home/xin/kernigham# g++ -O3 markov_list.cpp; time ./a.out < bib1910.txt > /dev/null;

real    0m0.247s
user    0m0.232s
sys     0m0.012s
morpheus:/home/xin/kernigham# g++ -O3 markov_deque.cpp; time ./a.out < bib1910.txt > /dev/null;

real    0m0.395s
user    0m0.300s
sys     0m0.008s

morpheus:/home/xin/kernigham# gcc -O3 markov.c; time ./a.out < bib1910.txt > /dev/null;

real    0m0.054s
user    0m0.052s
sys     0m0.000s

Die damals gemessenen Werte waren und meine Werte, einfach mit 'time' ermittelt

Sprache         250MHz R1000         400 MHz Pentium II      Athlon 64 3200
C               0,36s                 0,30s                  0,054s
C++/STL/deque   2,60s (*7,22)        11,20s (*37,33)         0,395s (*7,31)
C++/STL/list    1,70s (*4,72)         1,50s (* 5,00)         0,247s (*4,57)

An den Faktoren hat sich alles in allem nichts geändert, obwohl scrub dem nicht zustimmt und MrN kann ich beruhigen, der Compiler ist keine 10 Jahre alt. (GCC 4.1.3)

michba schrieb:

Mr. O schrieb:

zuerst mal ist es infantil anzunehmen, dass ein in c++ geschriebener algorithmus langsamer läuft als in c, da der selbe code zuerst einmal gleich assembliert wird.
b) angenommen man hat für den algorithmus template methoden gebaut, so dass sich tatsächlich der "overhead" vom virtuellen methodenaufruf auf jede iteration niederschlägt ist eine zahl von 5-10mal so langsamer noch immer weltfremd.
aber zum thema komplexität:
c) die algorithmus wird nicht langsamer dadurch dass ich wie in b implementiere. ein algorithmus "dauert" immer "gleich lang". auch mit einem Sleep(1000) in jeder schleife.

Äh, du hast aber schon gelesen, was ich geschrieben habe, insbesondere das in der Klammer?

ja. oder steht da dass ich dir nicht zustimme?

michba schrieb:

Mr. O schrieb:

sorry das ist blödsinn, offentsichtlich hast du das thema zeitkomplexität nicht verstanden.

Dann erklär mir doch bitte, was genau ich falsch gemacht habe, nachdem du meinen Post nochmal in Ruhe durchgelesen hast.

Wie DEvent erkannt hat löst sich die konstante "5 mal langsamer" wunderbar in das n auf. aus einem O(n) algorithmus wird deshalb eben kein "O für c++ = O(5*n)" algorithmus
weiter siehe unten

Jester schrieb:

Mr. O schrieb:

die algorithmus wird nicht langsamer dadurch dass ich wie in b implementiere. ein algorithmus "dauert" immer "gleich lang". auch mit einem Sleep(1000) in jeder schleife.

Aha? Wenn ich also 5000 Werte in ne Liste packe dauert das genauso lange wie wenn ich 5000 Werte in ne Liste packe und nach jedem Wert sleep(1000) aufrufe?

nein es dauert länger. eigentlich habe ich um solchen wie dir vorzubeugen das "dauert gleich lang" in anführungszeichen gesetzt, weil der algorithmus immer noch (achtung anführungszeichen) "gleich lang dauert". auf meinem alten 386er läft der algorithmus genauso schnell. ebenso wie mit papier und stift. genau dafür gibt es ja die O notation...

Jester

Xin: was Du sagst mag ja alle stimmen (meinetwegen). Aber du redest halt nicht von dem was man als Objektorientierung bezeichnet. Das ist so wie wenn jemand erzählt 2+2 sei fünf... und am Ende rückt er damit raus, dass er das was wir vier nennen einfach fünf nennt. Dann stimmt das auch. Aber es wird natürlich weder breit akzeptiert noch generell richtig im kontext der normalen Bedeutung.

(Ich beziehe mich hier nur auf den OOP-Teil, dass Listen nicht schneller oder langsamer als Arrays sind hat MrN ja schon schön dargelegt).

Jester schrieb:

Xin: was Du sagst mag ja alle stimmen (meinetwegen). Aber du redest halt nicht von dem was man als Objektorientierung bezeichnet. Das ist so wie wenn jemand erzählt 2+2 sei fünf... und am Ende rückt er damit raus, dass er das was wir vier nennen einfach fünf nennt. Dann stimmt das auch. Aber es wird natürlich weder breit akzeptiert noch generell richtig im kontext der normalen Bedeutung.

danke