Wie bekomme ich die exe kleiner?

[Stevie]

Interessant, dass bei diesen "Exe Größe" Diskussionen meist komplett vergessen wird, das selbst die modernsten Prozessoren keinen duzende MB großen Instruction Cache haben. Das heißt, je größer und verteilter der ausgeführte Code, desto eher wird der CPU Durchsatz vom RAM gebremst.

Aber ja, wir reden hier von High Performance und weniger von nem GUI Progrämmchen wo das kaum Auswirkungen hat.

[himitsu]

Zitat von Stevie:

das selbst die modernsten Prozessoren keinen duzende MB großen Instruction Cache haben. Das heißt,

Da bin ich selber mal drauf reingefallen.

Hatte einen Code schön mit Assembler "optimiert", mit dem Ergebnis, dass auf modernen CPUs (die arbeiten teilweise schon den/die nächsten Befehl vor)
alles extrem langsamer lief, im Gegensatz zu dem was der Delphi-Compiler produzierte.
Durch ein paar Jumps wurde dieser Cache und das "umsonst" Vorgearbeitete ständig verworfen und an anderer Stelle wieder neu angefangen.

Zitat von Rolf Frei:

Ehm, nein ist es nicht.

Doch.
https://de.wikipedia.org/wiki/Addres..._Randomization

[freimatz]

Also ich versuche ja meine Programme so zu machen, dass sie den Bedürfnissen der Anwendern möglichst entspricht.
Die Grösse der Exe war in den vielen Jahren bislang nur einmal ein Thema. Und das war auch nicht bei einem Anwender sondern einem Herausgeber der meinte, er könne zu dem Buch nur zwei Disketten beilegen.
Aber jedem sein Hobby wie es ihm gefällt.

[Stevie]

Zitat von himitsu:

Hatte einen Code schön mit Assembler "optimiert", mit dem Ergebnis, dass auf modernen CPUs (die arbeiten teilweise schon den/die nächsten Befehl vor)
alles extrem langsamer lief, im Gegensatz zu dem was der Delphi-Compiler produzierte.
Durch ein paar Jumps wurde dieser Cache und das "umsonst" Vorgearbeitete ständig verworfen und an anderer Stelle wieder neu angefangen.

Was du beschreibst, klingt weniger nach einem Problem mit der Instruction Cache Größe sondern nach einem Pipeline Stall, durch z.B. Register Pressure oder Branch Mispredictions.
Kann aber auch durchaus daran liegen, dass besonders oft ausgeführter Code ungünstig über mehrer Cachelines lag.

[Codehunter]

Ich habe solche Diskussionen mit Kollegen auch schon mehrfach geführt. Weniger bzgl. der Dateigröße von EXEn, aber was die Belegung von Arbeitsspeicher betrifft. Die Problemstellungen mögen bei uns sehr spezifisch sein, das Paradigma denke ich ist allgemeingültig:

Wenn man die Wahl hat zwischen hoch optimiertem Code oder einfach großen Caches im RAM, dann programiere ich bevorzugt RAM-lastig. Ganz einfach deshalb, weil es sehr zeitintensiv auf unserer Seite ist, hoch optimierten Code zu schreiben und zu pflegen. Dagegen ist Arbeitsspeicher zu kaufen und einzubauen inzwischen beinahe die lächerlich kleinste Übung. Was immer machbar ist, wird in irgendwelchen Listen (bevorzugt TDictionary oder Virtual Treeview) geparkt. Dateioperationen nur wenns unbedingt sein muss und dann per TStream angeströmt.

Wobei ich mich hierbei nur auf VCL beziehe. Bei FMX und mobilen Targets sehen die Anforderungen schon ganz anders aus.