# SU und Optimierungen

## Beforegod

So da diese Fragen ziemlich häufig auftauchen und bestimmt auch noch einige Male auftauchen werden.

Sollte einem der Zugriff zu su verwährt werden :

```

Permission denied

```

Bitte überprüfen ob der Benutzer in der Gruppe 'wheel' ist.

Wenn nicht bitte in der Faq nachsehen wie das geht!

https://forums.gentoo.org/faq.php#0

Zum zweiten :

Da im Moment die große Update Welle auf GCC 3.x anläuft sollte man folgenden Aspekt beachten :

 *Quote:*   

> 
> 
> - Aggressive Optimierungen (-march=athlon -O3) sollten vermieden werden. Wird das -march Flag gesetzt sollte ab gcc-3.1 nur noch die Option -O2 verwendet werden. -O3 funktioniert zwar bei dem größten Teil der Programme, allerdings gibt es bei Systemnahen oder größeren Programmen Probleme.
> 
> 

 

----------

## Egnat

 *Beforegod wrote:*   

> 
> 
> Da im Moment die große Update Welle auf GCC 3.x anläuft sollte man folgenden Aspekt beachten :
> 
>  *Quote:*   
> ...

 

Hmm, aus meiner /etc/make.conf:

```

CFLAGS="-pipe -O3 -fomit-frame-pointer -fstrength-reduce -frerun-cse-after-loop -frerun-loop-opt -fexpensive-optimizations -fschedule-insns2 -march=athlon-xp -mcpu=athlon-xp -mfpmath=sse -mmmx -msse -m3dnow -momit-leaf-frame-pointer"

```

Mein System läuft sehr stabil mit diesen Flags.

----------

## Dimitri

Moi aussi,

hab folgende wohl auch etwas agressive Flags:

-w -march=athlon-xp -O3 -pipe -m3dnow -mmmx -msse -fomit-frame-pointer -mfpmath=sse -funroll-loops -falign-functions=4 -frerun-cse-after-loop -frerun-loop-opt -ffast-math -fforce-addr

Mein System (KDE 3.1b2, glibc2.3.1, XF4.2.1 und Kernel 2.4.19) läuft absolut stabil und schnell. (Kernel ist gepacht mit XFS und Superpage und auch mit diesen Flags übersetzt)

Dim

----------

## Beforegod

Ich habe ja nicht geschrieben das es bei allen zu Probleme kommt.

Bei mir z.B. funktionierte der pppd erst nachdem ich ihm mit -O2 kompiliert habe. Desweiteren streikte bei mir manchmal auch Portage und einige Mathematische Anwendungen (sogar die fileutils!)..

Allerdings denke ich das es am gcc 3.1 liegt!

----------

## chh

Hallo,

eine Sache würde mich da mal interessieren.

Im Moment sind meine CFLAGS: march=athlon-xp -O3 -pipe

Hat irgendjemand Erfahrungen wie sich die Geschwindigkeit der Programme aber auch die Zeit des Kompilierens verändert wenn ich das auf -O2 ändere??

Gruß

Christian

----------

## Dimitri

Je mehr Optimierungen Du drinnen hast desto länger dauert es natürlich. Wie lange genau hab ich noch nie gemessen. Aber bei grossen Paketen (kdelibs, kdebase etc...) schon spürbar. 

Mit dem wechsel von -O3 auf O2 kommt es sicherlich darauf an welche Programme  du damit kompilierts. Kate wird darum wohl auch nicht schneller starten, aber beim kernel, der glibc usw. wird es sicher etwas schneller. (Wobei ich mit dem Kernel und -O3 manchmal Probleme hatte. Alle anderen Flags von mir funktionieren)

Dim

----------

## mikegr

Ich rate ebenfalls von der Verwendung von -O3 ab. Bei mir klappt dadurch mit su nicht und auch die KDE-Anwendungen mit Rootrechten wollen als normaler User nicht.

Mike

----------

## mikegr

Ich rate ebenfalls von der Verwendung von -O3 ab. Bei mir klappt dadurch mit su nicht und auch die KDE-Anwendungen mit Rootrechten wollen als normaler User nicht.

Mike

----------

## kl@us

 *chh wrote:*   

> Hallo,
> 
> eine Sache würde mich da mal interessieren.
> 
> Im Moment sind meine CFLAGS: march=athlon-xp -O3 -pipe
> ...

 

Hi chh, 

weil´s gerade so gut zu meiner Situation passt -durfte Gentoo aufgrund eines Hirnblackouts noch einmal von Stage1 installieren- hier ein kleiner Erfahrungsbericht:

Ich hatte mein altes Gentoo (1.4rc1) mit "march=athlon-xp -O3 -pipe -hau rein -gib alles -lauf du Sau -hier kommen noch 10 Zeilen" compiliert. 

Alles, aber wirklich alles, lief ohne Fehlermeldund durch; nur die Geschwindigkeit, die ich alleine aufgrund meiner Hardware erwartet habe, war nicht signifikant anders als die einer SuSE o. RedHat Distri.   :Sad: 

Habe einen XP 2400+ mit 768MB Ram + eine GForce 4600.

Gestern habe ich das Basissystem mit "march=athlon-xp -O3 -pipe -fomit-frame-pointer" compiliert. Dann aber xfree, kde, gnome & mozilla mit "O2". Was sol ich sagen, außer daß es in einer Höllengeschwindigkeit getan war -kde komplett in 328min., xfree in 74 min., etc.- hat es den überaus angenehmen Vorteil das kde und gnome jetzt _wirklich_ schnell sind. Gnome startet schneller als unser Kanzler Steuern eintreibt; dachte ich vorher immer ich müßte kde anschubsen, so staune ich jetzt nur noch  :Cool:  .  Ich kam vor Lachen kaum zum schlafen...

Mozilla, dieses Monster, macht Spass! Und das schon beim starten.

Auch ich dachte bis gestern, wenn nicht wenigstens 10 Zeilen Cflags folgen, kann´s ja nix sein. 

Ok, ein wirklicher Vergleich kann ja nur erfolgen, wenn man das System mindestens ein 2tes Mal mit anderen Flags compiliert hat. Also, solltet ihr euer System ´mal zerschiessen, habt den Mut "nur O2" zu nehmen. Aus vielen NG und Foren ist zu entnehmen, daß "fomit-frame-pointer" wesentlichen Speed gibt, von daher habe ich es dringelassen. Hier, und im Mandrake-Forum gibt es einen interessanten Thread zum Thema Mandrake 9.0 -KDE & Gnome schneller als Gentoo, etc.- Auch die bauen ihre Binaries mit "O2"!  :Idea:  Also, muß nicht für jeden passen, aber es ist einen Versuch wert. 

...und man schreibt sich nicht die Finger in der "/etc/make.config" blutig!

Gruß

Klaus

----------

## Beforegod

Das wichtigste ist ab gcc 3.x die -march Optimierungen..

Meine Optimierungen belaufen sich auf :

-march=athlon-xp -m3dnow -mmmx -O2

und alles läuft superschnell  :Wink: 

Mein GNOME 2 läuft schneller als auf vergleichbaren Systemen mit SuSE und RedHat  :Wink: 

----------

## maystorm

