# Gentoo beschleunigen (Kernel, CFLAGS, ...) - Ideensammlung

## Niko_K

Hi,

ich arbeite nun schon seit einiger Zeit mit Gentoo Linux und ich bin auch wirklich zufrieden! Es gibt zwar noch manchmal einige Probleme, aber generell kann man sagen, dass Gentoo mit den ebuild eine willkommene Abwechslung in der auch sonst schon schönen Linux Welt ist!

Wenn nun so ein System zuverlässig arbeitet, stellt man sich zwangsläufig die Frage, wie man das OS noch verbessern kann und genau das will ich hier ansprechen:

Wie bekomme ich Gentoo noch schneller und schlanker?

Klar, das kan man mit CFLAGS machen, aber dazu kommen wir erst später!

Ich möchte erst mal eine kleine "Umfrage" machen, wie man den Kernel konfigurieren sollte. Wenn ich den Kernel nun auf ein System anpasse (also lassen wir mal die plattformunabhängigkeit weg), sollte ich dann alles fest in den Kernel integrieren oder bei ein paar wenigen Bestandteilen doch lieber Module verwenden? Was bringt so ein Modul im Bezug auf schnelligkeit bzw- Kernelgröße?

Ich hoffe, dass wir es schaffen, eine weitläufige Diskussion zu erzeugen und somit eine deutschsprachige Ideensammlung im Bezug auf Gentoo-Schnelligkeit ins Internet zu stellen,

Niko

----------

## deepthought

Halte Deinen Kernel klein; versuche, nur das nötigste fest einzukompilieren -- das spart Arbeitsspeicher. Alles andere kann als Modul übersetzt werden, denn es kostet fast nichts, ein Modul nachzuladen; der Kernel "entlädt" unbenötigte Module nach einer Weile automatisch. Ansonsten ist wichtig, im Kernel Deinen Prozessortypen korrekt zu wählen. Viel mehr Optimierungsmöglichkeiten gibt es eigentlich nicht.

Viele Grüße,

Alexander

----------

## Niko_K

Hi,

was mache ich aber zum Beispiel mit einem Drucker?

Eigentlich ist der immer eingeschlatet und der PC braucht ihn ja auch eigentlich für einen Eintrag in /dev/...

Ist es jetzt klüger, den Drucker als Modul zu übersetzen?

Du schreibst da oben, dass der PC ein nicht benötigtes Tool nach einiger Zeit automatisch entlädt, ...

Macht er das dann auch mit dem Drucker und bedeutet das, dass der Drucker dann nicht mehr ansprechbar ist? (nach meiner Erfahrung nach ja nicht, aber wie funzt das dann?)

Niko

----------

## AustrianCoder

Das mit den Modulen wird wahrscheinlich so laufen:

Wenn du etwas drucken möchtest und das Modul ist nicht geladen, wird es automatisch geladen. Dann ist es noch eine Zeit lang geladen sein und wir dann, da man es wahrscheinlich nicht sofort wieder braucht, entladen.

Das Modul dienst also zur Steuerung des Druckers. Es sollte keinen Unterschied vom Speed geben, ob Modul oder fest im Kernel. Als Modul gibts einen Vorteil. Der Kernel ist schlanker und braucht dadurch weniger Arbeitsspeicher und ist schneller geladen.

Doch das laden und entladen von Modulen braucht nicht lange.

Hoffe, dass dies ungefähr der Realität entspricht. Bin Coder und hab mir das logischen Gedanken zusammengereimt   :Smile: 

----------

## Niko_K

Hi,

das "bin Coder und hab mir das (mit) logischen Gedanken zusammengereimnt" könnte von mir sein!

Ich dachet auch an sowas.

Ich bin nur unentschlossen, ob das Laden und Entladen der Module nicht wesentlich mehr Zeit in anspruch nimmt. Habt Ihr den Drucker als Modul im Kernel oder nicht?

Niko

----------

## deepthought

