Performancemythen?

C ist schneller als C++. Ende.

asc

Kenner des Codes schrieb:

C ist schneller als C++. Ende.

Von der Reinen Aussage her ja, genauso wie Assembler schneller als C ist.

Aber in der Praxis gibt es mehr als nur einen reinen Sprachvergleich:

a) Ist der Code noch so gut überschaubar das sich nicht Fehler und Codeduplikate sowie Performancefallen mehren? Zumeist liegt der Vorteil von C++ gegenüber C an der besseren Strukturierung (Wobei vieles an Programmiererfahrung liegt).

b) Der Code mag noch so schnell sein, die Umsetzung muss in der Regel gegen einen Gewissen Zeitdruck erfolgen. Performance ist nicht Alles, sonst würde es keine Sprachen wie Java und C# geben. Man muss immer gewisse Kompromisse eingehen.

cu André

Mr. N

asc schrieb:

Kenner des Codes schrieb:

C ist schneller als C++. Ende.

Von der Reinen Aussage her ja, genauso wie Assembler schneller als C ist.

Beides Blödsinn.

Xin

Cpt. Nukem schrieb:

Man liest ja hier öfters OOP ist langsamer als ohne OOP oder ++iter statt iter++.

Dazu vielleicht mal etwas Klartext:

int & int::operator ++() // ++i
{
  value = value + 1;
  return this;
}

int int::operator ++( int ) // i++
{
  int temp = value;
  value = value + 1;
  return temp;
}

Du siehst, die Postfix-Variante benötigt ein temporäres Objekt und hat daher mehr Aufwand.
Das Objekt ist in diesem Fall (int) kein erwähnenswertes Problem. Ergo auch kein Problem, da der Compiler das hier ausgleichen kann:

int & int::operator ++() // ++i
{
  value = value + 1;
  returncode = value;
}

int int::operator ++( int ) // i++
{
  returncode = value;
  value = value + 1;
}

Hier werden Objekte kopiert, was bei Integers durch die CPU problemlos erledigt werden kann. Nehmen wir an, es gibt ein Objekt Bitmap, dass mit ++ die Transparenz erhöht. Nun haben wir eine 2MPix Bitmap, das sind 8MB Daten.
Rufst Du ++i auf, wird die Bitmap verändert und stellt auch das Ergebnis dar. Rufst Du i++ auf, wird ein Temporäres Objekt erzeugt, 8MB Daten kopiert und modifiziert, um dann wieder verworfen zu werden.

++i spart - in der Regel - das Erzeugen und Zerstören eines temporären Objektes und die Verwendung von ++i ist definitiv kein Performance-Mythos.

Cpt. Nukem schrieb:

Was bringt sowas wriklich? Gibts dazu wirklich Beweise oder sind das nur Behauptungen? Bei manchen neuen Anwendungen fragt man sich schon, was da manchmal so lange braucht, aber liegt das wirklich an OOP?

OOP ist eine Technik, wenn Du OOP brauchst, um ein Problem zu lösen, brauchst Du OOP. Egal ob Du OOP in C++ oder C verwendest. OOP ist keine kostenlose Technik, sie verbraucht Rechenzyklen und geht damit auf die Performance. Das ist vergleichbar mit Arrays und Listen.
Arrays sind schneller, Listen sind eine Technik, die mehr Performance benötigt, aber Arrays eben flexibler macht. Obwohl es länger dauert, durch eine Liste zu iterieren als durch ein Array, ist es einfacher Elemente zu verschieben, hinzuzufügen oder zu entfernen.
Es gilt also zu entscheiden, wo die Schwerpunkte in Deinem Algorithmus liegen.

Grundsätzlich OOP zu verwenden verlangsamt Programme unnötig. Da OOP in C aufwendig ist, wird man in C vermeiden OOP zu verwenden. Wenn man allerdings wirklich OOP benötigt, ist die übliche Implementierung in C++ allerdings recht flott und im großen Ganzen die schnellste Methode, um OOP Probleme allgemeingültig zu lösen.

Mr. N

Xin schrieb:

Cpt. Nukem schrieb:

Man liest ja hier öfters OOP ist langsamer als ohne OOP oder ++iter statt iter++.

Dazu vielleicht mal etwas Klartext:
int & int::operator ++() // ++i
{
  value = value + 1;
  return this;
}

