Hallo Leute!

Den Titel habe ich bewusst als Frage formuliert, da mir meine Messresultate ein wenig seltsam vorkommen. Nun:

Ich habe ein Projekt, an dem ich arbeite, von Delphi auf Lazarus portiert. Es handelt sich dabei um einen Funktionen-Plotter mit eingebauter numerischer Integration. Standardmäßig ist in dem Projekt eine Laufzeitmessung integriert. D.h., wenn er eine Funktion zeichnet, spuckt er in einem Feld aus, wie lange er dafür gebraucht hat. Genauso bei der numerischen Integration.

Bei der portierung auf Lazarus wurde der Code 1-zu-1 übertragen. Nun kam mir der Plottvorgang der Funktionen in dem von dem FreePascal-Compiler (Lazarus) kompilierten Programm wesentlich schneller vor, als in dem von Delphi kompilierten Programm. Das veranlasste mich zur Aufzeichnung der Laufzeiten:

1. Die Funktion sin(x^2+0,2):

Die Darstellung der Funktion:
_Delphi-Kompiliert: 145 ms
_FCP-Kompiliert: 70 ms

Die numerische Integration von 0 bis 10 mit 5000 Intervallen:
_Delphi-Kompiliert: 669 ms
_FPC-Kompiliert: 320 ms

1. Die Funktion (x+1)^2*sin(1/x):

Die Darstellung der Funktion:
_Delphi-Kompiliert: 227 ms
_FCP-Kompiliert: 130ms

Die numerische Integration von 0 bis 10 mit 5000 Intervallen:
_Delphi-Kompiliert: 1095 ms
_FPC-Kompiliert: 550 ms

Ergebnis: Die FreePascal-Kompilierten Programme waren stets etwa doppelt so schnell wie die Delphi-Kompilierten.

Noch ein paar Informationen:
1.Der Source-Code ist in beiden Fällen exakt gleich
2.Ich habe sowohl in Delphi als auch in Lazarus die Optimierung eingeschalten. Mir ist aber aufgefallen, dass des FPC-Programm unoptimiert schneller läuft, als der Delphi-Programm optimiert.
3. Die Ergebnisse der numerischen Integration stimmten überein, beide Programme zeichneten die Funktionen korrekt.
4. Delphi 7 Pers, Lazarus 0.9.16 mit FPC 2.0.2
5. Die Programme wurden nicht von der Entwicklungsumgebung aus aufgerufen, sondern aus dem Explorer.
Des weiteren wurde als Betriebssystem WinXP Home verwendet.

Nun meine Frage an Euch:
Hat jemand ähnliche Erfahrungen gemacht?
Generell: Kennt jemand die Gründe?

Würde mich mal interessieren. Weil mich das doch stutzig macht, dass die Unterschiede derart groß sind. Hätte eher gedacht, dass mögliche Unterschiede im 1%-Bereich liegen.

Viele Grüße, Aristoteles

Es wäre schon möglich.
-Es kann am Compiler selnber, aber auch and der Komponentenbibliothek liegen. man müßte den Test mit nicht GUI-Programmen durchführen.
-Test mit neueren Versionen von Delphi wiederholen.

Moin moin,
mir ist aufgefallen, dass unter Delphi standardmäßig
die I/O-Laufzeitprüfung aktiviert ist (bei Lazarus nicht).
Vielleicht liegt es daran?
Ich wäre dir dankbar, wenn du das evtl. nochmal prüfen
könntest.

Ein weiterer Grund ist wahrscheinlich der Source, den FPC mitliefert. Während Borland haufen Müll eingebaut hat, hat das FPC vlt. nicht. Also bei deinem wäre es z.B. gut möglich, dass FPC einfach nur die GDI-Befehele ausführt, während Borland noch Fehlerbehandlung etc. drinne hat.

Hallo,

wie sieht es es denn disassembliert aus.
Wenn man Delphi 7 und 2005 bei Funktionen wie round vergleicht sind dort schon grosse Unterschiede bei mir gewesen. Insbesonders war 2005 eheblich langsamer, da bei jedem Aufruf erst die Steuerregister der FPU speziell gesetzt wurden.Dies liegt wahrscheinlich an der Rundungskompilatibiltaet zur Sprache C mit ihrer Rundungsvorschrift, die nicht Standart bei der FPU ist (wann kam der 8087 heraus, vor 25 Jahren? ).
Zudem soll der FPC Compiler auch statt ausschliesslich ST(0) auch ST(1) benutzen koennen , was natuerlch schneller sein kann. Falls nun auch noch immer mit extended gerechnet wird, ist die Leistung eh im Keller.
Ach da war mal was: www.bernd-leitenberger.de/benchmark.shtml

