3. C++ schneller als andere Sprachen?

C++ schneller als andere Sprachen?

  • ?

    Es kommt auf den Programmierer an.

    0
  • A

    HeyIhrNoobs schrieb:

    Es kommt auf den Programmierer an.

    Da hast du auch nicht unrecht. Aber wenn du einen Programmierer nimmst der in jeder der erwähnten Sprachen etwa gleich gut ist, ist die grobe Angabe ASM > C > C++ > Java nicht so abwägig.

    Bei dem Vergleich von C zu C++ stütze ich mich auf etwas aus der C++ Bibel (Die C++ Programmiersprache), auch wenn ich mir jetzt nicht sicher bin welche Auflage. Dort war eine grobe Angabe was C++ Features in etwa an Leistung kosten dürfen (Exceptions...). Auch wenn durchaus manche C++ Konstrukte zu schnelleren Code führen können. Dennoch, rein Leistungstechnisch ist meine Schätzung das C gegenüber C++ bei gleicher Codequalität (unter Nutzung von Sprachfeatures) ca. 10% schneller ist.

    Und C/C++ haben den Vorteil das die Optimierer dort schon Jahrzehnte herumschrauben... xD

    cu André

    0
  • ?

    camper schrieb:

    Es scheint aber, dass es einigen C-Fanatikern nicht in den Kopf geht, dass nicht jedes kleine Programm jedes einzelne Sprachfeature nutzen muss und diese überflüssige Nutzung ungeeigneter Sprachmittel natürlich der Performance nicht zuträglich sein wird. Da beide Sprachen (C und C++) grundsätzlich auf dem selben Maschinenmodell beruhen und für jedes Sprachmittel eine offensichtliche und effiziente (wenn auch nicht unbedingt optimale) Implementierung möglich ist, gibt es keinen Grund für fundamentale Unterschiede hinsichtlich Geschwindigkeit, Speicherverbrauch etc.

    die unterschiede sind zwar marginal, aber summieren sich auf. z.b. verwendet der c-coder gern char* mit zeichenketten. wer mit c++ rummacht, der nimmt lieber std::string. wo bei einem 'char *hallo = "hallo";' einfach eine adresse in den speicher geschrieben wird, führt 'std::string hallo = "hallo";' eine vielzahl von schritten aus. man erkauft sich höhere flexibilität für speed und speicherverbrauch. klar, wenn der c++ programmierer von seinem c++ nur den C subset nutzen würde, wären beide gleich schnell. aber dann wäre C++ auch überflüssig.
    🙂

    0
  • ?

    asc schrieb:

    HeyIhrNoobs schrieb:

    Es kommt auf den Programmierer an.

    Da hast du auch nicht unrecht. Aber wenn du einen Programmierer nimmst der in jeder der erwähnten Sprachen etwa gleich gut ist, ist die grobe Angabe ASM > C > C++ > Java nicht so abwägig.

    Die Annahme, dass ein Programmierer ein größeres Projekt fertigstellt und es darin nichts mehr zu optimieren gäbe, außer eine andere Sprache zu verwenden, ist aber abwägig. OK, ich könnte es vielleicht hin bekommen, aber dann müsste ich alle Libs selber schreiben und dazu hab ich jetzt auch keien Lust.

    0
  • S

    fricky schrieb:

    die unterschiede sind zwar marginal, aber summieren sich auf. z.b. verwendet der c-coder gern char* mit zeichenketten. wer mit c++ rummacht, der nimmt lieber std::string. wo bei einem 'char *hallo = "hallo";' einfach eine adresse in den speicher geschrieben wird, führt 'std::string hallo = "hallo";' eine vielzahl von schritten aus. man erkauft sich höhere flexibilität für speed und speicherverbrauch. klar, wenn der c++ programmierer von seinem c++ nur den C subset nutzen würde, wären beide gleich schnell. aber dann wäre C++ auch überflüssig.
    🙂

    Die Geschwindigkeitsunterschiede sind zwar messbar, aber heute mit Sicherheit nicht mehr fühlbar. 😉

    0
  • ?

    sri schrieb:

    fricky schrieb:

    die unterschiede sind zwar marginal, aber summieren sich auf. z.b. verwendet der c-coder gern char* mit zeichenketten. wer mit c++ rummacht, der nimmt lieber std::string. wo bei einem 'char *hallo = "hallo";' einfach eine adresse in den speicher geschrieben wird, führt 'std::string hallo = "hallo";' eine vielzahl von schritten aus. man erkauft sich höhere flexibilität für speed und speicherverbrauch. klar, wenn der c++ programmierer von seinem c++ nur den C subset nutzen würde, wären beide gleich schnell. aber dann wäre C++ auch überflüssig.
    🙂

    Die Geschwindigkeitsunterschiede sind zwar messbar, aber heute mit Sicherheit nicht mehr fühlbar. 😉

    Für dich vielleicht!!

    Ich spüre sogar den Unterschied zwischen mov eax,0 und test eax,eax!!!

    0
  • R

    fricky schrieb:

    camper schrieb:

    Es scheint aber, dass es einigen C-Fanatikern nicht in den Kopf geht, dass nicht jedes kleine Programm jedes einzelne Sprachfeature nutzen muss und diese überflüssige Nutzung ungeeigneter Sprachmittel natürlich der Performance nicht zuträglich sein wird. Da beide Sprachen (C und C++) grundsätzlich auf dem selben Maschinenmodell beruhen und für jedes Sprachmittel eine offensichtliche und effiziente (wenn auch nicht unbedingt optimale) Implementierung möglich ist, gibt es keinen Grund für fundamentale Unterschiede hinsichtlich Geschwindigkeit, Speicherverbrauch etc.

    die unterschiede sind zwar marginal, aber summieren sich auf. z.b. verwendet der c-coder gern char* mit zeichenketten. wer mit c++ rummacht, der nimmt lieber std::string. wo bei einem 'char *hallo = "hallo";' einfach eine adresse in den speicher geschrieben wird, führt 'std::string hallo = "hallo";' eine vielzahl von schritten aus. man erkauft sich höhere flexibilität für speed und speicherverbrauch.

    andererseits kannst du mit c++ dinge wie z.b. http://www.flipcode.com/archives/Faster_Vector_Math_Using_Templates.shtml machen die kaum in c zu machen sind, klar koennte man alle formeln auch per hand ausschreiben in c, aber dann waeren bibliotheken unnuetz. mit template math kann man hingegen dem compiler sehr helfen optimierten code zu schreiben.

    0
  • ?

    Asm-Hacker schrieb:

    Ich spüre sogar den Unterschied zwischen mov eax,0 und test eax,eax!!!

    troll

    0
  • D

    Das Assembler schneller ist als gut optimiertes C kann, muss aber nicht mehr sein.
    Ich hab mir einmal das Assembler Resultat von einem Programm-Stück angeschaut, der ein wenig langsam lief. Mitten in einer Schleife hab ich ein eigentlich völlig unnötiges

    xor eax, eax

    gefunden. Der Wert von EAX wurde danach eigentlich nicht mehr gebraucht, deshalb hab ich das mal gelöscht und neu assembliert. Resultat: Das ganze wurde langsamer.

    Ich nehme an, dass der Prozessor durch das eindeutige Löschen von EAX den Rest des Codes (der nicht vom Ergebnis davor abhängt) nebenher ausführen kann. Was die Prozessoren mit ihren MicroOps machen ist ja nicht mehr so ganz verständlich...

    0
  • R

    da hab ich die gegenteilige erfahrung gemacht 😉

    0
  • D

    C >> Java >> C++ :p

    0
  • A

    DEvent schrieb:

    C >> Java >> C++ :p

    Also dafür möchte ich nun wirklich einen Beweis (und zwar nicht so einen in der c't Art, die den Javacode relativ gut geschrieben hatten, den C++ Code aber so schlecht aufgebaut hatten, das man ebensogut einen geschobenen Düsenjäger mit einem gefahrenen Trabi hätte vergleichen können).

    cu André

    0
  • D

    asc schrieb:

    DEvent schrieb:

    C >> Java >> C++ :p

    Also dafür möchte ich nun wirklich einen Beweis (und zwar nicht so einen in der c't Art, die den Javacode relativ gut geschrieben hatten, den C++ Code aber so schlecht aufgebaut hatten, das man ebensogut einen geschobenen Düsenjäger mit einem gefahrenen Trabi hätte vergleichen können).

    cu André

    Ich habe eigentlich meine persoehnliche Favoriten aufgezaehlt 😃

    Ich denke das viele denken C++ seih die schnellste Sprache liegt einfach daran dass z.B. Spiele-Engines, Datenbaken, Server usw. in C++ geschrieben sind.

    Dabei kann man einen Server auch in Java schreiben, z.B. Tomcat, DNS Server, Mail Server, SMTP Server usw. In Java kann man auch Spiele schreiben, da eh 90% der Berechnungen in der GPU stattfindet.

    In C schreibe ich Programme die extrem viele Berechnungen machen, aber kein Speicherverwaltung oder Benutzereingaben haben/brauchen, oder Programme die Hardwareanbindung brauchen. Ebenso Bibliotheken, weil C der kleinste gemeinsame Nenner ist.

    In Java schreibe ich den Rest, komplexe Projekte, GUI, Server, Anwendungen mit Thread und Sockets.

    C++ ist fuer mich irgendwie obsolete geworten. Den Overhead fuer C++ will ich nicht mehr haben. Overhead ist z.B. Anwendungen portabel machen, die Include-Lib-Hoelle, das staendige neu kompelieren usw.

    0
  • ?

    DEvent schrieb:

    C++ ist fuer mich irgendwie obsolete geworten.

    👍

    0
  • A

    DEvent schrieb:

    Ich habe eigentlich meine persoehnliche Favoriten aufgezaehlt 😃

    Okay, unter den Umständen habe ich keine Probleme damit, dann sähe es bei mir auch anders aus: C# >> C++ >> Java >> C (Was aber nichts mit der Geschwindigkeit zu tun hat).

    DEvent schrieb:

    C++ ist fuer mich irgendwie obsolete geworten. Den Overhead fuer C++ will ich nicht mehr haben. Overhead ist z.B. Anwendungen portabel machen, die Include-Lib-Hoelle, das staendige neu kompelieren usw.

    Also ich habe mit C nicht mindere Probleme (Wobei ich dich durchaus verstehe, nachfolgendes ist meine Meinung). C++ gibt mir Konstrukte zur Vereinfachung, selbst wenn ich in Schnittstellen teilweise (je nach Portabilitätsanforderungen) auf C zurückgreifen muss.

    Und auch ein C-Programm muss man neu kompilieren (Wenn du auf die TMPL abziehlst wirst du das eh unter C nicht haben können, damit wäre der Vergleich obsolente; Und wenn man C++ entsprechend Programmiert sind die Compilezeiten auch nicht wirklich ein problem).

    Aber in Teilen kann ich es wirklich nachfühlen. Bis heute gibt es in C++ keine portablen Libs (wenn man wirklich mit C++ in den Schnittstellen arbeiten will), keine Standard-UI (Okay, auch nicht unter C)... Für mich hat sowohl C wie auch C++ den Zahn der Zeit verschlafen, man hätte vieles im nächsten C++ Standard nachholen können, aber der ist mir noch nicht weitreichend genug.

    Dennoch muss ich gestehen das ich bei privaten Projektideen nach geraumer Zeit wieder zu C++ zurückkehre...

    cu André

    0
  • R

    DEvent schrieb:

    Ich denke das viele denken C++ seih die schnellste Sprache liegt einfach daran dass z.B. Spiele-Engines, Datenbaken, Server usw. in C++ geschrieben sind.

    du scheinbar auch:

    In Java kann man auch Spiele schreiben, da eh 90% der Berechnungen in der GPU stattfindet.

    sonst wuerdest du ja nicht im gleichen atemzug behaupten dass man es auch in java coden kann da man nicht cpu limitiert ist.

    btw. ist deine verallgemeinerung allgemein falsch 😛

    0
  • D

    asc schrieb:

    Also ich habe mit C nicht mindere Probleme (Wobei ich dich durchaus verstehe, nachfolgendes ist meine Meinung). C++ gibt mir Konstrukte zur Vereinfachung, selbst wenn ich in Schnittstellen teilweise (je nach Portabilitätsanforderungen) auf C zurückgreifen muss.

    Ich vermisse nichts in C++ was ich nicht in C haben kann. Templates, Klassen und Operatorueberladung brauche ich nicht. OOP kann ich genauso gut in C machen und man hat den Vorteil das man C Code viel einfacher in andere Sprachen einbinden kann.

    0
  • ?

    hi wer code mit mmorpg die quellzeilen bitte!!!!!!!!!!!
    ich will es verkaufen du kriegst 1% ab also gib mmo
    beeil dich

    0
  • M

    Hi,

    was ich immer noch nicht so ganz verstehen kann, ist das herumreiten auf Portabilität. Sicher, für manchen ist es wichtig, aber ich behaupte mal, daß 95% aller Programmierer nur für eine Umgebung coden. Wer macht denn wirklich regelmäßig Programme, die sowohl unter Win als auch unter Linux, Unix und Mac laufen müssen.
    Und was die Bandbreite von Win 3.1 bis Win Vista betrifft, wers braucht... Für die meisten Programme die heute noch entwickelt werden reicht es doch völlig aus, wenn die ab XP oder meinetwegen ab Win 2000 laufen. Auch die Frage welcher Prozessor ist in vielen Fällen nicht bolle, weil das langsamste Glied der Kette meist 30 cm vor dem Rechner sitzt.
    So schön komplett portable Programme sein mögen, aber Portabilität heißt unweigerlich IMMER auch eine Einigung auf den KLEINSTEN Nenner. Ob das immer im Interesse des Kunden ist???
    In vielen fällen sitzt doch da nachher ein Nutzer vor dem Rechner, für den ein Computer ein Kasten mit vielen Knöpfen ist. Dem geht Portablität oder das letzte Ausreizen der Geschwindigkeit so was am Kreuz vorbei... der will einfach daß jedes neue Programm genau so aussieht, wie die die er bisher von Windows kennt damit er sich zurechtfindet und sich nicht neu einarbeiten muß...

    Gruß Mümmel

    0
  • B

    muemmel schrieb:

    So schön komplett portable Programme sein mögen, aber Portabilität heißt unweigerlich IMMER auch eine Einigung auf den KLEINSTEN Nenner. Ob das immer im Interesse des Kunden ist???

    Das sehe ich absolut nicht ein - in C oder C++ vielleicht (auch nicht, wenn du dir einfach angewoehnst multiplattform-Frameworks zu verwenden). Aber wenn du in Java oder Python entwickelst, ist das Ganze kein Thema. Und ich reduziere meine Moeglichkeiten dabei mitnichten auf den kleinsten Nenner, da das unterliegende Framework in der Regel Features, die auf einer Plattform nicht vorhanden sind, mit eigenen Mitteln implementiert. Da ist Portabilitaet kein Thema, sie ist impliziert.

    0
Anmelden zum Antworten