int int::operator ++( int ) // i++
{
  int temp = value;
  value = value + 1;
  return temp;
}
Du siehst, die Postfix-Variante benötigt ein temporäres Objekt und hat daher mehr Aufwand.
Das Objekt ist in diesem Fall (int) kein erwähnenswertes Problem. Ergo auch kein Problem, da der Compiler das hier ausgleichen kann:
int & int::operator ++() // ++i
{
  value = value + 1;
  returncode = value;
}

int int::operator ++( int ) // i++
{
  returncode = value;
  value = value + 1;
}
Hier werden Objekte kopiert, was bei Integers durch die CPU problemlos erledigt werden kann. Nehmen wir an, es gibt ein Objekt Bitmap, dass mit ++ die Transparenz erhöht. Nun haben wir eine 2MPix Bitmap, das sind 8MB Daten.
Rufst Du ++i auf, wird die Bitmap verändert und stellt auch das Ergebnis dar. Rufst Du i++ auf, wird ein Temporäres Objekt erzeugt, 8MB Daten kopiert und modifiziert, um dann wieder verworfen zu werden.

++i spart - in der Regel - das Erzeugen und Zerstören eines temporären Objektes und die Verwendung von ++i ist definitiv kein Performance-Mythos.

Das stimmt soweit natürlich alles.

Xin schrieb:

Cpt. Nukem schrieb:

Was bringt sowas wriklich? Gibts dazu wirklich Beweise oder sind das nur Behauptungen? Bei manchen neuen Anwendungen fragt man sich schon, was da manchmal so lange braucht, aber liegt das wirklich an OOP?

OOP ist eine Technik, wenn Du OOP brauchst, um ein Problem zu lösen, brauchst Du OOP. Egal ob Du OOP in C++ oder C verwendest. OOP ist keine kostenlose Technik, sie verbraucht Rechenzyklen und geht damit auf die Performance. Das ist vergleichbar mit Arrays und Listen.
Arrays sind schneller, Listen sind eine Technik, die mehr Performance benötigt, aber Arrays eben flexibler macht. Obwohl es länger dauert, durch eine Liste zu iterieren als durch ein Array, ist es einfacher Elemente zu verschieben, hinzuzufügen oder zu entfernen.
Es gilt also zu entscheiden, wo die Schwerpunkte in Deinem Algorithmus liegen.

Grundsätzlich OOP zu verwenden verlangsamt Programme unnötig. Da OOP in C aufwendig ist, wird man in C vermeiden OOP zu verwenden. Wenn man allerdings wirklich OOP benötigt, ist die übliche Implementierung in C++ allerdings recht flott und im großen Ganzen die schnellste Methode, um OOP Probleme allgemeingültig zu lösen.

Wie kommst du auf diesen Unfug? Das hätte ich von dir nicht erwartet.

Shade Of Mine

Mr. N schrieb:

Wie kommst du auf diesen Unfug? Das hätte ich von dir nicht erwartet.

weil OOP ist evil...

Irgendwann werden die Leute schon verstehen dass ob OOP oder sonstwas - nur eine Art Probleme zu lösen ist. Man kann Probleme auf viele Arten lösen - mal mag die eine eleganter sein als die andere - aber mit Performance hat das erstmal nichts zu tun.

Bestes Beispiel sind virtuelle Funktionen. Klar kosten sie mehr als eine normale Funktion - aber dafür hat man eine Fallunterscheidung die man ja nicht einfach ignorieren kann. Egal wie ich das Problem nun angehe - ich brauche diese Fallunterscheidung. Sei es eine Jump Table, ein if, ein switch, virtuelle Funktionen oder höher stehende Magie - ich habe kosten für diese Unterscheidung.

asc schrieb:

Kenner des Codes schrieb:

C ist schneller als C++. Ende.

Von der Reinen Aussage her ja, genauso wie Assembler schneller als C ist.

Aber in der Praxis gibt es mehr als nur einen reinen Sprachvergleich:

a) Ist der Code noch so gut überschaubar das sich nicht Fehler und Codeduplikate sowie Performancefallen mehren? Zumeist liegt der Vorteil von C++ gegenüber C an der besseren Strukturierung (Wobei vieles an Programmiererfahrung liegt).
**
b) Der Code mag noch so schnell sein, die Umsetzung muss in der Regel gegen einen Gewissen Zeitdruck erfolgen. Performance ist nicht Alles, sonst würde es keine Sprachen wie Java und C# geben. Man muss immer gewisse Kompromisse eingehen.**

cu André

LOL das mag ja richtig sein was du unter b) gesagt hast, aber ging es grad net um die reine Performance .