So, wie ihr es beschrieben habt, läuft es auch: im Kernel-Space des Betriebssystems läuft ein Dämon, der Module nach Bedarf lädt und entlädt. Bis Linux-2.2.x konnte man diesen sogar als eigenen Prozeß mit ps anzeigen, er hieß kmod. Das Laden und Entladen von Modulen ist effizient, d.h. es kostet (fast) keine Prozessorzeit. Das automatische Laden erfolgt anhand des in /etc/modules.conf angegebenen Mappings von Major/Minor-Gerätenummern auf das entsprechende Kernelmodul. Das ganze funktioniert im Prinzip so:

1. Ein Prozeß fordert ein bestimmtes Gerät an (z.B. /dev/foo/bar, welches 141/13 als Major/Minor-Nummer hat)

2. Das Gerät ist unter /dev nicht vorhanden (devfs) oder es ist kein physisches Gerät für diesen Eintrag registriert (non-devfs). Der Kernel suspendiert den anfordernden Prozeß (schreibt PCB und so weg), lädt den Kernel-Moduldämon und übergibt ihm die Kontrolle.

3. Der Kernel-Moduldämon durchsucht die Tabelle in /etc/modules.conf nach der Zeile für die angegebene Gerätenummer (141/13). Hinter dem gefundenen Eintrag steht das zuständige Modul (falls nicht -> Fehler).

4. Der Kernel-Moduldämon versucht, das entsprechende Modul in /lib/modules/`uname-r` zu finden und zu laden (falls das Modul nicht existiert oder nicht geladen werden kann -> Fehler)

5. Der Kernel lädt den suspendierten Prozeß wieder in die CPU und startet ihn dort, wo er vorher angehalten wurde. Für den Prozeß ist das Gerät -- schwupps -- sicht- und (hoffentlich, z.B. wegen Rechten) nutzbar.

Insofern ist es auf alle Fälle effizienter, Module zu verwenden, wo immer möglich, weil so der vom Kernel benötigte Arbeitsspeicher klein gehalten wird.

Viele Grüße

Alexander

----------

## Niko_K

Hi,

okay, ich werde da zwar einige Ausnahen machen (USB full HID support - den brauche ich wegen meiner USB Tastatur und meiner USB Maus wirklich immer), aber der Rest wird jetzt mal auf Module umgestellt!

Kommen wir nun zu einr weiteren Optimierunsoption, den CFLAGS. Postet doch einfach mal eure Einstellung, ich habe meine schon fast überoptimiert (ich poste meine dann auch später mal, mache jetzt zuerst mal den Kernel)

Niko

----------

## deepthought

CFLAGS="-march=athlon -O3 -pipe -fomit-frame-pointer -ffast-math -funroll-loops -fforce-addr"

Aber mal ganz abgesehen davon ist für diese Diskussion CFLAGS Central der bessere Ort...

Viele Grüße,

Alexander

----------

## AustrianCoder

Noch was:

Dein Gentoo kannst du mit den richtigen Parametern für hdparm beschleunigen. Must halt bloß wissen, was deine Festplatte/n mitmacht.

----------

## dertobi123

 *deepthought wrote:*   

> Aber mal ganz abgesehen davon ist für diese Diskussion CFLAGS Central der bessere Ort...

 

... Oder der "su und Optimierungen" Thread im deutschen Forum ...

Tobias

----------

## Niko_K

Hi,

na dann klappere ich mal die anderen Beiträge und Webseiten ab.

Ich persönlich denke, dass mein Gentoo ziemlich schnell läuft, allerdings kann sich nochmal erkundigen nicht schaden, ...

Hdparm bringt zwar bei den Festplatten einiges, aber bei meinem DVD kann ichs fast vergessen (grip rippt nur mit 3.2-3.8x Geschwindigkeit)

Niko

----------

## MrTom

Bei mir hat der Umstieg auf GCC 3.3.1 einiges gebraucht. 

Hab keine Messungen gemacht, aber finde das compilieren geht schneller und der erzeugte Code ist auch schneller.

----------

## bmichaelsen

Füttert bitte auch das

