Grösse der exe FPC vs. C / externe libs

[Mathias]

Dies wurde schon vielfach erwähnt, das die erzeugten EXE von FPC recht gross sind.
Ein HelloWorld ist in C gut den Faktor 10 kleiner als bei FPC.

Ich vermute mal ein Grund dafür wird sein, bei C wird für jedes kleinste Ding eine externe lib angesprochen. Schon ein einfaches puts() braucht eine lib. Und FPC macht fast alles selbst, auch das einfachste Writeln braucht einiges.
Bei dem Inlude System bei C sind die Include-Dateien *.h nur ein Verweiss auf externe libs und beihalten ein paar Konstanten und Type-Definitionen, evtl . noch ein paar Macros.
Beim Unit-System von Pascal, kann man in jeder Unit zwischen dem "begin" und "end." noch ein paar Befehle ausführen, Und dieses Zeugs landet am Ende auch in der EXE. Und ich vermute die Unit-System welche zwingen erfordrlich ist macht schon einige Initialisierungen.

Habe ich dies richtig verstanden ?

[Warf]

Ja das liegt daran das C die "native" Sprache für Unix Systeme ist. Die Unix spec definiert die system APIs als C Funktionen und die libC ist neben anderen Bibliotheken (z.b. pthreads) ein Teil der Unix spec.
Das hat neben Standardisierung und Größeneinsparung noch einen weiteren Vorteil, die Systeme bringen normalerweise LibC Versionen die auf die Prozessorarchitektur optimiert sind mit, d.h. Code in der LibC wie z.B. memcpy ist für gewöhnlich ein Vielfaches schneller als das entsprechende Pascal equivalent (move)

Pascal hingegen hat seine eigene runtime, die RTL, die eine Eigenentwicklung ist. Da also jedes Unix system die LibC umfasst aber nicht die RTL, können C Programme einfach gegen die System LibC binden, während Pascal Programme ihre RTL selbst mitbringen müssen.

[Jorg3000]

Hi!
Um Missverständnisse zu vermeiden, sollten wir mal mit konkreten Zahlen arbeiten.

Vergleichbar ist es nur, wenn man in den Projekteinstellung > Debuggen "Use external debug symbols file (-Xg)" einstellt.
Dann ist z.B. die kleinste visuelle Windows-Anwendung rund 2,5 MB groß (meine ich mich zu erinnern, habe es gerade nicht getestet).

Ich trauere noch etwas den kleinen Größen aus der früheren Delphi-Zeit nach. Unter Delphi 7 konnte man ein nicht-visuelles Programm mit rund 50 kb und eine visuelle Anwendung ab 300 kb Größe erstellen (meine ich mich zu erinnern).
Ob das wirklich viel größer war, als es mit C möglich ist? Ich glaube der Unterschied war schon damals nicht relevant. Dafür erhielt man mit Delphi eine unabhängige, monolithische Anwendung, was ich sehr mag.

Mich würde aber schon interessieren, woher die krassen Unterschiede zwischen (altem) Delphi und derzeitigem Lazarus herkommen, denn es ist mindestens der Faktor 8.
Grüße, Jörg

[KoBraSoft]

Die Größe der ausführbaren Dateien von Lazarus zu Delphi wurde schon ausführlich diskutiert, ebenso wie die Größe der exe von Delphi zu Turbo Pascal für Windows, welche ebenfalls um den Faktor 10 (wenn ich mich recht erinnere) gewachsen sind.
Die Größe der ausführbaren Dateien von Lazarus war damals für mich ein echtes Problem, da das Programm nicht mehr auf eine Diskette passte. Das Problem hat sich erledigt.
Das Größenwachstum hat sich, meiner subjektiven Wahrnehmung nach, bei Lazarus verlangsamt.

OT
Ich sehe aber ein neues, größeres Problem, die Größe meines Lieblingsbetriebssystems ist über Nacht gigantisch gewachsen.
Ich habe das Problem hier: https://forum.ubuntuusers.de/topic/waru ... u-so-fett/ angesprochen.

[Mathias]

Dann ist z.B. die kleinste visuelle Windows-Anwendung rund 2,5 MB groß (meine ich mich zu erinnern, habe es gerade nicht getestet).

Meine Feststellung war bei einem einfachen Konsolen-HelloWorld. Da ist kein LCL und co. dabei.
FPC = 212KB
C = 18KB
ASM = 9KB
Alles Linux Varianten.

Die Größe der ausführbaren Dateien von Lazarus war damals für mich ein echtes Problem, da das Programm nicht mehr auf eine Diskette passte. Das Problem hat sich erledigt.

Am schlimmsten ist dies Effekt bei 8088 EXE. Turbo-Pascal war da sehr kompakt, der FPC 8088 Cross-Complier ist das schon recht aufgebläht. TB hatte gerade mal 2.9KB.



Ich vermute mal in der Unit-System gibt es gegenwärtig viel mehr Initialisierungen, wie zu TP-Zeiten.
Man denkt nur an das ganze Zeugs für die dynamischen Arrays. Oder die Classen.
In C muss man für die Arrays schon einen extra-Header verwenden.

[wp_xyz]

FPC = 212KB

Bei mir (Windows) wird das folgende Projekt 34 kB groß (FPC 3.2.2, ohne Debug-Informationen):

Code: Alles auswählen

program Project1;
begin
  WriteLn('Hello world');
end.

[Mathias]

Bei mir (Windows) wird das folgende Projekt 53 kB groß (FPC 3.2.2, ohne Debug-Symbole):