Xin schrieb:

Cpt. Nukem schrieb:

Was bringt sowas wriklich? Gibts dazu wirklich Beweise oder sind das nur Behauptungen? Bei manchen neuen Anwendungen fragt man sich schon, was da manchmal so lange braucht, aber liegt das wirklich an OOP?

OOP ist eine Technik, wenn Du OOP brauchst, um ein Problem zu lösen, brauchst Du OOP. Egal ob Du OOP in C++ oder C verwendest. OOP ist keine kostenlose Technik, sie verbraucht Rechenzyklen und geht damit auf die Performance. Das ist vergleichbar mit Arrays und Listen.
Arrays sind schneller, Listen sind eine Technik, die mehr Performance benötigt, aber Arrays eben flexibler macht. Obwohl es länger dauert, durch eine Liste zu iterieren als durch ein Array, ist es einfacher Elemente zu verschieben, hinzuzufügen oder zu entfernen.
Es gilt also zu entscheiden, wo die Schwerpunkte in Deinem Algorithmus liegen.

Grundsätzlich OOP zu verwenden verlangsamt Programme unnötig. Da OOP in C aufwendig ist, wird man in C vermeiden OOP zu verwenden. Wenn man allerdings wirklich OOP benötigt, ist die übliche Implementierung in C++ allerdings recht flott und im großen Ganzen die schnellste Methode, um OOP Probleme allgemeingültig zu lösen.

Ich versteh zwar den Zusammenhang nicht, dass etwas langsamer ist, weil es eine Technik ist. Aber es stimmt natürlich, dass es mehr Zeit braucht ein Objekt zu erzeugen und damit eine Funktion aufzurufen, als direkt eine Funktion aufzurufen.

Man kann natürlich noch weiter gehen und sagen, dass Funktionsaufrufe Zeit brauchen, darum sollte man alles direkt hinschreiben. Macht wohl keiner.

Aber was macht OOP in der Praxis aus? Viel Prozent der Zeit gehen für sowas drauf? 30, 3, 0.3 oder noch weniger? Gibts dazu eine verlässliche Quelle?

Mr. N

Cpt. Nukem schrieb:

Aber es stimmt natürlich, dass es mehr Zeit braucht ein Objekt zu erzeugen und damit eine Funktion aufzurufen, als direkt eine Funktion aufzurufen.

Falsch!

tntnet

Mr. N schrieb:

Cpt. Nukem schrieb:

Aber es stimmt natürlich, dass es mehr Zeit braucht ein Objekt zu erzeugen und damit eine Funktion aufzurufen, als direkt eine Funktion aufzurufen.

Falsch!

Richtig! Also Richtig, daß es Falsch ist . Ich wollte nur eine kleine Erläuterung dazu fügen. Ein Konstruktor, der inline ist und nichts macht ist performancetechnisch kostenlos. Daher ist es einfach egal, ob ich ein Objekt erzeuge und damit eine Funktion aufrufe oder direkt eine Funktion aufrufe. Und hier gilt das gleiche, wie Shade Of Mine über virtuelle Methodenaufrufe gesagt hat. Ein Aufruf einer Methodenfunktion erfüllt einen Zweck. Und um diesen Zweck zu realisieren, ist ein Objekt eine mögliche Lösungsvariante, die nicht unbedingt teurer ist, als eine nicht-OOP Technik.

Und ich möchte der Aussage, daß Listen teurer sind als Array auch noch wiedersprechen. Erstelle einfach mal eine Array und eine Liste mit 10000 Elementen. Dann messe mal die Zeit, die es benötigt, nach dem ersten Element ein Element einzufügen. Danach entfernst Du das 3. Element. Und dann schau mal, welche Datenstruktur schneller war. Die Liste ist in dem Anwendungsfall dem Array haushoch überlegen. Es kommt halt immer auf den Anwendungsfall an, ob eine Liste oder ein Array schneller ist.

Hier kommt doch gleich ein Vorteil von C++ gegenüber C zum Tragen. Bei so einem Anwendungsfall überlege ich mir in C 2 mal, ob ich den Aufwand, eine Liste zu programmieren auf mich nehme. In C++ schreibe ich einfach std::list statt std::vector. Daher bin ich bestrebt, in C++ die effizientere Lösung zu realisieren.

hustbaer

Wer nicht glaubt dass es CPU limitierte Games gibt soll mal X³ spielen...

Xin

