Geschwindigkeitsvorteil 64 ggüb. 32 Bit - woran ermitteln?

[Delphi-Laie]

Hallo Pascal-/Lazarusfreunde!

Zur Zeit interessiert mich der Geschwindigkeitsvorteil von 64 gegenüber 32 Bit. Den festzustellen kommt zur Zeit ja nur Lazarus infrage.

Weiß jemand, bei welchen Operationen, Datentypen u.ä. sich der Geschwindigkeitsvorteil von 64 zu 32 Bit besonders signifikant feststellen läßt?

Auf Anhieb fällt mir eigentlich nur der Datentyp Int64 mit den entsprechenden Operationen (am besten jenseits der 2^32? vermutlich aber doch in jeder Größe) ein, der ja auch unter 32-Bit-Pascal (ab Delphi 4) nutz-/verwendbar ist.

Sind z.B. die relativ rechenintensiven Stringoperationen unter 64 Bit auch beschleunigt?

Für eventuelle Antworten danke ich schon mal im voraus!

Viele Grüße

Delphi-Laie

[himitsu]

Int64-Operationen sollten sehr, sehr viel schneller laufen,
denn in 32 Bit werden diese über zwei Integer "aufwändig" berechnet.

Und was noch ein Vorteil wäre:
- über 2 GB Arbeitsspeicher
- bessere Integration in ein 64-Bit-Betriebssystem

Wenn man z.B. die MMX-Register nutzt, dann kann man auch unter 32-Bit schneller/optimaler arbeiten.

[Delphi-Laie]

Danke! War meine Vermutung mit dem Int64 also anscheinend richtig.

Zitat:

Zitat von himitsu

Und was noch ein Vorteil wäre:
- über 2 GB Arbeitsspeicher

Wie, was? Können 64-Bit-Programme über 2 GByte nutzen? Bei 32-Bit-Programmen soll das ja nicht möglich sein. Oder ist gemeint, daß mehr als 2 GByte Hauptspeicher vorteilhaft ist? Das ist doch aber schon bei 32 Bit so. Also vermute ich, daß ersteres gemeint ist. Weißt Du dann auch, welcher Arbeitsspeicherbereich maximal einem bzw. jedem Program zur Verfügung steht?

[Valle]

Zitat:

Zitat von himitsu

- über 2 GB Arbeitsspeicher

(2**32) Bytes in Gigabytes = 4GB. ;-)

Zitat:

Zitat von himitsu

- bessere Integration in ein 64-Bit-Betriebssystem

Teilweise Treiber- oder Softwareprobleme, dank mangelnder 64bit Unterstützung.
(Installation eines TeamSpeak-Servers unter 64bit-Debian war grausam, bis ich den Grund dann rausfand...)

Liebe Grüße,
Valle

[Bernhard Geyer]

Zitat:

Zitat von himitsu

Int64-Operationen sollten sehr, sehr viel schneller laufen,
denn in 32 Bit werden diese über zwei Integer "aufwändig" berechnet.

Kommt auf dem Prozessor an. Die Itanium-Prozessoren waren echte Schnecken was 32-Bit Anwendungen betrifft.

Zitat:

Zitat von himitsu

Und was noch ein Vorteil wäre:
- über 2 GB Arbeitsspeicher

Eher 3 GB. Man kann einem 32-Bit Prozess über Einstellung im Compiler mitteilen das die Exe auch mit 3GB lauffähig ist.

[himitsu]

Standardmäßig kann ein 32-Bit-Programm nur 2 GB (2^31, da Signed) nutzen, aber man kann ein bestimmtes PE-Flag setzen und bis zu etwa 3,5 GB freischalten.

Zusammen mit PEA sind aber "offiziell" bei Homesystemen (Windows) bis zu 8 GB und Server 64 GB möglich.



Bei 64 Bit-CPUs sind physikalisch theoretisch bis zu 16 EB möglich, aber praktisch nur bis zu 256 TB, da es nur 48 Adressleitungen gibt.

Die neueren Server-CPUs haben aber alle 64 Adressleitungen.

[Delphi-Laie]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von himitsu

Zitat:

Zitat von himitsu

Und was noch ein Vorteil wäre:
- über 2 GB Arbeitsspeicher

Eher 3 GB. Man kann einem 32-Bit Prozess über Einstellung im Compiler mitteilen das die Exe auch mit 3GB lauffähig ist.

