Delphi und 64-Bit Programme

[Harry Stahl]

Danke für Euer Feedback.

Es ging mir jetzt nicht speziell um dieses StringList-Demo. Wie man die zitierte 2GB großte Text-Datei (mit 17,5 Mio Zeilen) trotzdem in eine Stringlist laden kann, weiß ich (Daniel hat es schon angedeutet, mit Hilfe eines Streamreaders)).

Es ging mir um die generelle Frage, ob man die Klassen (z.B. mit Überladungen) auf 64-Bit Nutzung umstellen bzw. erweitern sollte. Könnte mir vorstellen, z.B. bei größeren Simulationen, wo z.B. 5 Mrd. Werte wegen der Echtzeit-Anforderung im Arbeitsspeicher gehalten müssen, es u.U. doch in irgendeinem Zusammenhang auch hilfreich sein könnte, ein TDictionary zu verwenden. Aber auch das könnte ich nicht verwenden, da dort in der Klasse z.B. "FCount" und alle anderen relevanten Zahlenwerte Integer sind.

Mir ist schon klar, dass ist hier eine Diskussion von untergeordneter Relevanz und nichts was jetzt in Delphi vorrangig behandelt werden müsste (wenn überhaupt).

Mich hat es nur interessiert, ob irgendjemand hier auch schon mal an ähnliche Grenzen in Umgang mit sehr großen Datenmengen in Zusammenhang mit 32/64 Bit Implementierung der Standard-Delphi Klassen gestoßen ist und irgendwo Erweiterungsbedarf gesehen hätte.

[jaenicke]

Sicher wäre es wünschenswert, wenn es weniger Grenzen geben würde. Allerdings sollte man dabei auch nicht vergessen, dass die vorhandenen Klassen für so große Datenmengen, wie Daniel auch schon angedeutet hat, schlicht nicht ausgelegt sind.

Es wäre daher sinnvoller für diesen Zweck nicht die vorhandenen Klassen zu erweitern, sondern komplett neue zu entwickeln, die intelligenter mit solchen Datenmengen umgehen. Zum Beispiel wäre es sinnvoll, wenn man mit mehreren Threads arbeiten könnte, um so die Lade- und Zugriffszeiten zu verkleinern.

Dafür wären aber ganz andere Ansätze erforderlich als sie aktuell in Delphi implementiert sind. In anderen Systemen gibt es dafür ja auch schon einiges.

[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)