Gentoo Kernel And Hardware Wiki  :Shocked:   :Cool:   :Very Happy:   :Very Happy: 

das aus Ideen hier im Forum entstand.

Grüsse, Björn

----------

## kollega

Hi

Auch wenns nich wirklich kernelspezifisch ist...

Was mir recht geholfen hat ist der CCBench den es auf der RockLinux-Page gibt. Den einfach mal rennnen lassen und dann findet der Benchmark die "schnellsten" CFlags heraus. Man kann das Tool auch selbst ein wenig erweitern indem man einfach in das Skript ein paar mehr CFlags miteinbindet.

Das rentiert sich in meinen Augen aber nur wenn man schon ein bestehendes System hat und das mit emerge --emptytree "aufbohren will.

Ausserdem hab ich mit der prelink-Geschichte auch schon einige positive Erfahrungen gemacht. Dazu brauch ich mich aber glaub ich nicht weiter auslassen

greetz

tobi

----------

## yhirmikq

Hi,

eine Frage zum ccbench. Ich hab hier einen Pentuim 4 und ccbench behauptet steif und fest am besten sollte ich mit --march=athlon-xp kompilieren  :Question: 

Kann man das machen oder gibt es das Probleme? 

-

Sebastian

----------

## Niko_K

Edit ian!:

Sorry, dass kann ich nicht so stehen lassen. Das ist schlichtweg falsch. Die Note von mir hier, damit jemand nicht wegen diesem Posting auf die Idee kommt das wirklich zu machen.

 *Quote:*   

> 
> 
> Hi,
> 
> also generell kannst du dass auch mit -march=athlon-xp kompilieren und die Programme werden auch alle funktionieren.
> ...

 

EDIT Niko: Sorry, das wusste ich nicht so genau, ...

----------

## deepthought

Hm, dann muß ich wohl mit dem Editieren auch nachsteuern, damit keine Mißverständnisse entstehen:

ian! hat völlig Recht: Niko_Ks Aussage stimmt so nicht und kann zu massiven Problemen führen. Die --march=<irgendwas>-Option sollte man mit äußerster Vorsicht verwenden, da hierdurch Objektcode für einen bestimmten Prozessor (mit all seinen Erweiterungen) erzeugt wird und nicht nur für eine bestimmte Architektur.

Es ist nämlich durchaus möglich, daß der eine Prozessor ein paar Opcodes mehr kennt als ein anderer (man denke an Erweiterungen wie MMX, SSE(2), 3Dnow! u.ä.). Gibt man als Architekturoption (--march) keine generische Architektur (z.B. i686) an, sondern eine konkrete Prozessorfamilie (z.B. athlon-xp), gestattet man damit dem Compiler, Opcodes zu benutzen, die NUR DIESER Prozessor kennt.

Stimmt nun aber der verwendete --march-Schalter nicht mit dem eigenen Prozessor überein, kann es sein, daß im Objektcode Maschinenbefehle stehen, die der eigene Prozessor gar nicht kennt. IdR. wird der Prozessor einen Interrupt erzeugen (Illegal Opcode Exception), den das Betriebssystem (sozusagen das Sicherheitsnetz) -- hoffentlich -- fängt und behandelt, indem es den Prozeß tötet. Passiert der ganze Salat im Kernel, gibt es kein Netz, das einen fangen könnte -- der Kernel verursacht einen oops() und steigt aus.

Insgesamt ist also DRINGEND davon ABZURATEN, eine andere als die *wirklich* vorhandene Prozessorarchitektur/-familie anzugeben.

Viele Grüße,

Alexander

----------

## furanku

