Programmgeschwindigkeit Lazarus vs Delphi

[xcs123]

Hallo,

ich hätte zwei Fragen. Bin neulich wegen der Notwendigkeit eines 64-Bit-compilers von Delphi auf Lazarus umgestiegen.
Dabei fiel mir sofort folgendes auf:

1. Die ausführbare Programmdatei (.exe) eines meiner Projekte war bei Delphi stets nur 2-3 MB groß. Wenn ich das selbe Projekt mit Lazarus kompiliere, ist die .exe über 30 MB groß!! Wie kommt das???

2. Die Performance ist nach Kompilierung mit Lazarus viel schlechter als nach Kompilierung mit Delphi. Es handelt sich um ein Projekt, bei dem sehr viele aufwendige Gleitkommaoperationen und Exponentialfunktionen berechnet werden.

Betriebssystem: Windows 7, 64 Bit; Lazarus-64-Bit-Verison 0.9.28.2 Beta

[af0815]

1. Die ausführbare Programmdatei (.exe) eines meiner Projekte war bei Delphi stets nur 2-3 MB groß. Wenn ich das selbe Projekt mit Lazarus kompiliere, ist die .exe über 30 MB groß!! Wie kommt das???

Wie wäre es mit der Forumsuche oder ein Blick in die Wiki von Lazarus oder auch Google oder auch englische LazarusForum . DIESER Punkt ist ein Wiederkäuer, Er stösst auf und wird immer wieder durchgekaut. Zusätzlich sollte man sich in der Wiki auch mit dem Punkt umstieg von Delphi zu Lazarus vertraut machen.

[xcs123]

danke für den Hinweis bzgl der Größe der .exe

Was die Geschwindigkeit der Rechenoperationen betrifft:
Ist ein Lazaruskompilat grundsätzlich langsamer oder liegt es daran, dass es eine 64-Bit-Anwendung ist?
Insbesondere ist der Programmteil, in dem viele Exponentialfunktionen berechnet werden, cirka 2mal so langsam wie das mit Delphi kompilierte Programm.

[mse]

Ist ein Lazaruskompilat grundsätzlich langsamer oder liegt es daran, dass es eine 64-Bit-Anwendung ist?

Dass 64bit nicht unbedingt schneller als 32bit sondern öfters sogar langsamer ist, daran musst du dich gewöhnen. Selbstverständlich predigen die Marketingabteilungen der Prozessor- und Betriebssystemhersteller etwas anderes und viele Entwickler lassen sich von dem Gedröhn beeinflussen. Da 64bit Programme den Cache-Speicher viel stärker belasten, sind sie gegenüber 32bit Äquivalenten benachteiligt. Bei FPC kommt dazu, dass der 64bit Compiler (noch) nicht so gut optimiert als der 32bit Bruder, auch für Optimierung der Fliesskomma-Berechnungen bietet FPC noch viel Raum.
Ich würde das Thema mal auf der Mailinglist aufs Tapet bringen:

http://www.freepascal.org/maillist.var

Martin

[theo]

Irgendwie ist die 64 bit Computerei noch nicht so recht angekommen.
Oft hat man den Eindruck, gewisse Dinge seien mit den 64bit Versionen noch nie getestet worden.
Z.B. Android SDK auf Windows 7 64bit mit JDK 6 64bit lässt sich erst mal gar nicht installieren.

[Socke]

DIESER Punkt ist ein Wiederkäuer, Er stösst auf und wird immer wieder durchgekaut. Zusätzlich sollte man sich in der Wiki auch mit dem Punkt umstieg von Delphi zu Lazarus vertraut machen.

Vielleicht sollte man auf der Mailing-Liste mal anregen, standardmäßig die Debugging-Symbole in eine externe Datei auzulagern. Bei mir hat das bisher wunderbar geklapt, und jeder, der besondere Anforderungen (z.B. Remote-Debuggin) hat, sollte eh, wissen, was er da tut. Klar, das ist dann immer noch keine Release-Version (-> Optimierungen), aber immerhin haben wir nicht mehr die ganzen Anfragen dazu

