OOP vs PP compile size
-
Noch ein Nachtrag: Schnell und klein schließt sich häufig gegenseitig aus.
Entweder man optimiert auf Größe oder auf Geschwindigkeit.
-
Le Fox schrieb:
wollte mal wissen wie groß der unterschied zwischen in PP geschriebenen Programmen und in OOP geschriebenen Programmen in Hinsicht auf die Größe der compilierten Datei ist.
Sofern man die unterschiedlichen Bibliotheksgrößen herausrechnet eher gering. Wobei man in C++ die Programmgröße durch Templates wohl aufblähen kann (Anderseits bekommt man dafür Typsicherheit).
Le Fox schrieb:
Ich möchte gerne ein Programm schreiben was möglichst klein und schnell ist,...
Klein sollte nicht mit schnell gleichgesetzt werden. Ein größere exe kann schneller als eine Kleine sein. Compiler bieten in der Regel auch die Option an ob man entweder auf Größe oder auf Geschwindigkeit Optimieren lässt.
-
asc schrieb:
Wobei man in C++ die Programmgröße durch Templates wohl aufblähen kann (Anderseits bekommt man dafür Typsicherheit).
Davon merkt man was nach dem Kompilieren? oO
-
cooky451 schrieb:
asc schrieb:
Wobei man in C++ die Programmgröße durch Templates wohl aufblähen kann (Anderseits bekommt man dafür Typsicherheit).
Davon merkt man was nach dem Kompilieren? oO
Ich weiß nicht wie weit inzwischen Codeoptimierungen (falls hier überhaupt möglich) sind, aber grundsätzlich würde ich davon ausgehen das ein Template das mit verschiedenen Typen instanziert wird, auch entsprechend viel Maschinencode erzeugt.
Oder beziehst du dich auf die Typsicherheit? Mir sind Compilerfehler per se lieber als Laufzeitfehler.
-
Ja, wenn man ungeschickt ist, kann man mit templates seinen Code durchaus ganz schön aufblähen. Aber wenn man geschickt ist, muss das nicht unbedingt der Fall sein. Abgesehen davon, sind Linker heutzutage in der Lage, zumindest Funktionen, die den selben Maschinencode generieren, zusammenzufassen...
-
c++ kompiliert einfach total langsam :p
-
Meine Erfahrung: C++ Bibliotheken/Programme sind um ein Vielfaches groesser als reines C.
-
kellerassel schrieb:
c++ kompiliert einfach total langsam :p
Mag sein, ich kann aber mit Compilezeiten von 1-2 Minuten (nach Clean) für unser Projekt leben. Außerhalb der VM wäre es bei etwa 30 Sekunden. Größenordnung etwa etwas unter einer halben Million Codezeilen, verhältnismäßig wenige C++ Templates (Von etwas STL-Einsatz einmal abgesehen).
-
cooky451 schrieb:
asc schrieb:
Wobei man in C++ die Programmgröße durch Templates wohl aufblähen kann (Anderseits bekommt man dafür Typsicherheit).
Davon merkt man was nach dem Kompilieren? oO
Ja. Dafür ist es aber eventuell schneller, weil für jeden Typen eine optimierte Version erzeugt werden kann. Die void*-Technik in C stellt hingegen eine praktisch unüberwindliche Optimierungshürde dar, auch wenn dadurch natürlich die erzeugten Funktionen nur einmal erzeugt werden müssen.
Typisches Beispiel, welches oft heran gezogen wird: sort vs. qsort. C++ braucht länger zum compilieren und wird größeren Code erzeugen, falls mehrere Datentypen/Vergleichskriterien benutzt werden. Aber das Resultat ist i.d.R. viel schneller, wenn die Vergleichsfunktion billig ist, da der Compiler sie trivial inlinen kann, bei qsort hingegen steht immer ein fetter Funktionsaufruf.
-
@Le Fox
Ein Programm ist sowohl in C als auch in C++ ziemlich genau so gross und so schnell wie du es machst.In C++ ist es bloss viel einfacher unabsichtlich etwas zu machen was dazu führt dass das Programm viel grösser oder etwas langsamer wird als es sein müsste.
Dafür ist C++ halt auch die wesentlich angenehmere Sprache.
-
SeppJ schrieb:
Typisches Beispiel, welches oft heran gezogen wird: sort vs. qsort. C++ braucht länger zum compilieren und wird größeren Code erzeugen, falls mehrere Datentypen/Vergleichskriterien benutzt werden. Aber das Resultat ist i.d.R. viel schneller, wenn die Vergleichsfunktion billig ist, da der Compiler sie trivial inlinen kann, bei qsort hingegen steht immer ein fetter Funktionsaufruf.
ist schon richtig, aber ein schlauer compiler könnte qsort und konsorten bzw. die vergleichsfunktion auch inlinen, sehe da eig. kein problem. zumindest wenn der code als src vorliegt. warum das nicht gemacht wird, ist mir sowieso schleierhaft
das würde einen großteil der c vs c++ benchmarks umwerfen
-
kellerassel schrieb:
warum das nicht gemacht wird, ist mir sowieso schleierhaft
btw. der richtige c progger braucht das eh nicht, der behilft sich einfach mit einem #define qsort :p
-
kellerassel schrieb:
SeppJ schrieb:
Typisches Beispiel, welches oft heran gezogen wird: sort vs. qsort. C++ braucht länger zum compilieren und wird größeren Code erzeugen, falls mehrere Datentypen/Vergleichskriterien benutzt werden. Aber das Resultat ist i.d.R. viel schneller, wenn die Vergleichsfunktion billig ist, da der Compiler sie trivial inlinen kann, bei qsort hingegen steht immer ein fetter Funktionsaufruf.
ist schon richtig, aber ein schlauer compiler könnte qsort und konsorten bzw. die vergleichsfunktion auch inlinen, sehe da eig. kein problem.
Wie genau soll ein Compiler das deiner Meinung nach anstellen? Ich kenn zumindest keinen, der das tut...
kellerassel schrieb:
das würde einen großteil der c vs c++ benchmarks umwerfen
Was für Benchmarks meinst du genau? Ich kenn nur die, wo C++ bei solchen Dingen 2x+ schneller ist als C, wie man es logischerweise erwarten würde; da ist imo also alles in Ordnung...
-
dot schrieb:
kellerassel schrieb:
SeppJ schrieb:
Typisches Beispiel, welches oft heran gezogen wird: sort vs. qsort. C++ braucht länger zum compilieren und wird größeren Code erzeugen, falls mehrere Datentypen/Vergleichskriterien benutzt werden. Aber das Resultat ist i.d.R. viel schneller, wenn die Vergleichsfunktion billig ist, da der Compiler sie trivial inlinen kann, bei qsort hingegen steht immer ein fetter Funktionsaufruf.
ist schon richtig, aber ein schlauer compiler könnte qsort und konsorten bzw. die vergleichsfunktion auch inlinen, sehe da eig. kein problem.
Wie genau soll ein Compiler das deiner Meinung nach anstellen? Ich kenn zumindest keinen, der das tut...
ich auch nicht, aber hab ja schon geschieben, dass ich das feature nicht brauch
dot schrieb:
kellerassel schrieb:
das würde einen großteil der c vs c++ benchmarks umwerfen
Was für Benchmarks meinst du genau? Ich kenn nur die, wo C++ bei solchen Dingen 2x+ schneller ist als C, wie man es logischerweise erwarten würde; da ist imo also alles in Ordnung...
wir waren gerade an dem punkt, wo templates eine stdlib funktion outperformen
was aber faktisch ein äpfel/birnen vergleich ist.und wenn wir die diskussion noch weiterführen, kommen wir sicher iwann zu dem punkt, wo du mir erzählen willst, dass c++ einen 2x+ schnelleren algo implementiert hat, der sich in c nicht umsetzen lässt, weil das die sprache nicht hergibt
-
kellerassel schrieb:
dot schrieb:
kellerassel schrieb:
das würde einen großteil der c vs c++ benchmarks umwerfen
Was für Benchmarks meinst du genau? Ich kenn nur die, wo C++ bei solchen Dingen 2x+ schneller ist als C, wie man es logischerweise erwarten würde; da ist imo also alles in Ordnung...
wir waren gerade an dem punkt, wo templates eine stdlib funktion outperformen
was aber faktisch ein äpfel/birnen vergleich ist.Stimmt, natürlich kann man nicht direkt Features zweier Sprachen vergleichen, wenn eine der beiden Sprachen kein vergleichbares Feature hat. Man kann aber dennoch feststellen, dass eine der beiden Sprachen kein vergleichbares Feature bietet und daher gewisse Dinge in dieser Sprache einfach nicht möglich sind bzw. gewisse Dinge in der anderen Sprache viel besser gehen...
-
ich hab jetzt keine lust ein bsp. mit konstrukten zu kreieren, die sich in c++ per definition nicht umsetzen lassen. damit ist das thema für mich durch
wenn du mir nicht glaubst dass es die gibt, und es dir das wert ist, mir meinen stundenlohn zu zahlen bekommst eins
-
Auf welches Konto soll ich die 2 Cent ueberweisen?
-
kellerassel schrieb:
ich hab jetzt keine lust ein bsp. mit konstrukten zu kreieren, die sich in c++ per definition nicht umsetzen lassen.
Wäre das nicht Äpfel mit Birnen vergleichen?
Btw: Das coole an C++ ist, dass dort sowohl Äpfel als auch Birnen wachsen können...
-
knivil schrieb:
Auf welches Konto soll ich die 2 Cent ueberweisen?
ich bin doch nicht larry page :p
-
dot schrieb:
kellerassel schrieb:
ich hab jetzt keine lust ein bsp. mit konstrukten zu kreieren, die sich in c++ per definition nicht umsetzen lassen.
Wäre das nicht Äpfel mit Birnen vergleichen?
Btw: Das coole an C++ ist, dass dort sowohl Äpfel als auch Birnen wachsen können...
das einzig coole was ich der sprache abringen kann, ist, dass sie vielen lowlevel entwicklern nicht taugt, was dazu führt, dass ich damit bei meinen highlevel programmen nicht oft in kontakt komm. DAS ist