Mr. N schrieb:

Xin schrieb:

...

Das stimmt soweit natürlich alles.

Cool. :->

Mr. N schrieb:

Xin schrieb:

Cpt. Nukem schrieb:

Was bringt sowas wriklich? Gibts dazu wirklich Beweise oder sind das nur Behauptungen? Bei manchen neuen Anwendungen fragt man sich schon, was da manchmal so lange braucht, aber liegt das wirklich an OOP?

OOP ist eine Technik, wenn Du OOP brauchst, um ein Problem zu lösen, brauchst Du OOP. Egal ob Du OOP in C++ oder C verwendest. OOP ist keine kostenlose Technik, sie verbraucht Rechenzyklen und geht damit auf die Performance. Das ist vergleichbar mit Arrays und Listen.
Arrays sind schneller, Listen sind eine Technik, die mehr Performance benötigt, aber Arrays eben flexibler macht. Obwohl es länger dauert, durch eine Liste zu iterieren als durch ein Array, ist es einfacher Elemente zu verschieben, hinzuzufügen oder zu entfernen.
Es gilt also zu entscheiden, wo die Schwerpunkte in Deinem Algorithmus liegen.

Grundsätzlich OOP zu verwenden verlangsamt Programme unnötig. Da OOP in C aufwendig ist, wird man in C vermeiden OOP zu verwenden. Wenn man allerdings wirklich OOP benötigt, ist die übliche Implementierung in C++ allerdings recht flott und im großen Ganzen die schnellste Methode, um OOP Probleme allgemeingültig zu lösen.

Wie kommst du auf diesen Unfug? Das hätte ich von dir nicht erwartet.

Ich weiß nicht, was Du hier konkret als Unfug bezeichnest, entsprechend kann ich Dir auch nichts erläutern oder Dir sagen, wie ich darauf komme, es hier zu schreiben.

Zwei Dinge kann ich jedoch beantworten. Erstens: Ich schreibe keinen Unfug und zweitens: ich schreibe hier nicht, um Erwartungen zu entsprechen.

Ich habe in einem anderen Thread schonmal ausführlich beschrieben, was OOP ist und wie es umgesetzt wird. Wenn das nicht bekannt ist, so sollten wenigstens die sich daraus ergebenen Vor- und Nachteile sollten bekannt sein. Die habe ich in dem Bereich aufgeführt, den Du als Unfug bezeichnest.

Cpt. Nukem schrieb:

Ich versteh zwar den Zusammenhang nicht, dass etwas langsamer ist, weil es eine Technik ist.

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.

Das macht man, um Entscheidungen nicht treffen zu müssen.
Die Umsetzung von OOP in C++ ist also auch eine Technik, die hilft bei komplizierten Fragestellungen den Überblick zu behalten und notwendige Fragen in grundsätzlich nur 3 Schritten zu beantworten. Das hilft Zeit zu sparen, denn ein Algorithmus, der fragt, bräuchte mehr Schritte.

Nutzt man OOP bei Funktionsrufen, wo keine Entscheidungen zu treffen sind, so verliert man Zeit. Nutzt man OOP bei Funktionen, die objektabhängig sind, spart man Zeit oder viel Aufwand und erhält übersichtlichen Code. Man verliert in dem Fall aber keine Zeit, weil die Entscheidung muss so oder so getroffen werden. Und in der Regel wird sie schlechter implementiert, als es C++ macht. In dem Fall ist OOP mit C++ schneller.
Man muss OOP sinnvoll und bewußt einsetzen.

Cpt. Nukem schrieb:

Aber es stimmt natürlich, dass es mehr Zeit braucht ein Objekt zu erzeugen und damit eine Funktion aufzurufen, als direkt eine Funktion aufzurufen.

Richtig. Hier verliert man bei ungeschickter Programmierung (z.B. i++ statt ++i) unnötig Zeit.

Im Regelfall benutzt man allerdings vorhandene Objekte (z.B. bei ++i) und ruft statisch an den Klassentyp gebundene Funktionen. Das ist klassenorientiert oder datentyporientiert und hat absolut nichts mit Objektorientierung zu tun.
Das ist identisch zu einem Funktionsaufruf in C, ergo verliert man auch keine Zeit:

Macht man sich vom Objekttyp abhängig, programmiert das Ganze also objektorientiert statt sich auf die aktuelle Sichtweise auf das Objekt zu konzentrieren (klassenorientiert), dann wird der Funktionsaufruf dynamisch und zur Laufzeit ermittelt.

