Wie gross ist der Geschwindigkeitsunterschied C/C++

idefix

In der letzten c't (21/2003) ist auch ein schöner Artikel drin. Es geht zwar nicht unbedingt um den Unterschied zwischen C und C++. Hier kann man schön sehen wie schwer es ist, das Leistungsvermögen verschiedener Sprachen und Complilern heraus zuarbeiten. Ich finden den Artikel einerseits völlig überflüssig, anderseits wiederum sehr aufschlussreich.

HumeSikkins

Ich finden den Artikel einerseits völlig überflüssig, anderseits wiederum sehr aufschlussreich.

Sehe ich auch so. Er hat eindrucksvoll die Relevanz der Worte von Dieter Nuhr bewiesen: "Wenn man keine Ahnung hat, einfach mal Fresse halten".

RHBaum

eigentlich ist C++ noch mit nem blauen Auge von gekommen.

Stellt euch vor, die haetten als GeschwindigkeitsTest ne Matrizen Manipulation genommen.
Alle die hoch gelobten interpretierenden Sprachen haetten es mit ihren eigenen Containern irgendwie realisiert.
Und bei C++ haette man dann ueber ActiveX ne Excel Instanz geoeffnet, die Zellen befuellt, schnell noch nen Exel Makro fuer die Berechnung mit reingepresst, ausgefuehrt und Ergebniss aus den Zellen wieder ausgelesen. Faellt ja in die Rubrik "uebliche Vorgehensweisse" und spiegelt natuerlich auch das Wesen von C++ wieder, Schnelligkeit und portabilitaet !!!!

Ich hoffe ich hab nun kein Stichwort fuer den naechsten Geschwindigkeitsvergleich geliefert !

Ciao ...

rofl

Gerard

idefix schrieb:

Ich finden den Artikel einerseits völlig überflüssig, anderseits wiederum sehr aufschlussreich.

hast du dir den c++ code angekuckt? die leute die das programmiert haben, kennen solche grundlegenden sachen wie referenz in c++ nicht

idefix

jo, hatte ich mir angeguckt.

Vielleicht, mußte man irgendwie eine Gemeinsamkeit finden!? Wobei const CString mir ein Rätsel ist.
Wenn ich den Test richtig verstehe ging es auch nur darum, heraus zufinden
wielange der Objektaufbau (Initialisierung) dauert. Aber muß es unbeding MFC sein.
Wer baut den heute noch Vektoren mit CObArray zusammen. STL wäre hier doch angebrachter gewesen.
Man hätte nicht mal valarray nehmen müßen, sonder einfach nur den vector.
Naja, wenn man C++ testet, testet man eben auch gleich MFC. Weil MFC der Bestandteil von
C++ ist.

Das Gleiche gilt auch für CString. Hier wird immer mehr Speicher angefordert als eigentlich, nötig.
Wegen CStringData. CString ist ganz toll in der MFC-Applikationen, aber in Algorithmen??

Ich vermute das, hier noch was heraus zuholen wäre. Ich kann durch aus damit leben, das C++ etwas langasmer oder genauso schnell ist, wie andere Sprachen und ihre Compiler. Nur sollte man auch C++
nehmen und nicht irgndeine Lib, die primär auf einen OS zugeschnitten ist. C/C++ ist doch erstmal eine OS-Unabhängige Sprache.
Somit wird auch gleich das OS mit eingebunden. Ich kenn mich in den anderen Sprachen nicht so aus, könnte aber vermuten das deren Quelltexte OS unabhängierer sind. Der Test schreibt sich auf die Fahnen das C++
langsamer, schneller, genauso schnell ist wie Java, Delphi, C# usw. Was hat mit MFC?? Ich möchte MFC nicht schlecht machen aber in diesem Zusammenhang, nix gut.

virtuell Realisticer

Der Artikel sagt soviel aus wie: C++ == MFC

Toller Artikel, heise rutscht immer mehr ab.

Mir kommt es vor, als gehen denen die Themen aus, denn irgendwie
werden die Artikel immer schlechter.

mfg
v R

Walli

virtuell Realisticer schrieb:

Der Artikel sagt soviel aus wie: C++ == MFC