Na ja, solange es keine verlässlichen Benchmarks gibt, die die verschiedenen Optimierungsoptionen miteinander vergleichen, bleiben die ganzen Diskussionen über den "superlangsamen Mozilla" bis hin zum "sauschnellen Starten von KDE/Gnome" doch nur reine Spekulation.

Zu viele Faktoren spielen hierbei einfach eine Rolle: CPU-Hersteller und -Takt, Mainboard und Chipsatz, Festplatte(n) und ihre Einstellung(en) (hier besonders DMA-Zugriff, PIO-Modus, 32-bit-Zugriff und dgl.), Art und Größe des verfügbaren RAM-Speichers, usw. usw.

Compiler-Optionen, die auf einem bestimmten Rechner A eine höhere Performance ergeben, müssen dies nicht auch zwangsläufig auf einem  anderen Rechner B tun.

YMMV.

----------

## Lasker

 *kl@us wrote:*   

> 
> 
> Gestern habe ich das Basissystem mit "march=athlon-xp -O3 -pipe -fomit-frame-pointer" compiliert. Dann aber xfree, kde, gnome & mozilla mit "O2". Was sol ich sagen, außer daß es in einer Höllengeschwindigkeit getan war -kde komplett in 328min., xfree in 74 min., etc.- hat es den überaus angenehmen Vorteil das kde und gnome jetzt _wirklich_ schnell sind.

 

Es gibt einen gigantischen thread über das Thema in CFLAGS Central:

https://forums.gentoo.org/viewtopic.php?t=5717&highlight=cflags

Darin fand ich einen interessanten Beitrag zum Unterschied zwischen O2 und O3.

Der Author vertritt darin die Ansicht, dass bei moderner Hardware der Engpass die Festplatte wäre:

Mit anderen Worten, während Geschwindigkeitsvorteile bei den laufenden Programmen zwischen mit O2 und O3 compilierten

Programmen kaum noch spürbar wären, würde die O3 Compilierung längeren Code erzeugen und die daraus resultierende

längere Ladezeit durchaus spürbar sein.

Vermutlich ist also der Rat, besser mit O2 zu optimieren, nicht von der Hand zu weisen.

Nichts desto trotz sehen meine CFLAGS so aus (gentoo 1.4, gcc 3.2):

CFLAGS="-march=athlon-tbird -O3 -pipe -fomit-frame-pointer -funroll-loops -fexpensive-optimizations -mmmx -m3dnow"

EDIT:

...und  inzwischen (seit einiger Zeit schon) sehen sie so aus:

CFLAGS="-march=athlon-tbird -O2 -pipe"

Ohne einen spürbaren Unterschied übrigens...

/EDIT

Ich behaupte nicht, dass das der Weisheit letzter Schluss wäre; auf jeden Fall geht meine Kiste jetzt ab wie Zäpfchen und läuft absolut stabil.Last edited by Lasker on Thu Jan 02, 2003 8:52 pm; edited 1 time in total

----------

## Headhunter123

Hier sind auch einige Optimierungen aufgelistet

----------

## olafk

 *Quote:*   

> Ich hatte mein altes Gentoo (1.4rc1) mit "march=athlon-xp -O3 -pipe -hau rein -gib alles -lauf du Sau -hier kommen noch 10 Zeilen" compiliert. 
> 
> [...]
> 
> 

 

heh ...

 *Quote:*   

> Gestern habe ich das Basissystem mit "march=athlon-xp -O3 -pipe -fomit-frame-pointer" compiliert. Dann aber xfree, kde, gnome & mozilla mit "O2". Was sol ich sagen, außer daß es in einer Höllengeschwindigkeit getan war -kde komplett in 328min., xfree in 74 min., etc.- hat es den überaus angenehmen Vorteil das kde und gnome jetzt _wirklich_ schnell sind. Gnome startet schneller als unser Kanzler Steuern eintreibt; dachte ich vorher immer ich müßte kde anschubsen, so staune ich jetzt nur noch 8-) .

 

ich habe jetzt ein paar postings hier gelesen (zum thema compiler flags). um die sache ggf endlich mal aufzuklaeren: also es ist doch eigentlich ganz einfach. wenn man von etwas UE-BER-HAUPT keine ahnung hat, dann liesst man doch erst einmal die bedienungsanleitung, oder meinet wegen das manual. in diesem waere es die bedienungsanleitung des kompilers den man da verwendet.

```

man gcc

```

dann wird man folgende erkenntnis erlangen:

[...]

-O2 turns on all optional optimizations except for loop unrolling, function inlining, and register renaming.  It also turns on the

-fforce-mem option on all machines and frame pointer elimination on machines where doing so does not interfere with debugging.

[...]

-O2 implementiert also alle optimierungen, bis auf die oben genannten (omit frame pointer eingeschlossen, da stehts auch). -fomit-frame-pointer im zusammenhang mit -O2 oder -O3 ist nicht ratsam. man kann aber durch zusaetzliches anbegen dieses parameters praktisch einen override vornehmen und nochmal etwas an performance dazu geiwnnen. wenn es allerdings sicher ist -fomit-frame-pointer  ohne verlust der debug funktionalitaet zu benutzen, dann passiert das bei -O2 automatisch.

-fomit-frame-pointer

Don't keep the frame pointer in a register for functions that don't need one.  This avoids the instructions to save, set up and restore

frame pointers; it also makes an extra register available in many functions.  It also makes debugging impossible on some machines.

[...]

-O2 schon implimentiert -fomit-frame-pointer, aber nur gg. dem f. das es ein dubuggen des codes nicht unmoeglich macht. solche sachen sind stark arch abhaengig und man sollte sich zunaehst ein wenig mit x86 Assembler und pointern, heap und stack auseinander setzen um zu verstehen was dort auf maschinen ebene eigentlich passiert. dieses blinde optimieren und flags raten finde ich ehrlich gesagt zeihmlich unsinnig. lesen wir weiter ...

[...]

-O3 turns on all optimizations specified by -O2 and also turns on the -finline-functions and -frename-registers

options.

[...]

-O2 + die bei -O2 ausgeschlossenen optionen -frename-registers und -finline-functions werden also von -O3 implementiert.

-frename-registers

Attempt to avoid false dependencies in scheduled code by making use of registers left over after register allocation.  This optimization

will most benefit processors with lots of registers.  It can, however, make debugging impossible, since variables will no longer stay in a

``home register''.

-finline-functions

Integrate all simple functions into their callers.  The compiler heuristically decides which functions are simple enough to be worth inte-

grating in this way.

[...]

wie einer meiner vorredner bereits sehr richtig bemerkte, ist der unterschied zwischen -O2 und -O3 kaum spuerbar, groesserer code laed nur laenger.  die performance misst man dann auch eher zur laufzeit, also wenn sich das programm bereits im speicher befindet. ggf bemerkt man einen performance gewinn von ein paar usec beim starten wenn man das ganze von, sagen wir einer ramdisk, aus startet.

desweiteren habe ich beim aktuellen stage3-athlon.tbird-hastenichtgesehen tarball, sowie in vielen postings hier, einige unstimmigkeiten bemerkt. ein deklarieren von -march UND -mcpu zusammen finde ich ziehmlich unsinnig, da -march -mcpu implementiert, jedoch noch weiter geht und die combability zu anderen cpus bricht. wie genau sich gcc verhaelt wenn man beides nacheinander deklariert, ich weiss es nicht. wahrscheinlich applied er nur den letzten der sich wiedersprechenden parameter, in diesem fall -mcpu. ich hab mir den kram dann lieber von stage1 an nochmal selber gebaut.

