Linux-Compilat 3x grösser als windows ?

[m.fuchs]

So habe ich immer noch das Problem, dass GUI-Programme gerade unter Linux über mehrere Tage Speicher akkumulieren bis zur Unbenutzbarkeit. Und da bekommt man ganz schwer raus, woran das liegt.

Heaptrc.

[Warf]

Wenn das Programm unter Linux einfach so mal 3 mal so groß ist, wie unter Windows (wobei ich das auch für unnötig halte),
dann gibt es da einfach Optimierungspotential und zu Fragen Warum ist einfach kontraproduktiv und ebenfalls überflüssig.
Vor allem, wenn dann diese Linuxprogramm ggf. (WARUM auch immer) auf einem Raspi oder Co. eingesetzt werden sollen ist gerade Größe auf jeden Fall relevant.

Was spräche dagegen, mal an die Optimierung von FPC/LAZ zu gehen und zu zeigen, es geht besser.

Es ist etwas irreführend wenn du sagst das program ist 3 mal so groß. Wie bereits erwähnt ist der overhead eher konstant, wenn du also ein 30 MB programm für windows hast, wird das Linux programm wahrscheinlich nicht größer als 40 mb sein, da ist es nur 30% größer.

Und da du den Raspi ansprichst, eine 32 GB SD karte kostet 10€. Wenn du mehr als 32 GB brauchst nimm für 15€-20€ ne 64 GB karte. Und wenn du mehr als 64 GB brauchst denk lieber drüber nach ob dann ein Raspi wirklich die richtige wahl als hardware ist. Speicher kostet nichts und ist komplett irrelevant, außer eventuell auf mikrocontrollern, und dafür ist Pascal nie designed worden (afaik ist avr pascal eh noch in den kinderschuhen).

Und das mit dem optimieren ist doch kompletter müll. Speicher ist billig, und das optimieren dauert. Ich denke da einfach nur an C welches alle möglichen solcher optimierungen macht, man für ein projekt zu kompilieren aber einfach mal ein paar stunden brauchen kann. Z.B. FPC kompiliert bei mir in 5-10 minuten. LLVM als vergleichbares projekt (Vergleibare Anzahl LOC und ähnliche art von program) braucht 40-60 minuten.
Noch dazu würde es entwickler benötigen die sowas implementieren, also muss man sich fragen, sollen die FPC entwickler ihre zeit lieber mit unnötigen optimierungen die niemand verwenden würde (da mir zeit wichtiger ist als speicher) verschwenden, oder lieber neue features in die sprache integrieren die den workflow verbessern?
Relevant würden solche optimierungen höchstens für AVR pascal aber warum sollte irgendein entwickler seine zeit investieren um das in den x86 compiler zu implementieren?

[Warf]

Vor allem, wenn dann diese Linuxprogramm ggf. (WARUM auch immer) auf einem Raspi oder Co. eingesetzt werden sollen ist gerade Größe auf jeden Fall relevant.

Ich bin ja auch für Ressourcenschonung, und beim AVR Controller kämpfe ich auch um jedes Byte - naja, nicht jedes...

Aber wenn ich sehe was auf dem Raspi sonst so rumgammelt, da mache ich mit um ein paar mehr MByte mehr für mein Programm keine Sorgen. Was mich viel mehr stört ist schwer vorhersagbares Langzeitverhalten. So habe ich immer noch das Problem, dass GUI-Programme gerade unter Linux über mehrere Tage Speicher akkumulieren bis zur Unbenutzbarkeit. Und da bekommt man ganz schwer raus, woran das liegt.

Klingt nach nem memory leak. Außerdem warum hast du GUI programme die so lange laufen? Realisier langzeit jobs besser als daemon die du dann mit einem GUI programm ansteuern kannst (z.B. über FIFOs)

[Socke]

Außerdem warum hast du GUI programme die so lange laufen? Realisier langzeit jobs besser als daemon die du dann mit einem GUI programm ansteuern kannst (z.B. über FIFOs)