Wenn man es nur auf die MFC schieben könnte. Die ist in dem Fall aber völlig unschuldig, da die Leute noch nichteinmal mit C++ umgehen können.

RHBaum

Naja, meine Ansicht ist es ging nicht dierekt um C++/Java/C# sondern eher um die speziellen Entwicklungsumgebungen.
Deshalb Deshalb gabs ja auch 2 Varianten von C++, den Vc++ und den BCB. Nen Test mit nem gnu compiler haette der Autor eh ned hingekriegt ! :p

Wenn man sich VC++ zulegt, ist halt die MFC dabei, wenn man das "Handbuch" oder die MSDN aufschlaegt, dreht sich fast alles nur um die MFC, alle anderen Themen werden gut versteckt. Zumindest kommt man erst beim 2.en mal hingucken drauf. Ich denk mal mehr als die Haelfte, die VC++ einsetzen, verwenden dann auch die MFC.
Von daher ist die Verallgemeinerung VC++ = MFC Ansichtssache, aber zumindest diskussionswuerdig.

Wofuer aber Null verstaendnis habe ... Fuer klassen, die sich ned serialisieren muessen, Ableitungen CObject zu nehmen ... und CObjArray ist eh der greul.
Aus der MSDN:

Ab MFC, Version 4.0, wird beim Kopieren vonCString-Objekten ein Verweiszähler erhöht, anstatt die Daten zu kopieren. Dadurch wird das Übergeben von Parametern und das Zurückgeben von CString-Objekten nach Wert leistungsfähiger gemacht. Diese Vorgänge lösen den Aufruf des copy-Konstruktors aus, manchmal mehr als einmal. Durch das Erhöhen eines Verweiszählers wird der Verwaltungsaufwand für diese häufigen Vorgänge reduziert und die Verwendung von CString-Objekten zu einer attraktiveren Option.

Beim Entfernen der einzelnen Kopien wird der Verweiszähler im Originalobjekt heruntergesetzt. Das ursprüngliche CString-Objekt wird erst entfernt, wenn sein Verweiszähler bei Null angelangt ist.

Sie können über die CString-Member-FunktionenLockBuffer undUnlockBuffer die Verwendung des Verweiszählers deaktivieren oder aktivieren.

Wenn dem so ist, sollte der CString zumindest nicht der Performancekiller sein.

Trotzdem wird mir beim anblich eines Naiven "Function(const CSTring astring)" regelrecht schlecht.
Und wer weiss, was CString macht, wenn man mulithreading einschaltet ???

Wir koennten ja folgendes machen ... Wir entwickeln, oder verbessern den C++ code dahingehend, das wir das rennen gewinnen wuerden, in allen disziplinen .. wie erwaret ! Weiterhin eroeffnen wir eine Kollecte, und mit dem geld kaufen wir nen Buch uber die Grundlagen von C++ insbesondere ueber referenzen und Container (muessen ja nicht die STL Container sein, ne CList ist ja schon ne verbesserung :p ) Das ueberreichen wir zusammen den Author mit der Bitte, den Test doch noch mal zu wiederholen, wenn er mit der Lektuere fertig ist !

Ciao ...

Oder wir sparen uns den Aufwand und treten dem Autor einfach so kräftig in den Arsch

daishi

Optimizer schrieb:

Oder wir sparen uns den Aufwand und treten dem Autor einfach so kräftig in den Arsch

Nicht gerade die optimale Lösung.

Wie wäre es, wenn man sich an die heise-Leute wendet und sie auf ihren nun mehr oder weniger offensichtlichen Fehler hinweist. Dies sollte doch im Interesse aller Beteiligten liegen, oder zumindest in unserem.

RHBaum

Sicher liegt es in unserem Intresse !
Fuer den Autor kann ich nicht sprechen !
Wir koennten in das heise/ct Forum ne kurze Notiz hinterlassen, falls den Autor es intressiert wie nen teil der C++ Gemeinde uber seinen Artikel denkt, das er mal auf nen Link zu diesem Forum klicken soll.

Aber wahrscheinlich wird der Autor eh keine Zeit haben, weil er grad wieder an nem anderen Artikel schreibt, wahrscheinlich nen me Bauanleitung fuer nen kleines "Notstromaggregat" aus nem alten Reaktor eines russischen Atom-UBootes (die sind sicher grad billig zu haben, also Handelsueblich !!! ) und wie man das Teil steuert mittels einem Handheld und Windows CE !

