DLL mit FPC/Codetyphon erheblich kleiner als unter Delphi

[ralfstocker]

Es ist ganz einfach. Der FPC Compiler macht einfach die bessere Analyse. Er lässt einfach mehr Sachen, die man nicht braucht, weg. Der Delphi Compiler hat sich seit Delphi 2 (1997) in dem Punkt nicht geändert. Ein weiterer wichtiger Punkt ist der generierte Code von FPC. Der ist einfach schlanker und direkter. Bei Delphi gibt es Tonnen von unnötigen Register saves und restores, die den Code langsam machen und die EXE/DLL aufblähen.

[EWeiss]

Zitat:

Das ist aber Stand heute nicht möglich.

Klar ist das möglich nur nicht mit Delphi..

C++
- Full optimization (/Ox)
- Favor small code (/Os)

mehr muss man nicht sagen..

gruss

[jaenicke]

C++ kennt aber auch keine Reflection, d.h. Methoden, die nicht im Code angesprochen werden, können auch nicht ausgeführt werden. In Delphi hingegen kannst du die RTTI benutzen um auch z.B. Methoden eines Records auszuführen usw., die nirgends im Code verwendet werden.

Außerdem ist der C++ Compiler eben auch deutlich langsamer als der von Delphi, natürlich wird in der zusätzlichen Zeit auch etwas gemacht.

Natürlich könnte man auch die Units in Delphi umschreiben, damit nicht mehr so viel automatisch geladen oder angesprochen wird. Aber genau dass ich vieles einfach so benutzen kann und zur Verfügung habe, finde ich an Delphi ja besser als eben z.B. an C++.

[jbg]

Zitat von jaenicke:

Natürlich könnte man auch die Units in Delphi umschreiben, damit nicht mehr so viel automatisch geladen oder angesprochen wird. Aber genau dass ich vieles einfach so benutzen kann und zur Verfügung habe, finde ich an Delphi ja besser als eben z.B. an C++.

Um beim Beispiel Application und Screen zu bleiben. Man müsste das Erstellen der Objekte einfach nur in den Klassen-Konstruktor (gibt es seit Delphi 2010) verschieben. Und schon könnte man Vcl.Forms einbinden ohne dass TApplication und TScreen im Kompilat laden, wenn man auf keine der Funktionalitäten direkt oder indirekt zugreift.
Idera/Embarcadero müsste halt mal die initialization und finalization der Units aufräumen (oder entfernen).

Es wäre auch mal von Vorteil, wenn z.B. das gesamte DFM Streaming aus TStream herausgelöst werden würde. Ein Konsolenprogramm, das Streams benutzt braucht in der Regel kein DFM Streaming.

Aber bei der RTL/VCL ist diese "jeder nutzt jeden" zum Glück nicht ganz so schlimm ausgeprägt wie es bei der FMX ist. Da hat man gefühlt schon fast 80% allen FMX Codes in der Anwendung zu haben, wenn man nur eine FMX Unit einbindet.

[jaenicke]

Zitat von ralfstocker:

Ein weiterer wichtiger Punkt ist der generierte Code von FPC. Der ist einfach schlanker und direkter. Bei Delphi gibt es Tonnen von unnötigen Register saves und restores, die den Code langsam machen und die EXE/DLL aufblähen.

Ein konkretes Beispiel wäre schön. Wenn ich so den generierten Code vergleiche, kann ich davon nichts sehen. Ein einfaches Beispiel:

Delphi-Quellcode:

var
  a: string;
  b: Integer;
begin
  b := 42;
  a := IntToStr(b);
  ShowMessage(a);
end;

Delphi:

Code:

Unit93.pas.30: begin
00000000006B6B80 55               push rbp
00000000006B6B81 4883EC30         sub rsp,$30
00000000006B6B85 488BEC           mov rbp,rsp
00000000006B6B88 48C7452800000000 mov qword ptr [rbp+$28],$0000000000000000
00000000006B6B90 48894D40         mov [rbp+$40],rcx
00000000006B6B94 48895548         mov [rbp+$48],rdx
00000000006B6B98 90               nop
Unit93.pas.31: b := 42;
00000000006B6B99 C745242A000000   mov [rbp+$24],$0000002a
Unit93.pas.32: a := IntToStr(b);
00000000006B6BA0 488D4D28         lea rcx,[rbp+$28]
00000000006B6BA4 8B5524           mov edx,[rbp+$24]
00000000006B6BA7 E88493D7FF       call IntToStr
Unit93.pas.33: ShowMessage(a);
00000000006B6BAC 488B4D28         mov rcx,[rbp+$28]
00000000006B6BB0 E89B3BF3FF       call ShowMessage
00000000006B6BB5 90               nop
Unit93.pas.34: end;
00000000006B6BB6 488D4D28         lea rcx,[rbp+$28]
00000000006B6BBA E8217BD5FF       call @UStrClr
00000000006B6BBF 488D6530         lea rsp,[rbp+$30]
00000000006B6BC3 5D               pop rbp
00000000006B6BC4 C3               ret

