glibc selbst gemacht

[ThePsycho]

hallo,

auf der suche nach einem kleinen stückchen an performance-gewinn kam ich auf die idee, meine glibc mit den entsprechenden optimierungsflags selbst zu backen
nun habe ich etwas die faq durchstöbert und gesehen, dass libraries, die unter einer anderen major-version (wie übersetzt man das ?) kompiliert wurden, dann nicht mehr gehen
ok, jetzt war meine idee, einfach die exakt gleiche version zu nehmen, dann profitiert man zwar nicht von fixes und besserungen, aber die optimierungen bei etwas so zentralem wie der libc sollten auf jeden fall spürbar sein.
nun wäre nur noch die frage: welche glibc-version arbeitet bei mandrake 9.1 ?

desweiteren bitte ich jeden, bedenken, fragen, vor- und ratschläge jeder art zu posten, weil mir schon bewusst ist, dass das schnell in pfusch enden kann

danke

[Spartakus]

Allgemein ist es bei "älteren" Paket-Distributionen wie Mandrake/Redhat/Suse nicht so einfach, topaktuelle Paket-Sourcen (*.src.rpm) zu kompilieren. Sei es ein Problem mit der glibc oder dem C-Compiler oder was weiß ich nicht.

Ich empfehle deshalb, erstmal von Deinem Mandrake 9.1 (?) auf die aktuelle Cooker-Version upzugraden. Dies kannste ganz einfach mit dem Mandrake-Tool urpmi machen.

Hier ist erklärt, wie man urpmi benutzt:
http://www.pl-forum.de/t_system/urpmi.html#ToC3

Ich fasse mal kurz für den Fall "Upgrade" zusammen:

1.) Man suche sich auf http://www.mandrakelinux.com/en/ftp.php3 einen Download-Server und klicke sich dann zum Mandrake-Cooker-Verzeichnis durch.

2.) Dann sucht man die Datei "synthesis.hdlist.cz". Sie befindet sich auf dem jetzigen Server z.B. unter ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/Mandrake-devel/cooker/i586/Mandrake/RPMS/synthesis.hdlist.cz .

3.) Man öffnet die Paket-Verwaltung und fügt einen FTP-Server hinzu: Name ist egal, und als URL nimmt man den Link auf die "synthesis.hdlist.cz".

4.) Öffne eine Konsole, logge Dich mit "su" als root ein und tippsle: "urpmi --auto-select". Es werden dann alle Pakete angezeigt, die aktualisiert werden.

5.) Wenn du das Upgraden gestartet hast, darfst du unter keinen Umständen irgendwelche RPMs installieren/deinstallieren. Sonst ist der ganze URPMI-Cache futsch. Ärgerlich, wenn schon 500 MB an Daten runtergeladen worden sind. ^^

[Ganon]

Also eigentlich wird von jeglicher Optimierung der glibc abgeraten! Kann funktionieren, muss aber nicht! Kann sein das dein System danach instabil läuft, oder nur mist macht! Habe schon von vielen Sachen gehört.

[Spartakus]

Wie man nun Sourcen herunterladen und kompilieren lässt, hab ich noch nicht rausbekommen. Ich mach das immer per Hand.

Überhaupt ist es ein Proble, mal eben 'ne beliebige Datei durch eine "gleichaktuelle" zu ersetzen. Z.B. hängen an der Datei libxml2* zig Abhängigkeiten. Am einfachsten ist es da, auf eine neuere Version der Datei zu warten und diese dann zu kompilieren und zu installieren.

Kannste ja mal am Kernel 2.4.22-18mdk ausprobieren. Der Kernel wird nämlich nicht mit installiert bei "urpmi --auto-select".

Noch ein Fallstrick: Wenn man GNOME oder KDE aktualisiert, dann bitte in einem Rutsch. Sonst kann es passieren, dass man plötzlich nur noch die Konsole zur Verfügung hat. Und ich bin doch eher 'n GUI-Nutzer. Deshalb wie schon erwähnt am besten erstmal die ganze Distri upgraden; da kann dann nichts schiefgehen. Trotzdem natürlich die wichtigen Dateien sichern.

[Spartakus]

Original geschrieben von Ganon
Also eigentlich wird von jeglicher Optimierung der glibc abgeraten! Kann funktionieren, muss aber nicht! Kann sein das dein System danach instabil läuft, oder nur mist macht! Habe schon von vielen Sachen gehört.


Die glibc hab ich bei mir auf Athlon kompiliert und noch keine Probleme gehabt.
Edit: Allerdings hatte ich das ganze System neu aufgesetzt. Also nur 'ne neue glibc optimieren undinstallieren endet wohl im Desaster. ^^