nur was sagt uns das? immer erstmal lesen. man gcc ist dein freund. in diesem sinne,

messer, schere, licht, sind fuer kleine kinder nicht ...

oder etwas serioeser ausgedrueckt: ich empfehle dringend die weiterfuehrende dokumentation zum compiler und den einzelnen optimierungsmoeglichkeiten zu studieren, bevor der zu kompilierende code willkuerlich veroptimiert wird. ich denke minimale voraussetzungen fuer solche optimierungen sind grundkenntnisse der x86 arch, sowie x86 assembler und in C.

s/x86/$your_arch/g;

 *Quote:*   

> 
> 
> Ich kam vor Lachen kaum zum schlafen...
> 
> 

 

selbsterkenntnis ist der erste weg zur besserung

----------

## Dimitri

Ich bereue alles. *g*

Nach einigen "Modifikationen" (hehe) war ich mal wieder soweit mich zu entscheiden ein kaputtes System zu reparieren oder komplett neu zu installieren. Und ich hab mich (wie üblich eigentlich) für eine Neuinstallation entschieden. Und das ganze nur mit -O2 -pipe -fomit-frame-pointer. Und ich muss sagen die ganzen Optimierungen (siehe oben) waren eigentlich für die Katz. Was meinen Erfahrungen nach wirklich was gebracht hat, ist der Upgade auf glib 2.3.1, gcc 2.3.x und der Superpage Patch für Athlon. Alles andere ist nur Augenwischerei. Na ja fast alles: Man kann schon mal versuchen den Kernel mit härteren Optionen zu kompilieren. Bringt beim starten ca. 2 Sekunden. Ansonsten überhaupt nichts. Und ich hab wirklich viel ausprobiert.

Dim

----------

## ajordan

Was beinhaltet der Superpage Patch fuer den Athlon und was wird da gepatcht (kernel, libs..)?

Alex

----------

## KiLLaCaT

genau das hab ich mich auch gefragt. schau mal hier nach!

mfg, jakob

----------

## amiga

bei mir läufts mit -march=athlon-xp und -O3 auch ganz gut. Aber mal eine Frage: in der make.defaults steht schon -O2. Wird das ignoriert wenn man in der make.conf -O3 angibt ?

----------

## Dimitri

Kurz gesagt: Ja

Änderungen sollten auch nur in der make.conf gemacht werden. 

Dim

----------

## Tox

Ich habe einen Duron 1300 (Morgan-Core).

Welche Optimierung ist empfehlenswert? "Duron" oder "Athlon-XP"?

Eigentlich hat der Prozzi ja einen Athlon-XP-Core, andererseits weniger Cache und ist deshalb eben auch ein Duron...

Hat jemand mal 'nen Benchmark laufen lassen?

----------

## Dimitri

Hi,

wichtig ist der Befehlssatz nicht der Cache. Ich würd also athlon-xp nehmen.

Dim

----------

## Tox

So sehe ich das eigentlich auch. Nur stellt sich dann die Frage, wieso überhaupt eine Option "Duron" existiert... weil der Duron ja bekanntermaßen keinen eigenen Befehlssatz hat...   :Sad: 

----------

## Dimitri

Ich kenn mich da nicht so aus, kann mir aber Vorstellen, das der Duron in etwa sowas ist wie damals ein 368 DX und 386 SX als mal mit und mal ohne Coprozessor. (Klar hat der Duron eine FPU nur vom Prinzip her)

Wär interessant zu wissen, ob mit athlon-xp compilierte Programme auf einem Duron laufen...

Dim

----------

## Tox

naja, soweit ich weiß ist der einizige Unterschied die Cache-Größe.

LAUFEN tun für Athlon-XP optimierte Programme, die Frage ist halt nur, ob sie auch OPTIMAL laufen...

----------

## Donnergurgler

Ich würde den CFLAGS noch "-s" hinzufügen.

man gcc:

-s  Remove all symbol table and relocation information from the exe-

    cutable

Meine Flags:

CFLAGS="-s -march=k6-3 -O2 -pipe -m3dnow -mmmx"

CXXFLAGS="${CFLAGS}"

Just my 2 zsents.

----------

## nevermind

dieser thread ist auch noch recht interessant zu diesem thema:

http://freshmeat.net/articles/view/730/

----------

## knorke

also -march impliziert schonmal -mcpu, was letzteres wohl überflüssig macht

und da march dem compiler ja nur sagt, welche instruktionen verwendet werden dürfen/können wenn der code in asm umgesetzt wird, dürften -msse -m3dnow usw. wohl auch überflüssig sein wenn man zB -march=athlon-xp angibt AFAIK.

so bekommt man ne recht schlanke zeile mit CFLAGS

aus meiner make.conf:

CFLAGS="-march=athlon-xp -O3 -pipe -fforce-addr -fomit-frame-pointer -funroll-loops -falign-functions=4 -maccumulate-outgoing-args"

probleme mit -O3 konnte ich nicht feststellen, ich benutze gcc (GCC) 3.2.2 20030322 (Gentoo Linux 1.4 3.2.2-r2)

----------

## porter

Ich hab mal irgendwo gelesen, dass -O2 nur zwei optionen weniger als -O3 besitzt und deshalb fast genauso "aggressiv" ist. Bis jetzt hatte ich einmal den Fall, dass erst ein Wechsel von -O2 auf -O den Fehler in src_compile behoben hat.

----------

## MasterOfMagic

hm also ich hatte bisher mit meinen settings

```
CFLAGS="-march=pentium4 -O2 -pipe" 

```

keine schwierigkeiten. ausser bei der glibc hatte ich ein wenig gebastelt. da hab ich die sse erweiterungen  von -march=pentium4 rausgenommen.

mfg

masterofmagic

----------

## pZYchO

Interessanter Thread... Wäre vielleicht nicht schlecht wenn das man jmd verschieben könnte, schließlich geht es hier eigentlich um su... Naja, egal... =)

Sollte man nicht wollen, dass man zum su in der Gruppe wheel sein muss gibt es nocht die möglichkeit, unter /etc/pam.d/su-auth (wenn ich mich recht entsinne, habe im mom keinen zugriff auf das system) den pam_wheel.o eintrag entfernen (bzw. auskommentieren)........

MfG pZYchO

----------

## maikmerten

 *Tox wrote:*   

> So sehe ich das eigentlich auch. Nur stellt sich dann die Frage, wieso überhaupt eine Option "Duron" existiert... weil der Duron ja bekanntermaßen keinen eigenen Befehlssatz hat...  

 

So, ich denke folgendes (ohne Gewährleistung, usual disclaimers apply):

Die "Duron"-Option dürfte sich auf den "alten" Duron mit Spitfire-Kern beziehen, also auf den kleinen Bruder vom Thunderbird-Kern. Auch wenn diese beiden Kerne den gleichen Befehlssatz aufweisen, so macht es doch Sinn, eine eigene Duron-Option einzubauen - es wird wohl vorteilhaft sein, den Code für den Duron möglichst kompakt zu halten (aus offensichtlichen Gründen).