Gerade auf dem Raspberry kann ich mir GUI-Programme vorstellen, die man nicht regelmäßig neustartet. Wer möchte schon morgens fünf Minuten warten nur um das aktuelle Wetter anzuzeigen? Dann kann das GUI-Programm auch gerne ein paar Monate(!) durchlaufen.

Was spräche dagegen, mal an die Optimierung von FPC/LAZ zu gehen und zu zeigen, es geht besser.

Konjunktiv!
Sowohl meine Fähigkeiten, als auch meine Zeit sind definitiv ausgereizt, in jeder Hinsicht.
Für mich, für meine Projekte aber mache ich das, ich optimiere wo es nur geht. Das fängt damit an, dass ich Lazarus nicht nutze...

Es gibt zwar einige Personen, die durchaus die Fähigkeiten und das Wissen haben um das gesamte System dahingehend zu optimieren, nur haben die in der Regel eine genau so begrenzte Zeit wie du. Bei Free Pascal gilt wie bei allen anderen Open Source Projekten: du arbeitest an den Punkten, die dir wichtig sind, und woran du Spaß hast - außer du wirst für ein Feature bezahlt.

[Mathias]

Das ist ma 'ne Frage. Weil es nicht nötig erscheint, weil auch in heutigen Zeiten Platz endlich ist (vor allem beim Download über die ach so tollen LTE Tarife).
Weil es mal gut wäre, wenn man wieder mehr optimieren würde.

Dies sollte heute kein Problem mehr darstellen, heutzutage hat man sogar im Grundpaket von UPC eine 40'000-Leitung.
Oder gibt es noch Leute, die den guten alten Akustikkoppler ausgraben und übers Telefon surfen ?

[Socke]

Dies sollte heute kein Problem mehr darstellen, heutzutage hat man sogar im Grundpaket von UPC eine 40'000-Leitung.
Oder gibt es noch Leute, die den guten alten Akustikkoppler ausgraben und übers Telefon surfen ?

Nicht jeder hat eine Million Euro für eine Glasfaserleitung übrig.
Bei einzelnen Programmen ist das in der Regel müßig über die Größe zu diskutieren. Wenn aber ein komplexes System aus vielen Programmen besteht, fragt man sich schon manchmal, warum der Download so groß ist. Aus meiner Erfahrung liegt das aber dann noch wieder weniger an dem einzelnen Programm sondern eher an der Zusammenstellung der Programme für eine allgemeine Aufgabe, obwohl man für die akute spezifische Aufgabe nur ein viel geringeren Umfang benötigt hätte.

[Mathias]

Nicht jeder hat eine Million Euro für eine Glasfaserleitung übrig.

Dies ist natürlich auch ein Extremfall, aber in einer normalen Gemeinde sollte dies eigentlich kein Problem mehr darstellen.
Wieso muss es immer gleich Glasfaser sein, ein Koax-Kabel bringt auch schon eine sehr grosse Datenmenge durch. In meine Wohnung geht vom Verteiler auch nur ein Koax-Kabel und dieses kann theoretisch 500,000MB übertragen.

Aber du hast schon recht, die EXE von FPC ist nach meiner Meinung auch etwas zu gross. Man nimmt auch nicht die dreifache Menge Olivenöl zum kochen, auch wen man es Fass weise kauft.

[wp_xyz]

Zurück zur ursprünglichen Frage: Hast du die Debug-Informationen gestrippt? Das macht einen Rieseneffekt. Außerdem gab es vor kurzem im englischen Forum eine Diskussion zum selben Thema: https://forum.lazarus.freepascal.org/in ... #msg277010, gerade der 64-Bit Compiler unter Linux scheint da eine Macke zu haben.

[relocate]

4. Wo ist der Unterschied?

Ich weiß wirklich nicht,worauf du hinaus willst.

Das Programm belegt dauerhaft Platz, das Video nur temporär. Da ist der Unterschied.

