Entwickler-Ecke
Programmierwerkzeuge - Delphi 7 --> neuere Version: Portierung viel Arbeit?
GuaAck - Do 27.08.20 23:14
Titel: Delphi 7 --> neuere Version: Portierung viel Arbeit?
Hallo,
der Empfehlung folgend habe ich mal einen neue Thread eröffnet zu dem im letzten Beitrag diskutierten Thema; aber meine Frage ist doch etwas anders.
Ich nutze Delphi 7, fast ausschließlich privat und gelegentlich für kleinere freiberufliche Arbeiten, die bzgl. der Privat-Nutzungslizenz unbedenklich sind, das habe ich prüfen lassen.
Vor etwa 5 Jahren hätte ich eine damals aktuelle Delphi-Version mit der Private-Nutzung-Lizenz sehr günstig erwerben können. Ich habe mir dann eine Demo-Version o.ä. installiert und festgestellt, dass es viele der in meinen Programmen verwendeten Standard-Delphi-Units nicht mehr gab und es aber viele andere Units gab. Da ich eine umfangreiche eigene Library habe, die ich laufend nach Bedarf erweitere, sah ich da viel Arbeit und bin bei Delphi 7 geblieben.
Mein Motiv für den Wechsel wäre neben dem "mal was Neues", der sicher besseren IDE auch die 64-Bit-Nutzung gewesen, auch wenn der Geschwindigkeitsgewinn gegenüber 32-Bit eher wenige als 10 % als mehr gewesen wäre.
Hat da jemand Erfahrung? Ich würde nach wie vor gerne auf eine moderne Version umsteigen.
Gruß
GuaAck
Narses - Fr 28.08.20 00:51
Moin!
Ich greife mal
jaenicke´s ganz sicher kurzfristig folgender Empfehlung der aktuell
sten Delphi-Version vor. :zwinker: :wave:
GuaAck hat folgendes geschrieben  : |
| der sicher besseren IDE |
Geschmacksache. :nixweiss: Vor dem Nutzen der ggfs. neueren Möglichkeiten ist erstmal eine lange Durststrecke der Eingewöhnung. ;) Schlimmer sind eigentlich die neuen Sprachfeatures, z.B. den Generics weine ich schon sehr schmerzhaft hinterher... :cry:
| GuaAck hat folgendes geschrieben : |
| 64-Bit-Nutzung gewesen, auch wenn der Geschwindigkeitsgewinn gegenüber 32-Bit eher wenige als 10 % als mehr gewesen wäre. |
Ein weit verbreiteter Irrtum, IMHO. :? Wenn du nicht auf den größeren Adressbereich einer 64bit-Anwendung angewiesen bist, dann gibt es praktisch keinen Vorteil. Im Gegenteil, da bei einer 64bit-Anwendung auch mehr Daten "bewegt" werden müssen (unterstellt, die 2GiB eines 32bit-Prozesses reichen aus), läuft eine 64bittige Anwendung messbar
langsamer als eine vergleichbare 32bittige!
| GuaAck hat folgendes geschrieben : |
| sah ich da viel Arbeit und bin bei Delphi 7 geblieben. |
Jap, das wird definitiv nicht ohne Anpassungen ausgehen. Hängt natürlich stark davon ab, wie "sauber" du programmiert hast. Häufig sind die größten Probleme im Bereich der Unicode-Strings zu finden.
| GuaAck hat folgendes geschrieben : |
Ich nutze Delphi 7, fast ausschließlich privat und gelegentlich für kleinere freiberufliche Arbeiten
[...]
Mein Motiv für den Wechsel wäre neben dem "mal was Neues" |
IMHO der "beste" Grund für einen Wechsel. Du willst es. Ob du es "brauchst" kannst du ganz leicht feststellen: fehlt dir aktuell was? :idea:
cu
Narses
jaenicke - Fr 28.08.20 08:55
| GuaAck hat folgendes geschrieben : |
| Ich nutze Delphi 7, fast ausschließlich privat und gelegentlich für kleinere freiberufliche Arbeiten, die bzgl. der Privat-Nutzungslizenz unbedenklich sind, das habe ich prüfen lassen. |
Wichtig ist hierbei, dass die aktuelle Community Edition nur eingesetzt werden darf, wenn die gesamten (!) Umsätze 5000 USD nicht überschreiten.
| GuaAck hat folgendes geschrieben : |
| Ich habe mir dann eine Demo-Version o.ä. installiert und festgestellt, dass es viele der in meinen Programmen verwendeten Standard-Delphi-Units nicht mehr gab und es aber viele andere Units gab. |
Die meisten Units gibt es nach wie vor, allerdings heißt z.B. die Unit SysUtils nun System.SysUtils. Wenn man den Namespace, in diesem Fall System, im Projekt hat, kann man die Unit aber auch ohne diesen ansprechen wie früher. Es gibt aber auch Komponenten wie die BDE oder die Socket-Komponenten, die nicht mehr standardmäßig mit installiert werden können.
Von daher lässt sich dazu allgemein wenig sagen ohne konkrete Beispiele, aber damit gab es bei unseren alten Projekten keine Probleme. Unicode hat uns (z.B. da wir sehr alte Socket- und ComPort-Ansteuerungen hatten) noch lange Zeit nach der Umstellung auf damals XE Probleme gemacht, die nicht auf den ersten Blick aufgefallen waren. Das lag allerdings meistens an unsauberer Programmierung wie
Narses schon sagte, allerdings konnte man auch nicht vorhersehen wie sich manches entwickeln würde. Unsere Probleme mit PChar versus PAnsiChar waren vorher allerdings eher schon Fehler, nicht unsaubere Programmierung.
| GuaAck hat folgendes geschrieben : |
| Da ich eine umfangreiche eigene Library habe, die ich laufend nach Bedarf erweitere, sah ich da viel Arbeit und bin bei Delphi 7 geblieben. |
Gerade eine solche eigene Bibliothek hilft bei der Umstellung mehrerer Projekte, denn wenn man diese einmal umgestellt hat, steht sie für alle Projekte zur Verfügung.
Eins ist jedenfalls klar:
Der Abstand deiner Version zur aktuellen Delphiversion wird immer größer. Von daher wird der Aufwand einer Umstellung immer größer. Wenn du also nicht gerade für immer bei deiner jetzigen Version bleiben möchtest, solltest du eher früher als später umstellen. ;-)
Die aktuellen Versionen sind natürlich deutlich weiter und sparen sehr viel Zeit, wenn man die neuen Sprachfeatures nutzt. Wenn du die neue Version genauso nutzt wie die alte und neue Möglichkeiten nicht verwendest, ist der Vorteil nicht so groß abgesehen von einer deutlich übersichtlicheren IDE.
Sprachfeatures wie die von
Narses genannten Generics sind aber schon extrem mächtig und wir schreiben heute kaum noch ein Programm, das diese nicht nutzt.
(Wir haben so etwas ähnliches, man könnte es eher Templates nennen, auch schon vor Generics verwendet. Per Ifdef wurden dann ab 2009 Generics und vorher Templates verwendet, der restliche Quelltext bei der Verwendung einer solchen Liste war identisch.)
Entscheidend ist aber vor allem, dass Delphi 7 unter Windows 10 (bzw. eigentlich schon seit Windows 2000 bei guter Konfiguration, sonst ab Vista) nicht mehr sauber läuft (Schreibzugriffe auf das eigene Verzeichnis, Hilfesystem, ...) und auch damit erstellte Anwendungen nicht mehr sauber überall laufen bzw. man Workarounds braucht (High-DPI, Formularränder, ...). Aus technischer Sicht ist daher ein Umstieg so oder so sinnvoll.
GuaAck - Fr 28.08.20 12:27
Vielen Dank für beide Antworten, sehr aufschlussreich für mich.
Insbesondere die von Jaenicke angesprochene Zukunftsfähigkeit ist für mich ein entscheidendes Argument, also nehme ich mir den Umstieg mal vor.
Viele Grüße
GuaAck
Gausi - Sa 29.08.20 12:14
Ich bin damals von Delphi 7 zu Delphi 2009 gewechselt (habe meine kurz vorher gewonnene RAD 2007 Enterprise-Lizenz als Basis zum Upgrade genommen), und es nicht bereut. Grund war Unicode. Etwas später habe ich nochmal etwas Geld in die Hand genommen für die VCL-Styles. Auch das habe ich nicht bereut, und bin jetzt sehr zufrieden mit den aktuellen Community-Editionen.
Der Umstieg von AnsiString zu UnicodeString kann ggf. etwas holprig sein, gerade wenn man Binär-Dateien mit enthaltenen Texten verwursten muss, oder auch mit WebAPIs kommunizieren möchte (die Zeichen-Kodierung ist da manchmal echt ein Krampf).
Aber der ganze Rest geht relativ problemlos. Ein paar Units in den Uses-Klauseln muss man ggf. umbenennen, aber mir ist jetzt nichts untergekommen, was wirklich "weg" wäre.
Neuere Sprachfeatures wie Generics muss man ja nicht nutzen. Älteren Code darauf anpassen ist dann unter Umständen nochmal etwas Arbeit, aber die muss man sich ja nicht machen. Ohne Generics läuft es auch. ;-)
Von 64-Bit habe ich bisher die Finger gelassen.
GuaAck - Sa 29.08.20 23:25
Hallo Gausi,
ich habe mir gestern noch die Commuty-Edition RAD10.3 (32 Bit) geladen (Lizenz gilt nur für ein Jahr, da hoffe ich, dass man sie von Jahr zu Jahr verlängern kann!) und erste Gehversuche unternommen.
Deine Erfahrung kann ich (für meine Anwendungen) voll und ganz bestätigen. Ich musste die DCUs in meiner Library neu erzeugen, aber dann lief Projekt 1 sofort.
Bei Projekt 2 gibt es einige Fehlermeldungen zu ANSI-String und Unicode, kümmere ich mich demnächst drum. Bei beiden Projeken erhalte ich beim Öffnen des Projektes immer eine Fehlermeldung "Keine Zuordnung für Unicode-Zeichen in der Multibyte-Zielcodeseite", aber die scheint den Betrieb nicht zu stören und wird wohl zu beheben sein. Vielen Forenbeiträgen nach sind wohl falsche Zeichen im Quelltext die Ursache.
Ich werde nach und nach umsteigen.
Gruß
GuaAck
jaenicke - So 30.08.20 00:19
| GuaAck hat folgendes geschrieben : |
| ich habe mir gestern noch die Commuty-Edition RAD10.3 (32 Bit) geladen (Lizenz gilt nur für ein Jahr, da hoffe ich, dass man sie von Jahr zu Jahr verlängern kann!) |
Man bekommt immer eine Lizenz für die aktuelle Version. Du musst also beim Ablauf der Lizenz ggf. auf die dann aktuellste Community Edition umsteigen.
GuaAck - Fr 11.09.20 23:55
Hallo an alle,
hier meine Erfahrungen zu meinem Beginn einer Umstellung von Delphi 7 (32-Bit) auf Delphi 10.3 (RAD Studio, 32-Bit-Version):
Projekt 1, Fast-Fourier (FFT): Viel Gleitkomma-Arithmetik und trigonometrische Funktionen. Es war keine Umstellung nötig, lief sofort. Aber: Mit Delphi 10.3 ist es 30 % langsamer als mit Delphi 7!
Projekt 2, ein Programm um Schachaufgaben zu lösen: Viel Logik und Integer-Arithmetik sowie Umspeichern von Datenblöcken von etwa 100 Bytes. Ein paar Stunden Arbeit für die Umstellung auf UniString war nötig, was in Anbetracht des Umfang des Codes ok ist. Zwar bekomme ich noch 60 Warnungen zu Strings, die aber alle harmlose Textausgaben betreffen. Außerdem noch zwei Warnungen zu Aufrufen zu Funktionen der Window-API. Das Programm läuft jedenfalls. Mit Delphi 10.3 ist es 15 % langsamer und die EXE ist um den Faktor 5 größer (wen juckt das heute noch?).
Mein Rechner hat eine 8-Core-AMD-CPU, bei der sich jeweils 2 Cores eine Gleitpunkt-Arithmetik teilen. Bei beide Tests lief der Code in einem einzigen Thread (also nur einem Core). Die Prüfung der Laufzeitfehler war jeweils aktiviert.
Ich finde das Ergebnis erstaunlich.
Editor, Debugger und Hilfe-System gefallen mir bei 10.3 viel besser als bei 7. Neue Projekte werde ich wohl in 10.3 starten, aber ansonsten lohnt eine Umstellung nicht.
Das zur Info für die, die es interessiert,
Gruß
GuaAck
jaenicke - Sa 12.09.20 20:12
Hier wäre es die Mühe wert die Verlangsamung genauer zu untersuchen. Denn wenn man genau zeigen könnte woran das liegt, bin ich mir recht sicher, dass auch Interesse seitens Embarcadero besteht das zu ändern. Eine so starke Verlangsamung hatten wir bei uns schlicht nicht, sonst würden wir das auch untersuchen.
GuaAck - So 13.09.20 00:15
Hallo Jaenicke,
ja, das interessiert mich auch. Ich habe einen Profiler (ProDelphi von Michael Adolph), den habe ich eben als Tool eingebunden und er läuft ohne Probleme mit Delphi 10.3 unter RAD Studio.Damit werde ich das FFT-Programm untersuchen, da ist der Laufzeitunterschied sehr groß und es sind nur 100 Zeilen Code.
Die nächsten Tage habe ich andere Dinge zu tun, ich melde mich wohl Mitte/Ende der Woche mit meinen Ergebnissen.
Gruß GuaAck
GuaAck - So 13.09.20 23:50
Hallo,
nun habe ich doch etwas Zeit gefunden für "Forschung":
Ich habe in meinem Testprogramm (FFT mit 2^22 Punkten, 20 Durchläufe, ca. 2 Minuten) einzelene rechenintensive Bereiche wie z. B. die Sinus- und Cosinus-Berechnung auskommentiert. Dabei habe ich darauf geachtet, dass alles was berechnet wird auch später gebraucht wird, sonst optimiert der Compiler das weg. Vor diesen dokumentierten Messungen habe ich viele Versuche gemacht. Daraus schätze ich, das die Zeitangaben etwa auf +/- 2 % genau sind.
Es ergibt sich, dass alle Programmteile unter Delphi 10.3.3 langsamer sind als unter Delphi 7, ich kann keine einzelene Funktion als Ursache identifizieren, unten eine Tabelle mit meinen Ergebnissen. Als Anhang habe ich meinen Code einschließlich der Tabelle angehängt. Der Code kann ohne jede Veränderung wahlweise mit Delphi 7 oder Delphi 10.3.3. übersetzt werden, wahrscheinlich auch mit alle anderen Versionen dazwischen. WICHTIG: Die *.res ist nicht kompatibel, die *.res aus Delphi 10.3.3 führt bei Delphi 7 zu einem Fehler. Also einfach löschen, Delphi erstellt sie dann neu.
Für mich ist das Thema abgeschlossen. Ich wechsele zu Delphi 10.3 und bleibe bei Delphi 7 für rechenintensive Programme.
Viele Grüße
GuaAck
jaenicke - Mo 14.09.20 11:50
Die Taktfrequenz 4 GHz wie in dem Programm genannt sagt heute nichts mehr über die Geschwindigkeit eines Prozessors aus. ;-)
Ich habe 3,6 GHz und bei mir läuft das Programm in 10 Sekunden (Delphi 7) bzw. 13 Sekunden (Delphi 10.2 + Delphi 10.4) durch, egal ob in einer VM (mit Delphi 7, das habe ich nicht mehr außerhalb einer VM) oder auf dem Hostrechner selbst.
Interessanterweise braucht das Programm mit Delphi XE kompiliert aber 47 (!) Sekunden. Mit Delphi XE6 sind es auch 13 Sekunden.
Offenbar wurde da also seit XE schon wieder optimiert.
Wenn man sich einfach mal anschaut was der Compiler da ausspuckt, sieht man, dass der einzige relevante Unterschied hier liegt:
Delphi 7:
Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
| kneu := kneu DIV 2;
8B45E0 mov eax,[ebp-$20]
D1F8 sar eax,1
7903 jns $005d7291
83D000 adc eax,$00
8945E0 mov [ebp-$20],eax
FF45D4 inc dword ptr [ebp-$2c] |
Neues Delphi:
Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
| kneu := kneu DIV 2;
B902000000 mov ecx,$00000002
8B45E0 mov eax,[ebp-$20]
99 cdq
F7F9 idiv ecx
8945E0 mov [ebp-$20],eax
FF45D4 inc dword ptr [ebp-$2c] |
Die Integerdivision ist hier der Flaschenhals. Hintergrund:
Wenn du durch 2 teilst, musst du aufgrund der Binärdarstellung nur die Ziffern um 1 nach rechts verschieben. Das macht sar (Shift Arithmetic Right). Das ist natürlich deutlich schneller als eine echte Division.
Eventuell kannst du "div 2" einfach durch "shr 1" ersetzen.
// EDIT:
| Narses hat folgendes geschrieben : |
| GuaAck hat folgendes geschrieben : | | 64-Bit-Nutzung gewesen, auch wenn der Geschwindigkeitsgewinn gegenüber 32-Bit eher wenige als 10 % als mehr gewesen wäre. |
Ein weit verbreiteter Irrtum, IMHO. :? Wenn du nicht auf den größeren Adressbereich einer 64bit-Anwendung angewiesen bist, dann gibt es praktisch keinen Vorteil. Im Gegenteil, da bei einer 64bit-Anwendung auch mehr Daten "bewegt" werden müssen (unterstellt, die 2GiB eines 32bit-Prozesses reichen aus), läuft eine 64bittige Anwendung messbar langsamer als eine vergleichbare 32bittige! |
q.e.d.
Das Tool läuft unter 32-Bit ja in 13 Sekunden, unverändert aber unter 64-Bit in 49 Sekunden... (was aber sicher nicht nur an 32-Bit/64-Bit liegt, sondern am erzeugten Code)
GuaAck - Mo 14.09.20 22:33
Hallo,
die Ursache ist gefunden: In RAD-Studio/Delphi 10.3.3 muss die Code-Optimierung expliziet eingeschaltet werden. Unter der Überschrift "Quelltexterzeugung" hätte ich allerdings nie diese Option erwartet. Bei meinem Delphi 7 war die Optimierung immer aktiv. Dic Optimierung bringt die Laufzuzeit bei meinem Testprogramm (FFT) von 1:55 Minuten auf 1:31 Minuten runter, damit gibt es keinen Unterschied mehr zu Delph 7.
Mein Compiler übersetzt übrigen DIV 2 wieder in SAR 1.
Insgesamt hat mir die Diskussion hier im Forum gut geholfen und Anregungen zu neuen Denkrichtungen gegegeben.
Bis demnächst,
Gruß
GuaAck
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2024 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!