Lazarus / FPC:

Code:

unit1.pas:37                              begin
000000010002C390 55                       push   %rbp
000000010002C391 4889e5                   mov    %rsp,%rbp
000000010002C394 488d6424c0               lea    -0x40(%rsp),%rsp
000000010002C399 48894df0                 mov    %rcx,-0x10(%rbp)
000000010002C39D 488955f8                 mov    %rdx,-0x8(%rbp)
000000010002C3A1 48c745e800000000         movq   $0x0,-0x18(%rbp)
000000010002C3A9 90                       nop
unit1.pas:38                              b := 42;
000000010002C3AA c745e02a000000           movl   $0x2a,-0x20(%rbp)
unit1.pas:39                              a := IntToStr(b);
000000010002C3B1 8b45e0                   mov    -0x20(%rbp),%eax
000000010002C3B4 488d4de8                 lea    -0x18(%rbp),%rcx
000000010002C3B8 89c2                     mov    %eax,%edx
000000010002C3BA e8c11a0200               callq  0x10004de80 <SYSUTILS_$$_INTTOSTR$LONGINT$$ANSISTRING>
unit1.pas:40                              ShowMessage(a);
000000010002C3BF 488b4de8                 mov    -0x18(%rbp),%rcx
000000010002C3C3 e828201100               callq  0x10013e3f0 <SHOWMESSAGE>
unit1.pas:37                              begin
000000010002C3C8 90                       nop
000000010002C3C9 4889e9                   mov    %rbp,%rcx
000000010002C3CC e89fffffff               callq  0x10002c370 <fin$0>
unit1.pas:41                              end;
000000010002C3D1 90                       nop
000000010002C3D2 488d6500                 lea    0x0(%rbp),%rsp
000000010002C3D6 5d                       pop    %rbp
000000010002C3D7 c3                       retq

[Benedikt Magnus]

Dazu fällt mir dieser Artikel hier ein:
http://blog.synopse.info/post/2015/0...er-than-Delphi

[ralfstocker]

Danke!

Zitat von Benedikt Magnus:

Dazu fällt mir dieser Artikel hier ein:
http://blog.synopse.info/post/2015/0...er-than-Delphi

[jaenicke]

Auch der neuere 64-Bit Compiler von Delphi benutzt diese Optimierung übrigens nicht.
Es stimmt auch, dass dadurch diese Zeile in FPC Code etwa viermal schneller ausgeführt wird.
Allerdings lässt sich selbst ohne Optimierung diese Zeile auf meinem nicht ganz neuen Rechner 100 Millionen mal in einer Sekunde ausführen, bei FPC eben viermal so oft.

In wie vielen realen Programmen wird dies also relevant sein?

An der Stelle finde ich, dass es nicht unbedingt sinnvoll ist, zu viel Aufwand in "extreme corner case" Optimierungen zu stecken... zumindest nicht in einem kommerziellen Produkt wie Delphi.

[BUG]

Kommt immer darauf an. Ereignisgetriebene Datenbankoberflächen (CRUD-Anwendungen) ist das vermutlich egal, da eh alle paar Instruktionen irgendwo hin gesprungen wird.
Hier im Forum habe ich aber auch einige Leute gesehen, die numerische Simulationen in Delphi schreiben. Und in einer engen Schleife bedeutet 4x länger halt, dass die Simulation 4x länger läuft.

[TRomano]

Die Relevanz (millionenfaches Berechnen in einer engen Schleife) ist wohl bei den allermeisten Entwicklern gering.
In meinem bisherigen Entwicklerleben hatte ich einmal das Vergnügen (Landesamt für Statistik) und dort wurde dann gleich zu SSE2/SSE3 gegriffen, also wurde der interne BASM angeschmissen
und nur Arrays, Listen etc. an die Func/Proc übergeben und der Rest intern mit dem Assembler gemacht. Oder man hat gleich extern (High Lever Assembler HLA) programmiert und die OBJ-Files in Delphi eingebunden.

Natürlich wünschen wir uns alle hochoptimierten Code, aber auf der anderen Seite wollen wir einen flinken Compiler/Linker, dass wir effizient arbeiten können. Das ist Delphi (fragt mal einen C oder C++ - Entwickler). Vor 20-25 Jahren musste man echt noch auf die Größe der Kompilate achten, aber heute ist das nicht mehr relevant.

Schön wäre es natürlich, wenn man normal mit Delphi entwickeln könnte und bei der Fertigstellung eines Releases einfach den Compiler mit einer hohen Optimierungsstufe anschmeissen könnte. Der Linker würde danach automatisch alle Funcs/Procs/Consts/... aus eingebundenen Units rausschmeißen, die man nicht braucht ...