3. performance von C und gegenüber C++

performance von C und gegenüber C++

  • G

    mathik schrieb:

    - evt. ein try-catch-block mit exceptions. in C hätte man dann allerdings irgendwelche "if-orgien"

    die theorie sagt das es mit exception schneller geht, wenn du bei jeden kleinen funktions aufruf ein if machen muss um zu sehen ob alles ok gelaufen ist
    irgend wann hatt man erstmal die nasse voll jede kleine funktion abzufragen, die prüfungen versperen einen den blick auf das wesentliche
    außerdem
    funktion_a ruft funktion_b auf und funktion_b ruft funktion_c auf, wenn funktion_c jetzt ein fehler macht, wird der fehler einmal in funktion_c gefunden, bearbeitet und an funktion_b zurückgegeben, funktion_b stellt jetzt diesen fehler auch fest (finden/bearbeiten/zurückgeben), das gleiche haben wir dann in funktion_a usw.

    d.h. die fehler von funktion_c werden in diesen bsp drei mal bearbeitet

    in der praxis soll exception-code langsammer sein, war zumindestenz in vc6.0 so 😞
    aber meine test mit vc2003 haben kein unterschied gezeigt (vielleicht waren meine test nicht gut genug)

    0
  • D

    HumeSikkins schrieb:

    Generell kann man aber sagen, und das ist wohl der einzig wichtige Satz in diesem Posting:
    Ein Problem das sich zufriedenstellend mit C lösen lässt, lässt sich ebenso auch mit C++ lösen.

    Allerdings ist die naheliegende Lösung dann kein C++ mehr. Das ist wenigstens die Meinung, die ich aus zahlreichen Artikeln im C++-Forum deduzieren konnte.

    0
  • M

    hallo leute,

    danke erstmal für eure beiträge.

    ich habe da allerdings noch ein paar fragen:
    wieso wird im embedded bereich denn immer noch so oft in C programmiert? ich meine ok, wenn jetzt kein C++ compiler zu verfügung steht, dann ist das ja ok, aber warum dann, wenn einer da ist (insbesondere auch ein BS wie QNX). da kommt dann meinstens das argument, C sei schneller, was ich überhaupt nicht nachvollziehen kann (ihr ja auch nicht ;))

    und warum wird denn überhaupt noch so viel in C programmiert? siehe z.b. die ganze software unter Linux (apache, samba, usw.) .

    0
  • M

    HumeSikkins schrieb:

    ich habe da gerade eine diskussion mit einem bekannten laufen, der meint, dass C schneller ist als C++.

    Was schneller? Schneller müde? Schneller langweilig? Schneller erlent? Schneller geparst? Schneller compiliert?
    Einige von diesen Eigenschaften sind auf jeden Fall richtig.

    Wenn es aber um die Ausführungseffiziens geht, dann ist diese Aussage in dieser Form käse.

    ich wollte euch fragen, was ihr zu diesem thema sagt. welche konstrukte in C++ sind denn langsamer?

    Das ist eine sehr eigenartige Frage. Normalerweise benutzt man langsamer im Vergleich. Also: "A ist langsamer als B". Statt nur "A ist langsamer".

    @hume
    mit performance meine ich, wie du es ja schon richtig erkannt hast, die laufgeschwindigkeit des programms. 😉
    warum soll das denn käse sein?
    ich könnte ja behaupten ein sehr guter C-programmierer kann ein programm schreiben, das schneller ist als das äquivalente eines sehr guten C++-programmierers, der das ganze objektorientiert macht. oder nicht?
    oder auch, dass alle C++ programme langsammer sind als die äquivalenten C programme, weil die objektorientierung einfach zu viel overhead produziert.

    im internet finde ich zu dem thema leider auch nichts. vielleicht kannst du mir ja einen link posten, wenn du eins hast. 🙄

    0
  • S

    mathik schrieb:

    wieso wird im embedded bereich denn immer noch so oft in C programmiert?
    [..]
    da kommt dann meinstens das argument, C sei schneller

    Weil es oft keinen C++ gibt - bzw. es aufwendig ist, einen C++ Compiler zu schreiben. C ist da wesentlich einfacher zu handlen.

    Und teilweise liegt es auch an falschem wissen. zB dass C++ langsamer sei, oder dass template mehr Speicher fressen, etc.

    Dabei habe ich letztens einen alten Artikel in comp.std.c++.moderated oder comp.lang.c++.moderated (weiss nicht mehr) gelesen. Templates haben auf embedded systemen einen großen Vorteil: es werden immer nur die funktionen instanziiert die auch gebraucht werden - bei einer 'normalen' klassen, werden ja immer alle Methoden instanziiert.

    allerdings muss man auch zugeben, dass schlechte c++ compiler schlechten code erzeugen. Gerade bei Exceptions und templates kann es sein, das alte bzw. schlechte Compiler echt miesen code erzeugen - und vorallem: an sowas erinnert man sich dann ewig. auch wenn die compiler besser geworden sind.

    Selbiges hast du übrigens bei der Spieleprogrammierung (zumindest der hobbymäßigen). Denn die meisten Spieleprogrammierungsbücher erzählen so einen quark 😞

    ich könnte ja behaupten ein sehr guter C-programmierer kann ein programm schreiben, das schneller ist als das äquivalente eines sehr guten C++-programmierers, der das ganze objektorientiert macht. oder nicht?
    oder auch, dass alle C++ programme langsammer sind als die äquivalenten C programme, weil die objektorientierung einfach zu viel overhead produziert.

    ja, behaupten kannst du es, aber das macht die aussage auch nicht richtig.

    es gibt eben kein direktes äquivalent zu virtual in C. Sicher, man kann es simulieren - aber du erreichst damit nicht die flexibilität wie das echte virtual.

    Und das eine 'kann 70% von dem was virtual kann' implementation uU eine kleine spur schneller läuft ist damit begründet, dass es einfach nicht alles kann was virtual kann. Wenn man dann nämlich diese restlichen 30% braucht, wirds in C vermutlich im längen langsamer...

    Wenn man aber einfach sagt: switch VS virtual - da schneidet virtual zumindest nicht signifikant schlechter ab.

    irgendwann habe ich mal was von einem prozessor gehört, der einen virtual call als opcode implementiert hat - da ist switch natürlich wieder langsamer. (allerdings habe ich das nur gehört, und kann nix konkretes sagen - auch nicht ob es überhaupt stimmt)

    OOP erzeugt nicht zwangsläufig Overhead - gute compiler optimieren da 'wie sau'. schlechte Compiler bauen natürlich auch viel mist.

    ob man
    void f(foo* this);

    oder
    void foo::f();

    hat - ist ja egal - der generierte code wird sehr ähnlich sein (wenn nicht uU sogar gleich)

    Bei vergleichen C mit C++ wird aber oft der Fehler gemacht zu sagen:

    void foo(void);
    ist schneller als
    void Class::foo();

    -> ist ja auch logisch, dass das stimmt. aber die beiden konstrukte sind ja auch nicht identisch...

    c++ bietet eine Menge möglichkeiten den Code schneller zu machen, die C nicht hat. zB expression templates oder das functoren geinlinet werden können, etc.

    ich glaube also kaum, dass ein C++ Programm signifikant langsamer oder schneller als ein äquivalentes C programm laufen wird.

    0
  • ?

    Wenn C++ wirklich so performant wäre, wie es C-Compilate unbestritten sind, stellt sich die Frage, warum gängige Betriebssysteme noch immer in C und nicht in C++ geschrieben werden.

    0
  • T

    gast i.s.b.
    ***********

    ich vermute mal, weil die vielleicht keinen bock haben ihre hunderttausende von quellcodezeilen umzuschreiben? man könnte das ja alles nach c++ portieren, nur siehts dann immernoch wie C aus 😉 sprich man braucht auch ne komplette redesignphase/neuschreibphase...und rechtfertigt das den aufwand? ich vermute weiter wenn du nen OS schreibst brauchste ja auch irgendwann ein compiler für dein system und ein C compiler ist da glaub ich schneller entwickelt als C++ (zumindest ist der C standard von den ausmaßen sicher nur ein drittel vom c++ standard)

    tschööö

    tt

    0
  • G

    Gast ist schon belegt schrieb:

    Wenn C++ wirklich so performant wäre, wie es C-Compilate unbestritten sind, stellt sich die Frage, warum gängige Betriebssysteme noch immer in C und nicht in C++ geschrieben werden.

    und was ist mit win2000 (drauf aufbauend winxp, win server 2003, win longhorn usw.)?

    klar ist linux noch in c und windows würde auch noch in c sein, wenn ms nicht so viel geld hätte und sich gedacht hatt: ok wir vergessebn den win9x & winnt code und schreiben alles neu, aber diesmal sauber und in c++

    mathik schrieb:

    und warum wird denn überhaupt noch so viel in C programmiert? siehe z.b. die ganze software unter Linux (apache, samba, usw.) .

    weil sie keine zeit haben die software neu in c++ zu schreiben

    0
  • H

    Hallo,
    C++ != Objektorientier. Das sollte man immer bedenken, bevor man irgendwelche Aussagen trifft.

    wieso wird im embedded bereich denn immer noch so oft in C programmiert?

    Immer langsam. So schnell geht das mit dem Wechsel nicht. Es hat viele Jahre gedauert, bis im Embedded-Bereich im Großen Stil C statt Assembler benutzt wurde. Und es wird viele Jahre dauern, bis C++ statt C verwendet wird. Wenn man sich aber mal ein bischen in der Embedded-Literatur-Welt umschaut, wird man feststellen, dass C++ immer häufiger ein Thema wird (siehe z.B. Embedded Systems Programming)

    Eins sollte aber relativ klar sein: Niemand der 4k Speicher zur Vrfügung hat wird sein Steuerungsprogramm schön Objektorientiert aufbauen, fein mit Hierarchien, virtuellen Methoden und vielen kleinen Objekten. Die OOP hat gute Anwendungsgebiete, aber nicht alles was programmiert werden muss, sollte oo programmiert werden. Dennoch: auch wenn man auf oop verzichtet hat C++ gegenüber C Vorteile.

    im internet finde ich zu dem thema leider auch nichts. vielleicht kannst du mir ja einen link posten, wenn du eins hast

    Nachher vielleicht. Jetzt muss ich los.

    0
  • B

    Ein wichtiger Grund ist auch, dass C++-Compiler um Größenordnungen schwerer zu entwickeln sind als C-Compiler, und zwar zwar hauptsächlich wegen der komplizierteren Semantik. Kleine Klitschen, die C-Compiler für embedded-Systeme bauen, kümmern sich lieber um Code-Optimierung als um Name-Lookup oder Überladungsauflösung.

    0
  • S

    Bashar schrieb:

    [..] Kleine Klitschen, die C-Compiler für embedded-Systeme bauen, kümmern sich lieber um Code-Optimierung als um Name-Lookup oder Überladungsauflösung.

    Jetzt hätt ich einmal auch nen gutes Argument gehabt um mitzureden und dann im
    letzten Posting ist mir einer zuvorgekommen 😞 😉

    0
  • R

    @Shade
    das Argument mit den Templates verstehe ich nicht

    #include <cstdio>

