C++ Overhead gegenüber C

Daniel E.

HumeSikkins schrieb:

Ich fände eine Begründung/Erklärung also nach wie vor hilfreicher als ein "offensichtlich".

Mein Einwand war: Generell (nehmen wir eine beliebige Menge an C- und an C++-Programmen, die von vergleichbarer Qualität [nicht, dass jemand mit einem qsort vs sort daherkommt] und einen handelsüblichen Compiler) laufen C-Programme in kürzerer Zeit ab. Darauf können wir uns (a) entweder einigen, oder (b) nicht. Wenn (a) gilt, dann muss doch irgendetwas dafür verantwortlich sein. Dieses Ding, das die Verantwortung trägt, nenne ich 'Grund'. Wenn es diesen Grund nicht gibt, dann kann (a) nicht gelten. Daraus habe ich geschloßen, dass es einen Grund gibt, mehr kann ich dir ja leider auch nicht sagen, aber Volkard (siehe unten).
Sollte (b) gelten, müsste ich euch überzeugen, was recht schwierig werden dürfte, weil ich kein Material da habe und immer nur 'Beweis durch Beispiel' betreiben müsste, was plöt und langweilig wäre.

volkard schrieb:

sag mir einen konkreten, und ich weise dir nach, daß er nicht sein müßte.

Der Grund, warum meine konkreten C++-Programme so ablaufen, wie sie es tun, ist der GCC (genauer: 'gcc32 (GCC) 3.2 20020518 (experimental) [FreeBSD]', meint 'gcc332 -- version') und die Umgebung (die ich gerade nicht ändern möchte). Ich habe den Quelltext noch vorliegen, Du musst mir nur die Zeile und Datei sagen, in der steht, dass C++-Programme langsamer ablaufen als das 'C-Äquivalent'. Ich freue mich schon darauf, endlich schnelle C++-Programme bauen zu können, danke im Voraus.

(Ein bisschen gespannt bin ich ja schon, weil ich zu blöd bin, GNU-Programme zu verstehen.)

volkard

Shade Of Mine schrieb:

blöde frage:
aber im gegensatz zu nem riesigen switch() schneiden virtuelle methoden doch sicherlich besser ab... (zumindest nicht schlechter)

doch, schlechter. gehen wir mal von vielen klassen aus und nur sehr kleinen funktionen. über den trick mit den funktionszeiger wird keine mehr inline sein. der compiler wird auch nicht versuchen, gemeinsamen code in den vielen zweigen zusammenzufassen. eiffel geht da nen lustigen weg und macht auch mal statt ner vtbl entscheidungsbäume, was duchaus manchmal schneller ist. aber man muß schon ganz schön genau messen, um das sehen zu können.
ist auch alter stand, vermutlich hat intel längst 100000 transistoren geopfert, um den befehl für "guck in tabelle nach und call nach inhalt on tabellenstart plus 4 mal offset" verflixt schnell hinzukriegen. so kanns auch passieren, daß ne sprache dadurch schnell wird, daß sie so viel verwendet wird.

Bashar schrieb:

Sie haben keinen, wenn sie gebraucht werden, d.h. wenn man ohne sie switch oder Funktionszeiger verwenden müßte. Wenn man einfach so irgendwas virtual macht, weil man das mal wo gesehen hat und cool findet, dann schon.

Jemand hat schonmal gesagt, dass es Eiffel mit Binären Bäumen und nicht mit einer einzigen vtbl macht und das schneller wäre. Warum? Kann ich mir nicht vorstellen?

volkard

Daniel E. schrieb:

volkard schrieb:

sag mir einen konkreten, und ich weise dir nach, daß er nicht sein müßte.

Der Grund, warum meine konkreten C++-Programme so ablaufen, wie sie es tun, ist der GCC (genauer: 'gcc32 (GCC) 3.2 20020518 (experimental) [FreeBSD]', meint 'gcc332 -- version') und die Umgebung (die ich gerade nicht ändern möchte). Ich habe den Quelltext noch vorliegen, Du musst mir nur die Zeile und Datei sagen, in der steht, dass C++-Programme langsamer ablaufen als das 'C-Äquivalent'. Ich freue mich schon darauf, endlich schnelle C++-Programme bauen zu können, danke im Voraus.

du solltest den grund anschaffen. ich behaupte doch, daß es keinen gibt.