Cpt. Nukem schrieb:

Man kann natürlich noch weiter gehen und sagen, dass Funktionsaufrufe Zeit brauchen, darum sollte man alles direkt hinschreiben. Macht wohl keiner.

Würde auch keinen Sinn machen, da nicht ohne Funktionsaufrufe kaum etwas programmieren kann. Um z.B. Bäume zu durchwandern, müsste man sich in dem Fall den Stack selbstbauen, weil man rekursive Algorithmen nicht direkt hinschreiben kann. Man spart in dem Fall also auch nichts.

Cpt. Nukem schrieb:

Aber was macht OOP in der Praxis aus? Viel Prozent der Zeit gehen für sowas drauf? 30, 3, 0.3 oder noch weniger? Gibts dazu eine verlässliche Quelle?

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.

Die Zahlen sind alt, die Differenz sollte inzwischen kleiner sein, aber selbst würde ein Programm 10x langsamer laufen, hilft C++ deutlich, Programme übersichtlicher und damit fehlerfreier zu gestalten. Ein Programm, dass nach 10 Stunden zum Ziel kommt ist effizienter als ein Programm, das nach 1 Stunde ein falsches Ergebnis liefert.

tntnet schrieb:

Und ich möchte der Aussage, daß Listen teurer sind als Array auch noch wiedersprechen. Erstelle einfach mal eine Array und eine Liste mit 10000 Elementen. Dann messe mal die Zeit, die es benötigt, nach dem ersten Element ein Element einzufügen. Danach entfernst Du das 3. Element. [...] Es kommt halt immer auf den Anwendungsfall an, ob eine Liste oder ein Array schneller ist.

Arbeitest Du eigentlich im Marketing-Bereich?

(Oder) gilt es heute wirklich schon als Diskussionsargument, wenn man die Aussage des Vorredners wiederholt und behauptet, man würde ihm so widersprechen?

Lies doch nochmal nach, wogegen Du widersprichst:

Xin schrieb:

Arrays sind schneller, Listen sind eine Technik, die mehr Performance benötigt, aber Arrays eben flexibler macht. Obwohl es länger dauert, durch eine Liste zu iterieren als durch ein Array, ist es einfacher Elemente zu verschieben, hinzuzufügen oder zu entfernen.
Es gilt also zu entscheiden, wo die Schwerpunkte in Deinem Algorithmus liegen.

Mr. N

Xin schrieb:

Mr. N schrieb:

Wie kommst du auf diesen Unfug? Das hätte ich von dir nicht erwartet.

Ich weiß nicht, was Du hier konkret als Unfug bezeichnest, entsprechend kann ich Dir auch nichts erläutern oder Dir sagen, wie ich darauf komme, es hier zu schreiben.

So wie das da stand war das verallgemeinernder Quark.

Xin schrieb:

Zwei Dinge kann ich jedoch beantworten. Erstens: Ich schreibe keinen Unfug und zweitens: ich schreibe hier nicht, um Erwartungen zu entsprechen.

Nicht gleich beleidigt sein. :p

Xin schrieb:

Ich habe in einem anderen Thread schonmal ausführlich beschrieben, was OOP ist und wie es umgesetzt wird.

Ich kenne den Begriff OOP schon eine Weile. Und ich weiß, dass er vor allem schwammig ist. Ich weiß aber auch, dass OOP nicht äquivalent zu virtuelle Klassenmethoden ist (ich vermute, das meinst du mit "OOP", aber sicher bin ich auch nicht).

Xin schrieb:

Wenn das nicht bekannt ist, so sollten wenigstens die sich daraus ergebenen Vor- und Nachteile sollten bekannt sein. Die habe ich in dem Bereich aufgeführt, den Du als Unfug bezeichnest.

Bevor ich das weiter kommentiere warte ich lieber auf deine Definition von OOP.

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.

Xin schrieb:

Im Regelfall benutzt man allerdings vorhandene Objekte (z.B. bei ++i) und ruft statisch an den Klassentyp gebundene Funktionen. Das ist klassenorientiert oder datentyporientiert und hat absolut nichts mit Objektorientierung zu tun.
Das ist identisch zu einem Funktionsaufruf in C, ergo verliert man auch keine Zeit:

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.)

Xin schrieb:

Cpt. Nukem schrieb:

Aber was macht OOP in der Praxis aus? Viel Prozent der Zeit gehen für sowas drauf? 30, 3, 0.3 oder noch weniger? Gibts dazu eine verlässliche Quelle?

