Performancemythen?

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

Jester

Mr. O schrieb:

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

Ehm ja... die O-Notation ist ein theoretisches Werkzeug. Und man kann damit toll Algorithmen vergleichen (sogar ohne sie konkret zu implementieren). Und dass man dabei die Konstanten plattklopfen kann ist echt praktisch. Aber gerade die Konstanten sind in der Realität eben doch von Bedeutung. Die kann man da nicht einfach unter den Tisch fallen lassen. Die O-Notation hilft nicht irgendwas schneller oder langsamer zu machen.

Xin

Jester schrieb:

Xin: was Du sagst mag ja alle stimmen (meinetwegen).

Meinetwegen?

Wenn nichts mehr drum herrum führt, dann geben wir ihm meinetwegen recht?

Jester schrieb:

Aber du redest halt nicht von dem was man als Objektorientierung bezeichnet.

Stimmt, ich halte mich an Kernigham oder Stroustrup oder sonstige Leute, die davon keine Ahnung haben.

Jester schrieb:

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.

Wenn "man" bestimmt, was die normale Bedeutung ist und nicht die Logik, dann gibt's bald 'ne "Bild der Entwickler".

Jester schrieb:

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

Gute Nacht, Jester...

Jester schrieb:

Mr. O schrieb:

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

Ehm ja... die O-Notation ist ein theoretisches Werkzeug. Und man kann damit toll Algorithmen vergleichen (sogar ohne sie konkret zu implementieren). Und dass man dabei die Konstanten plattklopfen kann ist echt praktisch. Aber gerade die Konstanten sind in der Realität eben doch von Bedeutung. Die kann man da nicht einfach unter den Tisch fallen lassen. Die O-Notation hilft nicht irgendwas schneller oder langsamer zu machen.

das hab ich verstanden, nur michba offensichtlich DEvents beispiel.

otze

Mir kommt diese Diskussion mit Xin irgendwie bekannt vor....wo war das noch gleich...ach stimmt, im letzten oop definitionsflamewar.

hustbaer

@Xin: dein Verständnis von OOP deckt sich anscheinend nicht mit dem was die Masse unter OOP versteht. Abstraktion/virtuelle Aufrufe sind IMO eine Technik die man OOP zuordnen kann bzw. verwenden kann um OO Programme zu schreiben, aber nicht Voraussetzung damit irgendwas "OO" ist.

Mein Verständnis von prozedural vs. OO:

Prozedural: man hat bestimmte Funktionen/Prozeduren die man aufruft um bestimmte Dinge zu erledigen. Diesen gibt man bestimmte Parameter mit.
Als "Auswahlkriterium" welcher Code wirklich ausgeführt wird dient der Name der Prozedur und sonst nix (ggf. noch die Signatur, wenn man Features wie Overloading verwendet).

OO: man schickt eine Nachricht an ein Objekt. Diese Nachricht besteht aus einem "Verb" + ggf. zusätzlichen Parametern.
Als "Auswahlkriterium" welcher Code wirklich ausgeführt wird dient das "Verb" der Nachricht + das Objekt an welches man die Nachricht geschickt hat.

Wenn man diese Definition von OO(P) verwendet heisst das noch lange nicht dass man hier irgendwelche abstrakten Klassen, Polymorphie oder virtuelle Aufrufe braucht. Wenn ein Programm so entworfen ist dass "die Auswahl des auszuführenden Codes" immer zur Compile-Zeit erfolgen kann (ohne natürlich den "falschen" Code auszuwählen), dann ist das kein Grund warum das Programm nichtmehr "OO" wäre. Logischerweise kann man viele Dinge damit nicht machen, oder muss sie zumindest ganz anders machen als wenn man z.B. virtuelle Aufrufe verwenden würde.

Anders gesagt: OO(P) schreibt nicht vor *wie* genau irgendwas zu passieren hat, sondern nur was zu passieren hat. Wenn das *wie* z.B. in einem bestimmten C++ Programm bedeutet dass der Programmierer verflixt aufpassen muss nicht mit dem "falschen" statischen Typ irgendwelche Sachen zu machen, dann ist das zwar vielleicht unschön und fehleranfällig, aber dennoch OO.

Xin schrieb:

Jester schrieb:

Xin: was Du sagst mag ja alle stimmen (meinetwegen).

Meinetwegen?

Wenn nichts mehr drum herrum führt, dann geben wir ihm meinetwegen recht?

Jester schrieb:

Aber du redest halt nicht von dem was man als Objektorientierung bezeichnet.

Stimmt, ich halte mich an Kernigham oder Stroustrup oder sonstige Leute, die davon keine Ahnung haben.

Jester schrieb:

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.

Wenn "man" bestimmt, was die normale Bedeutung ist und nicht die Logik, dann gibt's bald 'ne "Bild der Entwickler".

Jester schrieb:

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

Gute Nacht, Jester...

au weia Xin deine ignoranz und arroganz ist ja kaum zu übertreffen. musst jeden post auseinandernehmen und so hinbiegen dass er in dein weltbild passt? oder ist das deine standardvorgehensweise wenn du nichts mehr zu sagen weißt?

Jester

Xin schrieb:

Jester schrieb:

Aber du redest halt nicht von dem was man als Objektorientierung bezeichnet.

Stimmt, ich halte mich an Kernigham oder Stroustrup oder sonstige Leute, die davon keine Ahnung haben.

Gib mal ne Quelle. Behaupten kann man vieles.

Xin schrieb:

Wenn "man" bestimmt, was die normale Bedeutung ist und nicht die Logik, dann gibt's bald 'ne "Bild der Entwickler".

Ehm ja, weil es natürlich kein Stück willkürlich ist 4 mit vier zu bezeichnen und nicht mit fünf... völlig logisch.