Alles unter der Voraussetzung, dass march=duron wirklich was anderes anstellt als march=athlon... Ersteres könnte natürlich ein simpler alias für Letzteres sein. (es dürfte einige Leute geben, die ein seltsames Gefühl haben, auf ihrem Duron march=athlon zu verwenden - in diesem Falle ist march=duron eine hinreichend gute Placebo-Option, die automatisch das Richtige(tm) anstellt)

Aber da ich nicht weiss, inwiefern sich march=duron von march=athlon unterscheidet, höre ich auf, hierüber zu spekulieren...   :Embarassed: 

Vor dem Hintergrund des Fehlens einer Option wie march=duron2 und mit dem Wissen über die vom Palomino geerbten Verbesserungen erscheint es mir durchaus ratsam, bei einem Duron mit Morgan-Kern march=athlon-xp zu verwenden.   :Very Happy: 

Maik

----------

## Ulukay

CFLAGS="-march=athlon-xp -O3 -pipe -m3dnow -mmmx -msse -mfpmath=sse,387 -finline-functions -fmerge-all-constants -fthread-jumps -fomit-frame-pointer -fexpensive-optimizations -ffast-math -fforce-addr -falign-functions=64 -falign-jumps=4 -falign-loops=4 -frerun-cse-after-loop -frerun-loop-opt -fprefetch-loop-arrays -maccumulate-outgoing-args"

funzt aber alles einwandfrei    :Very Happy: 

----------

## MaJor_PerMutation

 *Donnergurgler wrote:*   

> Ich würde den CFLAGS noch "-s" hinzufügen.
> 
> man gcc:
> 
> -s  Remove all symbol table and relocation information from the exe-
> ...

 

Altes posting, aber das "-s" hat mich interessiert, unter google habe ich diesen Thread dazu gefunden:

http://linuxfromscratch.org/pipermail/lfs-support/2003-January/013650.html

Da nicht genau klar zu sein scheint, was "gcc -s" bewirkt, würde ich es nicht unbedingt ausprobieren bzw. nur dann, wenn USE="static" gesetzt ist.

Aber ich lasse mich gerne eines Besseren belehren.  :Very Happy: 

Gruß, 

Marcel

----------

## dertobi123

Hallo,

gcc -s hat nichts mit static zu tun, die Option wird bei LFS nur beim bauen der statischen Umgebung genutzt, richtige gcc Option zum statischen bauen ist gcc -static

Aus der LFS Doku:

 *Quote:*   

> gcc -s we set in order to prevent debugging symbols from being compiled into our static packages. By omitting these symbols during the linking stage of compilation, we save hard drive space and decrease our build time.

 

aus der Man-Page:

 *Quote:*   

> -s  Remove all symbol table and relocation information from the executable.

 

Auswirkung von gcc -s also:

Weniger Plattenplatz benötigt

Kürzere Build-Zeit

Gruß Tobias

----------

## ian!

Ob es so ratsam ist, Pakete mit "-s" zu bauen stelle ich hier mal in Frage. Beispiel: KDECrashManager. Diesr lädt sich nach einem Programmabsturz diese Symbols und gibt sie aus. Gerade bei Bugreports eine essentielle Sache.

Es ist natürlich jedem selbst überlassen, aber ich wollte auch mal auf die "Sideeffects" aufmerksam machen. Debugging / Bugreporting wird dadurch erschwert / unmöglich.

Gruß,

ian!

----------

## dertobi123

Ich hatte das eher unter dem Gesichtspunkt gcc -s ungleich gcc -static betrachtet, dass gcc -s natürlich auch das Debugging erschwert/unmöglich macht geht ja aus der Doku hervor. Ich hab im übrigen auch kein Statement pro gcc -s abgegeben, wenn das so rübergekommen ist: sorry   :Confused: 

Ausserdem setze ich vorraus, das wer solch spezielle Optionen nutzt (die in Gentoo weder dokumentiert noch default sind), auch die entsprechenden Docs und Mans gelesen hat. Ich weiss, ich erwarte viel  :Wink: 

Gruß Tobias

----------

## ian!

 *dertobi123 wrote:*   

> Ich hab im übrigen auch kein Statement pro gcc -s abgegeben, wenn das so rübergekommen ist: sorry  
> 
> 

 

Nein, nein. So war das nicht gemeint. Wollte wie gesagt nur mal die Nebeneffekte aufzeigen.

Nicht das hinterher einer kommt und sagt "Mensch klasse! Jetzt aber in die vollen mit "-O9 --mach --den --sourcecode --schnell --bisZumAnschlag" CFLAGS, dann noch ein "-s" reinhaut und sich dann wundert, daß er keine debugging-symbols mehr bekommt.  :Wink: 

Solche Leute soll's ja geben.  :Wink: 

Gruß,

ian!

----------

## MaJor_PerMutation

OK, habe ich mich zu unklar ausgedrückt, also nächster Versuch  :Wink: 

Mir ist klar, dass "gcc -s" != "gcc -static", ich habe ja auf den Thread verwiesen und kann die Diskussion darin jetzt nachvollziehen.

Also, jemand möchte die Überoptimierung übehaupt und setzt neben "-O333 -hyperfastpipe -fomit-everything-that-needs-time"  :Wink:  nun auch noch "-s".

Laut der LFS-Doku werden Debugging-Symbole entfernt.

Laur 'man gcc' werden aber !alle! "symbol tables" und "relocation" informationen entfernt.

Für mich ist das ein Widerspruch, weil alle != debugging symbols.

Weiterhin kann man unter 'man gcc' nachlesen, dass "-s" eine Linker-Option ist und nicht zum Einsatz kommt, wenn nicht gelinkt wird (ach was?  :Wink: )

Also gucken wir doch mal 'man ld':

```

-s

--strip-all

Omit all symbol information from the output file.

-S

--strip-debug

Omit debugger symbol information (but not all symbols) from the output file.

```

Also:

"gcc -s" = "ld -s" = '!alles! wird ge-strip-t' != "-S nur debug wird ge-strip-t"

Die Informationen in gcc.man und ld.man stimmen überein.

Die LFS-Doku widerspricht diesen Informationen, weil sie anscheinend versucht "-s" mit "-S" zu erklären!

Und genau darüber handelt auch der Thread, über diese (falsche) Erklärung, die zu Verwirrung führt.

Zurück zu Gentoo:

Wenn aber "-s" an den Linker 'durchgereicht' wird, werden nicht nur Debugging Informationen entfernt, sondern 'alle' symbol tables etc.

Wenn aber wirklich !alles! gestript wird, ist das für einen dynamische build der Tod, weil dann auch die Info gestript wird, womit dynamisch gelinkt werden soll.

Daher kam ich zu der Überlegung:

Wenn alles gestript wird, kann man dynamisches linking vergessen, also würde ich das nur versuchen, wenn ich auch USE="static" gesetzt hätte und wirklich alles ohne Folgeschäden für die Lauffähigkeit gestript werden könnte.

Und wer es noch ein wenig paradoxer mag  :Wink:  :

User in dem Thread haben Test gemacht mit "--strip-all" und die Symbole für die dynamische Verlinkung waren anscheinend dennoch vorhanden.

Vielleicht ist es einfach nur eine schlecht geschriebene Aussage in den man-pages, vielleicht sollte es heißen:

```

-s

--strip-all

Omit all symbols except symbols needed for dynamic linking

```

oder sowas in der Art.

