Autor Beitrag
Aristoteles
ontopic starontopic starontopic starontopic starontopic starofftopic starofftopic starofftopic star
Beiträge: 69

SuSE Linux 10.0
Lazarus 0.9; Delphi7 PE
BeitragVerfasst: So 24.09.06 19:16 
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
mkinzler
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 4106
Erhaltene Danke: 13


Delphi 2010 Pro; Delphi.Prism 2011 pro
BeitragVerfasst: So 24.09.06 19:25 
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.

_________________
Markus Kinzler.
waran
Hält's aus hier
Beiträge: 1



BeitragVerfasst: Fr 06.10.06 05:37 
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.
Heiko
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 3169
Erhaltene Danke: 11



BeitragVerfasst: Fr 06.10.06 10:08 
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.
Horst_H
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 1640
Erhaltene Danke: 234

WIN10,PuppyLinux
FreePascal,Lazarus
BeitragVerfasst: Fr 06.10.06 15:03 
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
Quake User
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 159



BeitragVerfasst: Fr 06.10.06 18:12 
user profile iconAristoteles 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.
marcov
Hält's aus hier
Beiträge: 1

Win XP, FreeBSD
FPC, Lazarus, Delphi 7, Delphi 2006
BeitragVerfasst: Fr 06.10.06 22:34 
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.
Horst_H
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 1640
Erhaltene Danke: 234

WIN10,PuppyLinux
FreePascal,Lazarus
BeitragVerfasst: Di 10.10.06 12:39 
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
Bernhard Geyer
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 721
Erhaltene Danke: 3



BeitragVerfasst: Di 10.10.06 21:03 
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.
Robert_G
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 416


Delphi32 (D2005 PE); Chrome/C# (VS2003 E/A, VS2005)
BeitragVerfasst: Mo 16.10.06 00:50 
user profile iconBernhard 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. ;)
Aristoteles Threadstarter
ontopic starontopic starontopic starontopic starontopic starofftopic starofftopic starofftopic star
Beiträge: 69

SuSE Linux 10.0
Lazarus 0.9; Delphi7 PE
BeitragVerfasst: Di 31.10.06 11:18 
user profile iconRobert_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;


Zuletzt bearbeitet von Aristoteles am Di 31.10.06 11:26, insgesamt 1-mal bearbeitet
Robert_G
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 416


Delphi32 (D2005 PE); Chrome/C# (VS2003 E/A, VS2005)
BeitragVerfasst: Di 31.10.06 11:22 
user profile iconAristoteles 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. :mrgreen:
Allesquarks
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 510

Win XP Prof
Delphi 7 E
BeitragVerfasst: Di 31.10.06 16:43 
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.
harald mittermeier
Hält's aus hier
Beiträge: 5

Win XP, Kubuntu
Delphi
BeitragVerfasst: Di 31.10.06 18:12 
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.
Aristoteles Threadstarter
ontopic starontopic starontopic starontopic starontopic starofftopic starofftopic starofftopic star
Beiträge: 69

SuSE Linux 10.0
Lazarus 0.9; Delphi7 PE
BeitragVerfasst: Di 31.10.06 18:38 
user profile iconharald 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:

ausblenden Quelltext
1:
 strip --strip-all pfad/zur/datei/dateiname					


ein. Dadurch werden die Debuginformationen entfernt, und das Programm schrumpft um ein Vielfaches.
christian_u
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 30



BeitragVerfasst: Di 31.10.06 22:35 
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.
tommie-lie
ontopic starontopic starontopic starontopic starontopic starofftopic starofftopic starofftopic star
Beiträge: 4373

Ubuntu 7.10 "Gutsy Gibbon"

BeitragVerfasst: Mi 01.11.06 00:22 
user profile iconchristian_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.

_________________
Your computer is designed to become slower and more unreliable over time, so you have to upgrade. But if you'd like some false hope, I can tell you how to defragment your disk. - Dilbert
Martok
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Moderator
Beiträge: 3655
Erhaltene Danke: 594

Win XP x86, Win 8.1 x64
Lazarus Snapshot; Delphi 7,2007,XE; PHP (PHPEdit,PhpStorm); JS; Java(Eclipse)
BeitragVerfasst: Mi 01.11.06 00:40 
user profile icontommie-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.

_________________
"The phoenix's price isn't inevitable. It's not part of some deep balance built into the universe. It's just the parts of the game where you haven't figured out yet how to cheat."
tommie-lie
ontopic starontopic starontopic starontopic starontopic starofftopic starofftopic starofftopic star
Beiträge: 4373

Ubuntu 7.10 "Gutsy Gibbon"

BeitragVerfasst: Mi 01.11.06 09:35 
user profile iconMartok 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.

_________________
Your computer is designed to become slower and more unreliable over time, so you have to upgrade. But if you'd like some false hope, I can tell you how to defragment your disk. - Dilbert
Aristoteles Threadstarter
ontopic starontopic starontopic starontopic starontopic starofftopic starofftopic starofftopic star
Beiträge: 69

SuSE Linux 10.0
Lazarus 0.9; Delphi7 PE
BeitragVerfasst: Mi 01.11.06 13:26 
user profile icontommie-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.