Darf ich fragen, welche Einstellung(en)?

[markus5766h]

@ Bernhard Geyer

.....Die Itanium-Prozessoren waren echte Schnecken was 32-Bit Anwendungen betrifft


Der ITANIUM musste ja den x86-Befehlssatz emulieren ...

[hoika]

Hallo,

Zitat:

Darf ich fragen, welche Einstellung(en)?

Warum sind Leute immer so faul zum suchen ?

Eine Google-Suche "windows 3GB" bringt mir

1


PAE suchen bringt was zur Programmierung


Heiko

[Valle]

Zitat:

Zitat von himitsu

Standardmäßig kann ein 32-Bit-Programm nur 2 GB (2^31, da Signed) nutzen, aber man kann ein bestimmtes PE-Flag setzen und bis zu etwa 3,5 GB freischalten.

Achso, sorry, ich dachte du beziehst dich auf den gesamt theoretisch verfügbaren Speicher.
Von Windows' internem Speichermanagement hab' ich als Linuxer keine Ahnung. :mrgreen:

Liebe Grüße,
Valle

[s.h.a.r.k]

Aber als Linuxer muss man Google weit aus mehr befragen, als ein Windows-User :mrgreen:

[Valle]

Zitat:

Zitat von s.h.a.r.k

Aber als Linuxer muss man Google weit aus mehr befragen, als ein Windows-User :mrgreen:

Das mag sein, aber ich war mir eigentlich recht sicher, dass himitsu was anderes meinte, deswegen hielt ich das nicht für nötig. Außerdem wollt' ich auch mal bisschen klugscheißen, ja? :zwinker:

Liebe Grüße,
Valle

[Horst_]

Hallo,

es gibt doch noch das shootout Spiel:
64-Bit:
http://shootout.alioth.debian.org/u6...p?lang=fpascal

Code:

Program     N    CPU secs   Elapsed secs   Memory KB   Code B
binary-trees     12   0.13   0.13   ?   769
binary-trees     16   2.06   2.08   7,192   769
binary-trees     20   44.93   44.93   131,420   769

32-Bit:
http://shootout.alioth.debian.org/u3...p?lang=fpascal

Code:

Program    N    CPU secs   Elapsed secs   Memory KB   Code B
binary-trees     12   0.10   0.11   ?   769
binary-trees     16   1.60   1.60   4,176   769
binary-trees     20   36.44   36.44   65,684   769

64-Bit ist langsamer, es wird ja auch die doppelte Datenmenge bewegt.
Wenigstens ist 64-Bit bei k-nucleotide 25,000,000 wirksam/ ohne Fehler im Ablauf.

Ein Vorteil von 64-Bit ist der Umstand, dass die 1 Gbyte Grafikkarte Dir nicht den Hauptspeicher um diese Größe eindampft, weil nun in einem Adressbereich oberhalb 4 GByte liegen kann, jedenfalls waren bei mir 3,9 Gbyte frei statt 3,5 Gbyte (ja nur eine kleine Grafikkarte ;-) ).
Programmtechnisch könnten die 8 zusätzlichen CPU-Register etwas beschleunigend wirken, wenn die Kompiler das auch nutzt und auch alle Daten schön aligned ausrichtet sind.

Gruß Horst

[Luckie]

Also unter 32-Bit kann man 2^32 Adressen ansprechen und das sind 4294967296 Stück. Mehr Speicher kann ein 32-Bit OS nicht verwalten. Unter Windows hat jeder Prozess seinen eigenen, geschützten Adressraum. Dieser ist genau 2^32 GB groß. Da aber ein Prozess nicht aus seinem Adressraum so einfach rauskommt, er aber natürlich die Betriebssystemfunktionen braucht, werden diese in seinen Adressraum eingeblendet. Dem Betriebssystem steht dazu die Hälfte des Adressraumes zu: 2GB. Demzufolge kann ein Prozess über die restlichen 2GB frei verfügen. Mit einem Schalter kann man den frei verfügbaren Adressraum für einen Prozess auf 3GB vergrößern. Dies ist aber nicht zu empfehlen, da dann für das Betriebssystem nur noch 1GB übrig bleiben.