Aber solange das nicht geklärt ist, kam ich zu der Schlussfolgerung, dass ich "-s" eben nur in Verbindung mit "-static" benutzen würde.

Ufz....sorry für den Roman, aber ich hoffe, es ist damit klar geworden, was ich meinte und welchen Widersprüche ich sehe.

Mal weg von der Theorie...wie viel bringt denn einen --strip-alles-außer-dynamic-linking-symbols?

Ein paar bytes? kilobytes?

Und build-time? Bei einem schnellen Rechner ein paar Sekunden? (wenn überhaupt)

Hat jemand Vergleichs-builds gemacht?  :Wink: 

Gruß,

Marcel

----------

## ian!

 *MaJor_PerMutation wrote:*   

> 
> 
> Ufz....sorry für den Roman, aber ich hoffe, es ist damit klar geworden, was ich meinte und welchen Widersprüche ich sehe.
> 
> 

 

Hey, gutes und aufschlussreiches Posting!  :Smile: 

 *MaJor_PerMutation wrote:*   

> 
> 
> Mal weg von der Theorie...wie viel bringt denn einen --strip-alles-außer-dynamic-linking-symbols?
> 
> Ein paar bytes? kilobytes?
> ...

 

Also so aus dem Bauch heraus würde ich mal sagen, daß es nicht die Welt sein kann. Ein vernünftig optimiertes System ist ja eine gute Sache. Aber ich möchte auch, dass die Kisten stabil laufen. Was nützt mir das ganze Optimieren, wenn ich vor lautem Optimierungswahn nicht mehr zu meiner eigentlichen Arbeit komme?

Einige Leute mussten ja auch schon feststellen, daß man mit übertriebenen CFLAGS wie CFLAGS="-O2^10 --pipe_from_hell --break_my_binarys --make_it_damn_fast --hell_yeah_i_don_not_know_what_i_am_doing_here --dont_give_a_shit"  :Wink:  die Binarys ja dann zur Laufzeit sogar wieder langsamer werden können. Oder die Binarys sind so aufgeblasen (Bsp. --funroll-loops), daß die Ladezeit wesentlich länger wird.

Nun ja, wie auch immer. Ich baue Systeme immer mit "--march="<arch>" -O3 --pipe --fomit-frame-pointer" und gut ist. Ich will mein Schicksal nicht herausfordern. Mehr Zeit auf Optimierungen zu verwenden, als ich die Zeit durch die schnelleren Programme wieder rausholen kann, entbehrt ja jeder Vernunft. Das es ein paar Jungs geben muss, die das auf Teufel komm raus austesten, ausreizen und dokumentieren finde ich eigentlich sehr gut. Aber es reicht, wenn die sich ihre Kisten schiessen. Dafür arbeite ich an anderen Baustellen...

 *MaJor_PerMutation wrote:*   

> 
> 
> Hat jemand Vergleichs-builds gemacht? 
> 
> 

 

Du wolltest dich als Freiwilliger melden?!  :Wink: 

Gruß,

ian!

----------

## unique

Find ich voll intressant des Thema,.... ich bin auch noch am rumbasteln.

Mein Hauptproblem ich bin in sachen englisch ziemlich gelackaft wenns darum geht n Howto oder irgendwelche manpages zu lesen ;/ ...d.H. ich komm leider damit net weiter, da ich gerade mal soviel Englisch kann um meine Grossmutter nach n Kecks zu fragen.  :Rolling Eyes: 

Des halb bin ich froh das es deutsche Comunitys gibt.  :Wink: 

Ich kompilier jetzt gento schon zum x-ten mal und find immer noch net die richtigen optimierungen, jetzt versuchs ich mal mit i686 vieleicht klappt jetzt alles.

Mein System : Athlon MP 1600+ ( 2CPUs )

Weiss jemand was des einzeln Optionen in etwa bedeuten? 

-pipe

-m3dnow 

-mmmx 

-msse 

-mfpmath=sse,387 

-finline-functions 

-fmerge-all-constants 

-fthread-jumps 

-fomit-frame-pointer 

-fexpensive-optimizations 

-ffast-math 

-fforce-addr 

-falign-functions=64 

-falign-jumps=4 

-falign-loops=4 

-frerun-cse-after-loop 

-frerun-loop-opt 

-fprefetch-loop-arrays 

-maccumulate-outgoing-args

...wobei ich mir bei -m3dnow -mmmx und -msse ziemlich sicher bin es mir vorstellen zu können.

Wenn ich mein System Fertig-Kompiliert hab sag ich bescheid mit was ich bis jetzt am besten gefahren bin.

MfG

Unique

----------

## sirro

Naja sind keine ausführlichen Erklärungen, aber vielleicht ein Anfang. Grundsätzlich sollte alles, was in -O2 oder kleiner enthalten ist keine Probleme machen.

Bei mir läuft:

Als Standart: "-mcpu=athlon-xp -march=athlon-xp -O3 -pipe -fomit-frame-pointer -m3dnow -msse -mfpmath=sse -mmmx -fforce-addr -ffast-math -falign-functions=4"

Für Server und ähnliches: "-mcpu=athlon-xp -march=athlon-xp -O3 -pipe -fomit-frame-pointer -fstack-protector -msse -mfpmath=sse -mmmx -fforce-addr -ffast-math -falign-functions=4"

Für Dosemu und was sonst noch so Probleme macht: "-mcpu=athlon-xp -march=athlon-xp -O2 -pipe -fomit-frame-pointer"

Bis auf bei bestimmten Programmen (z.B. Dosemu, OpenOffice) läuft das bei mir ohne Probleme. Und ja ich bin einer von der sorte "-placebo -hau_alles_rein_was_geht_auch_wenn_es_wahrscheinlich_gar_nix_bringt_hauptsache_ich_fühl_mich_gut_dabei"  :Wink: 

Normalerweise würde ich ja sagen "man gcc", aber wenn du wirklich kein Englisch kannst- (In der Linuxwelt ist das wohl leider sehr unvorteilhaft, du könnstest gerade bei Gentoo auf Probleme stoßen)

-pipe

Vorzugsweise Pipes statt temporäre Dateien beim kompilieren nutzen (mit dem GNU-Assembler kein Problem)

-finline-functions 

Std in -O3

Bindet "einfache" (der Compiler entscheidet) Funktionen direkt in den Code ein, wenn das bei allen Aufrufen dieser funktion gemacht wird, dann fällt der Extracode für fie Funktion weg.

-fmerge-all-constants 

Identische Konstanten oder variablen werden zusammengeführt. Die Option führt zu nicht Std-konformen Verhalten

-fomit-frame-pointer 

Aktiviert in -O -O2 -O3 -Os (warum gibt man es eigentlich dann noch extra an?)

Bewirkt, dass funktionen, die den FramePointer nicht benötigen, diesen nicht im Register behalten. (kann auf manchen Architekturen dazu führen, dass debugging unmöglich ist)

-fexpensive-optimizations 

Std in -O2 -O3 -Os

kleinere Optimierungen, die aber verhältnismäßig rechenintensiv sind. 

-ffast-math 

Setzt -fno-math-errno, -funsafe-math-optimizations, -fno-trap-ping-math, -ffinite-math-only and -fno-signaling-nans.

Aktiviert eine Preprozessoroption. Kann zu Problemen mit Programmen führen, die sich strikt an ISO/IEEE halten.