Man geht davon aus, dass ein C++ Programm 5-10mal langsamer läuft als ein entsprechndes C Programm.

Woher hast du den Unfug? Wird ja immer krasser. Mir ist diese Annahme neu und sie wird auch meistens falsch sein. (GNOME ist nicht 5-mal schneller als KDE, vergleichbar sind beide aber sehr wohl.)

[Allerdings benutze ich selbstverständlich aktuelle Compiler, für mich ist die Zeit nicht vor 10 Jahren stehen geblieben.]

Xin schrieb:

tntnet schrieb:

Und ich möchte der Aussage, daß Listen teurer sind als Array auch noch wiedersprechen. Erstelle einfach mal eine Array und eine Liste mit 10000 Elementen. Dann messe mal die Zeit, die es benötigt, nach dem ersten Element ein Element einzufügen. Danach entfernst Du das 3. Element. [...] Es kommt halt immer auf den Anwendungsfall an, ob eine Liste oder ein Array schneller ist.

Arbeitest Du eigentlich im Marketing-Bereich?

Ich denke nicht, dass tntnet im Marketing-Bereich arbeitet.

Xin schrieb:

Arrays sind schneller, Listen sind eine Technik, die mehr Performance benötigt, aber Arrays eben flexibler macht. Obwohl es länger dauert, durch eine Liste zu iterieren als durch ein Array, ist es einfacher Elemente zu verschieben, hinzuzufügen oder zu entfernen.
Es gilt also zu entscheiden, wo die Schwerpunkte in Deinem Algorithmus liegen.

Das ist inkonsistent. Sind Arrays nun schneller oder nicht?

hustbaer

Ist ja krass wie ihr euch hier gegenseitig beflegelt, und das ganz ohne "Java vs. C++" Flamewar. Da soll nochml wer sagen Programmierer seien unflexibel.

Was die "OOP" Diskussion angeht... da wäre es denke ich wirklich mal angebracht dass alle beteiligten schreiben was sie unter "OOP" verstehen.

Ich für meinen Teil denke dass es gewisse "Techniken" gibt die man "OOP" zuordnen kann. Einige gehen auf Kosten der Performance, andere nicht oder kaum.

Mr. N

hustbaer schrieb:

Was die "OOP" Diskussion angeht... da wäre es denke ich wirklich mal angebracht dass alle beteiligten schreiben was sie unter "OOP" verstehen.

Klar.

OOP: Schwammiger Begriff, in C++ meist: alles was nach Objekt riecht, allerdings auch eine Anzahl von Design-Richtlinien, im Zweifelsfalle eher weit zu interpretieren.

Hustbaer schrieb:

Ich für meinen Teil denke dass es gewisse "Techniken" gibt die man "OOP" zuordnen kann. Einige gehen auf Kosten der Performance, andere nicht oder kaum.

Stimme zu.

Xin

Hallo Mr. N

Bevor Du antwortest, lies es erstmal komplett.

Mr. N schrieb:

Xin schrieb:

Ich habe in einem anderen Thread schonmal ausführlich beschrieben, was OOP ist und wie es umgesetzt wird.

Ich kenne den Begriff OOP schon eine Weile. Und ich weiß, dass er vor allem schwammig ist. Ich weiß aber auch, dass OOP nicht äquivalent zu virtuelle Klassenmethoden ist (ich vermute, das meinst du mit "OOP", aber sicher bin ich auch nicht).

Deine Vermutung ist korrekt. Was nicht korrekt ist ist, dass Du weißt, dass OOP ein schwammiger Begriff ist.
Der Begriff OOP läßt sich sehr exakt formulieren, man muss es nur tun.
Und für die meisten ist er schwamming, weil die meisten glauben, dass objektorientiert = C++ - C ist.
Wenn einem das nicht griffig genug ist, besteht die Möglichkeit mal darüber nachzudenken. Es würde auch vollkommen reichen OOP mal auszuschreiben und sich Gedanken darüber zu machen, was die einzelnen Worte, die OOP abkürzt, überhaupt bedeuten und warum man genau diese Worte gewählt hat, um eine Technik zu bezeichnen.

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".
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".

Um etwas zu klassifizieren kann man in C++ "class" nehmen. Es geht in C aber genauso gut mit "struct".
Nur weil man der Sprache mitteilen kann, dass Funktionen einer Datenstruktur zugehörig ist, wird daraus kein OOP.
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.

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.

