Warum ist C so schnell?
-
Hallo,
ich hätte eine Frage:
Warum ist die Programmiersprache C so schnell?
MfG
Gimly
-
Hallo
Was soll denn diese Frage?
chrische
-
Gimly schrieb:
Warum ist die Programmiersprache C so schnell?
meinst du die executables oder den compilevorgang?
die ausführbahren datein sind schnell, weil C programme direkt in maschinencode übersetzt werden.
das compilieren geht schnell, weil C relativ einfach zu parsen ist.
-
Weil der Code i.d.R. direkt in Maschinensprache umgesetzt wird, d.h. ohne Umwege von der CPU ausgeführt wird.
-
vista schrieb:
das compilieren geht schnell, weil C relativ einfach zu parsen ist
Nein, weil Computer heutzutage sehr schnell sind. C ist sehr schwer zu parsen. C++ ist pervers schwer zu parsen, das ist kein Vergleich
-
Vielen Dank für eure Antworten
MfG
Gimly
-
Dieser Thread wurde von Moderator/in AJ aus dem Forum ANSI C in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Weil C nur eun besserer Makroassembler ist. Und Assembler ist schnell.
-
mit luft in der hand schrieb:
Weil C nur eun besserer Makroassembler ist.
ein _besserer_?
Und Assembler ist schnell.
Nö
-
mit luft in der hand schrieb:
Weil C nur eun besserer Makroassembler ist. Und Assembler ist schnell.
c wurde wirklich miunter so designed, dass es relativ gut auf maschinencode uebersetzt werden kann, quasi ein highlevel assembler. deswegen gibt es soviele cpu spezifische dinge die andere sprachen nicht bieten. (simples beispiel ist unsigned int). ein weiterer grund war, dass man frueher keine monster cpus und megaviel ram hatte die unmengen von optimierungen vom compiler erlaubt haetten, was auch ein grund dafuer ist, dass compiler + linker erstellt gemacht wurde, statt alles auf einmal zu generieren.c++ ist schonwieder ne andere geschichte
-
rapso schrieb:
c++ ist schonwieder ne andere geschichte
nicht wirklich.
dem makroassembler wurden nur einfach ein paar makros mehr spendiert.
-
vista schrieb:
rapso schrieb:
c++ ist schonwieder ne andere geschichte
nicht wirklich.
dem makroassembler wurden nur einfach ein paar makros mehr spendiert.
doch wirklich! ausfuehrungsgeschwindigkeit und sehr direktes mappen auf maschinensprache war nicht mehr zielrichtung, denn das hatte man ja mit c schon. viele dinge wurden so aufgebaut, dass es "sehr viel potential" fuer optimierungen gab fuer die compilerhersteller.
-
@rapso: Sehe ich genauso!
C ist ziemlich einfach auf Assembler und somit auch auf Maschinencode abzubilden. Es gibt so gute wie keine Abstraktionsmechanismen. Dadurch ist C sehr schnell und schlank. Bei C++ ist das so eine Sache. Die Abstraktionsmittel die man verwendet erhöhen die Produktivität und können je nach Compiler und verwendeter Standardlib durchaus langsameren Maschinencode als ein äquivalentes C Programm liefern. Templates und komplexe Klassenhierarchien mit Polymorphie sind halt viel schwieriger auf Assembler abzubilden, als einfache Funktionen und Variablen.
-
/. schrieb:
Templates und komplexe Klassenhierarchien mit Polymorphie sind halt viel schwieriger auf Assembler abzubilden, als einfache Funktionen und Variablen.
Aber einfacher als du denkst. Templates sowieso, die sind schwer zu parsen, aber nach der Instanziierung unterscheiden sie sich nicht mehr wirklich von normalem Code und können dann straight-forward auf Maschinencode abgebildet werden. Virtuelle Funktionen sind auch kein Problem, das ist nicht viel mehr als sowas wie (obj->vtable[2])() in C.
Ich schätze Exceptions sind am schwierigsten umzusetzen.
-
Bashar schrieb:
Ich schätze Exceptions sind am schwierigsten umzusetzen.
vielleicht benutzen die intern setjmp/longjmp?
richtige exceptions wie 'division durch 0' o.ä. sind aber bestimmt nicht einfach abzufangen...
-
Bashar schrieb:
/. schrieb:
Templates und komplexe Klassenhierarchien mit Polymorphie sind halt viel schwieriger auf Assembler abzubilden, als einfache Funktionen und Variablen.
Aber einfacher als du denkst. Templates sowieso, die sind schwer zu parsen, aber nach der Instanziierung unterscheiden sie sich nicht mehr wirklich von normalem Code und können dann straight-forward auf Maschinencode abgebildet werden. Virtuelle Funktionen sind auch kein Problem, das ist nicht viel mehr als sowas wie (obj->vtable[2])() in C.
Ich schätze Exceptions sind am schwierigsten umzusetzen.es geht ja nicht nur um den aufwand der umsetzung, sondern wie das performancemaessig dann ausschaut. ich denke gerade die ersten compiler haben alles erstmal nur funktional gemacht und nicht nach geschwindigkeit optimiert. quasi so wie es mit c war, nur war es bei c dann schon relativ optimal, weil direkt auf microcode gemappt.
und auch wenn es dann einigermassen optimiert wurde, hat man oft kein direktes mapping auf den microcode. vtables sind z.b. fuer viele cpus der tod, sie werden wie falsch vorhergesagte spruenge behandelt und stallen die ganze pipeline. sind aber eines der grundkonzepte fuer polymorphismus. bei c hatte man jumptables nur explizit benutzt und nur an stellen die wirklich dann performance bekommen.
-
vista schrieb:
Bashar schrieb:
Ich schätze Exceptions sind am schwierigsten umzusetzen.
vielleicht benutzen die intern setjmp/longjmp?
die implementation davon ist nicht sonderlich einfach wegen den ganzen dingen die dabei beruecksichtig werden muessen wie z.b. destructoren von local variablen aufrufen usw.
richtige exceptions wie 'division durch 0' o.ä. sind aber bestimmt nicht einfach abzufangen...
doch sind sie, das macht die cpu fuer dich indem sie einen interrupt aufruft.
-
rapso schrieb:
richtige exceptions wie 'division durch 0' o.ä. sind aber bestimmt nicht einfach abzufangen...
doch sind sie, das macht die cpu fuer dich indem sie einen interrupt aufruft.
ja, aber dann bekommt man eine fehlermeldung vom OS und das programm steigt aus.
kann man sowas überhaupt mit einem C++ 'catch' fangen? wenn überhaupt, ist es doch bestimmt systemabhängig...
-
vista schrieb:
rapso schrieb:
richtige exceptions wie 'division durch 0' o.ä. sind aber bestimmt nicht einfach abzufangen...
doch sind sie, das macht die cpu fuer dich indem sie einen interrupt aufruft.
ja, aber dann bekommt man eine fehlermeldung vom OS und das programm steigt aus....
Eben genau das, was eben passiert ....
Sowas wird ebensowenig standardmäßig mit exception abgefangen wie seg-faults...Gruß,
Simon2.
-
vista schrieb:
Bashar schrieb:
Ich schätze Exceptions sind am schwierigsten umzusetzen.
vielleicht benutzen die intern setjmp/longjmp?
Ne, du musst ja noch den Stack aufrollen (also im C++-Sinne mit Destruktoren)
richtige exceptions wie 'division durch 0' o.ä. sind aber bestimmt nicht einfach abzufangen...
Das ist ja auch keine Exception im C++-Sinne. Wobei man hier auch noch 'division durch 0.0' unterscheiden muss