Ciao ...

Helium

http://www.c-plusplus.net/forum/viewtopic.php?t=50314&postdays=0&postorder=asc&start=66 und folgende.

Aber dann will ich auch eine Stellungnahme von den Autoren gefordert haben

Geo

Um zur eigentlichen Frage zurückzukommen...

Ich habe das mal in einem Embedded Projekt mit dem gcc untersucht, da hier die Rechenzeit knapp war.

Der Hauptunterschied, der ein C++ Programm langsamer macht, sind die (abschaltbaren) Features RTTI (RunTimeTypeInformation) und die Exceptionbehandlung, da dafür zusätzlicher Code erzeugt und ausgeführt wird, auch wenn die Exception nicht auftritt.

Das ist natürlich compilerhabhängig.

kartoffelsack

Exceptionbehandlung, da dafür zusätzlicher Code erzeugt und ausgeführt wird, auch wenn die Exception nicht auftritt.

Aber nur, wenn Du in dem entsprechende C-Programm auf Fehlerbehandlung verzichtest. Für ein

int i = doSomething();
  if (i != 0)
  {
    reportError(i);
  }

wird in C nämlich auch code erzeugt.

operator void

Geo schrieb:

Der Hauptunterschied, der ein C++ Programm langsamer macht, sind die (abschaltbaren) Features RTTI (RunTimeTypeInformation) und die Exceptionbehandlung, da dafür zusätzlicher Code erzeugt und ausgeführt wird, auch wenn die Exception nicht auftritt.

Dass ein Programm durch RTTI leicht größer werden kann, verstehe ich ja. Aber wie kann dadurch die Performance beeinträchtigt werden?

rüdiger

Exceptions finde ich gar nicht teuer, hier mal nen test mit dem gcc 3.3.2 (debian prerelease)

class bar {
  int *array;
public:
  bar() : array(new int[100]) { }
  ~bar() { //damit der dtor nicht geinlined wird etwas sinloser code
    double c=100;
    for(;c;--c);
    delete []array;
    for(c=100;c;--c);
  }
};

struct blob { };
struct blub { };

void mop(bool c) {
  if(c)
   return; //throw blob();
}

void foo(int c) {
  bar b0,b1;
  if(c)
    return; //throw blob();
  if(c-1)
    return; //throw blub();
}

int main(int argc,char **argv) {
  //try {
    foo(argc-1);
  /*}
  catch(...) {
    return 1;
  }*/
}

kompiliert sind das (Parameter: -Wall -W -std=c++98 -Os) 5,9kb

mit try/catch: 6,2kb

mit foo => throw blob(); aktiviert: 6,6kb
mit foo => throw blub(); aktiviert: 6,6kb
mit mop => throw blob(); aktiviert: 6,6kb

also sieht es so aus, dass man 0,8kb overhead für exceptions bezahlt (und zwar konstant im ganzen programm). Das hört sich so viel an, aber wenn man ein Projekt hat, wo die binarys über ein Megabyte gross sind, da sind 0,8kb nicht viel. Auf Embedded-Systemen lohnt es sich vielleicht auf Exceptions zu verzichten (aber Embedded-C++ kennt eh keine Exceptions AFAIK).

davie

jo, Marcus hatte auf dem treffen ein Buch zum Thema "Embedded C++" mit.

AFAIR auch keine templates (das Argument mit der Geschwindigkeit aus dem Buch war mir nicht ganz ersichtlich) und eben RTTI

Daniel E.

kingruedi schrieb:

Exceptions finde ich gar nicht teuer, hier mal nen test mit dem gcc 3.3.2 (debian prerelease)
class bar {
  int *array;
public:
  bar() : array(new int[100]) { }
kompiliert sind das (Parameter: -Wall -W -std=c++98 -Os)

Scherzkeks. Mit new baust Du hier bereits Exceptions in dein Programm ein. Wenn Du etwas objektiver wirken willst, dann schaltest Du Ausnahmen auf Compilerebene ab; trotzdem bezweifle ich, daß Du hier relevante Unterschiede feststellen kannst.