-falign-functions=64 

Std in -O2, -O3.

-falign-jumps=4 

Std in -O2, -O3.

-falign-loops=4 

Std in -O2, -O3.

-frerun-cse-after-loop 

Std in -O2, -O3, -Os

Beseitigt nach den Loop-Optimierungen nochmal "Unterausdrücke".

----------

## hoschi

hallo, eines frag ich mich schon die ganze zeit:

mir wurde gesagt das "athlon-xp" automatisch mmx, sse, 3dnow, 3dnow+ usw. enthält, was eben der prozzesor kann  :Very Happy: 

aber viele von euch verwenden trotzdem diese prozessor flags:

mcpu=athlon-xp -march=athlon-xp -O3 -pipe -fomit-frame-pointer -m3dnow -msse -mfpmath=sse -mmmx -fforce-addr -ffast-math -falign-functions=4

warum -m3dnow, -mmmx, -msse???

liegt es daran das nur -mcpu und nicht -march verwendet?

vielen dank im voraus  :Very Happy: 

----------

## thundersteele

Hab mal ein paar Infos zusammengesucht (auch weil es mich gerade selber interessiert hat). Stammt eigentlich alles von der   gcc Homepage. 

 *Quote:*   

> -march=cpu-type 
> 
> Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mcpu. Moreover, specifying -march=cpu-type implies -mcpu=cpu-type. 

 

D.h. es ist völlig überflüssig neben -march=xxx auch noch -mcpu=xxx zu definieren. Evtl. macht es einen unterschied wenn für die beiden Optionen unterschiedliche Prozessortypen angegeben werden, ich weis aber nicht was dann jeweils zuerst beachtet wird. 

Was -mmmx usw. betrifft:

Ich hab gerade in der Manual gesucht, dazu steht leider explizit nix drin. Im sourcecode von gcc ist das allerdings zu finden, zumindest wenn man dieser Seite vertraut:

http://www.freehackers.org/gentoo/gccflags/faq.html

So steht es auch in meiner 3.2.3 source. 

Man könnte natürlich auch benchmarks laufen lassen um zu testen ob es einen Unterschied macht diese Optionen nochmals extra anzugeben, ich denke aber es ist überflüssig. 

Warum es trotzdem gemacht wird kann ich nur vermuten:

1. Es sieht einfach schneller aus wenn der CFLAGS="..." Eintrag mehrere Zeilen lang ist. Placebo effekt eben.

2. Unwissenheit: Manche beschäftigen sich nicht genauer damit. In älteren gcc Versionen gab es zum glaube ich auch die pentium4 Option noch nicht, da musste man das dann von Hand einstellen. 

3. Es schadet normalerweise nicht, und vielleicht stimmt ja doch nicht alles was man woanders liest.

Man sieht auch immer wieder zwei- oder dreizeilige CFLAGS in denen viele Optionen drinstehen die schon mit -O3 eingeschalten werden. Die meisten Optionen bewirken eh nur minimale Veränderungen, teilweise sogar negative. Z.B. werden durch bestimmte Flags die binaries größer, sie laufen dann zwar vielleicht minimal schneller, das wird aber durch die höheren Ladezeiten wirder aufgefressen. Wahrscheinlich müsste man das für jedes Programm anders einstellen. 

Ausserdem sind für einige, vor allem größere Programme viele Kompilieroptionen abgeschaltet, da die Programme damit nichtmehr stabil laufen.

----------

## c07

 *thundersteele wrote:*   

> Man könnte natürlich auch benchmarks laufen lassen um zu testen ob es einen Unterschied macht diese Optionen nochmals extra anzugeben, ich denke aber es ist überflüssig.

 

Eigentlich sollte schon ein simples diff zwischen den Binarys reichen.

 *thundersteele wrote:*   

> Z.B. werden durch bestimmte Flags die binaries größer, sie laufen dann zwar vielleicht minimal schneller, das wird aber durch die höheren Ladezeiten wirder aufgefressen.

 

Das Problem damit sind weniger die Ladezeiten als die Tatsache, dass damit der Cache zugemüllt wird. Häufig ist aber gerade der der eigentliche Engpass, insbesondere bei Durons und Celerons. Wo das passiert, werden die Programme auch zur Laufzeit langsamer.

----------

## c07

 *sirro wrote:*   

> -fomit-frame-pointer 
> 
> Aktiviert in -O -O2 -O3 -Os (warum gibt man es eigentlich dann noch extra an?)

 

Das stimmt nur für Architekturen, wo der Framepointer nicht zum Debuggen notwendig ist, also nicht bei x86. Für alle, die den Code nicht debuggen wollen, ist das eine der wenigen sinnvollen Optionen jenseits von -O2 bzw. -O3.

----------

## c07

Nachdem sich das Gerücht mit -fomit-frame-pointer so hartnäckig hält, hier noch eine Anleitung, wie man das konkret überprüfen kann:

```
~/tmp $ echo "void f(){} int main(){f();}" > t.c

~/tmp $ gcc -fno-inline-functions -S -O3 -o t1.s t.c

~/tmp $ gcc -fno-inline-functions -S -O3 -fomit-frame-pointer -o t2.s t.c

~/tmp $ diff t1.s t2.s

7,9d6

<       pushl   %ebp

<       movl    %esp, %ebp

<       popl    %ebp

```

Nur mit -O3 wird also der Framepointer auf x86 selbst dann gesetzt, wenn er unmittelbar danach wieder gelöscht wird. In main() hilft übrigens selbst -fomit-frame-pointer nicht, deshalb die leere Funktion.

----------

## hoschi

@jeder

lese ich das richtig haus:

der hier compilierte code würde nicht auf einem athlon-xp, pentium3 etc. laufen, weil z.b (und genau darauf kommt es mir an!) sse2 verwendet wird?

gcc -v -Q -O3 -march=pentium4 -pipe -fomit-frame-pointer blah.c

Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/specs

Configured with: /var/tmp/portage/gcc-3.2.3-r2/work/gcc-3.2.3/configure --prefix =/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.2 --includedir=/usr/lib/gcc-lib/ i686-pc-linux-gnu/3.2.3/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/ 3.2 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man --infodir=/usr/share/ gcc-data/i686-pc-linux-gnu/3.2/info --enable-shared --host=i686-pc-linux-gnu --t arget=i686-pc-linux-gnu --with-system-zlib --enable-languages=c,c++,f77,objc,jav a --enable-threads=posix --enable-long-long --disable-checking --enable-cstdio=s tdio --enable-clocale=generic --enable-__cxa_atexit --enable-version-specific-ru ntime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/inclu de/g++-v3 --with-local-prefix=/usr/local --enable-shared --enable-nls --without- included-gettext

Thread model: posix

gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r2, propolice)

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/cc1 -lang-c -v -D__GNUC__=3 -D__GNUC_M INOR__=2 -D__GNUC_PATCHLEVEL__=3 -D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix -D__gn u_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__ -D__unix -D__ linux -Asystem=posix -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i38 6 -Di386 -D__i386 -D__i386__ -D__pentium4 -D__pentium4__ -D__tune_pentium4__ -D_ _SSE__ -D__MMX__ -D__SSE2__ blah.c -dumpbase blah.c -march=pentium4 -O3 -version -fomit-frame-pointer -o - |

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../../i686-pc-linux-gnu/bin/as - V -Qy -o /tmp/ccZBytF5.o -