So, womit ich mich noch nicht beschäftigt habe, ist wie der Adressraum und dessen Verwaltung unter 64-Bit aussieht. Wenn ich da mal was gescheites zu lesen finden würde im Internet oder so, wäre das eine schöne Sache. Sehe gerade ist genauso: halbe/halbe. 16TB davon 8TB für das Betriebssystem und 8TB für den Prozess.
http://msdn.microsoft.com/de-de/library/bb978906.aspx

Was jetzt interessant wäre bei der Geschwindigkeit: Ist das gleiche Programm einmal als 64-Bit unter einem 64-Bit OS schneller als 32-Bit unter einem 32-Bit OS.

[Bernhard Geyer]

Es ist eigentlich nebenwirkungsfrei einem 32-Bit Prozess (hier D6 mit FastMM) per Compilerflag eine 3GB-Adressierung zu ermöglichen. Was problematisch ist, in einem 32-Bit Windows diese Adressierung freizuschalten, da es genügend HW-Treiber für Win32 gibt die damit nicht klar kommen.

Für uns war mal dieser Schalter die einzige Möglichkeit ein Problem per Hotfix zu lösen. Normalerweise lassen wir aber das Programm mit max. 2GB laufen. Selbst bei größeren DB's im 2stelligen GB-Bereich kommt unsere Programm sehr selten über 100-200 MB Speichernutzung.

[Luckie]

Zitat:

Zitat von Bernhard Geyer

per Compilerflag eine 3GB-Adressierung zu ermöglichen.

Dann muss aber auch Windows mit dem entsprechenden Flag gestarte werden:

Zitat:

Virtual Address Space für 32-Bit-Prozesse: 2GB (3 GB, wenn das System mit Option /3GB gestartet wurde)

[FAlter]

Hi,

auch mal was sagen...

Zum Thema 32-Bit-Programm mit mehr als 2 GB (in die DPR):

Delphi-Quellcode:

{$SetPEFlags $20} //IMAGE_FILE_LARGE_ADRESS_AWARE

Achtung: Der Standard-Memorymanager von Delphi < 2006 rechnet mit Vorzeichen!

Zum Thema Adressraum:
Unter 64-Bit ist physikalische = logische Adresse. Speichersegmentierung gibt es nicht mehr.

Gruß
FAlter

[Luckie]

Speichersegemente gab es auch unter 32-Bit nicht mehr. der Adressraum ist linear ansprechbar. Nur gibt es unter 64-Bit keinen virtuellen Adressraum mehr, deswegen gilt, wie du sagst physikalische Adresse = logische Adresse.

[Bernhard Geyer]

Zitat:

Zitat von FAlter

Achtung: Der Standard-Memorymanager von Delphi < 2006 rechnet mit Vorzeichen!

Könnte sein. Da wir aber seit Jahren auf FastMM angewiesen sind (Fragmentierungsproblem des alten Speichermanagers) ist uns das nicht aufgefallen.

[Horst_]

Hallo,

www.ece.neu.edu/students/dye/papers/iiswc06.pdf zeigt einen Vergleich von 64-Bit/32-Bit in der Anwendungsperformance und die Gründe für die Vor/Nachteile.
Wenn viel FPU Rechnerei vorliegt und/oder viele Register von Vorteil sind -> 64-Bit.
Die meisten Anwender werden nicht über mehrere Gigabyte gleichzeitig verarbeiten müssen, aber wer weiß, es reichen ja 640 kByte ;-)

Gruß Horst

[Elvis]

Zitat:

Zitat von Delphi-Laie

Zur Zeit interessiert mich der Geschwindigkeitsvorteil von 64 gegenüber 32 Bit. Den festzustellen kommt zur Zeit ja nur Lazarus infrage.

Freepascal taugt für diesen Vergleich leider nicht viel. Nicht wenn du daraus schließen willst, was dich mit Delphi64 erwarten wird.
Denn FPC64 scheint nicht großartig anderen Code zu erzeugen als die 32Bit Variante. Es wird nicht "aggressiv" für die Register und den Befehlsatz optmimiert, den man auf AMD64 CPU voraussetzen kann.
Ein Delphi64 compiler würde höchstwahrscheinlich besseren Code erzeugen. Aber das wissen wir erst wenn er da ist, und wenn er 5 Jahre später die meisten Kinderkrankheiten losgeworden ist.