Gruss Horst

Aristoteles hat folgendes geschrieben:

Hallo Leute! ... Ich habe ein Projekt, an dem ich arbeite, von Delphi auf Lazarus portiert. Es handelt sich dabei um einen Funktionen-Plotter mit eingebauter numerischer Integration. Standardmäßig ist in dem Projekt eine Laufzeitmessung integriert. D.h., wenn er eine Funktion zeichnet, spuckt er in einem Feld aus, wie lange er dafür gebraucht hat. Genauso bei der numerischen Integration. ... Viele Grüße, Aristoteles

Diese Fragen sollte Borland beantworten. Hast Du es mal bei Borland versucht?
Wenn mein Auto zu langsam fährt, frage ich beim Hersteller nach.

FPC support SSE2, aber das muss explicit an gesetzt werden.

Hasst du mit Delphi auch ein BUILD gemacht mit optimierung?

FPC kann sehr sicher schneller sein, aber solche grosse Unterschieden sind richtige Ausnahmen.

Hallo,

ich habe mal Lazarus mit FPC 2.04 instaliert und bin sehr erstaunt.
Mein Beispiel www.delphi-forum.de/viewtopic.php?t=65290 ohne Rechnerei, sondern Stringkopiererei laeuft unter Lazarus bei n=26/k=25 (Es sind 67.108.837 Rekursionsaufrufe) ohne Ausgabe(auskommentiert) in 00:00:18.006 Sekunden unter Delphi 7.0 mit FastMM4 in 00:00:27.359 sekunden, ohne FastMM4 in 00:01:08.508 Sekunden also erheblich langsamer.

Nun gut Lazarus kompiliert langsam, aber auch nicht 9 Sekunden.
Man muesste mal andere Anwendungen testen, die nicht so einseitig sind.

Gruss Horst

Schon mal probiert das FastCode-Project (www.fastcodeproject.org/) in dein Programm zu integrieren?

Borland hat schon seit D5 in dem Bereich Compiler-Optimierung für neuere CPU's nicht mehr viel gemacht. Der Verlustausflug Linux/Kylix und die große Portierung Richtung .NET sowie die Planlosigkeit des Borland-Management haben dafür keine Zeit und Ressourcen übrig gelasen.

Bernhard Geyer hat folgendes geschrieben:

Schon mal probiert das FastCode-Project (www.fastcodeproject.org/) in dein Programm zu integrieren? Borland hat schon seit D5 in dem Bereich Compiler-Optimierung für neuere CPU's nicht mehr viel gemacht. Der Verlustausflug Linux/Kylix und die große Portierung Richtung .NET sowie die Planlosigkeit des Borland-Management haben dafür keine Zeit und Ressourcen übrig gelasen.

Kann ich nicht wirklich nachvollziehen. Bisher sind noch alle Binaries, die ich mit TurboDelphi kompostiert habe, merklich schneller gewesen als D7 Binaries mit gleichem Source code. Da ab BD2006 so schnieke Neuerungen wie statische class methods oder sealed overrides dabei sind lässt sich mit leicht verändertem Code nochmal einiges rausholen.
Deine Vermutung á la "seit D5 nix mehr für neue CPUs gemacht" ist eigentlich falsch.
IMO, generiert Delphi Code, der auf 486'ern läuft.
Der Compiler selbst optimiert sicherlich besser als der von FPC (wild guess), aber FPC lässt dich neuere CPU instruction sets nutzen. Deshalb sollte es nicht weiter verwundern wenn Berechnungen plötzlich nur noch einen Bruchteil dauern.

Robert_G hat folgendes geschrieben:

Der Compiler selbst optimiert sicherlich besser als der von FPC (wild guess), aber FPC lässt dich neuere CPU instruction sets nutzen. Deshalb sollte es nicht weiter verwundern wenn Berechnungen plötzlich nur noch einen Bruchteil dauern.

Guten Morgen!

Nun: Meine CPU kommt aus einer Zeit, in der Delphi 7 aktuell war. Von daher liegen die Gründe wahrscheinlich nicht im Instructionset.