Ich habe auch alles abgestellt, was Debugging anbelangt. Auch Bereichsprüfung. etc.

Verwendet die Windows Version von FPC evtl. Win-Api Funktionen ?

[PascalDragon]

Mich würde aber schon interessieren, woher die krassen Unterschiede zwischen (altem) Delphi und derzeitigem Lazarus herkommen, denn es ist mindestens der Faktor 8.

Das liegt an der Struktur der LCL. Die VCL ist ein ziemlich dünne Schicht um die Windows API, weswegen die VCL selbst auch nie direkt auf eine andere Plattform portiert wurde (Kylix hatte eine eigene Abart auf Qt basierend).

Die LCL wiederum hat entsprechende Abstraktionsschichten drin, die es ermöglicht andere Backends anzubinden und es damit überhaupt erst möglich und für ein vergleichsweise kleines Team wartbar macht die LCL (und die IDE) auf so vielen Plattformen bereitzustellen. Durch die Struktur dieser Schicht kann der Compiler bzw. Linker allerdings auch nicht entsprechend leicht Code rauslassen, der nicht verwendet wird.

Dann ist z.B. die kleinste visuelle Windows-Anwendung rund 2,5 MB groß (meine ich mich zu erinnern, habe es gerade nicht getestet).

Meine Feststellung war bei einem einfachen Konsolen-HelloWorld. Da ist kein LCL und co. dabei.
FPC = 212KB
C = 18KB
ASM = 9KB
Alles Linux Varianten.

Hast du mit aktiviertem Smartlinking kompiliert? Compiler Option -XX. Unter nicht-Windows ist das standardmäßig deaktiviert, da es sonst Probleme mit dem Debuginformationen gibt (im Gegensatz zu Windows, wo das standardmäßig aktiviert ist).

Bei mir kommt für ein einfaches HelloWorld dann ein Unterschied von 187 KB (ohne Smartlinking) zu 35 KB (mit Smartlinking) raus.

Und wenn man noch dazu mit der experimentellen Unterstützung für Runtime Packages baut, dann ist die Executable nur noch 16 KB groß (und die librtl.so hat dann 3,7 MB, weil sie auch die ganze (Kern-)RTL enthalten muss, da dann keinerlei Smartlinking - außer innerhalb der Bibliothek - möglich ist).

Verwendet die Windows Version von FPC evtl. Win-Api Funktionen ?

Unter Windows wird beim Win32/Win64 Ziel immer die Windows API verwendet, das ist die niedrigste, allgemein verfügbare Schnittstelle, die allgemein genutzt werden kann (theoretisch könnte man zwar auch die NT API verwenden, aber da die um ein vielfaches niedriger ist, muss man da viel zu Fuß machen und ist damit für allgemeine Anwendungsentwicklung nicht sinnvoll).

Prinzipiell könnte FPC auch noch kleinere Anwendungen für die großen Plattformen erstellen, allerdings können ein paar der Abstraktionsschichten (ähnlich zu dem was Lazarus hat) nicht gut genug wegoptimiert werden, was sich dann in der Größe niederschlägt. Ich habe ein paar Ideen, wie ich da den Optimizer verbessern kann, aber ich muss da erstmal die Zeit finden, dass ich mit den Ideen experimentieren kann...

[Mathias]

Mal eine andere Frage, kann man bei FPC irgendwie umgehen, das die unit System nicht geladen wird ?
Wen dies gehen würde, würde es auch die ganze RTL umgehen und die bin müsste etwa gleich sein wie unter C.

Ein HelloWorld würde dann so aussehen.

Code: Alles auswählen

  function printf(str: PChar): Integer; varargs cdecl; external 'c';

begin
  printf('Hello World'#10);
end.  

[Warf]

Es gibt einen komandozeilen Parameter mit limitierten Typen zu kompilieren, dann wird ohne RTL kompiliert. Das wird z.b. benutzt um die system unit selbst zu kompilieren.

Das gesagt, dann kannst du halt den größten Teil der Sprache nicht nutzen (Klassen, Objekte, arrays, strings, etc)

[PascalDragon]

Mal eine andere Frage, kann man bei FPC irgendwie umgehen, das die unit System nicht geladen wird ?

Was durch die System-Unit bereit gestellt wird ist ein integraler Bestandteil der Sprache Pascal und die System-Unit ist genauso integraler Bestandteil der Compiler/RTL Kombination. Deswegen stellt der Compiler auch keine Mechanismen dazu zu Verfügung, weil der Compiler davon ausgehen muss, dass die System-Unit verfügbar ist.

[Mathias]

Ich habe gerade einen neunen Befehl von Linux entdeckt "strings".
Den habe ich mal auf einem einfachen HelloWorld ohne DebugInfos ausprobiert.

Code: Alles auswählen

strings project1>test.txt

Dies gibt eine Text Datei mit 141Kb und 5994 Zeilen.
Da frage ich mich, ob der Compiler da nicht noch ein wenig optimieren könnte ?

[PascalDragon]

Es würde helfen, wenn du noch sagen würdest, was denn dein project1 genau ist?

[Mathias]

Ein einfaches HelloWorld. Ohne Debug Infos.

[Warf]

Bei mir ist das ganze ein gutes Stück kleiner:

Code: Alles auswählen

$> cat test.pas
program Test;

begin
  WriteLn('Hello World');
end.
$> fpc ./test.pas
Free Pascal Compiler version 3.2.2 [2023/10/09] for x86_64
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling ./test.pas
Linking test
5 lines compiled, 0.3 sec
$> strings test | wc -l
1877
$> strings test | sort -u | wc -l
809