Irgendwie ist die 64 bit Computerei noch nicht so recht angekommen.

Im Bereich der Privat-Anwender hast du da auf jeden Fall Recht. 64 Bit Speicherbreite zahlen sich erst aus, wenn man mit vielen Daten hantiert und sehr viel Arbeitsspeicher braucht. Bei großen Datenbanken kommt man mittlerweile ohne 64-Bit-Architektur nicht mehr wirklich weit. Auch lassen sich hier schneller große Zahlen (44-64bit) mit der ALU berechnen (anderer Co-Prozessoren können natürlich noch schneller noch größere Zahlen berechnen).

Fazit: 64-Bit ist nicht für schneller sondern für mehr.

Edit/Übrigens: Auch in FreePascal-Programm wird nicht immer Architektur-unabhängig programmiert. Zum Beispiel wird die Länge eines Strings in einem SizeInt-Typen abgelegt (32/64 Bit, je nach CPU); Lazarus empfiehlt für Length(String) aber unter i386 Longint als Variablentypen, was zusätzlichen Aufwand bei der Portierung mit sich bringt.

[theo]

Fazit: 64-Bit ist nicht für schneller sondern für mehr.

Das ist mir schon klar.
Was mich als "late adopter" einfach erstaunt ist, dass nachdem ich nun auf meinem neuen NetBook (ziemlich gut das Teil für < CHF 500.- http://shop.stegcomputer.ch/shop.asp?prodid=759165" onclick="window.open(this.href);return false;)
mit Win7 64bit zwangsbeglückt wurde, und nach all den Jahren endlich mal die 64bit Windows-Schiene teste, feststellen muss, dass die Programme immer noch nicht so recht funzen wollen und sich offenbar "die grosse Masse" nicht wirklich darum kümmert.
Ich gehe bis auf weiteres wieder auf 32bit Tauchstation.

[carli]

2. Die Performance ist nach Kompilierung mit Lazarus viel schlechter als nach Kompilierung mit Delphi. Es handelt sich um ein Projekt, bei dem sehr viele aufwendige Gleitkommaoperationen und Exponentialfunktionen berechnet werden.

Den Grund kann ich dir nennen,
er liegt im Sourcecode des FPC: compiler/x86_64/aoptcpu.pas enthält einfach nur ein leeres Klassengestell
Der 64-bit Compiler hat keinen Peephole-Optimizer, der Compiler erzeugt manchmal sogar Sprünge auf das nächste Byte.
Da sich aber x86 und x86_64 kaum unterscheiden, bin ich mir sicher, dass man die Optimierung aus dem x86 einfach so kopieren könnte. Warum das bis jetzt niemand gemacht hat, ist mir ein Rätsel. Ich habe auch öfters danach gefragt.

Die FPC-Entwickler meinen nur, es sollte sich mal jemand ransetzen und das Ding komplett neu schreiben.

[Socke]

Warum das bis jetzt niemand gemacht hat, ist mir ein Rätsel. Ich habe auch öfters danach gefragt.

Die FPC-Entwickler meinen nur, es sollte sich mal jemand ransetzen und das Ding komplett neu schreiben.

Könnte daran liegen, dass wirklich zu wenig Interesse daran besteht. Auf der anderen Seite übernimmt ein kompletter Rewrite keine alten Fehler (bringt dafür neue mit ).

[theo]

Die FPC-Entwickler meinen nur, es sollte sich mal jemand ransetzen und das Ding komplett neu schreiben.

Dann mach doch mal, du kennst dich ja anscheinend prima aus damit.

[carli]

Die FPC-Entwickler meinen nur, es sollte sich mal jemand ransetzen und das Ding komplett neu schreiben.

Dann mach doch mal, du kennst dich ja anscheinend prima aus damit.

Zumindest würde ich auch direkten Nutzen davon tragen.

Mal überlegen. Fakt ist, dass der FPC außer "read the Source Code" ziemlich schlecht dokumentiert ist. Wenigstens die verwendeten Datentypen und das Konzept hinter der internen Coderepräsentation würde mich mal interessieren