Daniel E.

volkard schrieb:

du solltest den grund anschaffen. ich behaupte doch, daß es keinen gibt.

Ich kann dir nicht mehr sagen, als dass dein 'konkreter Grund' (O-Ton) voll konkret im GCC steckt. Genauer weiß ich es nicht, aber da ist er trotzdem.

Oder willst Du nur darauf hinaus, dass es auf einem hypotetischen System mit einem hypothetischen C++-Compiler von einem Guru wie dir C++-Programme durchaus mit C-Programmen gleichziehen könnten? Und dass es Blödsinn ist, nur dir Sprachen (ohne Implementiereungen) zu vergleichen? Darauf können wir uns herzlichst einigen.

volkard

Daniel E. schrieb:

volkard schrieb:

du solltest den grund anschaffen. ich behaupte doch, daß es keinen gibt.

Ich kann dir nicht mehr sagen, als dass dein 'konkreter Grund' (O-Ton) voll konkret im GCC steckt. Genauer weiß ich es nicht, aber da ist er trotzdem.

Oder willst Du nur darauf hinaus, dass es auf einem hypotetischen System mit einem hypothetischen C++-Compiler von einem Guru wie dir C++-Programme durchaus mit C-Programmen gleichziehen könnten? Und dass es Blödsinn ist, nur dir Sprachen (ohne Implementiereungen) zu vergleichen? Darauf können wir uns herzlichst einigen.

geht viel direkter.
ich kann kein c++-programm bauen, das du nicht oin c genauso schnell hinkriegen würdest. (nimmst einfach nen c++-nach-c-compiler). du kann kein c-programm baen, das ich nicht in c++ genauso schnell hinkriegen würde. (ich geb dem c++-compiler einfach c zu essen).
also sind in jedem wettkampf beide sprachen exakt gleich schnell.
falls jemand lahmen code baut und verkauft, bei nem wettkampf aber besseren bauen würde, so ist der lahme irrelevant.

volkard

Daniel E. schrieb:

dass es auf einem hypotetischen System mit einem hypothetischen C++-Compiler von einem Guru wie dir C++-Programme durchaus mit C-Programmen gleichziehen könnten...

du tust so, als seien c++-progs generell lahmer. das stimmt einfach nicht. findest genauso lahme c-progs zu schnellern c++-progs wie umgekehrt. hängt einfach nur davon ab, wer es schrieb und wozu.

Bashar

Daniel E. schrieb:

Es gibt aber sehr wohl prinzipielle Gründe, warum C++-Programme idR langsamer ablaufen als C-Programme (bei gleicher Programmierqualität).

Daniel E. schrieb:

Oder willst Du nur darauf hinaus, dass es auf einem hypotetischen System mit einem hypothetischen C++-Compiler von einem Guru wie dir C++-Programme durchaus mit C-Programmen gleichziehen könnten? Und dass es Blödsinn ist, nur dir Sprachen (ohne Implementiereungen) zu vergleichen? Darauf können wir uns herzlichst einigen.

Kann es sein dass du dir gerade selbst ein Bein gestellt hast? Gibt es jetzt Massenv^Wprinzipielle, in der Sprache begründete, Gründe oder nicht?

Daniel E.

Bashar schrieb:

Gibt es jetzt Massenv^Wprinzipielle, in der Sprache begründete, Gründe oder nicht?

Huch? Ich schrieb nichts, über »in der Sprache begründete Gründe«, sondern von »prinzipiellen Gründen, warum C++-Programme(!) langsamer ablaufen«. Unter einem Programm verstehe ich etwas, das mit einer konkreten Implementierung übersetzt wurde und ausgeführt werden kann. Und genau dort scheinen die Gründe zu liegen, warum übliches C++ 'nicht so schnell wie C ist'.

volkard schrieb:

du tust so, als seien c++-progs generell lahmer. das stimmt einfach nicht. findest genauso lahme c-progs zu schnellern c++-progs wie umgekehrt. hängt einfach nur davon ab, wer es schrieb und wozu.

Das ist sicher der Hauptfaktor Mensch, aber nochmal: 'Meine' C++-Compiler sind schlechter, als 'meine' C-Compiler.

volkard

Daniel E. schrieb:

Das ist sicher der Hauptfaktor Mensch, aber nochmal: 'Meine' C++-Compiler sind schlechter, als 'meine' C-Compiler.

