Welcher C-Compiler erzeugt die kleinsten Dateien?

rüdiger

-Os -s

Das -s stript die Datei noch. Aber unter Windows ist glaube ich einfach das Problem, dass er viele Teile aus der Standardbibliothek statisch linken muss. Vielleicht kann man da dynamisches linken erzwingen oder du könntest auf "schwere" Funktionen wie printf verzichten.

was genau macht denn -Os -s ?

wird die datei da komprimiert? oder was wird da weggelassen, damit die datei kleiner ist?

*edit* (tut mir leid mit den doppelposts und so)

mit komprimiert mein ich laufzeitkomprimiert, wie es z.b. upx tut

DrakoXP

?-! schrieb:

mit komprimiert mein ich laufzeitkomprimiert, wie es z.b. upx tut

Nein, es gibt nur für viele Operationen mehrere Möglichkeiten um diese auf dem Prozessor umzusetzen.

Beispiel:

a *= 8;

Das lässt sich in Assembler so umsetzen:

; quasi das, was im C code steht
mul eax, 8

; die effizientere Variante
shl eax, 3

Jetzt stelle dir eine Multiplikation nicht mit 8 (oder generell einer Potenz von 2 [ 1, 2, 4, 8, 16, ...]) vor, sondern einer beliebigen Zahl.

Das lässt sich auch wieder mit einem Befehl (mul) machen oder eben über eine Kombination aus Additionen und Bitverschiebungen.
Die Variante mit der Multiplikation ist in der Regel kleiner, während die Variante mit Addition+Bitverschiebung auf manchen Systemen schneller sein wird.

Dazu ein Beispiel von http://isthe.com/chongo/tech/comp/fnv/

#if defined(NO_FNV_GCC_OPTIMIZATION)
    hval *= FNV_32_PRIME;
#else
    hval += (hval<<1) + (hval<<4) + (hval<<7) + (hval<<8) + (hval<<24);
#endif

Quasi kann man manche Dinge auch schon im C Code selbst optimieren.
Allerdings ist das nur sehr bedingt empfehlenswert, da Compilerbauer in der Regel mehr Ahnung von den verschiedenen Systemen haben, als z.B. ein Programmieranfänger.

EDIT: Ich könnte mir auch noch vorstellen, dass der Compiler weniger Funktionen inline'd, wenn er auf Dateigröße optimiert. Dadurch wird das Programm kleiner, aber auch langsamer.

aber die funktionalität bleibt zu 100% erhalten?

und das programm ist weiterhin portabel?

Soweit ich weiß, sind Optimierungen nie ohne Probleme und können sogar Bugs enthalten.

DrakoXP

Das ist unsinn.
Sofern der Compiler keine Fehler hat, wird sich die Funktionalität deines Programmes durch Optimierungen nicht ändern.
Es wird schließlich nicht das "Was?" geändert, sonder das "Wie?".

Natürlich kann es vorkommen, dass ein Programm kaputt-optimiert wird und früher kam dies wahrscheinlich häufiger vor.
Allerdings liegt das nicht am den Optimierungen an sich, sondern eben daran, dass der Optimierungscode des Compilers fehlerhaft ist.

Generell sind Optimierungen empfehlenswert, obgleich man natürlich auch das optimierte Programm ausführlich testen sollte um eventuell entstandene Bugs zu finden.

EDIT: Der Code bleibt auch portabel, so lange man nicht extra für eine bestimmte Zielplattform optimiert.
Zum Beispiel kann man dem GCC mit "-march=native" speziell Code für den im aktuellen System befindlichen Prozessor zu generieren.
Damit läuft das Programm unter Umständen bei dir schneller,
kann aber auf anderen Prozessoren möglicherweise nicht mehr ausgeführt werden.

Jochen Kalmbach

Ich komme mit VC++ auf 688 Bytes:

http://blog.kalmbach-software.de/2008/02/02/smallest-application-size-for-win32-console-application/

ich wüsste jetzt wirklich gerne, woran das mit den großen dateien bei mingw liegt.

diese glibc-lib braucht man nicht unbedingt oder (ich weiß nichtmal, für was die gut ist)? ich benutz immer nur die standardlib von c.
kann ich das mit der glibc-lib irgendwie abschalten?

DrakoXP

die glibc ist die GNU lib C... also die C-Standard-Bibliothek, die normalerweise mit dem GCC ausgeliefert wird.
Microsoft verwendet AFAIK die von Dinkumware.

Du kommst aber mit dem MinGW nur schwer um die glibc herum...
Gegen die Standardbibliothek vom MSVC zu linken wird schwierig, da MSVC *.lib Dateien verwendet und GCC *.a Dateien (Die sind auch inhaltlich verschieden ;-)).

DrakoXP schrieb:

Du kommst aber mit dem MinGW nur schwer um die glibc herum...

GCC/MinGW nutzt unter Windows die Glibc? Irgendwie kann ich mir das nicht so ganz vorstellen. Es gibt doch gar keinen Windows-Port der Glibc. MinGW verwendet wohl eher die Microsoft-Libc.

DrakoXP

Du hast Recht, unter Windows verwendet MinGW tatsächlich die alte msvcrt.dll.
Alt, weil die ganzen neuen Visual Studios jeweils ihre eigene C-Runtime mitbringen.

Die msvcrt.dll ist aber auf allen Windows vorhanden, weshalb man so nicht auch noch auf die Redistributable Packages von Microsoft angewiesen ist, wenn man sein Programm weitergeben möchte.

Keine Ahnung wie weit C-- mit C verwandt ist.
Mit C-- soll eine ausführbare "Hallo World" etwa 40 Byte gross sein.

MfG f.-th.

Jochen Kalmbach

f.-th. schrieb:

Mit C-- soll eine ausführbare "Hallo World" etwa 40 Byte gross

Das kann nicht sein. Unter Windows ist schon allein der Header min. 80 Bytes oder noch mehr groß...

Okay. Die Dateiendung soll dann .com und nicht .exe sein.

f.-th. schrieb:

Okay. Die Dateiendung soll dann .com und nicht .exe sein.

sind das nicht dateien für 16-bit?
du laufen unter windows 7 nicht

DrakoXP

Das ist nicht ganz richtig.
Die 64 Bit Versionen von Windows unterstützen keine 16 Bit Anwendungen mehr, die 32 Bit Versionen jedoch schon.
Das liegt aber nicht direkt an Windows selbst, sondern daran, dass der Prozessor im Long Mode keine Möglichkeit mehr hat 16 Bit Code auszuführen.

Jochen Kalmbach

Mit COM bekommt man "Hello World" mit < 30 Bytes hin... aber das war ja nicht dir Frage...

Die dümmsten Compiler erzeugen die größten Objektdateien.