template<class T> T foo(int c) { return c/static_cast<T>(2); };

int main() {
  std::printf("%f\n",foo<float>(5));
  std::printf("%d\n",foo<int>(5));
}

    #include <stdio.h>

int foo_int(int c) { return c/2; }
float foo_float(int c) { return c/(float)2; }

int main() {
  printf("%f\n",foo_float(5));
  printf("%d\n",foo_int(5));
  return 0;
}

    sollte ja die gleiche Code größe ergeben. Dachte Templates sind nützlich, weil man Code spart und nicht für jeden Fall alles neu implementieren muss (und noch ein paar andere Tricks). Aber ich denke nicht, dass die Binarys deswegen kleiner werden.

    zB dass C++ langsamer sei

    Ich denke eher, dass die Leute in dem Fall mehr an die Binary größe denken, aber die ist ja bei C++ gleich (wenn man die C++ Standard-Library nicht linkt, die auf Embedded Systemen ja eh nicht vorhanden ist)

    0
  • S

    kingruedi schrieb:

    @Shade
    das Argument mit den Templates verstehe ich nicht

    weil dus falsch verstanden hast 😉

    Ich meine nur bei Member Funktionen (habe ich nicht explizit geschrieben, weil ich dachte dass es klar ist - aber jetzt wo ichs nochmal gelesen habe -> du hast recht, ist nicht klar ersichtlich).

    Denn es werden nur die Member Funktionen von Template Klassen instanziiert, die auch gebraucht werden, die anderen nicht. Bei 'normalen' non-Template Klassen werden alle Member Funktionen instanziiert.

    Dies ist natürlich normalerweise ziemlich egal - aber gerade auf Embedded Systemen kann es Vorteile bringen.

    0
  • B

    Wer sagt denn, dass alle Memberfunktionen von nicht-Template-Klassen "instanziiert" werden müssen? Es gibt kein konformes Programm, dass feststellen kann, dass eine Memberfunktion nicht instanziiert wurde, also steht es dem Übersetzer frei, die Definition im Executable nicht einzubinden, wenn sie nicht angesprochen wird.

    0
  • S

    @Bashar: siehe comp.lang.c++.moderated

    0
  • B

    Das mag bei dem einen Compiler so sein. Generell sagen kann man das mit Sicherheit nicht. Die Frage ist nur, ob der Compiler (bei Templates) oder der Linker (bei nicht-Templates) schlau sein muss.
    Dass Memberfunktionen von Templates nicht instanziiert werden, hat eigentlich nur den Effekt, dass in diesen Funktionen nicht nach Fehlern gesucht wird. Beispiel vector<T>::resize für ein T ohne Standardkonstruktor -- macht nichts, solange resize nicht aufgerufen und damit instanziiert wird.

    0
  • H

    mathik schrieb:

    im internet finde ich zu dem thema leider auch nichts. vielleicht kannst du mir ja einen link posten, wenn du eins hast

    HumeSikkins schrieb:

    Nachher vielleicht. Jetzt muss ich los.

    So, jetzt bin ich wieder da.

    Teste mal std::sort gegen qsort()

    Bitte schön

    OOP erzeugt nicht zwangsläufig Overhead - gute compiler optimieren da 'wie sau'

    Stichwort: Abstraction Penalty

    Geschwindigkeit dank Templates:
    Bitte schön
    Bitte schön

    Ein paar simple Vergleiche:
    Comparing C++ and C Performance I

    Comparing C++ and C Performance II

    0
  • J

    Agilent verwendet meines Wissens im Embedded-Bereich fast ausschließlich C++.
    Okay, was ich bis jetzt gesehen habe sieht eher nach C+ aus, aber egal.
    Und die scheinen recht glücklich mit ihrer Wahl zu sein.

    MFG Jester

    0
  • R

    (denke ich werd den Thread später in die FAQ packen, vorallem die Links von Hume sehen sehr gut aus)

    0
Anmelden zum Antworten