Wahrend beim schauen eines Online Videos mehrere Computer beteiligt sind und Strom fressen, interessiert die Dateigröße des Executable in dieser Grössenordnung auf deiner Festplatte eigentlich ökologisch nicht weiter.

Ökologie war nicht das Thema.

Aber lass gut sein. Mich interessiert dein extreme Meinung eigentlich gar nicht mehr.

Mit der extremen Meinung habe ich nicht angefangen. Mich nervt nur diese egal Einstellung bei der Entwicklung von Programmen. Ich komme aus der Admin Schiene und ich mache nichts weiter als Rechner aufrüsten, weil Software die kein bisschen besser ist als eine Vorgängerversion mehr und mehr Ressourcen verschwendet. Anwender beklagen sich, das die Rechner so träge sind. Weil Software immer mehr bloated ist. Und wenn dann einer daher kommt und sagt, scheiß drauf, was solls, die Verschwendung ist wurscht, dann konter ich mit, Optimierung hat ihren Sinn. Programmeffizienz ist aber für Softwareentwickler immer mehr zum Fremdwort gekommen, hauptsache die fetten Teile werden schnell rausgerotzt. Soll der Anwender und der Admin gucken wie sie damit klarkommen.

[relocate]

Wenn das Programm unter Linux einfach so mal 3 mal so groß ist, wie unter Windows (wobei ich das auch für unnötig halte),
dann gibt es da einfach Optimierungspotential und zu Fragen Warum ist einfach kontraproduktiv und ebenfalls überflüssig.
Vor allem, wenn dann diese Linuxprogramm ggf. (WARUM auch immer) auf einem Raspi oder Co. eingesetzt werden sollen ist gerade Größe auf jeden Fall relevant.

Was spräche dagegen, mal an die Optimierung von FPC/LAZ zu gehen und zu zeigen, es geht besser.

Es ist etwas irreführend wenn du sagst das program ist 3 mal so groß. Wie bereits erwähnt ist der overhead eher konstant, wenn du also ein 30 MB programm für windows hast, wird das Linux programm wahrscheinlich nicht größer als 40 mb sein, da ist es nur 30% größer.

Ich bezog mich auf das Beispiel oben.

Und da du den Raspi ansprichst, eine 32 GB SD karte kostet 10€. Wenn du mehr als 32 GB brauchst nimm für 15€-20€ ne 64 GB karte. Und wenn du mehr als 64 GB brauchst denk lieber drüber nach ob dann ein Raspi wirklich die richtige wahl als hardware ist. Speicher kostet nichts und ist komplett irrelevant, außer eventuell auf mikrocontrollern, und dafür ist Pascal nie designed worden (afaik ist avr pascal eh noch in den kinderschuhen).

Auch der Raspi war ein Beispiel. Aber es passt, weil es für ein Linuxsystem eben sehr begrenzt ist. Auf einem gewöhnlichen Rechner spielt es wiederum eine kleinere Rolle.

Und das mit dem optimieren ist doch kompletter müll. Speicher ist billig, und das optimieren dauert. Ich denke da einfach nur an C welches alle möglichen solcher optimierungen macht, man für ein projekt zu kompilieren aber einfach mal ein paar stunden brauchen kann. Z.B. FPC kompiliert bei mir in 5-10 minuten. LLVM als vergleichbares projekt (Vergleibare Anzahl LOC und ähnliche art von program) braucht 40-60 minuten.

Es ist sicher kein kompletter Müll und genau so eine Einstellung (sehr extrem) hat mich im Prinzip zum Gegenextrem geführt. Aber ich verlange eigentlich gar keine Optimierung bis zum geht nicht mehr. Aber die Einstellung, dass Optimierung in der Größe und auch in der Laufzeit bei Softwareentwickelrn überhaupt nicht mehr im Horizont ist, nervt. Wie schon woanders geschrieben. Als Admin schiebe ich für fette Software immer fettere Rechner unter den Allerwertesten ohne dass die Software besser arbeitet. Anwender beschweren sich immer öfter und ich kann daran nichts ändern aber bin der Schuldige. Das hat allein auch nichts mit FPC zu tun, das gleiche gilt für die NET Monster und Java Programme.