Mit 'nem optimierten GCC hatte ich weniger Erfolg und konnte dann nicht mehr kompilieren. Lag aber vielleicht daran, dass ich GPP nicht aktualisiert habe.

[ThePsycho]

@spartakus

mein mandrake kann ich einerseits nicht per rpms updaten, da ich da schon einiges verändert habe, das würde sicher zu problemen führen

und auf der anderen seite will ich gar nichts verändern. das system ist so ok wie es läuft, nur wär halt n tick mehr geschwindigkeit nett.

@ganon
so rein aus der theorie heraus sollten optimierungen die funktion nicht beeinflussen, sonst wäre es imho ein compilerbug
möchte deine aussage aber auch nicht in frage stellen

evtl kannst du mir sagen, wo du schon von problemen gehört hast ?
oder wo ich vll leute finde, die sowas schon gemacht haben

also auf jeden fall danke für die antworten, mehr meinungen wären schön :)

und natürlich steht noch die frage offen, welche glibc in einem mandrake 9.1 arbeitet... wie finde ich das heraus ?

[Ganon]

Original geschrieben von ThePsycho
@ganon
so rein aus der theorie heraus sollten optimierungen die funktion nicht beeinflussen, sonst wäre es imho ein compilerbug
möchte deine aussage aber auch nicht in frage stellen

evtl kannst du mir sagen, wo du schon von problemen gehört hast ?
oder wo ich vll leute finde, die sowas schon gemacht haben


Sicher! Es kann funktionieren! Klar ist das dann ein Compiler-Bug und der gleichen! Und gerade gcc ist nicht gerade Bug-frei!

Bei Optimierungen wird der Code ja besser an die Maschine angepasst, d.h. zum Beispiel wird ein gewisser Bestandteil durch´s SSE oder MMX gejagt, statt über die normale FPU! Ist dann da nur ein Bug drinnen, dann ist´s mit der glibc Essig, da das ein heikles Teil des Systems ist. Der gcc weiß nämlich nicht was er da übersetzt.

Gerade bei richtig scharfer Optimierung kann es zu Problemen kommen und durch entsprechende Rechenfehler und der folgenden Pipeline-Leerung sogar zu Geschwindigkeitsverlust.

Sicher! Es muss nicht sein, kann sein das alles prima läuft. Aber das musst du entscheiden. Aber da du das System wohl nicht produktiv einsetzt, würde ich auch Optimieren bis der Compiler raucht! Aber nur als 2. System! *gg*

Guck dir mal LRs an! Ist zwar zur Zeit auf Eis gelegt, aber die Verwenden noch etwas anderes! Combreloc heißt das imo! Soll bis zu 30% Leistung bringen. Musst dich mal informieren!

[Spartakus]

[SIZE=1]Original geschrieben von ThePsycho
@spartakus

mein mandrake kann ich einerseits nicht per rpms updaten, da ich da schon einiges verändert habe, das würde sicher zu problemen führen

und auf der anderen seite will ich gar nichts verändern. das system ist so ok wie es läuft, nur wär halt n tick mehr geschwindigkeit nett.



Das Problem ist auch nur, dass sich bereits installierte Pakete nicht einfach durch die selbe Version überschreiben lassen. Ein Paket muss erst deinstalliert werden, um es neu zu installieren. Überschreiben funzt zu 99% nicht, weil's Abhängigkeiten gibt oder einfach nicht funktioniert. Deshalb halt eine neuere Paket-Version benutzen. Und neuere Paketversionen werden vermutlich Probleme bereiten beim kompilieren bereiten, weil entweder der Compiler zu alt ist, oder eben 'ne glibc zu alt ist oder 'n neues Paket (vielleicht 1 Jahr) sich nicht kompilieren lässt, weil die Abhängigkeite zu alt sind.

Ich hab z.B. anfangs versucht, punktuell einige Pakte zu optimieren. Kleine Sachen wie eroaster, gftp und grip z.B. lassen sich ziemlich problemlos optimieren und installieren, weil kaum/keine Abhängigkeiten bestehen. Dagegen hab ich mit GNOME 2.2 aus Mandrake 9.1 keine Erfolg gehabt: Es gibt zum einen einige Pakete, die sich nicht deinstallieren lassen (z.B. wird curl nicht im Paket-Uninstaller angezeigt) und zum anderen lassen sich einige Pakete partout nicht kompilieren, wahrsch. weil irgendwelche Devel-Libaries zu alt sind.

Deswegen hab ich vor 'nem Monat auf Mandrake Cooker (ist zur Zeit auf dem Stand von Mandrake 9.2) "gepatcht" und danach alle neuen Updates selber kompiliert und installiert.

[Spartakus]

Original geschrieben von ThePsycho
und natürlich steht noch die frage offen, welche glibc in einem mandrake 9.1 arbeitet... wie finde ich das heraus ?

