Delphi und 64-Bit Programme

[jobo]

Da kann ich nur zustimmen. Schön wär's, wenn die alten Verfahren nur mit größeren Typen kompiliert werden müssten. Aber das ist nur ein Traum.

Dann also lieber neu, mit besseren Strategien. Es gibt (jenseits von XML) Datenformate, die extra für Streaming leicht verändert werden bzw. speziell für Streaming empfohlene Verfahren.

Hab mal zum Spaß 2GB XML in VS Code geöffnet. Ich hätte es ihm zugetraut, aber auch nach diversen Warnungen "starte mich neu mit 4GB Speicherreservierung" war da nichts zu machen. Was VS Code ganz nett macht, es schaltet mit einem Hinweis das Parsing bei großen Dateien ab, deswegen war ich auf die Idee gekommen, das einfach mal doof auszuprobieren. Anderswo wird also auch nur mit Wasser gekocht.

[HRolle]

Für große Textdateien, natürlich auch für große XML-Dateien, würde ich Notepad++ (kann in der neuesten Version 8.3 mit Dateien > 2GB umgehen) oder PilotEdit (kann in der professionellen Variante bis zu 400GB große Dateien editieren) empfehlen. Beide Programme arbeiten offensichtlich mit Streaming, halten also nur eine bestimmte Teilmenge des Textes im Hauptspeicher.

Für große Datenfelder, wie gelegentlich bei Simulationsrechnungen notwendig, würde ich ebenfalls mit Streams oder einer Aufteilung eines Feldes von z.B. 5Mrd Double-Werten in mehrere Teilfelder arbeiten. Der Index im Stream ist bei Delphi die Position-Eigenschaft und die ist Int64.

[hoika]

Hallo,
hier widerspreche ich mal Daniel.

Einer der oft propagierten Vorteile von 64Bit ist ja gerade der Zugriff auf mehr als 2 (?), 4 GB Speicher.
Hier müsste Embarcadero auch bei StringList nacharbeiten.

Andere mit 64Bit erzeugten Programme können das ja auch.

Wobei man ja nicht weiß, wie viel RAM ein Anwender wirklich in seinem Rechner hat.
Oft wird ja Chunking benutzt, also das Aufteilen der Datei in einzelne Bereiche.
Unter 64Bit könnten größere Bereiche oder mehr Bereiche geladen werden, in Abhängigkeit des tatsächlichen Speichers.

Ich hatte mal unter 32Bit mit StringList's in einer StringList gearbeitet, dass klappte sogar ...

[Der schöne Günther]

Gibt es nicht ganz genau dafür den Typ NativeInt?

Zitat:

NativeInt repräsentiert eine Untermenge der Integer-Zahlen. Der Bereich von NativeInt ist von der aktuellen Plattform abhängig. Auf 32-Bit-Plattformen entspricht NativeInt dem Typ Integer. Auf 64-Bit-Plattformen entspricht NativeInt dem Typ Int64.

Meine Schleifenvariablen, Array-Indizes usw. sind auch immer vom Typ NativeInt .

Ist ja in anderen Sprachen genauso (size_t in C++, isize/usize in Rust, ...).

[jaenicke]

Zitat von hoika:

Hier müsste Embarcadero auch bei StringList nacharbeiten.

Andere mit 64Bit erzeugten Programme können das ja auch.

Die arbeiten dann aber auch nicht mit einer String-basierten Struktur wie einer TStringList. Denn auch z.B. in C# oder anderen .NET Sprachen können Strings nicht länger sein... das Limit ist ähnlich wie bei Delphi.

Wenn man geeignete Klassen wie eben einen Stream verwendet, kann man ja auch in Delphi problemlos mehrere GiB in den Speicher schaufeln.

[Sinspin]

Ich dachte das Integer der generische Typ ist und automatisch zu Int64 wird, wenn man auf 64Bit als Zielpattform übersetzt.
Früher war das jedenfalls mal so das aus 16 Bit Integer 32 Bit wurden beim Umstieg auf ein neueres Delphi (incl schöner Probleme beim lesen von Binärdateien, bei denen man keinen Gedanke auf das Anpassen des Loaders verschwendet hatte)

[TheDelphiCoder]

Das war wohl so beim Wechsel von Delphi 1 zu Delphi 2.
Integer bleibt aber tatsächlich bei 4 Byte. Wenn es automatisch gehen soll, dann brauchst NativeInt bzw. NativeUInt.

[dummzeuch]

Zitat von TheDelphiCoder:

Das war wohl so beim Wechsel von Delphi 1 zu Delphi 2.
Integer bleibt aber tatsächlich bei 4 Byte. Wenn es automatisch gehen soll, dann brauchst NativeInt bzw. NativeUInt.

Außer man verwendet (auch) noch ein älteres Delphi, bei dem NativeInt auch für 32 Bit Programme als 64 Bit deklariert ist. Das gilt für Delphi 7 bis 2007.

[jaenicke]

Zitat von Sinspin:

Ich dachte das Integer der generische Typ ist und automatisch zu Int64 wird, wenn man auf 64Bit als Zielpattform übersetzt.

Das hätte man erwarten können, aber da Intel und andere den generischen Integer-Typ bei 32-Bit belassen haben, blieb kaum etwas anderes übrig als dem auch mit Delphi zu folgen, so verwirrend und folgenschwer das auch war.

[Uwe Raabe]

Zitat von Sinspin:

Ich dachte das Integer der generische Typ ist und automatisch zu Int64 wird, wenn man auf 64Bit als Zielpattform übersetzt.

Das ist teilweise immer noch so: Platform-dependent integer types

LongInt entspricht bei 32-Bit und bei 64-Bit Windows einem 32-Bit Wert, bei 64-bit POSIX (incl. iOS und Linux) aber einem 64-Bit Wert. Wie Sebastian schon sagte, hat man sich da an den entsprechenden Vorgaben seitens Intel und Microsoft orientiert. In C# ist ein int halt immer ein 32-Bit Wert - in Objective C aber nicht.