C++-exe Größe-Vergleich

/rant/ schrieb:

Im Ernst: iostream besteht aus so vielen von einander abhängigen Templates, da ist es kein Wunder, dass dort irgendwie ein paar Hundert KB zu Stande kommen. Und bei cstdio mit printf ist es auch logisch, dass es weniger braucht. Ist ja auch viel weniger komplex und bietet nicht mal ansatzweise so viele Möglichkeiten. Schreib dir selbst eine (brauchbare!) iostream-Library (oder schau dir STLport an) und du wirst merken, dass es nicht so einfach ist

MfG

Haha Da merke ich , dass ich der Sohn von dem Urprogrammierer bin der noch mit Lochkarte gecodet hat und sich tierisch aufgeregt hat wenn sein Fortran-Compiler zu groß war.
Ich finde es bloss sehr schade , dass ich in Code::Blocks (mit keinem einzigen Compiler) eine kleine exe(<457kB) hinbekomm , in der nur das drin ist , was gebraucht wird. Der VisualC++-Compiler kann das ja auch (8kB).
MfG nt0r

EDIT: Mir ist grade eben was aufgefallen : Wenn ich mein Programm manuell über cygwin bzw. g++ kompiliere (g++ main.cpp -s -o tested.exe) , dann ist die Größe durch das strippen verringert. Wenn ich beim Code::Blocks das anschmeiße tut sich nichts. Weiß jemand genauer bescheid?

Athar

nt0r schrieb:

Kein Mensch kann mir erzählen , dass nur die stream-Klassen schon 450 kB brauchen.

Doch, klar. Da hängt so einiges dahinter, was nicht unbedingt offensichtlich ist, z.B. die locale-Bibliothek.

nt0r schrieb:

Ich finde es bloss sehr schade , dass ich in Code::Blocks (mit keinem einzigen Compiler) eine kleine exe(<457kB) hinbekomm , in der nur das drin ist , was gebraucht wird. Der VisualC++-Compiler kann das ja auch (8kB).

Wie gesagt, VC++ linkt die C++-Runtime normalerweise dynamisch, MinGW dagegen statisch. Das hat durchaus Vorteile, so benötigen MinGW-Executables keine Varianten von msvcrXX.dll und msvcpXX.dll um zu funktionieren. Du kannst zwar auch mit MinGW dynamisch linken und damit die Größe ebenfalls auf 8 KB drücken, aber dann müsstest du libstdc++-6.dll mitliefern.
Das ist auch nicht besser.

Wenn dir was an Executablegrößen liegt, kannst du auf Standard-C++-Streams verzichten. Das erfordert aber natürlich, dass du mindestens gleichwertigen Ersatz dafür hast (cstdio zählt nicht dazu).

nt0r schrieb:

PS: Mit dem Upx bekomm ich die größe auf 127kB unter , aber ich glaub das ist nicht gut für die Performance

Mit Performanz hat das nur sehr begrenzt zu tun, aber ein großer Teil der Antivirus-Software stuft UPX-gepackte Executables als verdächtig oder gleich als Schadsoftware ein. Spätestens nach der 1000sten Nutzerbeschwerde oder nachdem dein Server "zu deiner eigenen Sicherheit" vom Netz genommen wurde, weil der Routinescan Schadsoftware auf deinem Webspace gefunden hat, hast du darauf keine Lust mehr.
Laufzeitgepackte Executables haben auch andere kleinere Probleme, z.B. dass jede Programminstanz eine eigene Kopie der entpackten Binary im Speicher hält.

nt0r schrieb:

Wenn ich beim Code::Blocks das anschmeiße tut sich nichts.

Weil -s für das Release-Target bereits standardmäßig aktiviert ist.

Belli

Athar schrieb:

Wie gesagt, VC++ linkt die C++-Runtime normalerweise dynamisch, MinGW dagegen statisch.

Aber auch, wenn man mit VS (ich hab hier VS 2008) statisch linkt, ist der Unterschied gewaltig. Für

#include <iostream>

int main()
{
	std::cout << "Hello World\n";
}

