DLL mit FPC/Codetyphon erheblich kleiner als unter Delphi

[ralfstocker]

Danke!

Zitat:

Zitat von Benedikt Magnus (Beitrag 1337569)

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 ...

[EWeiss]

Zitat:

musste man echt noch auf die Größe der Kompilate achten, aber heute ist das nicht mehr relevant.

Destotrotz sehe ich keinerlei Nutzen darin warum Kompilate so dermaßen aufgebauscht werden müssen.

Zitat:

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 ...

Wobei man das letztendlich mit UPX bewerkstelligen kann/könnte.
Schöner wäre es natürlich direkt in der IDE mit einstellbaren Optimierungs flags.
Aber was rede ich hier den aufwand zu betreiben ist den Entwicklern von Delphi einfach nicht wert.

gruss

[TiGü]

Zitat:

Zitat von EWeiss (Beitrag 1337617)

Zitat:

musste man echt noch auf die Größe der Kompilate achten, aber heute ist das nicht mehr relevant.

Destotrotz sehe ich keinerlei Nutzen darin warum Kompilate so dermaßen aufgebauscht werden müssen.

Ich möchte wetten, das diejenigen Leute, die sich jetzt über das ein oder andere Megabyte mehr in dem Kompilat "aufregen", genau diejenigen wären, die sich über zu lange Kompilierungszeiten beschweren würden, wenn der Delphi-Compiler so hoch optimieren würde wie der ein oder andere C++-Kompiler.

Meckern, um des Meckern willen. :roll:

[Daniel]

Zitat:

Zitat von TiGü (Beitrag 1337619)

Ich möchte wetten, das diejenigen Leute, die sich jetzt über das ein oder andere Megabyte mehr in dem Kompilat "aufregen", genau diejenigen wären, die sich über zu lange Kompilierungszeiten beschweren würden, wenn der Delphi-Compiler so hoch optimieren würde wie der ein oder andere C++-Kompiler.

"Größere Kompilate vs. kürzere Kompilier-Zeit aufgrund weniger Optimierung": Unser Prof sprach vom "Elend-Erhaltungssatz". Seiner Ansicht nach bliebe die Menge an Elend stest die selbe: Entweder Du erhältst kleinere Kompilate und wartest dafür länger oder Du wartest nicht so lang und hast dann größere Kompilate.

Offen gestanden hatte ich in all den vergangenen Jahren nicht ein einziges Kundenprojekt, bei dem ein MB mehr oder weniger bei den EXEn irgendwie relevant geworden wäre.

[EWeiss]

Zitat:

Offen gestanden hatte ich in all den vergangenen Jahren nicht ein einziges Kundenprojekt, bei dem ein MB mehr oder weniger bei den EXEn irgendwie relevant geworden wäre.

Ach darum geht's doch gar nicht..
Es geht um die Verschwendung von Ressourcen.
Das fängt damit an das man jedes Lebensmittel wo das Ablaufdatum ausgelaufen ist wegwirft und hört hier bei Bit und Bytes auf.
Mal überlegt wie viel Strom man sparen könnte wäre unsere Gesellschaft KEINE Wegwerfgesellschaft?
Es geht doch nur noch um Zeit und Geld.
Allein die Bitcoins zu generieren verbraucht TeraWatt an Strom auf der anderen Seite verdursten Menschen weil sie nicht mal über einen Brunnen für ihr Dorf verfügen.

Zitat:

Meckernm um des Meckern willen.

Logisch wenn man nicht über den Rand des Tellers hinweg schauen will.

gruss

[TiGü]

Zitat:

Zitat von EWeiss (Beitrag 1337623)

Zitat:

Offen gestanden hatte ich in all den vergangenen Jahren nicht ein einziges Kundenprojekt, bei dem ein MB mehr oder weniger bei den EXEn irgendwie relevant geworden wäre.

Ach darum geht's doch gar nicht..
Es geht um die Verschwendung von Ressourcen.
Das fängt damit an das man meint jedes Lebensmittel wo das Ablaufdatum ausgelaufen ist wegwirft und hört hier bei Bit und Bytes auf.
Mal überlegt wie viel Strom man sparen könnte wäre unsere Gesellschaft KEINE Wegwerfgesellschaft?

Man spart aber keinen Strom, wenn die EXE ein, zwei Megabyte kleiner ist! :roll:

Es wäre aber definitiv eine Verschwendung von Ressourcen seitens der Kompiler-Entwickler, wenn sie jetzt Mannmonate/-jahre in die Optimierung stecken würden.
Es würde sich nämlich nicht lohnen (für den typischen Delphi-Entwickler).
Die Bereiche in der Softwareentwicklung, in denen das relevant ist, verwenden eh schon was anderes (siehe oben den Beitrag von TRomano) als technologische Lösung.

Zitat:

Zitat von EWeiss (Beitrag 1337623)

Zitat:

Meckernm um des Meckern willen.

Logisch wenn man nicht über den Rand des Tellers hinweg schauen will.

Welche alte Delphi-Version verwendest du nochmal?
Und was kann die alles nicht im Vergleich zu Seattle/Berlin?

[EWeiss]

Zitat:

Man spart aber keinen Strom, wenn die EXE ein, zwei Megabyte kleiner ist!

Mal zig Milliarden? Nein?

Zitat:

Und was kann die alles nicht im Vergleich zu Seattle/Berlin?

Und?
Da sollte man sich erst mal die Frage stellen ob man das denn alles braucht.

gruss