Mr. N schrieb:

Xin schrieb:

Im Regelfall benutzt man allerdings vorhandene Objekte (z.B. bei ++i) und ruft statisch an den Klassentyp gebundene Funktionen. Das ist klassenorientiert oder datentyporientiert und hat absolut nichts mit Objektorientierung zu tun.
Das ist identisch zu einem Funktionsaufruf in C, ergo verliert man auch keine Zeit:

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?
In C++ verwischen Grenzen? Ist OOP in C++ was anderes als in Simula, Java, oder warum verwischen Grenzen grade in C++?

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.
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.

Solange kein virtual in der Klasse auftaucht, besitzt das Objekt keine Typinformation und reagiert unabhängig vom Typ des Objektes auf den Referenztyp der Klasse. Und der Referenztyp der Klasse muss nicht dem Typ des Objektes entsprechen. Es orientiert sich nicht am Typ des Objektes. Wenn sich etwas nicht am Objekt orientiert, wüßte ich nicht, wieso man von objektorientierter Programmierung sprechen sollte.

Ich sehe keine Grenzen, die hier verwischen. Ich sehe hier sehr scharf gezogene Grenzen in den Definitionen.

Die "Implementierungsphilosophie" gibt vor, was wie programmiert wird. OOP kann man in einen Compiler implementieren. Dafür gibt es Algorithmen. "Kompilier mir eine Textverarbeitung besser als OpenOffice" ist ein toller Sourcecode, aber Kreativität ist bisher als Programmiertechnik nicht beschrieben. Hier scheitert Philosophie an der Implementierung.
Für mich ein guter Grund, erst nach der Implementierung zu fragen und dann nach der Philosophie von Nachwuchsentwicklern.

Mr. N schrieb:

Xin schrieb:

Cpt. Nukem schrieb:

Aber was macht OOP in der Praxis aus? Viel Prozent der Zeit gehen für sowas drauf? 30, 3, 0.3 oder noch weniger? Gibts dazu eine verlässliche Quelle?

Man geht davon aus, dass ein C++ Programm 5-10mal langsamer läuft als ein entsprechndes C Programm.

Woher hast du den Unfug? Wird ja immer krasser. Mir ist diese Annahme neu und sie wird auch meistens falsch sein. (GNOME ist nicht 5-mal schneller als KDE, vergleichbar sind beide aber sehr wohl.)

Bist Du in der Lage, drei Sätze weiter zu lesen und zu kapieren, warum ich extra für Dich Worte fett schreibe und unterstreiche?
Ja, es ist eine rhetorische Frage...

Aber um Deine Frage zu beantworten: "Programmierpraxis" von Brian Kernigham und Rob Pike. Dort wurden Laufzeittests in verschiedenen Sprachen gefahren und Programme mit entsprechenden Sprachmerkmalen umgesetzt, was in C++ STL bedeutete.

Mr. N schrieb:

Xin schrieb:

Arrays sind schneller, Listen sind eine Technik, die mehr Performance benötigt, aber Arrays eben flexibler macht. Obwohl es länger dauert, durch eine Liste zu iterieren als durch ein Array, ist es einfacher Elemente zu verschieben, hinzuzufügen oder zu entfernen.
Es gilt also zu entscheiden, wo die Schwerpunkte in Deinem Algorithmus liegen.

Das ist inkonsistent. Sind Arrays nun schneller oder nicht?

Es ist schon spät, oder? Wenn's für Dich zu spät wird, dann geh besser schlafen. Derartige Äußerungen sind unpraktisch, wenn man anderen unterstellt Unfug zu schreiben.

Ein Ferrari ist schneller als ein Traktor.
Und wenn Du Bauer wirst, kaufst Du Dir einen Ferrari, weil Du damit Deine Felder schneller bestellen kannst. Das ist Deine Auffassung von konsistent? Merkst Du was? Spätestens, wenn der Traktor den Ferrari aus dem Dreck zieht, wirst Du's merken.

(Ich meine die Sportwagen... nur für den Fall, dass Du rausbekommst, dass es auch Ferrari-Traktoren gibt...^^ )

Da das Buch auf dem Schreibtisch liegt, schlage ich für extra Dich nochmal in "Design und Entwicklung von C++" nach, Seite 92, Kapitel "3.5 - Virtuelle Methoden". Wenn Fettdruck nicht reicht, vielleicht hilft Bjarne.

