3. Warum ist C so schnell?

Warum ist C so schnell?

  • R

    DEvent schrieb:

    Sagtmal, was eigentlich diskutiert ihr da überhaupt? Ob die Sprache C schnell ist? - Hallo?

    hallo? must du hier nen ewiglangen text schreiben um zu zeigen wie wenig ahnung du davon hast nur um zu flamen?

    Genauso könnte man einen C-Compiler bauen der ...

    geht hier aber nicht um compilerbauen, sondern um das konzept der sprache c.

    Wäre C seit Heute die neuste Neuheit auf dem PC, dann würdet ihr eher diskutieren wieso C so unglaublich lahm ist, das Pascal-Programme dagegen wie Überschallflieger aussehen.

    es gibt neue c implementationen die fuer neue hardware gemacht wurde z.b. hlsl/cg/cuda fuer gpus und wie damals erzeugt c relativ guten code. keiner beschwert sich dass es lahm ist, im gegenteil, es ist wieder eine gute alternative zu assembler. das konzept von c ist wiedermal erfolgreich womit deine aussage ist widerlegt. q.e.d.

    Weil der Code i.d.R. direkt in Maschinensprache umgesetzt wird, d.h. ohne Umwege von der CPU ausgeführt wird.

    Das kann man mit jeder X-beliebigen Sprache auch machen, man muss nur einen Compiler schreiben der das macht.

    andere sprachen wurden aber nicht mit dem ziel entwickelt leicht effizienten microcode zu generieren.

    0

  • Gimly schrieb:

    Warum ist die Programmiersprache C so schnell?

    Wiedermal eine der dümmsten Fragen von überhaupt.

    C ist so schnell weil es indirekt von BCPL abstammt. Durch das Entfernen von 3 Buchstaben konnte einiges an Gewicht eingespart werden, und C hat einfach den besseren CW Wert, z.B. auch verglichen mit B.
    Daher ist C so schnell.

    0
  • K

    Ein paar interessante Links:

    www.google.de c warum schnell

    http://scienceblogs.com/goodmath/2006/11/the_c_is_efficient_language_fa.php

    * C: 0.8 seconds.
    * C++: 2.3 seconds.
    * OCaml: 0.6 seconds interpreted, 0.3 seconds fully compiled.
    * Java: 1 minute 20 seconds.
    * Python: over 5 minutes.

    0
  • ?

    Bei nicht-imperativen Sprachen gibt es sogar überhaupt keine direkte Übersetzung.

    Diese Behauptung ist aber nicht ganz richtig.
    Letztendlich könnte jede Hochsprache direkt in Assembler oder besser gleich in Maschinencode compiliert werden.
    Es muss sich nur jemand finden, der einen Compiler dafür schreibt, der anstatt in z.B. irgendwelchen ByteCode direkt Maschinencode erzeugt.
    Wie die Performance dieser Sprache dann auch immer aussehen mag.

    0
  • M

    Hi,

    lange Zweit war bei mathematischen Anwendungen FORTRAN die schnellste Sprache.
    Erkauft wurde es damit, daß man dem Rechner nicht zu viel Arbeit aufbürdete.
    Es gab keine Rekursion, Parameter wurden nicht kopiert und alles so weit als möglich auch bei Unterprogrammaufrufen in Registern gehalten. Felder auf 7 Dimensionen beschränkt...War auf den damaligen Rechnern das Optimum.
    Wie hat maein alter Fortran-Lehrer mal gesagt: "die Kunst besteht im weglassen".

    Gruß Mümmel

    0
  • ?

    keksekekse schrieb:

    Ein paar interessante Links:

    www.google.de c warum schnell

    http://scienceblogs.com/goodmath/2006/11/the_c_is_efficient_language_fa.php

    * C: 0.8 seconds.
    * C++: 2.3 seconds.
    * OCaml: 0.6 seconds interpreted, 0.3 seconds fully compiled.
    * Java: 1 minute 20 seconds.
    * Python: over 5 minutes.

    Hast du den Artikel auch ganz gelesen? Letztendlich kommt dann heraus, dass aktueller JIT-Compiler für Java auch eine Laufzeit von 0.7 Sekunden "herausoptimieren" konnten (plus dem zusätzlichem Startup der etwa 1 Sekunde dauert).

    0
  • A

    keksekekse schrieb:

    Ein paar interessante Links:

    www.google.de c warum schnell

    http://scienceblogs.com/goodmath/2006/11/the_c_is_efficient_language_fa.php

    * C: 0.8 seconds.
    * C++: 2.3 seconds.
    * OCaml: 0.6 seconds interpreted, 0.3 seconds fully compiled.
    * Java: 1 minute 20 seconds.
    * Python: over 5 minutes.

    Völlig irrelevant, weil der Test so ca. im Jahr 2000 stattfand.

    foobar schrieb:

    Hast du den Artikel auch ganz gelesen? Letztendlich kommt dann heraus, dass aktueller JIT-Compiler für Java auch eine Laufzeit von 0.7 Sekunden "herausoptimieren" konnten (plus dem zusätzlichem Startup der etwa 1 Sekunde dauert).

    Hem, der JIT ist besser geworden, zum Glück. Aber was ist wenn ich einen heutigen C++-Compiler nehme und alles auf optimum stelle? Siehste!

    Hier mal der Kommentar von dem Typen, der den Vergleichstest machte:

    Mark Chu-Carroll schrieb:

    I can't give you the code I did the LCS tests on - as I said, it was six years ago!

    Yo, der Kommantar ist von 2006 minus 6 Jahre... 2000 wurde der Vergleich gemacht. Ist in der heutigen Zeit natürlich voll relevant. Egal ob für C, C++, Python oder Java. Alle haben heute einen anderen (besseren) Stand.

    0
  • ?

    Warum ist OCaml so schnell?

    0
  • ?

    Artchi schrieb:

    keksekekse schrieb:

    Ein paar interessante Links:

    www.google.de c warum schnell

    http://scienceblogs.com/goodmath/2006/11/the_c_is_efficient_language_fa.php

    * C: 0.8 seconds.
    * C++: 2.3 seconds.
    * OCaml: 0.6 seconds interpreted, 0.3 seconds fully compiled.
    * Java: 1 minute 20 seconds.
    * Python: over 5 minutes.

    Völlig irrelevant, weil der Test so ca. im Jahr 2000 stattfand.

    foobar schrieb:

    Hast du den Artikel auch ganz gelesen? Letztendlich kommt dann heraus, dass aktueller JIT-Compiler für Java auch eine Laufzeit von 0.7 Sekunden "herausoptimieren" konnten (plus dem zusätzlichem Startup der etwa 1 Sekunde dauert).

    Hem, der JIT ist besser geworden, zum Glück. Aber was ist wenn ich einen heutigen C++-Compiler nehme und alles auf optimum stelle? Siehste!

    Hier mal der Kommentar von dem Typen, der den Vergleichstest machte:

    Mark Chu-Carroll schrieb:

    I can't give you the code I did the LCS tests on - as I said, it was six years ago!

    Yo, der Kommantar ist von 2006 minus 6 Jahre... 2000 wurde der Vergleich gemacht. Ist in der heutigen Zeit natürlich voll relevant. Egal ob für C, C++, Python oder Java. Alle haben heute einen anderen (besseren) Stand.

    Der JIT war aber auch schon Stand 2000 so gut, dass man auf eine Laufzeit von 0.7 Sekunden gekommen ist. Insofern ist das völlig irrelevant, wie viel sich seither getan hat. Fakt ist halt nunmal, dass C/C++ in gewissen Bereichen nicht so optimieren kann, wie Java, OCaml, ..

    0
  • ?

    foobar`` schrieb:

    Fakt ist halt nunmal, dass C/C++ in gewissen Bereichen nicht so optimieren kann, wie Java, OCaml, ..

    Warum?

    0
  • T

    java und ocaml zwingen den programmierer in wesentlich striktere regularien. dadurch kann der compiler einfacher annahmen treffen und den code entsprechend optimieren.

    ginge in c++ sicherlich auch, aber irgendwann ist auch mal schluss bei der komplexität eines parsers.

    wäre bei benchmark vergleichen aber eh immer sehr sehr vorsichtig. code, der in einer sprache wahnsinnig performant ist, kann in einer anderen sprache plötzlich unglaublich ineffizient werden. wenn man wirklich vergleichen will, müsste man einen bestimmten algorithmus jeweils von absoluten spezialisten in ihren lieblingssprachen implementieren lassen. das ist aber sehr selten der fall.

    0
  • S

    Hydrogen_Snake schrieb:

    foobar`` schrieb:

    Fakt ist halt nunmal, dass C/C++ in gewissen Bereichen nicht so optimieren kann, wie Java, OCaml, ..

    Warum?

    Simpelstes Beispiel:

    f(a(),b(),c())

    In C++ ist das erstmal nicht parallelisierbar. In vielen funktionalen Sprachen aber, ist es problemlos parallelisierbar und wenn du zufaelligerweise 3 CPUCores hast, kann jede Funktion auf einem eigenen Core laufen.

    Generell gilt: desto mehr restriktionen die Sprache einem aufzwingt, desto staerker ist es optimierbar. Restriktionen sind nicht gleichbedeutend mit beschneiden von features - denn zB Lisp bietet sicher nicht wenig features an - man kann ja sogar seine eigenen sprachfeatures implementieren - aber dadurch das zB verboten wird, dass objekte state haben koennen, ermoeglicht man unmengen an optimierungen.

    Komplette virtuelle Maschinen wie Java und .NET erlauben dann auch wieder komplett andere Optimierungsansaetze da der Code erst kompiliert werden muss wenn er ausgefuehrt wird - das simpelste hier ist zB Profile Guided Optimization - etwas das in C++ nur mit grossem Aufwand (sprich viel Zeit) realisierbar und vorallem nur fuer vordefinierte Testfaelle machbar ist, bekommt man durch die virtuelle Maschine gratis.

    Das sind nur 2 Aspekte von vielen (wobei alles natuerlich seinen Vorteil und seinen Nachteil hat).

    PS:
    solche Benchmarks sind aber in den meisten Faellen Schrott.

    0
  • B

    Shade Of Mine schrieb:

    Generell gilt: desto mehr restriktionen die Sprache einem aufzwingt, desto staerker ist es optimierbar. Restriktionen sind nicht gleichbedeutend mit beschneiden von features - denn zB Lisp bietet sicher nicht wenig features an - man kann ja sogar seine eigenen sprachfeatures implementieren - aber dadurch das zB verboten wird, dass objekte state haben koennen, ermoeglicht man unmengen an optimierungen.

    Es ist in Lisp nicht verboten, dass Objekte State haben.

    0
  • S

    Bashar schrieb:

    Es ist in Lisp nicht verboten, dass Objekte State haben.

    Damn 😕
    Ich hab gewusst dass ich lieber nichts ueber lisp sagen sollte :p

    Im Prinzip wollte ich damit lediglich das fehlen von seiteneffekten in vielen Funktionalen Sprachen (wie zB Erlang, F#, Haskell,...) beschreiben - von Lisp habe ich leider zuwenig Ahnung und huete mich da wieder vermutungen daruber anzustellen.

    0
  • F

    Shade Of Mine schrieb:

    f(a(),b(),c())

    In C++ ist das erstmal nicht parallelisierbar.

    Warum nicht? a(), b() und c() können doch wohl parallel berechnet werden. Nur f() muss warten.

    0
  • ?

    funky cat schrieb:

    Shade Of Mine schrieb:

    f(a(),b(),c())

    In C++ ist das erstmal nicht parallelisierbar.

    Warum nicht? a(), b() und c() können doch wohl parallel berechnet werden. Nur f() muss warten.

    a(), b() und c() könnten globale Variable lesen/schreiben.

    0
  • F

    Vermutung schrieb:

    a(), b() und c() könnten globale Variable lesen/schreiben.

    Hast Recht. Hmmm.. fürs parallelisieren gibts in C++ ja OpenMP

    0
  • ?

    funky cat schrieb:

    Vermutung schrieb:

    a(), b() und c() könnten globale Variable lesen/schreiben.

    Hast Recht. Hmmm.. fürs parallelisieren gibts in C++ ja OpenMP

    Könnte man nicht dem Compiler sagen, dass das Programm keine globalen Variablen hat? Dann könnte man doch parallelisieren?

    0
  • F

    Gegenfrage schrieb:

    funky cat schrieb:

    Vermutung schrieb:

    a(), b() und c() könnten globale Variable lesen/schreiben.

    Hast Recht. Hmmm.. fürs parallelisieren gibts in C++ ja OpenMP

    Könnte man nicht dem Compiler sagen, dass das Programm keine globalen Variablen hat? Dann könnte man doch parallelisieren?

    Ne, In C++ ist alles erlaubt, was kein Syntax Error ist. Demzufolge kann ein Compiler nicht zu viel Intelligenz des Programmierers voraussetzen. Man könnte vielleicht einen super-optimierenden Compiler entwickeln, der erstmal 3 Stunden den Code analysiert. In C gibt es neuerdings das "restrict" Schlüsselwort. Damit wird ein ähnlicher Ansatz verfolgt, aber letztendlich muß der Programmierer immer mitspielen. Wenn der Scheiße baut, kann der beste Compiler nichts reißen.

    0
  • R

    Das ist halt oft das problem bei den benchmarks. Viele sprachen haben ihre restriktionen und machen dann, egal wie ahnungslos der programmierer ist, ihre optimierungen. Bei c/c++ haengt sehr viel optimierung von dem programmierer ab. du kannst alles richtig oder alles falsch machen. machst du alles richtig, gibt es keinen grund weshalb ein c/c++ compiler nicht das schnellste executable generiert. machst du etwas falsch, bist du 100mal langsammer als scriptsprachen.

    Entsprechend sind solche benchmarks oft nur die aussage darueber wie gut jemand programmiert.

    0
Anmelden zum Antworten