hmmm, ich bin seit 7 Jahren mit Linux dabei, und compiliere mir auch meine Kernel seit dem. Eherlichgesagt habe ich ausser grob verkonfigurierten Kernels keine echten Performance Unterschiede im Alltagsbetrieb gespürt. Und auch die nur bei speziellen Anwendungen. Auch die CFLAGS habe ich, wie jeder Gentoo User, durchprobiert. Letztens bin ich von -03 auf -02 umgestiegen weil die libavi (bin mir nicht mehr so sicher) nicht mit -03 kompilierte. Habe auch keinen Unterschied gemerkt. Eherlichgesagt, glaube ich dass man nicht sooo laut mit dem Gentoo Performance Vorteil hausieren gehen sollte, da gibt es andere schöne Sachen, die Gentoo zu bieten hat. Bei SuSE, RedHat, Mandrake, Debian, etc.. arbeiten schliesslich auch keine Idioten.

Schön das wir's pro Paket einstellen können, aber, mal ehrlich, wer macht das?

Frank

----------

## thundersteele

```
gcc -O2 -march=k6 -fomit-frame-pointer -fcse-follow-jumps -funroll-loops -fgcse -maccumulate-outgoing-args -falign-functions=2
```

Also irgendwie glaube ich das nicht so ganz. Hab den test auf nem Pentium4 gemacht. Das script hat meiner Meinung nach überdurchschnittlich häufig mit -march=k6 verschiedene Optionen durchprobiert und vielleicht deshalb diese einstellung vorgeschlagen. Anscheinend ist die einstellung nichtmal diejenige die die meisten Punkte im Benchmark erreichte sondern die zuletzt probierte. 

Ich teste nochmal mit editierten script, das nur -march=pentium4 durchprobiert, aber ich glaube das hat keinen Sinn. 

@furanku

Es steht nirgends das viele Flags = schnell oder das sich O3 und O2 groß unterscheiden. Ich glaube ein System läuft auch mit -Os und -march=prozessor ziemlich schnell, wenn nicht schneller wegen der geringeren Ladezeiten für Programme/Libraries. 

Ich hab noch nirgends gesehen das SUSE (bzw. jede andere Distri die mit vorkompilieren Paketen arbeitet) verschiedene Versionen für jeden Prozessor anbietet. Also kann SUSE seine binaries bestenfalls mit -march=i686 kompilieren. Ich denke hier liegt doch eine Möglichkeit von Gentoo einen Performancevorteil rauszuholen, abgesehen von allen anderen Möglichkeiten. 

Es ist natürlich auch umgekehrt möglich mit einem schlecht konfigurierten Gentoo trotz perfekter compiler Flags wesentlich langsamer zu sein als z.B. SUSE.

----------

## sputnik1969

 *deepthought wrote:*   

> 
> 
> Aber mal ganz abgesehen davon ist für diese Diskussion CFLAGS Central der bessere Ort...
> 
> 

 

Sehe ich anders, denn CFLAGS Central ist in ENGLISCH...

Sonst müsstest du auch sagen, beinahe jede Diskussion hier im deutschen Teil des Forums gehört in einen anderen Teil des Forums...

 *deepthought wrote:*   

> Insgesamt ist also DRINGEND davon ABZURATEN, eine andere als die *wirklich* vorhandene Prozessorarchitektur/-familie anzugeben.

 

Ist meiner Ansicht nach auch nur bedingt richtig.

Ich würde das eher wie folgt formulieren:

Insgesamt ist also DRINGEND davon ABZURATEN, eine andere als die *wirklich* vorhandene Prozessorarchitektur/-familie anzugeben, wenn man nicht genau weiss was man tut.

Denn unter bestimmten Umständen ist das kein Problem:

Auf einem Athlon-XP laufen mit -march=pentium3 / pentium2 / pentium-mmx / K6-2 / K6-3 compilierte Programme einwandfrei, da dieser 100% kompatible zu den genannnnten Architekturen ist... Der P4 würde evtl. mit -march=K6-2 oder K6-3 abstürzen, da dieser Prozessor kein 3dnow! beherrscht. Also für jemanden, der sich mit Prozessorarchitekturen genau auskennt, ist es kein Problem, mit anderen -march Parametern runzuspielen, obwohl ich nicht wirklich viel davon halte, denn es wird in der Regel keinen Vorteil bringen. Aber wenn man ein CPU-Upgrade (auf einen Athlon/Athlon4/AthlonXP/Athlon64) macht, muss man evtl. nicht das ganze System neu kompilieren, nur weil man vorher ein -march=K6-2 angegeben hatte.