Noch dazu würde es entwickler benötigen die sowas implementieren, also muss man sich fragen, sollen die FPC entwickler ihre zeit lieber mit unnötigen optimierungen die niemand verwenden würde (da mir zeit wichtiger ist als speicher) verschwenden, oder lieber neue features in die sprache integrieren die den workflow verbessern?
Relevant würden solche optimierungen höchstens für AVR pascal aber warum sollte irgendein entwickler seine zeit investieren um das in den x86 compiler zu implementieren?

Wäre mal toll, wenn die Software denn auch tatsächlich besser werden würde, aber das ist IMHO nur noch selten der Fall. Lieber bastelt man an Features die keiner benötigt und wünscht, statt dass die Programme wirklich den Workflow verbessern würden.

[relocate]

Konjunktiv!
Sowohl meine Fähigkeiten, als auch meine Zeit sind definitiv ausgereizt, in jeder Hinsicht.
Für mich, für meine Projekte aber mache ich das, ich optimiere wo es nur geht. Das fängt damit an, dass ich Lazarus nicht nutze...

Es gibt zwar einige Personen, die durchaus die Fähigkeiten und das Wissen haben um das gesamte System dahingehend zu optimieren, nur haben die in der Regel eine genau so begrenzte Zeit wie du. Bei Free Pascal gilt wie bei allen anderen Open Source Projekten: du arbeitest an den Punkten, die dir wichtig sind, und woran du Spaß hast - außer du wirst für ein Feature bezahlt.

Das ist schon klar, nur die Einstellung auf Optmierung gar nichts zu geben und das nicht mal im entferntesten im Fokus zu haben, geht mir komplett gegen den Strich. Es geht nicht um die allerletzten Bits, zu optimieren, aber es wird eben gar nichts darauf gegeben und das ist meiner Meinung nach eben auch falsch. Bevor man an irgend ein neues vermeintliches super tolles Feature geht, sollte mal darüber nachgedacht werden, ob nicht irgendwo eine Optimierung aber ggf. auch Bugs mal eher angegangen werden sollten. Wie nun öfter geschrieben, ich komme aus der Admin Schiene, ich nutze FPC (da ich fast ausschließlich nur Pascal kann, beherrschen sicher nicht) um mir "kleine" Tools zu bauen, die mir das Leben dahingehend erleichtern.

[relocate]

Das ist ma 'ne Frage. Weil es nicht nötig erscheint, weil auch in heutigen Zeiten Platz endlich ist (vor allem beim Download über die ach so tollen LTE Tarife).
Weil es mal gut wäre, wenn man wieder mehr optimieren würde.

Dies sollte heute kein Problem mehr darstellen, heutzutage hat man sogar im Grundpaket von UPC eine 40'000-Leitung.
Oder gibt es noch Leute, die den guten alten Akustikkoppler ausgraben und übers Telefon surfen ?

Es ist super, wenn die Infrastruktur das hergibt. Aber bei uns in der Stadt (und es ist keine kleine Stadt, aber wir sind etwas am vergessenen Rand) erreichen wir 10Mbit gerade mal so mit Kanalbündelung und zahlen ein heiden Geld dafür. Internet ist aber immer wichtiger und bei 50 Usern die sich das Teilen bekomme ich die Prügel dafür. Und ja, per User ist das fast wieder Akkustikkoppler Geschwindigkeit.

[Mathias]

Ein kleiner Versuch, wie schlecht, das FPC optimiert.

Code: Alles auswählen

program Project1;
type
  TC=class
  end;
begin
end.

Code: Alles auswählen

program Project1;
type
  TC=class
  end;
begin
end.

Wieso wird das Programm 10KB grösser, obwohl ich die Classe TC nicht mal verwende ?

Code: Alles auswählen