Bjarne Stroustrup schrieb:

Das Problem liegt darin, dass hier nicht zwischen den allgemeinen Eigenschaften einer beliebigen Form [...] und den speziellen Eigenschaften einer bestimmten Form (ein Kreis ist eine Form, die einen Radius besitzt [...]) unterschieden wird. Derartige Unterschiede auszudrücken und zum Vorteil zu verwandeln macht objektorientierte Programmierung aus. Eine Sprache mit Konstrukten, die die Beschreibung und Verwendung derartiger Unterschiede erlauben, unterstützt OOP. Eine Sprache, der diese Eigenschaften fehlen, tut es nicht.

Daraus 2 Schlussfolgerungen:
1. ohne virtual, keine OOP-Unterstützung. Also Klassen ohne virtual: keine OOP Unterstützung, weil sie auch nix mit OOP zu tun haben.
2. Unterstützung bedeutet nicht, dass OOP ohne virtual nicht möglich wäre. Auch in C kann man OOP programmieren, aber C unterstützt den Entwickler dabei nicht.

Es wäre mir eine Freude, wenn ich Deine verwischten Definitionen von OOP etwas graderücken konnte. Falls Rückfragen sind, ist das kein Problem, solange Du sie nicht mit "Das ist Unfug" einleitest. Auf freundlich gestellte Fragen reagiere ich deutlich positiver als auf "Das ist Unfug", wenn "Das ist Unfug" Unfug ist und nichtmals eine brauchbare Begründung zum Widerspruch gereicht wird.

hustbaer schrieb:

Was die "OOP" Diskussion angeht... da wäre es denke ich wirklich mal angebracht dass alle beteiligten schreiben was sie unter "OOP" verstehen.

Die Tage haben wir in einem anderen Thread festgestellt, dass die Herkunft bzw. Bedeutung von Wörtern sich nicht in einer Umfrage erklären lässt, sondern eher durch Recherche.

Ansonsten haben wir nämlich genau das, was Mr. N schreibt: schwammige Begriffe, weil jeder ihn nach seiner subjektiven Meinung auslegt.
Davon gibt es mehr als genug in der Informatik, doch OOP gehört eigentlich nicht dazu.

Ist das eigentlich ein Sport in solchen Threads, die Sätze einzeln zu betrachten und möglichst falsch zu verstehen? Nur damit man was hat bei dem man sagen kann "Falsch", wenn einer was schreibt, was nicht mit der Meinung des anderen übereinstimmt.

Erkenner schrieb:

Ist das eigentlich ein Sport in solchen Threads, die Sätze einzeln zu betrachten und möglichst falsch zu verstehen? Nur damit man was hat bei dem man sagen kann "Falsch", wenn einer was schreibt, was nicht mit der Meinung des anderen übereinstimmt.

Kein Sport sondern gelebte deutsche Kultur. Anstatt das man versucht zu verstehen was der Andere sagen will macht es doch viel mehr Spaß um jeden Preis zu beweisen das der Andere falsch liegt. Dabei heiligt der Zweck die Mittel, will sagen im Zweifelsfall reisst man halt die Aussagen aus dem Kontext und verfälscht sie soweit bis sie halt falsch sind. Auch wäre es ja viel zu anstrengend vor allem längere Postings komplett zu lesen.

Mir scheint es manchmal so zu sein das einige ihr Selbstwertgefühl darüber definieren wieviele Fehler sie bei anderen finden können.

Ist wahrscheinlich die Transition des deutschen Stammtisches in die Welt der Online-Foren...

this-*gt*that

skals schrieb:

blablabla

Bei dir scheint es Tradition zu sein, deine klischeehafte Weltanschauung in Foren zu präsentieren.
Dass in Foren wie diesem geflamed wird, liegt an der Anonymität und der Zielgruppe. Mit Sachen wie Nationalität oder sowas hat das nichts zu tun. (offenbar warst du noch nie in ausländischen Foren)

Undertaker

tntnet schrieb:

Hier kommt doch gleich ein Vorteil von C++ gegenüber C zum Tragen. Bei so einem Anwendungsfall überlege ich mir in C 2 mal, ob ich den Aufwand, eine Liste zu programmieren auf mich nehme...

in C nimmt man einfach einen fertigen code für listen. da muss man nicht jedes mal alles neu programmieren

tntnet schrieb:

Daher bin ich bestrebt, in C++ die effizientere Lösung zu realisieren.

was bestimmt oft schwieriger ist als in C.