Und ich habe die Erfahrung gemacht, das das eine oder ander programm nicht richtig lief/ sich nicht compilieren liess mit -march=athlonxp, aber mit -march=pentium3. Und das lief dann trotzdem schneller als mit -cpu=athlonxp oder -cpu=pentium3 (was meist logisch ist, denn bei -cpu werden nur 386er Opcodes verwendet, dinge wie MMX/SSE/3dnow bleiben dannnn aussen vor und werden nicht genutzt.)

----------

## tacki

zum thema:

ich hab mal den fehler gemacht und falsche cflags verwendet... dummerweise bei den coreutils *arrrgs*... das zu reparieren war nicht ganz so einfach (zumal der Rechner kein CDRom für eine Rescue-CD hatte)  :Smile: 

----------

## dertobi123

 *sputnik1969 wrote:*   

> Sehe ich anders, denn CFLAGS Central ist in ENGLISCH...
> 
> Sonst müsstest du auch sagen, beinahe jede Diskussion hier im deutschen Teil des Forums gehört in einen anderen Teil des Forums...

 

Es gibt ja auch im deutschen Teil des Forum einen speziellen Thread zu Optimierungen und deren Sinn; hab ich ja bereits drauf hingewiesen ...

 *sputnik1969 wrote:*   

> wenn man nicht genau weiss was man tut

 

Hey, der Spruch ist [tm] dertobi123  :Wink: 

Tobias

----------

## deepthought

 *sputnik1969 wrote:*   

> Sehe ich anders, denn CFLAGS Central ist in ENGLISCH...
> 
> Sonst müsstest du auch sagen, beinahe jede Diskussion hier im deutschen Teil des Forums gehört in einen anderen Teil des Forums...
> 
> 

 

Der Gedanke war wohl eher, dass die Informationen dort reichhaltiger und die Erfahrungen der Teilnehmer (zumindest einiger) groß sind. Ich sagte auch nicht "hier ist der falsche Ort", sondern "dort ist der bessere Ort". Mach' Dir keine Sorgen um das deutschsprachige Forum; ich wollte es nicht verbieten lassen... :Rolling Eyes: 

 *sputnik1969 wrote:*   

>  *deepthought wrote:*   Insgesamt ist also DRINGEND davon ABZURATEN, eine andere als die *wirklich* vorhandene Prozessorarchitektur/-familie anzugeben. Ist meiner Ansicht nach auch nur bedingt richtig.

 

Die Aussage ist so korrekt -- nicht nur bedingt.

 *sputnik1969 wrote:*   

> Ich würde das eher wie folgt formulieren:
> 
> Insgesamt ist also DRINGEND davon ABZURATEN, eine andere als die *wirklich* vorhandene Prozessorarchitektur/-familie anzugeben, wenn man nicht genau weiss was man tut.
> 
> Denn unter bestimmten Umständen ist das kein Problem:
> ...

 

Das habe ich auch nicht behauptet; und -- wie Du ja selbst sagst -- ist das "Herumspielen" an den -march- bzw. -mcpu-Optionen wenig sinnvoll; entweder erzeugt man inkompatiblen Objektcode, oder man verschenkt mögliche (wertvolle) Optimierungen.

 *sputnik1969 wrote:*   

> Und ich habe die Erfahrung gemacht, das das eine oder ander programm nicht richtig lief/ sich nicht compilieren liess mit -march=athlonxp, aber mit -march=pentium3. Und das lief dann trotzdem schneller als mit -cpu=athlonxp oder -cpu=pentium3 (was meist logisch ist, denn bei -cpu werden nur 386er Opcodes verwendet, dinge wie MMX/SSE/3dnow bleiben dannnn aussen vor und werden nicht genutzt.)

 