komisch.
'Meine' C++-Programme sind besser als 'meine' C-Programme.

Bashar

Wie kann der GCC ein prinzipieller Grund sein, dass C++-Programme idR langsamer ablaufen? GCC ist nur eine Implementierung von vielen.

Artchi

Daniel E.! Du scheinst hier nur zu widersprechen ohne konkrete Beispiele zu bringen. Deine Aussagen gehen mir deshalb voll A*** vorbei. Und ganz ehrlich, ich glaube lieber dem C++-Erfinder und Scott Meyers als dir. Da brauch ich garnicht lange zu überlegen.

An den Fragesteller dieses Topics, hier die zwei Bücher, die in jedes Regal eines C++ Coders gehören und in denen auch konkrete Beispiele sind:

Sehr gutes Buch, das man haben MUSS: http://www.amazon.de/exec/obidos/ASIN/3827313058/qid=1058202688/sr=2-4/ref=sr_aps_prod_4_2/028-8327082-9703769

Reines Nachschlagewerk, als Wälzer in dem man alles nachschlagen kann: http://www.amazon.de/exec/obidos/ASIN/382731660X/qid=1058202721/sr=2-2/ref=sr_2_11_2/028-8327082-9703769

Als ergenzung interessant, in dem auch viel über Performance der einzelnen Container geschrieben steht, und wieso und weshalb:
http://www.amazon.de/exec/obidos/ASIN/3540432124/qid=1058202825/sr=1-1/ref=sr_1_10_1/028-8327082-9703769

Hier mal ein Zitat aus dem Buch von Meyers:

class Point
{
   public:
      Point(short int xCoord, short int yCoord);
      ~Point();
   private:
      short int x, y;
};

Wenn ein short int 16 Bit belegt, passt ein Point-Object in ein 32 Bit-Register. ... Wenn Sie den Destructor von Point virtuell machen, ändert sich diese Situation gewaltig.

Quelle: Effektiv C++ Programmieren, Seite 87

Danach kommen noch einige Absätze wieso weshalb das alles so ist. Hab aber keine Lust jetzt alles abzutippen.

Wichtig ist doch nur zu verstehen, was denn aus so einer Klasse der Compiler macht bzw. machen darf. Denn das ist vom C++-Standard vorgegeben, wie eben das Beispiel mit den zwei Variablen in einem Objekt. Wenn natürlich ein Compiler in dem Fall Mist baut, ist das nicht die Schuld von C++. Im C++-Standard steht was anderes...

Warum sollte also das ganze langsamer als C sein? Die Funktionen in den Klassen werden doch nur einmal im Speicher vorliegen, lädiglich die Datenelemente (Variablen) werden wie in C so oft angelegt wie nötig.

Es ist doch so, das C++ nur ein Werkzeug ist, und zwar eines das auf Effektivität ausgelegt ist. Es soll ja den Coder unterstützen und nicht hindern. Wie jedoch letztendlich z.B. ein Algorythmus (z.B. Berechnungen, if-else-Konstrukte usw.) compiliert wird, hat doch aber mit C++ recht wenig zu tun? Das ist dann eher eine Compiler-Geschichte die genauso in C oder Pascal in die Hose gehen kann.

Daniel E.

Bashar schrieb:

Wie kann der GCC ein prinzipieller Grund sein, dass C++-Programme idR langsamer ablaufen? GCC ist nur eine Implementierung von vielen.

Ach? Der 'Grund', sind alle Implementierungen, die ich kenne. Dass das ein Tunnelblickbild ist, ist mir klar, aber die Theorie nützt mir in diesem Fall ausnahmsweise wirklich nichts.

Wenn wir hier Rechthaberdiskussionen über die Wortbedeutung von 'prinzipiell' führen wollen, so bin ich gerne bereit, die Sache erheblich abzukürzen :): Du hast recht, 'prinzipiell' ist hier prinzipiell unpassend.

volkard schrieb:

'Meine' C++-Programme sind besser als 'meine' C-Programme.

Schreib' einen C++-Compiler.

Floh

Daniel E. schrieb:

Das ist sicher der Hauptfaktor Mensch, aber nochmal: 'Meine' C++-Compiler sind schlechter, als 'meine' C-Compiler.