Am einfachsten den Paket-Uninstaller öffnen, nach "glibc" suchen und dann schauen, welche Versionsnummer die angezeigte "glibc-devel" hat. Andere Pakete von glibc werden nicht angezeigt, wahrscheinlich, weil sie unabkömmlicher Bestandteil des System sind.

[ThePsycho]

ich bin zu spät auf die idee gekommen, auf distrowatch zu kucken - auf jeden fall ist es die version 2.3.1

wegen updaten und selbst kompilieren: nunja, manchmal muss man unschönerweise libs von hand löschen und links neu setzen, es ist aber imho nicht so dramatisch wie du es darstellst

und wenn was fehl oder zu alt ist: gute gelegenheit, um auch das zu erneuern


nunja, was die glibc angeht, das hat sich leider erledigt.
es scheint tatsächlich compilerbugs zu geben (ich habe gcc version 3.2.3), da bei einem "make check" bei glibc version 2.3.1 und version 2.3.2 fehler auftreten
glücklicherweise wurden die fehler per selbst-diagnose gefunden, so wurde größerer schaden vermieden (bzw lösch-aufwand, weil ich die ganzen libs in /opt erstmal ausgetestet hätte)

aber ein schöner zustand ist das wahrhaftig nicht - denn das heisst, dass jedes programm ab einem bestimmten optimierungslevel auf beliebige art und weise fehlerhaft sein kann :(
- das gibt einem schon zu denken

[Spartakus]

Original geschrieben von ThePsycho

aber ein schöner zustand ist das wahrhaftig nicht - denn das heisst, dass jedes programm ab einem bestimmten optimierungslevel auf beliebige art und weise fehlerhaft sein kann :(
- das gibt einem schon zu denken

Also wie bereits gesagt: Probleme hatte ich explizit durch das Optimieren noch nie. Möglicherweise (wie oben gesagt) bei GCC mal, aber da hab ich auch nur die Hälfte durch optimierte Pakete übersetzt und die andere Hälfte durch den Standard-Compiler.

Es kann, wenn man sich das mal so überlegt, auch gar kein Fehler auftreten. Immerhin kompiliert Redhat seine Pakete z.B. auf i386, SuSe auf i486 (?) und Mandrake auf i586.

Mal meine Compilerflags (die Standard-Flags von Mandrake aus der Datei "rpmrc" im Verzeichnis "/usr/lib/rpm":


optflags: i386 -O2 -fomit-frame-pointer -pipe -march=i386 %{debugcflags}
optflags: i486 -O2 -fomit-frame-pointer -pipe -march=i486 %{debugcflags}
optflags: k6 -O2 -fomit-frame-pointer -pipe -march=k6 %{debugcflags}
optflags: i586 -O2 -fomit-frame-pointer -pipe -march=i586 -mcpu=pentiumpro %{debugcflags}
optflags: i686 -O2 -fomit-frame-pointer -pipe -march=i686 %{debugcflags}
optflags: athlon -O2 -fomit-frame-pointer -pipe -march=athlon %{debugcflags}
optflags: ia64 -O2 -pipe %{debugcflags}
optflags: x86_64 -O2 -pipe %{debugcflags}
optflags: amd64 -O2 -pipe %{debugcflags}


Wie man sieht, wurde bei den Optimierungen ziemlich "behutsam" zu Werke gegangen. "-O3" z.B. soll, wie ich gehört habe, im ungünstigen Fall schon wieder zu aufgeblähten Binaries und Performance-Einbußen führen.

[Ganon]

Also mit -O3 sollte es eigentlich schneller sein! Nur wie ich oben sagte->treten Fehler auf, dann muss die Pipeline geleert werden->langsamer!

Und mit Optimierung meine ich nicht -march=i686 oder -march=pentium4! Sondern richtige Optimierung mit SSE und weiß der Teufel was!

Bei normalen Programmen wie Video/Audio-Playern oder anderen Anwendungsprogrammen (KDE, OpenOffice etc.) ist extreme Optimierung schon nicht schlecht! Da passiert auch nicht viel und es könnte sogar schneller sein!

Nur bei System-nahen Sachen sollte man vorsichtig sein! Ich hab´s ja auch schon gemacht, also ich rate hier nicht nur rum! Da habe ich halt den Kernel mit -O3 -msse usw. usw. compiliert! Das das System nachher megamäßig langsam war, auch mal komplett verreckte und einige Module nicht funktionierten sollte verständlich sein!

[ThePsycho]

naja ich denke mir das eben so:code ist code !

code, der bei der glibc falsch übersetzt wird, wird auch bei anderen programmen falsch übersetzt.
die glibc ist bei weitem nicht das erste was ich optimieren wollte (aber das erste das fehler meldet)

nur: fehler die nicht entdeckt / bemerkt sind trotzdem vorhandene fehler

aber daran lässt sich wohl nichts ändern - immerhin funktioniert ja alles :)

zwecks reproduzierbarkeit: meine flags waren: -O2 -mcpu=athlon -march=athlon -mmmx -m3dnow

und genau diese befehlserweiterungen waren wohl der grund (obwohl das ja auch nicht sinn der sache ist

hat man sich bei gcc 3.3 eigentlich mit diesem problem befasst ?
(lese ich grade mal nach)

[Gast]

Original geschrieben von ThePsycho
naja ich denke mir das eben so:code ist code !

code, der bei der glibc falsch übersetzt wird, wird auch bei anderen programmen falsch übersetzt.
die glibc ist bei weitem nicht das erste was ich optimieren wollte (aber das erste das fehler meldet)

nur: fehler die nicht entdeckt / bemerkt sind trotzdem vorhandene fehler

aber daran lässt sich wohl nichts ändern - immerhin funktioniert ja alles :)

zwecks reproduzierbarkeit: meine flags waren: -O2 -mcpu=athlon -march=athlon -mmmx -m3dnow

und genau diese befehlserweiterungen waren wohl der grund (obwohl das ja auch nicht sinn der sache ist

hat man sich bei gcc 3.3 eigentlich mit diesem problem befasst ?
(lese ich grade mal nach)

Auf MMX- und 3DNOW-Optimierungen (sowie SSE/SSE2) bin ich erst durch die Gimp-Developer-Version 1.3.x aufmerksam geworden, weil der Status der Optimierungen beim Start des Programms direkt abgezeigt wird. Aber ist es einfach so möglich, auf das "Zeug" zu optimieren, wenn's vom Entwickler nicht vorgesehen ist? Ich hab da keine Antwort.

[Harleckin]

Aber ist es einfach so möglich, auf das "Zeug" zu optimieren, wenn's vom Entwickler nicht vorgesehen ist? Ich hab da keine Antwort.
Nein!
Gar so einfach ist es nicht. IMHO muss der Entwickler die Optimierungen in den Code einfliesen lassen..
solltest du mehr Interesse an diesen Thema haben, frag mal bei Zeckensack und Konsorten nach. ;)

@GANON
Hier mal meine Flags, diese sind für den G4 ganz interessant..

CFLAGS="-mcpu=7450 -mtune=7450 -maltivec -mabi=altivec" (gcc 3.x vorausgesetzt)

[1] http://www.freehackers.org/gentoo/gccflags/flag_gcc3.html

[Ganon]

Original geschrieben von Harleckin
@GANON
Hier mal meine Flags, diese sind für den G4 ganz interessant..

CFLAGS="-mcpu=7450 -mtune=7450 -maltivec -mabi=altivec" (gcc 3.x vorausgesetzt)

[1] http://www.freehackers.org/gentoo/gccflags/flag_gcc3.html

Danke! Morgen mal ein paar Tests machen! *ggg*

[Ganon]

Original geschrieben von Gast
Aber ist es einfach so möglich, auf das "Zeug" zu optimieren, wenn's vom Entwickler nicht vorgesehen ist? Ich hab da keine Antwort.

Hi!

Jain! Der Compiler kann nur den Standard-Code optimieren, bzw. verschiedene Code-Blöcke! Mal als Beispiel-> Zahl = 32,65423 * 65,215 / 53,545! Der Compiler schickt das ganze nun nicht durch die normale FPU, sondern durch SSE oder sonstiges, welches "schneller" ist (Jetzt mal nur als Beispiel)! Der Compiler versucht bei Optimierungen eigentlich nur die vorhandenen Register in der CPU am besten zu nutzen. So verwendet er wie oben erwähnt Zusätze in den CPUs die bei normaler Compilierung nicht verwendet würden.

Diese Art von Optimierung ist eigentlich sehr wirkungsvoll. Siehe hier einfach vergleiche zwischen GCC, Intel und sonstigen Compilern. Dort kommen krasse Unterschiede raus.

Besser optimieren kann der Programmierer. Dieser kann die extra Funktionen in der CPU direkt ansprechen. So gibt es z.B. unter Mac die altivec.h für C/C++! In dieser sind Funktionen vorhanden die dann alle über die Altivec-Einheit ablaufen. Anders optimieren ist auch möglich, z.B. durch intelligente Speichernutzung.

Noch etwas zum Punkt Compiler-Optimierung. Ein gutes Beispiel dafür sind ältere Versionen von GCC3. Dieser konnte in einigen Versionen keinen lauffähigen Linux-Kernel kompilieren. Da wurde halt intern zu viel optimiert, inkl. Bugs! Also schön vorsichtig sein.