Delphi und 64-Bit Programme

[Bernhard Geyer]

Zitat von Uwe Raabe:

Zitat von hoika:

Ja, aber mit 64Bit muss auch der komplette 64Bit-Speicherbereich ausgenutzt werden!

Das fände ich jetzt aber sehr unfair gegenüber den anderen Anwendungen.

[Uwe Raabe]

Zitat von Sinspin:

Wen juckt das überhaupt wie der intern aufgebaut ist?

Da ist in der Tat was dran. Rein von der Speicherstruktur sehe ich da kein wirkliches Hindernis. Allerdings gibt es etliche Stellen im Source, bei denen implizit eine String-Länge und auch die Indizierung mit 32-Bit angenommen wird. Das ist ein nicht zu unterschätzender Aufwand, unweigerlich begleitet von potentiell signifikanten Fehlerquellen.

Übrigens ist WideString auch keine Alternative (eigentlich sogar ein Rückschritt), da das interne Datenformat auch hier 4 Bytes für die Länge reserviert - dummerweise diesmal in Bytes, so dass ein WideString nur halb so lang werden darf wie ein string.

[TigerLilly]

Hmm. Egal, ob ich Code für 64 Bit oder 32 Bit kompiliere, ich gehe davon aus, dass der Code - nur für sich genommen - funktioniert. Schnittstellen, Dateien etc sind außen vor, das ist bei UniCode ja auch so. Dass ich mir beim Compilieren für 64 Bit überlegen muss, ob mein Code per se funktioniert, ist nicht so toll. Woher weiß ich denn, was in der RTL nicht funktionieren würde?

[Uwe Raabe]

Zitat von TigerLilly:

Woher weiß ich denn, was in der RTL nicht funktionieren würde?

Wenn du dich hierauf beziehst:

Zitat von Uwe Raabe:

Das ist ein nicht zu unterschätzender Aufwand, unweigerlich begleitet von potentiell signifikanten Fehlerquellen.

dann betrifft dieser Aufwand natürlich Embarcadero, sollten sie irgendwann mal 64-Bit-Strings unterstützen wollen. Für den Anwender (also uns) sollte das weitestgehend transparent sein.

[jziersch]

Braucht man wirklich Strings mit Int64 Länge? Was soll das bringen.

Für grosse Daten gibts ja MemoryStreams - die haben auch nicht das Problem, dass zwischen irgendwelchen codepages hin und her gewandelt wird. Viele moderne Speicherformate verwenden nur 8 Bit, also RTF, XML, HTML ... da strings mit seinen WideChar zeichen auch nicht aussreicht alle Zeichen zu codieren. Die Speicherung solcher Daten in einen "string" fürhrt dann regelmässig zu 00nn00nn00nn00nn.

Dass ein Integer 32 bit hat, auch unter 64 bit war meiner Ansicht nach die genau richtige Entscheidung, da der Entwickler so explizit die Möglichkeit hat zu entscheiden, ob der große Typ erforderlich ist, oder nicht und "alte" Programme 1:1 laufen.

Wichtig ist es aber IntPtr zu verwenden für alle Integer die auch Speicheradressen sein können- typischerweise für die Übergabe an SendMessage u.ä.

[jaenicke]

Zitat von jziersch:

Für grosse Daten gibts ja MemoryStreams

Ein Memorystream ist ja nicht so recht vergleichbar. Aber auch ein TArray ist nicht auf MaxInt als Länge beschränkt und eignet sich für große Datenmengen deutlich besser als ein String.

[Uwe Raabe]

Zitat von jziersch:

Braucht man wirklich Strings mit Int64 Länge?

Die Frage wollte ich eigentlich auch stellen. Allein schon das Hantieren mit 2GB Strings ist schon heikel genug. Bei jedem Copy-on-Write werden da mal eben weitere 2GB am Stück belegt. Einige Dinge sollte man mit so großen Strings einfach nicht machen. 64-Bit hin oder her, das ist einfach Verschwendung und schreit schon wegen der Performance nach einem anderen Ansatz. Computer sind zwar bekanntermaßen schnell, aber bei zu vielen Daten brauchen sie halt auch ihre Zeit. Mit einem effizienteren Algorithmus wird es dann meist nicht nur schneller, sondern braucht häufig auch weniger Speicher.