Es kamen nun hunderte Antworten auf meinen Beitrag. Und weitere Fragen. Ich werde versuchen, die Schritt für Schritt zu beantworten:

>>Diese Fragen sollte Borland beantworten. Hast Du es mal bei Borland versucht?

Nein, Borland habe ich nicht angeschrieben. Ich habe es auch nicht vor, da mir im Grund egal ist, wie schnell Delphi ist. Bin seit der Portierung dieses Programms auf Lazarus umgestiegen. Es lockte vor allem die Plattformunabhängigkeit.

>>Hasst du mit Delphi auch ein BUILD gemacht mit optimierung?

Ich kenne den Begriff Build mit der Bedeutung "Versionsstand".
Dazu: Sowohl das Lazarus-Programm, als auch das von Delphi kompilierte haben ein und den selben Quelltext. Wenn ich mich recht erinnere, habe ich beide Programme über Projekt->Erstellen kompiliert...
Wie gesagt, FPC war ohne Optimierung schneller als Delphi mit Optimierung.

@Horst_H:
Das klingt ja so, als hättest du ähnliche Erfahrungen gesammelt, wie ich?
Vielleicht können weitere Programmierer von Euch über Erfahrungen in Verbindung mit Laufzeiten unter Delphi und Lazarus berichten?

>> Schon mal probiert das FastCode-Project (www.fastcodeproject.org/) in dein Programm zu integrieren?

Kannte ich noch nicht.

>> mir ist aufgefallen, dass unter Delphi standardmäßig die I/O-Laufzeitprüfung aktiviert ist (bei Lazarus nicht). Vielleicht liegt es daran?

Das werde ich überprüfen, sobald ich Windows das nächste mal benutze. Bin zwischenzeitlich auf Linux umgestiegen...
Aber mal eine Frage: I/O-Laufzeitprüfung hört sich so nach Ein-/Ausgabe-Prüfung an? Dazu kann ich dann doch was sagen:
Während der numerischen Integration gibt es weder Ein- noch Ausgaben. Die CPU ist ausschließlich damit beschäftigt, Funktionswerte der Funktion zu berechnen und die Ergebnisse dafür zu verwenden, über das Verfahren der "Obersumme" das Integral der Funktion numerisch zu berechnen.


>>Man muesste mal andere Anwendungen testen, die nicht so einseitig sind.
Wie berechnet mein Programm die Funktionswerte? - Über eine für meine Verhältnisse rießige rekursive Funktion, die die Terme nach und nach aufspaltet und dabei algebraische Regeln anwendet. Die Routinen beinhalten bei mir also vor allem String-Operationen und allgemeine Rechen-Operationen. Allzu einseitig ist das ja nicht;

Aristoteles hat folgendes geschrieben:

Nun: Meine CPU kommt aus einer Zeit, in der Delphi 7 aktuell war. Von daher liegen die Gründe wahrscheinlich nicht im Instructionset.

Delphi kompiliert aber für Prozis, die zu Delphi1-Zeiten aktuell waren.

Falls Delphi so compiliert, wie es im CPU-Window angezeigt wird, dann optimiert es gar nicht.
Dass freepascal schneller ist hätte ich erwartet und ist nun offenbar bestätigt. ich denke auch, dass das ein weitestgehend allgemeiner Effekt ist, der sich auf fast jeden Code ausdehnt.

"developers can freely use eax,ecx,edx but must preserve the other registers." So ungefähr stand es in der Delphi Hilfe. Das wahre Ausmaß dieser Katastrophe wurde mir aber erst später klar. Funktionen geben resultate normalerweise in eax zurück. Delphi speichert die dann gerne in ebx oder esi oder sonstwas, damit in der nächsten Codezeile, nur für den Fall, der recht selten ist, dass ich assembler verwende, eax,ecx, edx frei sind. Wenn ich nun Hochsprache schreibe wird das meistens dann wieder nach eax zurückkopiert, da die meisten Operationen damit ausgeführt werden.

Delphi <> Optimierung; nur logisches Variablen wegdenken.

moin zusammen!

ich habe auch ein Programm für die Darstellung von Funktionen geschrieben
("Extended Math") und eine ähnliche Erfahrung gemacht.

Zuerst unter Delphi 2005 PE kompiliert, dann hab ich denselben Quelltext
(bis auf die Unit-Anpassungen) unter Lazarus 0.9.18 (läuft
bei mir unter Kubuntu 5.10 im Moment) geladen und kompiliert.