Wenn du also wirklich jetzt wissen willst was dir x64 bringt, wäre wohl eine Test suite für einen Compiler, der x64 auch tatsächlich nutzt, angemessener.
Pascal Code kannsu da natürlich nicht erwarten.

[Delphi-Laie]

Zitat:

Zitat von hoika

Hallo,

Zitat:

Darf ich fragen, welche Einstellung(en)?

Warum sind Leute immer so faul zum suchen ?

Eine Google-Suche "windows 3GB" bringt mir

1


PAE suchen bringt was zur Programmierung


Heiko

Den Faulheitsvorwurf verbitte ich mir und weise ihn brüsk zurück!

Lesen Sie mal bitte, was oben geschrieben wurde:

Zitat:

Zitat von himitsu

"Bernhard Geyer

Zitat:

Zitat von himitsu

Und was noch ein Vorteil wäre:
- über 2 GB Arbeitsspeicher

Eher 3 GB. Man kann einem 32-Bit Prozess über Einstellung im Compiler mitteilen das die Exe auch mit 3GB lauffähig ist.

Die exe! Und so suchte ich natürlich - wo auch sonst?! - in den Compileroptionen meiner Delphis (!) bis hinauf zum Turbo-Delphi nach einer mir bis dato unbekannten 3-GByte-Einstellung/-Option. Natürlich Fehlanzeige.

Die 3-GByte-Startoption kenne ich schon lang und verwende sie auch seit geraumer Zeit. Jedoch werden, soweit mir bekannt, damit nur der gesamten Anwendungssoftware (also wohl den Programmen, die im Usermodus laufen) die 3 GByte zugewiesen, die 2-GByte-Schranke gilt dennoch für jedes Programm.

Also erlaube ich mir, meine Frage zu wiederholen: Wo bitteschön kann man dem Compiler mitteilen, daß die Exe-Datei 3 GByte nutzt?

Edit: FastMM scheint wohl das Stichwort dazu zu sein.

[himitsu]

FastMM oder ein beliebiger SpeicherManager, welcher damit umgehen kann
UND der PF-Flag, welches die Speicherverwaltung seitens Windows (z.B. VirtualAlloc) dafür freischaltet.
Grund:
"Früher" wurde oftmals ein ungültiger Pointer durch (P < 0) gekennzeichnet und/oder oder das oberste Bit für Statusinformationen mißbraucht (dieses Bit konnte ja eh nicht für die Speicherverwaltung verwendet werden).

Darum sperrt Windows erstmal die Nutzung dieses Bits, damit die "älteren" Programme auch noch lauffähig sind.
Programme, welche aber dieser Einschränkung nicht unterliegen, können Windows über das PE-Flag ( {$SetPEFlags $20} ) dieses mitteilen und kommen dann in den Genuß dieser erweiterten Möglichkeiten.

[JamesTKirk]

Zitat:

Zitat von Luckie

Also unter 32-Bit kann man 2^32 Adressen ansprechen und das sind 4294967296 Stück. Mehr Speicher kann ein 32-Bit OS nicht verwalten.

Das ist so nicht ganz korrekt... es gibt nämlich die Physical Address Extension, die ausnutzt, dass 32-Bit Prozessoren einen 36-Bit breiten Addressbus besitzen. diese Erweiterung gilt allerdings nur für den vom OS verwaltbaren Arbeitsspeicher, nicht aber für den Prozessadressraum.

Gruß,
Sven

[Insider2004]

Ich rate dringend davon ab, über 2GB zu gehen. Der Schalter ist nicht ohne Grund optional und versteckt. Sonst hätte ja Borland den per default eingebaut. Es ist durchaus möglich, dass 99% des Codes schön mit 3GB laufen, Aber wehe, ein Programteil castet einen Pointer. Dann wird der Pointer verbogen und zeigt irgendwo hin. Das Programm verabschiedet sich.

[Micha88]

Wirkt sich eine Performancesteigerung auch auf das Arbeiten mit größeren Werten als Int64 aus? Mir schwebt da z.B. Extended vor.

[Medium]

Extended war bereits ein ein Register breit, und der Datentyp ist eigentlich auch mehr ein Hack, da dies nur das FPU interne Format sein sollte. Vor allem: FPU! Ob die ALU dabei 64 Bit, 32 16 oder 8 hat ist der prinzipiell erstmal egal. Einzig, wenn man Floats durch die CPU Register schubsen muss helfen die 64 Bit, aber dann auch nur bei Double so wirklich. Kurzantwort also: Nein, Langantwort: In konstruierten Ausnahmefällen in Nuancen vielleicht, aber für die Praxis wohl nicht relevant.