Man stelle sich nur mal vor, man würde eine 32GB Textdatei in einen solchen 64-Bit String einlesen. Ist die Datei UTF-8 codiert, kommen da ca. 64GB Speicherverbrauch zusammen. Da käme so manches handelsübliche Notebook schon an seine RAM-Grenzen und müsste Speicher auslagern, der dann später wieder eingelesen werden muss. Effizient geht anders.

Ich wäre als wirklich an konkreten Beispielen interessiert, wo Strings mit mehr als 2^30 Zeichen notwendig oder hilfreich (bequemer zählt nicht) wären.

[Sinspin]

Zitat von Uwe Raabe:

Allein schon das Hantieren mit 2GB Strings ist schon heikel genug. Bei jedem Copy-on-Write werden da mal eben weitere 2GB am Stück belegt. Einige Dinge sollte man mit so großen Strings einfach nicht machen. 64-Bit hin oder her, das ist einfach Verschwendung und schreit schon wegen der Performance nach einem anderen Ansatz.

Es geht ja nicht um die Realität, sondern um die theoretische Fähigkeit es tuen zu können ohne das es knallt.

Allerdings ging es garnicht um String sondern um TStrings (System.Classes.TStrings ).

Zitat von Uwe Raabe:

Man stelle sich nur mal vor, man würde eine 32GB Textdatei in einen solchen 64-Bit String einlesen.

Genau um sowas, eine Datei die etwas größer ist, in TStrings zu laden.
Also ein Zeilenweises array of String. Das sollte doch gehen?
Interessant ist die Frage, was passiert bei den Properties CommaText und Text, denn die sind String .

[jaenicke]

Zitat von Sinspin:

Genau um sowas, eine Datei die etwas größer ist, in TStrings zu laden.
Also ein Zeilenweises array of String. Das sollte doch gehen?
Interessant ist die Frage, was passiert bei den Properties CommaText und Text, denn die sind String .

Genau deshalb klappt das ja nicht. Die Implementierung könnte man (abgesehen von diesen Properties) relativ einfach anpassen, damit Dateioperationen möglich wären.

Aber mit TFileStream usw. gibt es ja sinnvolle Möglichkeiten für große Dateien.

[Uwe Raabe]

Zitat von Sinspin:

Genau um sowas, eine Datei die etwas größer ist, in TStrings zu laden.
Also ein Zeilenweises array of String. Das sollte doch gehen?

Das tut es ja jetzt schon, wenn man es entsprechend lädt. Also nicht mit Zuweisung von Text, CommaText oder LoadFromFile bzw. LoadFromStream. Die würden in der Tat 64-Bit Strings erfordern.

Zitat von Sinspin:

Interessant ist die Frage, was passiert bei den Properties CommaText und Text, denn die sind String .

Eben, das knallt dann halt. Das ist aber meiner Meinung nach durchaus OK. Es ist eigentlich nicht zu rechtfertigen, dass man, nur um solche Sonderfälle abzudecken, den ganzen Unterbau auf 64-Bit Verträglichkeit auslegt. Auch in 64-Bit sind die meisten TStrings Instanzen mit überschaubaren Inhalten versehen.

Aber wie Sebastian schon schreibt, spricht ja auch nichts dagegen eine Ableitung von TStringList zu schreiben, bei der die LoadFromStream/SaveToStream Implementierungen eben nicht über SetTextStr/GetTextStr laufen. Dann könnte man diese ja auch für größere Dateien verwenden.

Als Nebeneffekt würde auch der interne Buffer für das Encoding wegfallen. Da liegt nämlich auch noch ein Speicherfresser: Erst wird ein Buffer angelegt, der den kompletten Inhalt der Datei in den Speicher lädt. Dann wird daraus anhand des Encodings ein String gemacht, bevor dieser dann zeilenweise zerlegt in die interne Liste wandert. Das braucht dann temporär mal eben so etwa 5x soviel Speicher wie die Datei groß ist (danach dann 2x).

Wie man dann allerdings halbwegs performant mit so einer Monster-Stringliste umgehen soll steht auf einem anderen Blatt.