Moin.
Nachdem ich nun eine Weile mit der Live-CD von Gentoo auf dem iBook herumgespielt habe, will ich das Ganze fest installieren. Jetzt stellt sich für mich die Frage: Lohnt sich das übersetzen per Hand? Ich meine, das ist mein Produktivsystem und eine Woche "Ausfallzeit" ist zu lang. Wie groß ist der Leistungsunterschied zwischen selbstübersetztem und vorkompiliertem Paket?
MfG
Carsten
On 29.06.04 Carsten Friede (cfriede@wh8.tu-dresden.de) wrote:
Wie groß ist der Leistungsunterschied zwischen selbstübersetztem und vorkompiliertem Paket?
Nach diversen Quellen aus dem Usenet: Bei Programmen, die wirklich Rechenzeit brauchen sinnvoll, ansonsten unter der Nachweisgrenze.
H.
Hallo Carsten,
Nachdem ich nun eine Weile mit der Live-CD von Gentoo auf dem iBook herumgespielt habe, will ich das Ganze fest installieren.
Gute Idee. Gentoo ist wohl das momentan Beste für einen ppc. :-)
Jetzt stellt sich für mich die Frage: Lohnt sich das übersetzen per Hand? Ich meine, das ist mein Produktivsystem und eine Woche "Ausfallzeit" ist zu lang.
Nein, Ausfallzeit ist teurer.
Es sei denn, Du hast eine distcc-Farm in der Nähe ;-)
Wie groß ist der Leistungsunterschied zwischen selbstübersetztem und vorkompiliertem Paket?
Sehr sehr gering.
Nebenbei gesagt, mit einem G4 kannst Du eh nur -O2 machen sonst wird der Code Mist ;-)
Liebe Grüsse
Marek
On Tue, 2004-06-29 at 16:50, Hilmar Preusse wrote:
Wie groß ist der Leistungsunterschied zwischen selbstübersetztem und vorkompiliertem Paket?
Nach diversen Quellen aus dem Usenet: Bei Programmen, die wirklich Rechenzeit brauchen sinnvoll, ansonsten unter der Nachweisgrenze.
Nur so ein Gedanke: Alle wollen immer nur auf "Geschwindigkeit" optimieren. Es wäre mal interessant ein Gentoo mit Optimierungen für Speicherplatz aufzusetzen. Früher[tm] haben wir ausführbare Amiga-Programme gepackt ("Turbo-Imploder"?), weil die Ladezeitersparnis der gepackten Programme die Entpackdauer wesentlich überstieg. Wer weiß, vielleicht nützt es bei den heutigen Speicherschweinen auch was.
<träum> Wenn die dietlibc soweit ist, daß alle Gentoo-Pakete damit kompilier-/linkbar sind, könnte man ein USE-Flag dafür einführen... USE=dietlibc -glibc </träum>
Eric
Nur so ein Gedanke: Alle wollen immer nur auf "Geschwindigkeit" optimieren. Es wäre mal interessant ein Gentoo mit Optimierungen für Speicherplatz aufzusetzen. Früher[tm] haben wir ausführbare Amiga-Programme gepackt ("Turbo-Imploder"?), weil die Ladezeitersparnis der gepackten Programme die Entpackdauer wesentlich überstieg. Wer weiß, vielleicht nützt es bei den heutigen Speicherschweinen auch was.
Ladezeitverkürzung scheint mit prelink auch ganz gut zu gehen ...
<träum> Wenn die dietlibc soweit ist, daß alle Gentoo-Pakete damit kompilier-/linkbar sind, könnte man ein USE-Flag dafür einführen... USE=dietlibc -glibc </träum>
Eric
... es gibt neuerdings eine ganze Reihe von Paketen, die mit dem uClibc Flag kompilierbar sind.
Mfg, AlexT
* Eric Schaefer eric@gixgax.de [2004-06-29 20:15 +0200]:
On Tue, 2004-06-29 at 16:50, Hilmar Preusse wrote:
Nach diversen Quellen aus dem Usenet: Bei Programmen, die wirklich Rechenzeit brauchen sinnvoll, ansonsten unter der Nachweisgrenze.
Nur so ein Gedanke: Alle wollen immer nur auf "Geschwindigkeit" optimieren. Es wäre mal interessant ein Gentoo mit Optimierungen für Speicherplatz aufzusetzen.
Warum sind _alle_ _immer_ so radikal? ;-)
Man kann ja auch rechenintensive Programme auf Geschwindigkeit optimieren lassen auch wenn sie dadurch größer werden und den Rest (werden wohl mehr als 90% sein) auf geringe Größe.
Früher[tm] haben wir ausführbare Amiga-Programme gepackt ("Turbo-Imploder"?), weil die Ladezeitersparnis der gepackten Programme die Entpackdauer wesentlich überstieg. Wer weiß, vielleicht nützt es bei den heutigen Speicherschweinen auch was.
Du suchst gzexe [1] bzw. upx [2], aber ob das heute, außer für Rettungsdisketten, noch viel bringt ist eine andere Frage, die man durchaus mal untersuchen sollte. Vielleicht hilt es bei sehr großen Programmen, aber bei denen wird auch der großteil in den shared objects liegen..
Stefan
[1] gehört zu gzip, man beachte: $ grep frequently `which gzexe` # Use this only for binaries that you do not use frequently. [2] http://upx.sf.net/
Eric Schaefer schrieb:
<träum> Wenn die dietlibc soweit ist, daß alle Gentoo-Pakete damit kompilier-/linkbar sind, könnte man ein USE-Flag dafür einführen... USE=dietlibc -glibc </träum>
Ich schätze mal wenn die dietlibc alles kann, dann wird sie wohl genauso groß sein müssen wie die glibc. Oder kennst du ein Feature der glibc, das garantiert niemand braucht?
Torsten
On Tue, 2004-06-29 at 21:54, Torsten Werner wrote:
Ich schätze mal wenn die dietlibc alles kann, dann wird sie wohl genauso groß sein müssen wie die glibc. Oder kennst du ein Feature der glibc, das garantiert niemand braucht?
Bloat. Im Ernst, schau Dir die Implementation einer einfachen Funktion bei der glibc und bei den Alternativen (dietlibc, uClibc, freelib, etc) an, dann reden wir weiter.
Eric
Eric Schaefer schrieb:
Bloat. Im Ernst, schau Dir die Implementation einer einfachen Funktion bei der glibc und bei den Alternativen (dietlibc, uClibc, freelib, etc) an, dann reden wir weiter.
Aus irgendeinem Grunde sind die genannten Alternativen aber eben keine solchen, wenn es darum geht, alle existierenden Applikationen zu unterstützen. Welche Funktion / welches Feature ist denn deiner Meinung in der glibc nach sinnlos?
Torsten
On 30.06.04 Stefan Seyfried (seife@gmane0305.slipkontur.de) wrote:
On Tue, Jun 29, 2004 at 11:45:14PM +0200, Torsten Werner wrote:
Moin,
unterstützen. Welche Funktion / welches Feature ist denn deiner Meinung in der glibc nach sinnlos?
I18N.
Echte Männer haben eh' LANG=C in ihrer .profile ;-)
drachi:[hille] >grep LANG /etc/profile drachi:[hille] >grep LANG .bash_profile drachi:[hille] >locale|grep LANG LANG=C
Warum ist die glibc (2.3.2) eigentlich mehr als doppelt so groß wie libc5 (also die reine libc, nicht das was noch dazukommt)? Ich hab mal ein embedded system gesehen, da war glibc 2.2.5 drauf....
H.
On Wednesday 30 June 2004 01:04, Hilmar Preusse wrote:
Warum ist die glibc (2.3.2) eigentlich mehr als doppelt so groß wie libc5 (also die reine libc, nicht das was noch dazukommt)? Ich hab mal ein embedded system gesehen, da war glibc 2.2.5 drauf....
Es sind haufenweise Sub-Bibliotheken (z.B. libcrypt) in die glibc gewandert und die Rückwärtskompatibilität der glibc2 ist wesentlich besser als die der libc5 (sprich es sind mehrere Versionen vieler Funktionen da drin). Und es sind haufenweise Funktionen dazugekommen (z.B. md5_*).
Konrad
On Tue, 2004-06-29 at 23:45, Torsten Werner wrote:
Eric Schaefer schrieb:
Bloat. Im Ernst, schau Dir die Implementation einer einfachen Funktion bei der glibc und bei den Alternativen (dietlibc, uClibc, freelib, etc) an, dann reden wir weiter.
Aus irgendeinem Grunde sind die genannten Alternativen aber eben keine solchen, wenn es darum geht, alle existierenden Applikationen zu unterstützen. Welche Funktion / welches Feature ist denn deiner Meinung in der glibc nach sinnlos?
Ich sag nicht, daß irgendwelche Features überflüssig sind. Bloat ist überflüssig. Viele Funktionen sind einfach zu umständlich implementiert oder einfach in fette Wrapper gepackt. Klassisches Beispiel:
$ ls -l total 400 -rw-r--r-- 1 eric eric 70 Sep 29 2002 hello.c -rwxr-xr-x 1 eric eric 832 Jul 28 2002 hello_dietlibc_static -rwxr-xr-x 1 eric eric 4817 Sep 21 2002 hello_glibc_dynamic -rwxr-xr-x 1 eric eric 388768 Jul 28 2002 hello_glibc_static $ cat hello.c #include <stdio.h>
int main() { puts("Hello World\n"); return 0; }
Noch Fragen?
Es gibt viele Bereiche in denen die glibc ihren Platz hat, aber für Systeme, bei denen Speicher knapp ist, ist sie (und die anderen genannten) eine Alternative.
Eric
Hi Eric,
* Eric Schaefer eric@gixgax.de [2004-06-29 23:25 +0200]:
On Tue, 2004-06-29 at 21:18, Stefan Moch wrote:
Warum sind _alle_ _immer_ so radikal? ;-)
Weil _alle_ _Verallgemeinerungen_ falsch sind?
»All generalizations are false, including this one.« -- Mark Twain
(-;
Eric Schaefer schrieb:
$ ls -l total 400 -rw-r--r-- 1 eric eric 70 Sep 29 2002 hello.c -rwxr-xr-x 1 eric eric 832 Jul 28 2002 hello_dietlibc_static -rwxr-xr-x 1 eric eric 4817 Sep 21 2002 hello_glibc_dynamic -rwxr-xr-x 1 eric eric 388768 Jul 28 2002 hello_glibc_static $ cat hello.c #include <stdio.h>
int main() { puts("Hello World\n"); return 0; }
Noch Fragen?
Ja was ist das denn für ein Beispiel? Ist alles außer puts überflüssig? Ich denke das meinst du sicher nicht.
Kann deine geliebte dietlibc lokalisierte Ausgaben? Wenn nicht, dann ist sie schlicht unbrauchbar für den allgemeinen Nutzer.
Es gibt viele Bereiche in denen die glibc ihren Platz hat, aber für Systeme, bei denen Speicher knapp ist, ist sie (und die anderen genannten) eine Alternative.
Für embedded Systeme, wo nur wenige Features gebraucht werden, ist die glibc natürlich zu groß. Man würde dort ja auch kein KDE/gnome/openoffice usw. installieren. Trotzdem ist das keine Begründung, dass die glibc irgendwie bloated ist.
Torsten
On Thu, Jul 01, 2004 at 07:28:32AM +0200, Torsten Werner wrote:
Eric Schaefer schrieb:
Hi,
Kann deine geliebte dietlibc lokalisierte Ausgaben? Wenn nicht, dann ist sie schlicht unbrauchbar für den allgemeinen Nutzer.
ACK, dennoch gibt es viele Sachen in der glibc die wesentlich effizienter implementiert werden könnten, die BSDlibc macht es ja vor.
Es ist mir z.B. schleierhaft warum es in der glibc immer noch keine sichere StringCopy Funktion gibt, nur weil der Maintainer der _Meinung_ ist, alle anderen Programmierer bräuchten sowas nicht...
Ciao, Tobias
On Thu, 2004-07-01 at 07:28, Torsten Werner wrote:
-rwxr-xr-x 1 eric eric 832 Jul 28 2002 hello_dietlibc_static -rwxr-xr-x 1 eric eric 4817 Sep 21 2002 hello_glibc_dynamic
Ja was ist das denn für ein Beispiel? Ist alles außer puts überflüssig? Ich denke das meinst du sicher nicht.
Kann deine geliebte dietlibc lokalisierte Ausgaben? Wenn nicht, dann ist sie schlicht unbrauchbar für den allgemeinen Nutzer.
Nein. Die Frage ist, ob I18n derart speicherintensiv ausfallen muß. Wobei ich mich frage, wofür puts() I18n braucht?
Ansonsten siehe Tobias' Antwort...
Eric
Ich habe gerade mal die .so-Dateien auf meinem Rechner untersucht: die libc liegt nach Größe an Position 89 bzw. 96 (ohne bzw. mit tls) und die dickste library (/usr/lib/openoffice/program/libsvx645li.so) ist ca. zehnmal größer als die libc. Ich finde die Diskussion um die scheinbar fette libc aus dieser Sicht nun doch recht albern.
Torsten
On Sat, 2004-07-03 at 12:07, Torsten Werner wrote:
Ich habe gerade mal die .so-Dateien auf meinem Rechner untersucht: die libc liegt nach Größe an Position 89 bzw. 96 (ohne bzw. mit tls) und die dickste library (/usr/lib/openoffice/program/libsvx645li.so) ist ca. zehnmal größer als die libc. Ich finde die Diskussion um die scheinbar fette libc aus dieser Sicht nun doch recht albern.
In diesem Kontext hast Du ja auch recht.
Ich zitiere mich aber selbst nochmal:
-rwxr-xr-x 1 eric eric 832 Jul 28 2002 hello_dietlibc_static -rwxr-xr-x 1 eric eric 4817 Sep 21 2002 hello_glibc_dynamic
Faktor 5? Trotz daß es ersteres statisch und letzteres dynamisch gelinkt wurde?
Prinzipiell ist es so, daß Rechner heutzutage genügend Speicher haben, um sowas wegzustecken, aber war die Community nicht immer stolz darauf, daß Linux auch auf alter HW flott und sparsam läuft? Irgendwie entwickelt sich das in die falsche Richtung.
Eric
lug-dd@mailman.schlittermann.de
-
Alexander Tomisch -
Carsten Friede -
Eric Schaefer -
Hilmar Preusse -
Konrad Rosenbaum -
Marek Werstak -
Stefan Moch -
Stefan Seyfried -
Tobias Koenig -
Torsten Werner