Wie gross ist der Geschwindigkeitsunterschied C/C++

HumeSikkins

. Aber viele (oder alle ?) sagen immer das C viel schneller ist, als C++. Mich als Anfänger, würde mal intessieren, wie gross der Geschwindigkeitsunterschied tatsächlich ist ?

Es gibt keinen inhärenten Geschwindigkeitsunterschied zwischen C und C++.
C++ ist eine Obermenge von C.
Praktisch gesehen gibt es natürlich Unterschiede. Die hängen aber von Millionen Faktoren ab (Compiler, Bibliotheken, Sprachmittel, Problem, Struktur der Lösung...) und überdecken mehrere Bereiche (Compilezeit, Linkzeit, Laufzeit...).
Fakt ist, dass es sinnlos ist über Geschwindigkeit zu philosophieren (und zu disktuieren) solange man nicht das zu betrachtene Gebiet genau defeniert und weiß, worüber man eigentlich spricht.

Falls du nach einfachen absoulten Antworten a là: "C ist 23% schneller als C++" oder "C++ ist 8% schneller als C" suchst, die wirst du nicht finden. Und falls daoch, kannst du sicher sein, dass der Antwortende käse erzählt.

Falky

Gibt es in dem Falle evtl. (ausführlichere) Artikel darüber?
Ich würde mir gerne ein Bild davon machen :|

HumeSikkins

Gibt es in dem Falle evtl. (ausführlichere) Artikel darüber?

Es gibt unendlich viele Artikel mit unendlich vielen verschiedenen Schwerpunkten zu diesem Thema.
Es gibt sogar Bücher die sich mit der Thematik beschäftigen. Zum Aufbau von Basiswissen empfehle ich z.B. die Lektüre des (mittlerweile recht alten) Buchs: "Inside the C++ Object Model" von Lippman. Danach hat man wenigstens schon mal einen Überblick über die Kosten einzelner Sprachelemente.

Eine ausführliche google-Recherche wird dir außerdem unzählige Ergebnisse liefern.
Auf die schnelle:
Basiswissen 1
Basiswissen 2

Klassicher C++ Vorteil
http://www.openroad.org/school/cvscpp/cvscpp.html

Aber wie gesagt: Letztlich ist das alles sinnlos, solange du nicht weißt, was dich genau interessiert.

Vor allem sollten dich die (wenn überhaupt in der Praxis vorhandenen) geringen Geschwindigkeitsunterschiede nicht davon abhalten, C++ anstatt C zu lernen.
Sogar John Carmack ist inzwischen auf C++ umgestiegen - und der hat sich lange geziert

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.