[Stevie]

Zitat:

Zitat von Micha88 (Beitrag 1135140)

Wirkt sich eine Performancesteigerung auch auf das Arbeiten mit größeren Werten als Int64 aus? Mir schwebt da z.B. Extended vor.

Der Witz an der Sache ist sogar, dass Extended unter 64-bit auch nur noch 8 Byte groß ist und nicht 10, wie unter 32-bit.

Nen bisschen was über 64-bit und floating point Performance kann man bei Eric Grange auf dem Blog lesen:

http://delphitools.info/2011/09/02/f...t-performance/

http://delphitools.info/2011/09/05/x...isappointment/

http://delphitools.info/2011/09/09/h...precision-off/

[Micha88]

Zitat:

Der Witz an der Sache ist sogar, dass Extended unter 64-bit auch nur noch 8 Byte groß ist und nicht 10, wie unter 32-bit.

Mh. Das heißt, die Zahlen sind wohl kleiner.

Was sollte man bei XE2 statt Extended denn dann wohl besser nehmen?

[BUG]

Zitat:

Zitat von Micha88 (Beitrag 1135258)

Mh. Das heißt, die Zahlen sind wohl kleiner.
Was sollte man bei XE2 statt Extended denn dann wohl besser nehmen?

Vor allem ist die Genauigkeit geringer.
Mit viel Aufwand könnte man einen Record mit überladenen Operatoren schreiben, der Extended simuliert (nicht zu vergessen die passende Funtionen: Sin, Arcsin, Cos, Arcos, Abs, ...).

Das wäre doch was, wenn wieder jemand fragt, was er machen soll :mrgreen:

[TiGü]

Zitat:

Zitat von BUG (Beitrag 1135270)

Zitat:

Zitat von Micha88 (Beitrag 1135258)

Mh. Das heißt, die Zahlen sind wohl kleiner.
Was sollte man bei XE2 statt Extended denn dann wohl besser nehmen?

Vor allem ist die Genauigkeit geringer.
Mit viel Aufwand könnte man einen Record mit überladenen Operatoren schreiben, der Extended simuliert (nicht zu vergessen die passende Funtionen: Sin, Arcsin, Cos, Arcos, Abs, ...).

Das wäre doch was, wenn wieder jemand fragt, was er machen soll :mrgreen:

Oder man nutzt einfach das, was schon da ist:
http://docwiki.embarcadero.com/Libra...TExtended80Rec

[Medium]

Leider (aus dem Link):

Zitat:

Hinweis: Der Typ Extended80 wird für die Arbeit mit binären Daten mit den 32-Bit-Versionen von Delphi verwendet. Obwohl Extended80 10 Byte groß ist, kommen Berechnungen mit diesem Typ vor, die eine doppelte 8-Byte-Genauigkeitsarithmetik verwenden. D.h., Extended80 dient nur der Darstellungskompatibilität, es fügt 64-Bit-Delphi keine Berechnungsmöglichkeiten für eine erweiterte 10-Byte-Genauigkeit hinzu.

[Micha88]

Also bisher habe ich bei XE2 (Trial) nur Nachteile entdeckt. So ist eine leere Form bei x86 6 MB und x64 7,5 MB groß.

[Darlo]

Zitat:

Zitat von Medium (Beitrag 1135285)

Leider (aus dem Link):

Zitat:

Hinweis: Der Typ Extended80 wird für die Arbeit mit binären Daten mit den 32-Bit-Versionen von Delphi verwendet. Obwohl Extended80 10 Byte groß ist, kommen Berechnungen mit diesem Typ vor, die eine doppelte 8-Byte-Genauigkeitsarithmetik verwenden. D.h., Extended80 dient nur der Darstellungskompatibilität, es fügt 64-Bit-Delphi keine Berechnungsmöglichkeiten für eine erweiterte 10-Byte-Genauigkeit hinzu.

Die Release-Version ist erheblich kleiner.

http://www.delphipraxis.net/164359-x...ml#post1135292

Edit: Ups, war ja Dein eigenes Thema....

[Stevie]

Zitat:

Zitat von Micha88 (Beitrag 1135288)