versuch doch mal ein C-Programm als C und als C++ zu kompilieren und schau was rauskommt. ich wette mit dir das macht performancetechnisch keinen unterschied.

TheTester

also ich will ja nich rumnörgeln ich meine interessant ist das ja alles schon *gg* WIESO machen wir dann nich mal einen benchmark...ich meine ich bin ja auch der meinung das es am compiler liegt wie flott ein programm abläuft...wie wärs denn? mal verschiedene compiler... c / c++ und verschiedene programme...sowas der art wie "the great programming language shootout" halt nur für c / c++ und dort könnte man auch mal schauen wie schnell ein c programm abläuft wenn man es mit einem c++ compiler kompiliert und so weiter...natürlich müssten für sowas bestimmte bedingungen geschaffen werden...zb. ein unabhängiger rechner...und der sollte möglichst nich grad von einem c / c++ fanatiker...betrieben werden...(wegen der objektivität)

also bevor hier alle rumnölen...macht halt ma sowas

bye

tt

volkard

Daniel E. schrieb:

volkard schrieb:

'Meine' C++-Programme sind besser als 'meine' C-Programme.

Schreib' einen C++-Compiler.

was hat das damit zu tun? ich brauch doch keinen, denn bei mir sind die c++-programme ok. irgendwie sind alle deine kommentare völlig unverständlich.

Daniel E.

Floh schrieb:

versuch doch mal ein C-Programm als C und als C++ zu kompilieren und schau was rauskommt. ich wette mit dir das macht performancetechnisch keinen unterschied.

Na dann. Mal ein schneller Hack, von heute Nachmittag. [Achtung Unix!]

$ gcc32 -O2 ip.c -o c && g++32 -O2 ip.c -o cpp && ls -l c cpp
-rwxr-xr-x  1 de  de    5188 Jul 14 19:42 c
-rwxr-xr-x  1 de  de  191311 Jul 14 19:42 cpp
$ time ./c ; time ./cpp # gibt nur die Fehlermeldungen aus, sollte von daher weitestgehend uninteressant sein
Usage: ./c <iface>

real    0m0.005s
user    0m0.004s
sys     0m0.001s
Usage: ./cpp <iface>

real    0m0.008s
user    0m0.000s
sys     0m0.001s
$  strip c cpp ; ls -l c cpp
-rwxr-xr-x  1 de  de   3528 Jul 14 19:45 c
-rwxr-xr-x  1 de  de  27544 Jul 14 19:45 cpp
$ cat ip.c

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <netinet/in.h>
#include <net/if.h>
#include <arpa/inet.h>

int main(int argc, char** argv)
{
     struct ifreq ifa;
     struct sockaddr_in *i;
     int fd;

     if(argc < 2) {
          fprintf(stderr, "Usage: %s <iface>\n", *argv);
          return EXIT_FAILURE;
     }
     ++argv;
     if (strlen(*argv) >= sizeof ifa.ifr_name) {
          fprintf(stderr, "%s is to long\n", *argv);
          return EXIT_FAILURE;
     }

     strcpy(ifa.ifr_name, *argv);

     if((fd = socket(AF_INET, SOCK_DGRAM, 0)) == -1) {
          perror("socket");
          return EXIT_FAILURE;
     }

     if(ioctl(fd, SIOCGIFADDR, &ifa)) {
          perror("ioctl");
          return EXIT_FAILURE;
     }

     i = (struct sockaddr_in*)&ifa.ifr_addr;
     puts(inet_ntoa(i->sin_addr));

     return 0;
}

Zugegeben, objektiv ist was anderes.

Artchi: wem Du glaubst und wen Du beleidigst ist mir recht schnuppe. Aber ich will dir kein Buch verkaufen.

volkard

Daniel E. schrieb:

Na dann. Mal ein schneller Hack, von heute Nachmittag. [Achtung Unix!]

jo, mit msvc nicht nachvollziehbar.

Bashar

Bei mir (gcc 3.2.2) ist c 5758 und cpp 5971 Bytes groß (ungestrippt.) Gestrippt 3764 bzw. 3948.

EDIT: sorry, das ist ohne -O2 gewesen. Mit wäre cpp 5909 groß. c teste ich nicht nochmal.

achtung: unix-unbegabter!

was sagt mir dein benchmark? zähl ich die milisekunden zusammen? dann ist c++ um eine schneller.