Und siehe da:
Während man die Win-Version bei einer relativ einfachen Sinus-Funktion (sin(x)*x)
den Graphen zeichnen sieht, ist der Graph der Linux-Version sofort da.

Ich vermute irgendwie, dass Linux ein anderes Handling von mathematischen
Funktionen hat oder dass Lazarus diese eben einfach effizienter in nativen
Linux-Code umsetzt; bei Borland's Delphi wird wohl einfach zuviel drin sein...

Außerdem ist meine Linux-Ver etwa 8 MB groß, während die Win-Ver 1 MB
ausmacht. Also liegt es nicht an der Größe der ausführbaren Datei.

harald mittermeier hat folgendes geschrieben:

Außerdem ist meine Linux-Ver etwa 8 MB groß, während die Win-Ver 1 MB ausmacht. Also liegt es nicht an der Größe der ausführbaren Datei.

Da kann ich weiterhelfen:
In der aktuellen Version werden die Debug-Informationen nicht aus den Binärdateien gelöscht. Deshalb muss man das manuell nachträglich machen. Dazu gehst du einfach in die Konsole und gibst:



ein. Dadurch werden die Debuginformationen entfernt, und das Programm schrumpft um ein Vielfaches.

Zitat:

Und siehe da: Während man die Win-Version bei einer relativ einfachen Sinus-Funktion (sin(x)*x) den Graphen zeichnen sieht, ist der Graph der Linux-Version sofort da.

Der Vergleich Linux/Windows hinkt ein bissle, der LInux kernel ist in allem ein stück schneller.
Und zusätzlich Vergleichst du Delphi mit FPC.
Vergleich doch mal Lazarus mit Delphi unter Windows und Lazarus mit Lazarus unter Linux/Windows.

christian_u hat folgendes geschrieben:

harald mittermeier hat folgendes geschrieben: Graphen zeichnen Der Vergleich Linux/Windows hinkt ein bissle, der LInux kernel ist in allem ein stück schneller.

Der Vergleich hinkt prinzipbedingt, weil Grafik unter windows grundverschieden von Grafik unter Linux ist.

christian_u hat folgendes geschrieben:

Vergleich doch mal Lazarus mit Delphi unter Windows und Lazarus mit Lazarus unter Linux/Windows.

Auch damit wird man alles mögliche vergleichen, aber nicht die Geschwindigkeit der Berechnung "sin(x)*x" oder irgendeine spezielle Arithmetikgeschwindigkeit, die man in seinem Code zu messen versucht.
Wenn man unter Windows dem Zeichnen eines Graphen zuschauen kann, hat man irgendwas falsch gemacht oder die Formel ist weitaus komplexer als eine popelige Sinusberechnung.

tommie-lie hat folgendes geschrieben:

Auch damit wird man alles mögliche vergleichen, aber nicht die Geschwindigkeit der Berechnung "sin(x)*x" oder irgendeine spezielle Arithmetikgeschwindigkeit, die man in seinem Code zu messen versucht.

Ganz genau. Deshalb macht man Testprogramme für sowas auch als Konsolen-Apps: Damit die Grafik keine Rolle spielt. StdIn/StdOut ist eigentlich immer ähnlich schnell.
Außerdem sollte man mal versuchen, die Priorität auf Realtime zu setzen (kA, geht das bei Linux? Ich hab noch nicht unter Linux programmiert). Nur so kann man wirklich den Code vergleichen. Sonst sind immer Messfehler drin.

Martok hat folgendes geschrieben:

Außerdem sollte man mal versuchen, die Priorität auf Realtime zu setzen (kA, geht das bei Linux? Ich hab noch nicht unter Linux programmiert).

Ja, geht sogar ohne eigenen Code mit nice oder renice.

tommie-lie hat folgendes geschrieben:

Wenn man unter Windows dem Zeichnen eines Graphen zuschauen kann, hat man irgendwas falsch gemacht oder die Formel ist weitaus komplexer als eine popelige Sinusberechnung.

Hast du schonmal ein Zeichenprogramm für Funktionen geschrieben?
Wenn man da keine krassen Optimierungen durchführt kann auf einem 2500+ die Darstellung von sin(x)*x durchaus eine halbe Sekunde dauern, und sowas sieht man. Von daher kann ich die Beobachtung vom Harald durchaus nachvollziehen.