3. Warum ist C so schnell?

Warum ist C so schnell?

  • ?

    rüdiger schrieb:

    Was ich meinte: Assembler ist nicht per Definition schnell. Das wird imho immer falsch vermittelt. Heutige CPUs sind derart komplex, dass die Compiler dort deutliche Vorteile gewinnen. Um effiziente Programme in Assembler zu schreiben, muss man schon ein ziemlich guter Assembler Programmierer sein und die Details der CPU sehr gut kennen.

    Ja ich weiß, aber das ist genauso wie zu behaupten C ist nicht schnell, weil die meisten Programmierer zu dumm sind es richtig einzusetzen.

    0
  • R

    mit luft in der hand schrieb:

    rüdiger schrieb:

    Was ich meinte: Assembler ist nicht per Definition schnell. Das wird imho immer falsch vermittelt. Heutige CPUs sind derart komplex, dass die Compiler dort deutliche Vorteile gewinnen. Um effiziente Programme in Assembler zu schreiben, muss man schon ein ziemlich guter Assembler Programmierer sein und die Details der CPU sehr gut kennen.

    Ja ich weiß, aber das ist genauso wie zu behaupten C ist nicht schnell, weil die meisten Programmierer zu dumm sind es richtig einzusetzen.

    nö

    0
  • ?

    rüdiger schrieb:

    mit luft in der hand schrieb:

    rüdiger schrieb:

    Was ich meinte: Assembler ist nicht per Definition schnell. Das wird imho immer falsch vermittelt. Heutige CPUs sind derart komplex, dass die Compiler dort deutliche Vorteile gewinnen. Um effiziente Programme in Assembler zu schreiben, muss man schon ein ziemlich guter Assembler Programmierer sein und die Details der CPU sehr gut kennen.

    Ja ich weiß, aber das ist genauso wie zu behaupten C ist nicht schnell, weil die meisten Programmierer zu dumm sind es richtig einzusetzen.

    nö

    doch

    0
  • R

    C ist auch nicht per Definition schnell.

    (Und bei Assembler dürfte die Situation ja eher so sein, dass die meisten Leute schlechter sind als ein guter Compiler (ok vielleicht x86 ausgenommen, weil das so wenig Register hat, das man da mit ner manuellen Register-Verwaltung noch etwas rausholen kann))

    0
  • D

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

    Wenn ihr diskutieren würdet wieso der GCC Compiler so guten Code erzeugt, oder wieso der Intel-C-Compiler ein so schlechten Code erzeugt, das würde ich ja noch verstehen.

    Genauso könnte man einen C-Compiler bauen der so lahmen Code erzeugt, dass interpretiertes BASIC wie Assembler aussieht. Aber stattdessen wird hier diskutiert das C besser ist als Assembler weil das per definition schneller ist und einfacher zu parsen von einem Compiler wäre. Wenn ich Zeit hätte würde ich einen ASM-Interpreter schreiben, dann würdet ihr darüber diskutieren wieso die ASM-Sprache so lahm wäre...

    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.

    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.

    C ist auch nicht per Definition schnell.

    Echt nicht? Ich dachte bei der Sprache C kann jeder Compiler eine Kristallkugel befragen, so das dieser den Code für 100 Jahre im vorraus und für jede Eventualität vorherberechnen kann. Gibt es in C das Schlüsselwort magic nicht? Meine Sprache hat das. 🤡

    0
  • B

    DEvent schrieb:

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

    Ebenfalls Hallo! Deine Belehrungen in Ehren, aber bitte stell dich nicht um der Klugscheisserei willen duemmer als du bist. Dass es hier um die Implementierungen von C geht und darum, warum gaengige C-Compiler derart schnellen und effizienten Code liefern, liegt ja wohl auf der Hand 😉

    EDIT: wobei ich doch sehr wohl glaube dass die Sprache C einige Merkmale hat, die es einfacher machen, den Code auf Geschwindigkeit zu optimieren, waehrend man bei anderen Sprachen bewusst auf gewisse Moeglichkeiten verzichtet hat, um die Sprache einfacher zu machen.

    0
  • B

    DEvent schrieb:

    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.

    Manche Sprachen eignen sich aber nur bedingt dazu, von Compilern direkt in effizienten Maschinencode überführt zu werden. Bei nicht-imperativen Sprachen gibt es sogar überhaupt keine direkte Übersetzung.
    Was nicht heißt, dass sie nicht effizient übersetzt werden können, aber die Gründe liegen dann nicht -- wie bei C -- in der Direktheit, sondern darin, dass die Semantik so abstrakt ist, dass die Compiler gut optimieren können und Code dann effizinten Code erzeugen, der aber mit dem Quellprogramm nicht mehr viel gemeinsam hat.

    0
  • V

    es gibt z.b. prozessoren, die keinen stack, keine call/ret instructions, dafür aber übelst viele register haben. weil c-programmierer unheimlich gerne funktionen, lokale variablen und manchmal rekursion verwenden, ist so eine CPU schon eine kleine herausforderung für compilermacher...
    🙂

    0
  • R

    vista schrieb:

    es gibt z.b. prozessoren, die keinen stack, keine call/ret instructions, dafür aber übelst viele register haben. weil c-programmierer unheimlich gerne funktionen, lokale variablen und manchmal rekursion verwenden, ist so eine CPU schon eine kleine herausforderung für compilermacher...
    🙂

    nein, soeine cpu ist ein segen fuer einen kompilermacher. es gibt nur die resource "register" die ist dann 16 oder 32 oder 128mal vorhanden und darauf wird optimiert. bei alten CISC cpus gibt es hingegen bestimmte operationen die nur auf bestimmten registern funktionieren, einen algorithmus zu schreiben der darauf optimieren wuerde waere um einiges anstrengender was mit ein grund dafuer ist, dass damals jeder halbbegabte assembler-programmierer schnelleren code schreiben konnte als die c-compiler generierten, trotz der absicht c leicht auf cpus map"bar" zu machen.

    0
  • 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
Anmelden zum Antworten