tux@tux-To-be-filled-by-O-E-M ~/tmp $ ls -l
insgesamt 644
drwxrwxr-x 3 tux tux   4096 Jan 23 20:10 lib
-rwxrwxr-x 1 tux tux 362968 Mär 22 19:49 project1
-rw-rw-r-- 1 tux tux 137040 Mär 20 17:29 project1.ico
-rw-rw-r-- 1 tux tux     31 Mär 22 19:49 project1.lpr
-rw-rw-r-- 1 tux tux 138932 Mär 20 17:29 project1.res
-rw-rw-r-- 1 tux tux    323 Mär 20 17:29 unit1.lfm
-rw-rw-r-- 1 tux tux    439 Mär 20 17:29 unit1.pas
tux@tux-To-be-filled-by-O-E-M ~/tmp $ ls -l
insgesamt 656
drwxrwxr-x 3 tux tux   4096 Jan 23 20:10 lib
-rwxrwxr-x 1 tux tux 373800 Mär 22 19:50 project1
-rw-rw-r-- 1 tux tux 137040 Mär 20 17:29 project1.ico
-rw-rw-r-- 1 tux tux     56 Mär 22 19:50 project1.lpr
-rw-rw-r-- 1 tux tux 138932 Mär 20 17:29 project1.res
-rw-rw-r-- 1 tux tux    323 Mär 20 17:29 unit1.lfm
-rw-rw-r-- 1 tux tux    439 Mär 20 17:29 unit1.pas

Somit ist es nochmals 10KB grössser .

Code: Alles auswählen

program Project1;
type
  TC=class
    procedure Ausgabe(s:String);
  end;
 
procedure TC.Ausgabe(s: String);
begin
  WriteLn(s);
end;
 
begin
end.

[m.fuchs]

Für mich, für meine Projekte aber mache ich das, ich optimiere wo es nur geht. Das fängt damit an, dass ich Lazarus nicht nutze...

Es gibt zwar einige Personen, die durchaus die Fähigkeiten und das Wissen haben um das gesamte System dahingehend zu optimieren, nur haben die in der Regel eine genau so begrenzte Zeit wie du.

Das ist schon klar, nur die Einstellung auf Optmierung gar nichts zu geben und das nicht mal im entferntesten im Fokus zu haben, geht mir komplett gegen den Strich. Es geht nicht um die allerletzten Bits, zu optimieren, aber es wird eben gar nichts darauf gegeben und das ist meiner Meinung nach eben auch falsch.

Ich finde dein Auftreten hier ganz schön unverschämt. Hast du irgendwelche Belege dafür, dass sich niemand mit dem Thema Optimierung bei FPC beschäftigt? So einen Compiler zu entwickeln ist schon ein ganzen Stück anspruchsvoller, als die übliche Anwendungssoftware. Wenn es ein Multi-Plattform-Compiler ist, dann wird es noch deutlich komplexer. Das ist übrigens auch ein Unterschied zu Delphi, der sicherlich auch in die Größe der Datei hinspielt.

Es gibt hier sicherlich genug Programmierer die auch ihre Programme optimieren. Die Tatsache dass Lazarus genutzt wird und nicht irgendein Monster mit .NET- oder JAVA-Framework dazu, ist dafür auch schonmal ein Indiz. Aber Optimierung ist nicht alles. Und schon gar nicht ist es das, was an erster Stelle steht.
Zuerst schreibe ich lesbaren Code, fange Fehlerfälle ab und sorge für eine gute Testabdeckung, dann und erst dann optimiere ich.

Und eins noch:

Das fängt damit an, dass ich Lazarus nicht nutze...

Warum bist du dann hier und beschwerst dich?

[m.fuchs]

Bei Konsolen-Anwendungen sieht es sogar noch schlechter aus.
Ohne Debugger:
Linux64 182KB

Für so ein kleines Programme ist der Speicherverbrauch recht hoch.

Code: Alles auswählen

program Project1;
begin
  WriteLn('Hello World');
end.

Du solltest aber auch mal eine Optimierung dazu schalten. Mit

Code: Alles auswählen

fpc -XX hello.pas

komme ich auf gerade mal 26 KiB.