GNU CPP version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r2, propolice) (cpplib) ( i386 Linux/ELF)

GNU C version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r2, propolice) (i686-pc-lin ux-gnu)

compiled by GNU C version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r2, pro police).

options passed: -lang-c -v -D__GNUC__=3 -D__GNUC_MINOR__=2

-D__GNUC_PATCHLEVEL__=3 -D__GXX_ABI_VERSION=102 -D__ELF__ -Dunix

-D__gnu_linux__ -Dlinux -D__ELF__ -D__unix__ -D__gnu_linux__ -D__linux__

-D__unix -D__linux -Asystem=posix -D__OPTIMIZE__ -D__STDC_HOSTED__=1

-Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__pentium4

-D__pentium4__ -D__tune_pentium4__ -D__SSE__ -D__MMX__ -D__SSE2__

-march=pentium4 -O3 -fomit-frame-pointer

options enabled: -feliminate-unused-debug-types -fdefer-pop

-fomit-frame-pointer -foptimize-sibling-calls -fcse-follow-jumps

-fcse-skip-blocks -fexpensive-optimizations -fthread-jumps

-fstrength-reduce -fpeephole -fforce-mem -ffunction-cse

-fkeep-static-consts -fcaller-saves -fpcc-struct-return -fgcse -fgcse-lm

-fgcse-sm -frerun-cse-after-loop -frerun-loop-opt

-fdelete-null-pointer-checks -fschedule-insns2 -fsched-interblock

-fsched-spec -fbranch-count-reg -freorder-blocks -frename-registers

-fcprop-registers -fcommon -fgnu-linker -fregmove -foptimize-register-move

-fargument-alias -fstrict-aliasing -fmerge-constants -fident -fpeephole2

-fguess-branch-probability -fmath-errno -ftrapping-math

-fno-stack-protector -m80387 -mhard-float -mno-soft-float -mieee-fp

-mfp-ret-in-387 -mcpu=pentium4 -march=pentium4

ignoring nonexistent directory "/usr/local/include"

ignoring nonexistent directory "/usr/i686-pc-linux-gnu/include"

#include "..." search starts here:

#include <...> search starts here:

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include

/usr/include

End of search list.

main

Execution times (seconds)

TOTAL : 0.01 0.00 0.02

GNU assembler version 2.14.90.0.6 (i686-pc-linux-gnu) using BFD version 2.14.90. 0.6 20030820

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/collect2 --eh-frame-hdr -m elf_i386 -d ynamic-linker /lib/ld-linux.so.2 /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../ ../crt1.o /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../crti.o /usr/lib/gcc- lib/i686-pc-linux-gnu/3.2.3/crtbegin.o -L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2. 3 -L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../../../i686-pc-linux-gnu/lib - L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/../../.. /tmp/ccZBytF5.o -lgcc -lgcc_e h -lc -lgcc -lgcc_eh /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/crtend.o /usr/lib/ gcc-lib/i686-pc-linux-gnu/3.2.3/../../../crtn.o

options passed?

kann man jetzt sehr frei übersetzen...ausgelassen oder durchgearbeitet?

----------

## hoschi

wenn ich -mmmx und co. angebe steh bei options enabled eben "-mmmx" dran, ansonsten nicht...

macht mich stutzig

----------

## deepthought

Aus dem Ebuild für GCC 3.3.1-r5 (Version beliebig austauschbar):

```
# The next command strips CFLAGS and CXXFLAGS from nearly all flags.  If

# you do not like it, comment it, but do not bugreport if you run into

# problems.

#

# <azarah@gentoo.org> (13 Oct 2002)

strip-flags
```

Insofern ist es bei der GCC-Installation herzlich egal, welche Optimierungen in CFLAGS stehen und welche nicht.[/code]

Viele Grüße,

Alexander

ps. Manchmal ist es doch ganz gut, vor sich selbst beschützt zu werden...

----------

## hoschi

ich hoffe du meinst nicht mich, denn ich habe nicht gcc compiliert oder so sondern eine fake-datei wie auf http://www.freehackers.org/gentoo/gccflags/faq.html beschrieben!

mich interessiert eben nur diese und wirklich diese frage brennend:

wurde dort oben mit sse2 kompiliert, weil wenn nicht dann reicht die angabe das cpu-typs bei kompilieren nicht aus und man muss  mmx, 3dnow, sse, see2 usw. von hand angeben!

deswegen nochmal:

wurde dort oben mit sse2 kompiliert?

----------

## c07

 *hoschi wrote:*   

> deswegen nochmal:
> 
> wurde dort oben mit sse2 kompiliert?

 

Probier es halt einfach mit was aus, wo es einen Unterschied macht:

```
~/tmp $ echo "int main() { return 9.9 * rand(); }" > t.c

~/tmp $ gcc -O3 -march=pentium4 -o a.out t.c

~/tmp $ gcc -O3 -march=pentium4 -mno-sse2 -o b.out t.c

~/tmp $ diff a.out b.out

Files a.out and b.out differ
```

----------

## deepthought

 *Donnergurgler wrote:*   

> Ich würde den CFLAGS noch "-s" hinzufügen.
> 
> man gcc:
> 
> -s  Remove all symbol table and relocation information from the exe-
> ...

 

Das ist (für alles, was mit emerge gebaut wird) überflüssig. portage/emerge entfernen sowieso alle Debug-Symbole aus dem Objektcode (es rauscht als "stripping <irgendwas" an einem vorbei). Man kann das Gleiche auch mit 

```
strip --strip-debug
```

erreichen.

Viele Grüße,

Alexander

----------

## hoschi

 *c07 wrote:*   

>  *hoschi wrote:*   deswegen nochmal:
> 
> wurde dort oben mit sse2 kompiliert? 
> 
> Probier es halt einfach mit was aus, wo es einen Unterschied macht:
> ...

 

er gibt mir nach diff keine antwort, sind die datein damit gleich  :Very Happy: 

übrigens: danke für den genialen tipp

----------

## c07

Wenn die Dateien gleich sind, kann das natürlich auch nur heißen, dass gcc sowieso keine Veranlassung gesehen hat, SSE2 zu benutzen. Deshalb in diesem Fall -msse2 und -mno-sse2 gegenchecken und gegebenenfalls die Testdatei ein bisschen komplizierter machen, bis es da einen Unterschied gibt. Das geht natürlich analog mit allen anderen Optionen.

----------

## foxtrott

Ich möchte mein System von stage1 aus komplett selber ertstellen.

Nun haben mich die Diskussionen hier über die CFLAGS ein wenig verunsichert, welche ich nehmen soll. Also habe ich mal in ein fertiges stage2 bzw. stage3 Archiv, das man sich von www.gentoo.org herunterladen kann, angeschaut. In der dortigen make.conf werden die CFLAGS so angegeben:

```
CFLAGS="-O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe"
```

Und da das runterladbare stage-Archiv ausdrücklich auf stbilität konfiguriert wurde, kann ein O3 doch nicht so verkehrt sein, oder?

Meine geplanten CFLAGS sind: 

```
CFLAGS="-O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -fomit-frame-pointer -falign-functions=4 -fforce-addr -pipe"

```

Irgendwelche Einwände, oder Tips von Leute die mehr Erfahrung mit Gentoo haben als ich?

