C++ Overhead gegenüber C

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.

Bashar

nein, die kann man nicht zusammenzählen. "real" ist die Zeit aus der realen Welt, "sys" und "user" die im Kernel bzw. Userspace verbrachte Prozessorzeit. Die Messungen sind in der Größenordnung aber bullshit, wenn C für das eine write() 4ms braucht, braucht C++ die auch.

rüdiger

@Daniel E.

hmm, mal ein paar tests von mir (ich hab mal dein Programm genommen)

> uname -a
Linux debian01 2.4.20 #10 Son Apr 6 12:04:45 CEST 2003 i686 GNU/Linux
> gcc -v
[...]
gcc version 3.2.3 20030415 (Debian prerelease)
> gcc -O3 -o demo_cc demo.cc
> g++ -O3 -o demo_++ demo.cc
> gcc -O3 -o demo_c demo.c
> ls -lh demo_c demo_cc demo_++
-rwxr-xr-x    1 ki     us         5,0K 2003-07-14 20:18 demo_++
-rwxr-xr-x    1 ki     us         4,9K 2003-07-14 20:18 demo_c
-rwxr-xr-x    1 ki     us         4,9K 2003-07-14 20:17 demo_cc
> time ./demo_++
Usage: ./demo_++ <iface>

real    0m0.008s
user    0m0.010s
sys     0m0.000s
> time ./demo_cc
Usage: ./demo_cc <iface>

real    0m0.002s
user    0m0.000s
sys     0m0.000s
> time ./demo_c 
Usage: ./demo_c <iface>

real    0m0.003s
user    0m0.000s
sys     0m0.000s

Wie es aussieht ist die C++ Stdlib das Problem (bei der GCC). (Der Zeitunterschied zwischen demo_c und demo_cc ist innerhalb der Messtolleranz)

Artchi

Warum testet ihr COMPILER? Ich hab gedacht es geht um C und C++... irgendwie unsinnig, da man unter VC++ nur EINEN Compiler sowohl für C als auch C++ habe.

Daniel! Du testest GCC und GPP (oder wie sich der C++-GNU schimpft)... also hast du hier zwei völlig verschiedene Compiler-Implementierungen getestet, und nicht zwei Sprachen. Sorry, das ist Unfug!