Da ist aber meistens eher "-O<astronomischer Wert>", "-ffast-math" oder irgendeine andere wilde, exotische Optimierungsoption schuld dran. "Sichere" Optimierungen sind -march=<richtiger Prozessor>, -fomit-frame-pointer und -O2. Wer mag, kann noch -O3 testen, aber das führt manchmal zu defekten Paketen (bei mir zuletzt pam). Wer mutig ist, kann dann die diversen Vorschläge aus "CFLAGS Central" durchnudeln und schauen, was bei ihm funktioniert. Wenn -march=<richtiger Prozessor> Deine Pakete zersägt, solltest Du Dich dringend an die gcc-Jungs wenden.

Insgesamt hat furanku auch nicht so ganz Unrecht. Alle weitergehenden Optimierungen als -march, -O<irgendwas> und -fomit-frame-pointer verbessern die Performance nur marginal. Die Stärken von Gentoo liegen sicherlich anderswo...

Viele Grüße,

Alexander

----------

## sputnik1969

 *deepthought wrote:*   

> 
> 
> Da ist aber meistens eher "-O<astronomischer Wert>", "-ffast-math" oder irgendeine andere wilde, exotische Optimierungsoption schuld dran. "Sichere" Optimierungen sind -march=<richtiger Prozessor>, -fomit-frame-pointer und -O2. Wer mag, kann noch -O3 testen, aber das führt manchmal zu defekten Paketen (bei mir zuletzt pam).
> 
> ....
> ...

 

Also ich würde -ffast-math nicht unbedingt als "exotische" Optimierung bezeichnen. Mag sein, das das eine oder andere Programm das nicht mag, aber es gibt ja auch Programme, die mögen nichtmal ein -march=athlonxp.

Solange man jedoch keine Software benutzt, bei der es auf auf 100% garantierte Mathematische Präzision und Sicherheit ankommt, sollte man -ffast-math einfach mal ausprobieren. Vor allem Prrogramme ohne (handgeschriebene Assemblerroutinen für) 3dnow! oder SSE Unterstützung, die jedoch Fliesskommazahlen stärker nutzen, werden teilweise immens beschleunigt.

Auch Optimierungen wie -mfpmath=sse können (zum Beispiel beim neuen C3 mit Nehemia-Kern) eine deutliche Beschleunigung bewirken, da der C3 eine lausige FPU hat, da macht es möglicherweise was aus, lieber die SSE-Einheit zu "mißbrauchen".

 *deepthought wrote:*   

>  Wenn -march=<richtiger Prozessor> Deine Pakete zersägt, solltest Du Dich dringend an die gcc-Jungs wenden.

 

Naja, wäre aber nicht das erste mal, das sowas passiert (ich sage nur Athlon4 und Pentium4)

----------

## yhirmikq

 *thundersteele wrote:*   

> Hab den test auf nem Pentium4 gemacht. Das script hat meiner Meinung nach überdurchschnittlich häufig mit -march=k6 verschiedene Optionen durchprobiert und vielleicht deshalb diese einstellung vorgeschlagen. Anscheinend ist die einstellung nichtmal diejenige die die meisten Punkte im Benchmark erreichte sondern die zuletzt probierte. 

 

Also ich glaube der testet erst die schnellste, oder "beste" prozessorarchitektur und dann probiert er damit verschiedene Flags aus. Ich glaube ich bleibe bei meinem "alten" -O2 -fomitframepointer. Soviel Unterschied wird es nicht machen und ich muss mich nicht ärgern, weil etwas nicht klappt.

----------

## c07

 *sputnik1969 wrote:*   

> Also ich würde -ffast-math nicht unbedingt als "exotische" Optimierung bezeichnen. Mag sein, das das eine oder andere Programm das nicht mag, aber es gibt ja auch Programme, die mögen nichtmal ein -march=athlonxp.
> 
> Solange man jedoch keine Software benutzt, bei der es auf auf 100% garantierte Mathematische Präzision und Sicherheit ankommt, sollte man -ffast-math einfach mal ausprobieren.

 