ergeben sich mit g++ (3.4.5 mingw special) 477 KB, mit VS (cl - Version 15.00.30729.01) 96 KB, jeweils ohne irgendwelche Optimierungsschalter einfach von der Kommandozeile aus aufgerufen.

Ethon

Vlt hängt MinGW irgendetwas per Default dran, was MSC nichtmacht? Irgendwelche Symbole?

Athar

Ethon schrieb:

Vlt hängt MinGW irgendetwas per Default dran, was MSC nichtmacht? Irgendwelche Symbole?

Ja, Symbolnamen. Fairerweise muss man beim GCC mit -s linken.

Und beim GCC wird die (schwergewichtige) locale-Bibliothek vollständig mitgelinkt, auch wenn die nur in Teilen gebraucht wird (weil sich alles in der gleichen Objektdatei befindet).
Bei MSVC erhöht sich die Executablegröße gleich nochmal, wenn man statt "Hello World!" z.B. 3.14 ausgibt, da scheint das also etwas feinkörniger zu sein.

Ich frage mich, ob sich der GCC es gefallen ließe, wenn man libstdc++ und libgcc mit aktivierter LTO linken würde.
Damit könnte nicht benötigtes herausgeworfen werden, aber man müsste diese Bibliotheken erst einmal mit -flto neu bauen. Wer also mal Lust hat...

dot

Hello World war noch nie ein besonders gutes Beispiel für Benchmarking...

Belli

Du bist herzlich aufgerufen, ein anderes Beispiel (C++ wohlgemerkt, bei reinem C-Code erstellt der GNU-Compiler kleinere Dateien) zu posten, bei dem g++ eine kleinere exe - Datei erzeugt als cl.

Ethon

Belli schrieb:

Du bist herzlich aufgerufen, ein anderes Beispiel (C++ wohlgemerkt, bei reinem C-Code erstellt der GNU-Compiler kleinere Dateien) zu posten, bei dem g++ eine kleinere exe - Datei erzeugt als cl.

Selbes Beispiel, unter Linux kompiliert:

#include <iostream>

int main()
{
    std::cout << "Hello World\n";
}

[ethon@Slaybook ~]$ g++ -Os -s -o hello hello.cpp
[ethon@Slaybook ~]$ size hello
text data bss dec hex filename
1817 600 296 2713 a99 hello

ca 5kb.
Also schieben wir es mal lieber auf den Mist den MinGw macht und nicht g++, ok?

Edit: Upps, .exe überlesen ...

Athar

Außerdem wird libstdc++ unter Linux standardmäßig dynamisch gelinkt. Wenn du mit -static linkst, sieht es gleich wieder ganz anders aus.

tntnet

Was interessiert da die IDE? Die IDE ruft den gcc auf. Und dem gcc ist es egal, ob es über eine IDE oder einen Makefile oder wie auch immer aufgerufen wird. Es ist ja auch egal, mit welchem Editor ich den Sourcecode eingetippt habe.

Bei mir kommt übrigens mit -Os und strip exakt 5000 Bytes raus. Na ja - ist auch Linux und dynamisch gelinkt.

Also sagen wir mal, dass gcc prinzipiell erst mal kleine Binaries erzeugen kann. Dann wäre die Schuld entweder in den Compileroptionen oder in dem Windows-Port zu suchen.

Bitte ein Bit

Hmm, merkwürdiges Problem.

Ich schaue mir gerade Gimp Plugins unter Windows an und entwickele dazu eine Klasse unter Codeblocks. Mein Mini-Plugin (Plugins unter Gimp sind EXE Dateien) belegt mit allen gerade mal 70 kByte in der Debug Version.

Ethon

Bitte ein Bit schrieb:

Hmm, merkwürdiges Problem.

Ich schaue mir gerade Gimp Plugins unter Windows an und entwickele dazu eine Klasse unter Codeblocks. Mein Mini-Plugin (Plugins unter Gimp sind EXE Dateien) belegt mit allen gerade mal 70 kByte in der Debug Version.

Naja, die müssen ja fast dynamisch gelinkt werden.