mfg aus MeckPom

----------

## hoschi

ich würde die nehmen, erhebe aber keine garantie:

CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe"

O2=kleinerer code (da freut sich der cpu-cache), kürzerer compiler zeit, theoretische chance auf weniger compiler-fehler

O3=braucht länger zum kompilieren, soll manchmal leicht instabil werden können (ist glaub ich sehr subjektiv), größerer code

-march=pentium4 x86-686 +mmx +sse +sse2

funroll und pipe sind einfach, äh, "beliebt"   :Very Happy: 

-funroll-all-loops, wäre  noch erwehnenswert, manachmal hilfts, aber normaller weiße wird der code nur größer...

das problem beim selber kompilieren ist, das fast jedes packet eigentlich andere settings benötigen würde (die müsste man aber erst wissen und lernen und zweitens ständig ändern)  :Confused: 

edit: bissel spät dran  :Rolling Eyes: 

----------

## arkanlor

hatte mit -O3 und gcc 3.2.3 probleme, segfault bei xchat-2. dito bei cdrecord und anderen progs.

----------

## gentoo_neuling

hi,

ich bin immernoch am sourcen zusammenziehn werde aber hoffentlich am we anfangen können mit installation.

habe unter

http://gentoo.slinky.surrey.sfu.ca/cflagcollect/results.php

ne liste gefunden mit optimierungen.

kann mir jemand sagen wie sinnvoll unten das ist ?

```

-march=athlon-xp -mmmx -msse -m3dnow -freorder-blocks -fprefetch-loop-arrays -O3 -pipe

```

prozessor ist athlon xp 2100+

besser -O2?

ich wollte mein erstes gentoo nich gleich unstabil haben, deshalb frag ich lieber noch mal nach

----------

## amne

Ich fürchte, keiner wird dir mit 100%iger Sicherheit sagen können, ob deine Flags immer funktionieren werden. Entweder du probierst es mal aus   :Twisted Evil:  oder du hälst dich an die sicheren Flags (siehe Link auf Seite 1 dieses threads) von freehackers.org. Mit denen treten meines Wissens wirklich nur ganz selten Probleme auf.

----------

## Gekko

Dem kann ich mich hier nur voll und ganz anschliessen,

mit den Flags von Freehackers hatte ich noch nie Probleme.

Ich habe mehrere Stage1 auf verschiedenen Architekturen hinter mir, und nur bei einem Rechner Probleme gehabt - das allerdings aufgrund eines defekten Hauptspeichermoduls.

LG, Gekko

----------

## hoschi

CHOST="i686-pc-linux-gnu"

# Host and optimization settings 

# ==============================

#

#......

........

.........

#

# Decent examples:

#

#CFLAGS="-mcpu=athlon-xp -O3 -pipe"

CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer"

# If you set a CFLAGS above, then this line will set your default C++ flags to

# the same settings.

CXXFLAGS="${CFLAGS}"

bei cxxflags brauch ich ja nichts mehr wegen $, habs nimmer ganz in erinnerung (doch schon länger her  :Embarassed:   )

edit:

wie blöd kann man sein, da stehts doch  :Laughing: 

----------

## gentoo_neuling

jau dann werd ich erstmal die experimente lassen.

freehackers ist im moment tot aber vieleicht kommen die ja im laufe des tages wieder on

mfg gentoo_neuling

----------

## Michael_B

Es gibt nicht "die besten Flags ueberhaupt".

Ich habe af meinem Via C3 Nehemiah zum Beispiel weder -O2 noch -O3 im Einsatz, sonder -Os. Das gibt den kleineren Code und daher bei so wenig Cache das insgesamt schnellere Programm. Mit -O2 ist der Unterschied sehr gering, aber bei -O3 ist alles wesentlich langsamer. Ursache dabei ist das loop unrolling. Dabei kommt es dann halt oefter mal vor, dass die "ausgerollte" Schleife nicht mehr komplett in den Cache passt. Das kostet dann natuerlich jede Menge Strafzyklen.

Also, immer den Prozessor im Auge behalten, wenn man ueber die Flags nachdenkt. Bei kleinerem Cache eher an -Os oder -O2 denken. Bei Mega-Caches ist aber wohl -O3 die erste Wahl.

----------

## sarahb523

tja leider ist mein system jetzt schon fertig kompiliert und ich hab doch sowas wie die flags vergessen   :Crying or Very sad: 

Ich habe von der ganzen optimierung noch nich so den plan. Ich denke das ich bei meinem Rechner noch einiges rausholen kann.

cpu: Dual 433 MHz Celeron (die alten celerons)

Kann mir jemand sagen wie dazu das --march=? flag ist und wie man generelle smp unterstützung reinkompiliert?

thx

sarah

[/b][/quote]

----------

## reyneke

Hi,

bin auch eher Noob, was CFLAGS angeht, deshalb würde mich interessieren, ob diese Flags für einen "Mobile Intel(R) Pentium(R) 4 - M CPU 2.20GHz" (/proc/cpuinfo) Sinn machen:

 *Quote:*   

> 
> 
> CFLAGS="-march=pentium3 -mcpu=pentium4 -O2 -finline-functions -falign-jumps=5 -falign-loops=5 -falign-functions=64 -pipe"
> 
> 

 

Ich hab sie aus dem Howto von pi-cubic für seinen Toshiba-Lappie, der die gleiche CPU wie meiner haben dürfte. Bislang fahre ich eigentlich ganz gut damit, obwohl etwas Geschwindigkeit nicht schlecht wäre (allerdings nicht auf Kosten der Stabilität). Wäre es deshalb vielleicht besser, sich auf ein

 *Quote:*   

> 
> 
> CFLAGS="-march=pentium3 -mcpu=pentium4 -O2|3 -pipe"
> 
> 

 

zu beschränken?

Ich nehme an, "-march=pentium4" ist noch immer nicht zu empfehlen?

Gruß,

reyneke.

----------

## darksaidin

 *Michael_B wrote:*   

> Ich habe af meinem Via C3 Nehemiah zum Beispiel weder -O2 noch -O3 im Einsatz, sonder -Os. Das gibt den kleineren Code und daher bei so wenig Cache das insgesamt schnellere Programm.

 

Hast du das mal getestet? Wir sollten für die Uni vor kurzem ein paar Parameter vergleichen (gehörte zu einer Übung...) und was bei -Os rauskam war alles andere als schneller - wobei das natürlich nicht auf einem C3 war.

Wir hatten dazu ein simplen Primzahlgenerator geschrieben und der war mit -O etwa doppelt so schnell wie mit -Os. -O2 oder -O3 machten kaum messbare Unterschiede zu -O. Natürlich ist das kein sehr realitätsnaher Benchmark, aber trotzdem sollte das Ergebnis tendeziell richtig sein - zumindest für meine AthlonXp  :Very Happy: 

----------

## Stone

kann mir mal wer kurz die unterschiede von Os, O2 und O3 erklären?

ich verwende -march=athlon-xp -Os -funroll-loops -pipe -fomit-frame-pointer.

cpu ist ein amd xp 1600+ palio kern

----------

## sirro

 *Stone wrote:*   

> kann mir mal wer kurz die Unterschiede von Os, O2 und O3 erklären?

 

 :Arrow:  man gcc?

----------

## ian!

detached

----------