-ffast-math ist auf jeden Fall eine höchst riskante Option. Typische Fehler, die es produziert, sind entgegen landläufiger Meinung nicht verringerte Präzision, sondern eher völlig falsche Resultate sowie Abstürze. Es schaltet einfach Features der Programmiersprache ab, in der vagen Hoffnung, dass sie das compilierte Programm nicht benutzen wird (z.B. errno, Rechnen mit Unendlich).

Tatsache ist, dass es manche Programme ziemlich stark beschleunigen kann. Aber ob das gefahrlos möglich ist, können eigentlich nur die Autoren des Programms entscheiden. Deshalb ist -ffast-math in Makefiles durchaus angebracht, nicht aber als Strandardeinstellung in den CFLAGS. Wer es trotzdem drin hat, sollte sich über nichts wundern und insbesondere nicht nach Support suchen.

----------

## sputnik1969

 *c07 wrote:*   

> 
> 
> -ffast-math ist auf jeden Fall eine höchst riskante Option. Typische Fehler, die es produziert, sind entgegen landläufiger Meinung nicht verringerte Präzision, sondern eher völlig falsche Resultate sowie Abstürze. Es schaltet einfach Features der Programmiersprache ab, in der vagen Hoffnung, dass sie das compilierte Programm nicht benutzen wird (z.B. errno, Rechnen mit Unendlich).

 

Mir (jedenfalls) war klar, das diese Beschleunigung nicht durch eine verringerte Präzision zustande kommt, sondern du fehlende Sicherheitsüberprüfungen. Aber gut, das du es erwähnst, ich denke der eine oder andere, der hier mitliest wusste das nicht, und da ich ja weiss, was -ffast-math macht, bin ich nicht auf die Idee gekommen es genauer zu erklären, man nimmt halt einiges als selbstverständlich hin  :Wink: 

 *c07 wrote:*   

> Tatsache ist, dass es manche Programme ziemlich stark beschleunigen kann. Aber ob das gefahrlos möglich ist, können eigentlich nur die Autoren des Programms entscheiden.

 Nur ist es leider so, das sich viele Autoren nicht diesen Gedanken machen, geschweige denn es ausprobieren bzw. die Möglichkeit im Readme erwähnen, ob es laufen könnte oder nicht.

 *c07 wrote:*   

> Deshalb ist -ffast-math in Makefiles durchaus angebracht, nicht aber als Strandardeinstellung in den CFLAGS. Wer es trotzdem drin hat, sollte sich über nichts wundern und insbesondere nicht nach Support suchen.

 Naja, ich habe es drin, aber wenn ich instabilitäten oder unerwartete Ergebnisse  bei Programmen bemerke ermerge ich sie erneut mit weniger Optimierungen. Das hat sich bisher bei mir bewährt, aber ich weiss, das nicht jeder sich die Mühe macht, seine Kompilate zu testen und ggf. einzelne Programme mit einer geringeren Optimierung als das Restsystem zu erstellen.

Da aber in den Ebuilds bereits in vielen Fällen bestimmte CFLAGS abgestellt werden, sobald bekant wird, das sie instabilitäten erzeugen, ist die Zahl der Programme die daran "verrecken" in den letzten Monaten glücklicherweise geringer geworden  :Smile: 

----------

## kollega

 *yhirmikq wrote:*   

> Hi,
> 
> eine Frage zum ccbench. Ich hab hier einen Pentuim 4 und ccbench behauptet steif und fest am besten sollte ich mit --march=athlon-xp kompilieren 
> 
> Kann man das machen oder gibt es das Probleme? 
> ...

 

ich hatte das problem am anfang auch, habe aber dann jegliche architektur aus dem skript entfernt und das sieht bei meinem PIII-mobile nun etwa so aus:

```

do

        options_counter=0

        did_new_tests=0

        try "" -O2 -O3

        try "" -march={pentium{3,4}}

        try "" -fforce-addr

        try "" -mmmx

        try "" -pipe

        try "" -fomit-frame-pointer

        try "" -finline-functions

        try "" -fcse-follow-jumps -fcse-skip-blocks

        try "" -funroll-loops

        try "" -frerun-cse-after-loop

        try "" -frerun-loop-opt

        try "" -fgcse

        try "" -fexpensive-optimizations

        try "" -fdelayed-branch

        try "" -funroll-all-loops

        try "" -maccumulate-outgoing-args

        try "" -fschedule-insns -fschedule-insns2

        try "" -{m,f}align-functions={2,4}

        try "" -preferred-stack-boundary={2,4}

done

```

habe alles was nicht pentium ist rausgeworfen und einfach ein paar Flags mehr hineingeschrieben. dadurch fängt er garnicht erst an irgendwelche unmöglichen konstellationen auszuprobieren, denn ich glaube, dass das prog noch nicht wirklich ausgereift ist  :Smile: 

in diesem sinne, ich hoffe es bringt euch etwas weiter

greetz tobi

----------

## ian!

Also ich wäre da etwas vorsichtig. Wenn sich ccbench schon so mit den Architekturen verhaut, dann möchte ich nicht wissen, was da sonst noch bei den CFLAGS falsch läuft.

Bei der Architektur ist es ja noch offensichtlich, dass das falsch ist, aber bei den CFLAGS sieht man mögliche Fehler ja nicht direkt.

Nur so ein Gedanke...

Gruß,

ian!

----------

## deepthought

Da würde ich zustimmen, ian!.

Die Sache ist eben: Compileroptimierungen sind immer kritisch... Man kann keine allgemeingültige Aussage machen a'la "wenn Du dies, das und jenes in die CFLAGS schreibst, wird alles gut, wir bekommen Weltfrieden und George W. Bush..." (nein, lassen wir das). Ich habe lange herumprobiert, bis ich *für mein System* stabile, aber dennoch hochoptimierende Einstellungen gefunden hatte. Auch die "Erkennungsprogramme" sind keine große Hilfe; letztendlich "raten" die auch nur und hoffen, daß es richtig war...

IMHO hilft (bis auf ganz konservative Optimierugen wie -O, die eigentlich nie Probleme verursachen...) nur Ausprobieren, denn nur weil bestimmte Optimierungen bei mir keine Probleme verursachen, heißt das leider nicht, daß das für andere Leute auch zutrifft...

Viele Grüße,

Alexander

----------

## rincewind

HI !

Ich hab jetzt erst den thread gelesen und du sagst weiter oben du wollest hid fest in den kernel packen wegen tastatur und maus.

Ich habe bei mir aber festgestellt (mag sein das das phänomen auch nur bei mir auftaucht) das sich meine maus beim umstecken am usb hub (manchmal auch beim zuschalten des usb-druckers) im xfree aufhängt.

Als ich die hid unterstützung fest im kernel hatte, half nix anderes als ein neustart wenn ichs als modul kompiliere kann ich das modul entspannt entfernen und neu laden.

Das funzt super, weil meine Tastatur ps2 ist und sich nicht mit wegschiesst, aber in deinem fall wenn dieses Problem auftritt bliebe dir immer noch der modulneustart per ssh o.ä..

Zu der cflags Diskussion mochte ich auch was sagen: der marginale vorteil von -o3 -fomit-gib-alles wiegt meiner erfahrung nach nicht annähernd die kompilerzeiten wieder auf die dadurch zusätzlich erzeugt werden. 

Gruss Rince.

----------

## c07

 *rincewind wrote:*   

> der marginale vorteil von -o3 -fomit-gib-alles wiegt meiner erfahrung nach nicht annähernd die kompilerzeiten wieder auf die dadurch zusätzlich erzeugt werden.

 

Ja, wenn man (wie bei Gentoo üblich) oft neu kompiliert, ist das auch ein Argument. Aber die aufwendigen Optionen sind eigentlich alle schon in -O2 drin. Dann müsste man also -O1 nehmen bzw. explizit -fno-expensive-optimizations u.Ä. setzen.

----------