Also bisher habe ich bei XE2 (Trial) nur Nachteile entdeckt. So ist eine leere Form bei x86 6 MB und x64 7,5 MB groß.

Die Größe einer leeren Anwendung steigt schon seit Jahren durch Erweitung der Runtime und vor allem der RTTI. Wen das in Zeiten von Gigabit Lan, 100 MBit Internet und Terabyte Festplatten stört (weil er eventuell auf Bandbreite etc achten muss), hat die Möglichkeit, die RTTI explizit zu entfernen, mit Runtime packages zu arbeiten (wo man dann beim neu Deployen nur seine Anwendung und nicht die Packages nochmals übermitteln muss).

Beachte aber auch, dass die Größe einer leeren Applikation nahezu keine Aussagekraft hat (übrigens ist die Standard Config auf Debug gesetzt, die sind standardmäßig nochmal um einiges größer). Interessant wird es, wenn es eine richtige Applikation ist, und dann fällt das u.U. nicht mehr ins Gewicht.

[TiGü]

Zitat:

Zitat von Medium (Beitrag 1135285)

Leider (aus dem Link):

Zitat:

Hinweis: Der Typ Extended80 wird für die Arbeit mit binären Daten mit den 32-Bit-Versionen von Delphi verwendet. Obwohl Extended80 10 Byte groß ist, kommen Berechnungen mit diesem Typ vor, die eine doppelte 8-Byte-Genauigkeitsarithmetik verwenden. D.h., Extended80 dient nur der Darstellungskompatibilität, es fügt 64-Bit-Delphi keine Berechnungsmöglichkeiten für eine erweiterte 10-Byte-Genauigkeit hinzu.

Extended80 <> TExtended80Rec!

Oder hab ich mich verguckt?

[Medium]

Ich hab mich verquoted :oops:

Gleich darüber steht:

Zitat:

In Delphi unter Win32 ist der Extended-Datentyp 10 Byte groß. Unter Win64 ist der Extended-Datentyp jedoch nur 8 Byte groß. TExtended80Rec ermöglicht unter Win64 die Durchführung von speicherbezogenen Operationen mit 10-Bit-Gleitkommavariablen, aber keine arithmetischen Operationen mit der Genauigkeit "extended".

[JamesTKirk]

Free Pascal verfügt über eine "SoftFPU" Unit, welche es letztendlich erlauben soll 32, 64, 80 und 128 Bit Operationen in Software durchzuführen (mit dazugehörigen Datentypen). Die Unit soll letztendlich dazu verwendet werden, um von Systemen, die keinen 80-Bit Datentyp unterstützten (x86_64, ARM), auf Systeme zu kompilieren, die das tun (x86). Das Problem ist nämlich, dass Konstanten vom Compiler immer mit der höchsten für die Zielplattform verfügbaren Genauigkeit evaluiert werden sollten. Von x86 nach x86_64 ist das kein Problem, da der Compiler dann einfach nur mit der 64-Bit Genauigkeit evaluiert, aber von x86_64 nach x86 ist das problematisch, da ersterer nur bis 64-Bit Genauigkeit anbietet. Dies kann im Worstcase zu Programmen führen, die sich unterschiedlich verhalten je nachdem ob sie nativ unter x86 oder cross kompiliert wurden. Das darf natürlich nicht sein.
Die Unit basiert auf C-Code und ist leider noch nicht komplett konvertiert (nur die 32 und 64 Bit Operationen sind bereits konvertiert).

Gruß,
Sven

[Lemmy]

Zitat:

Zitat von Micha88 (Beitrag 1135288)

Also bisher habe ich bei XE2 (Trial) nur Nachteile entdeckt. So ist eine leere Form bei x86 6 MB und x64 7,5 MB groß.

um Anwendungen zu schreiben, die nur ein leeres Formular beinhalten ist Delphi mit ziemlicher Sicherheit kein gutes Werkzeug... ;-)

Wobei mich schon brennend interessieren würde woher der massive Anstieg von XE kommt...

[Bernhard Geyer]

Zitat:

Zitat von Micha88 (Beitrag 1135288)

Also bisher habe ich bei XE2 (Trial) nur Nachteile entdeckt. So ist eine leere Form bei x86 6 MB und x64 7,5 MB groß.

Debug-Infos und Erweiterte RTTI abschalten und schon wirds um einiges kleiner.