# Cflags

## Beelzebub_

Hallo geehrte Linux Gemeinschaft,

Ich nutze einen Bulldozer und habe mich gefragt, ob es noch weitere nützliche CFLAGS gibt.

Dabei bin ich auf dieser Seite gelandet.

http://en.gentoo-wiki.com/wiki/Hardware_CFLAGS

Mich würde interessieren ob ihr es für Sinnvoll hält alle unterstützen CFLAGS zu aktivieren. Außerdem frage ich mich was so einige CFLAGS bewirken, leider habe ich keine Liste dazu im Web gefunden. 

Hier mal meine unterstützen CFLAGS:

```
  echo "" | gcc -march=native -v -E - 2>&1 | grep cc1

 /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1 -E -quiet -v - -march=bdver1 -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mabm -mlwp -mno-fma -mfma4 -mxop -mno-bmi -mno-tbm -mavx -msse4.2 -msse4.1 --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver1

```

Habe gerade noch was gefunden: 

http://gcc.gnu.org/onlinedocs/gcc-4.4.4/gcc/i386-and-x86_002d64-Options.html

http://gcc.gnu.org/onlinedocs/gcc-4.4.4/gcc/Option-Index.html#Option-Index

Die liste ist leider sehr veraltet bzw. es fehlen viele meiner cflags.

----------

## Christian99

unter http://gcc.gnu.org/onlinedocs/ findest du die doku zu allen gcc versionen

nimm doch einfach march=native als flag, dann musst du dir nicht über jedes einzelne gedanken machen.

----------

## slick

 *Christian99 wrote:*   

> nimm doch einfach march=native als flag, dann musst du dir nicht über jedes einzelne gedanken machen.

 

++

Ich habe schon schlechte Erfahrung gemacht mit überoptimierten Systemen. -native ist ausreichend. Dann hast immer noch die Wahlmöglichkeiten zwischen -Os bis -O3, wobei ich -Os bevorzuge.

----------

## Klaus Meier

Von -O3 wird bei gcc Version 4 abgeraten. Und man sollte immer eins bedenken: Pakete, die von wirklich hohen Optimierungen profitieren, die haben so etwas im Ebuild. Einfach mal zuschauen, wenn es übersetzt wird.

----------

## Beelzebub_

Ich habe trotzdem mal ein paar CFLAGS geändert, man soll ja keiner Studie vertrauen, welche man nicht selbst gefälscht hat.  :Wink: 

Vorher 

```
 CFLAGS="-O2 -pipe -fomit-frame-pointer -march=native " 
```

Nachher 

```
 CFLAGS="-O2 -pipe -fomit-frame-pointer -march=native -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mabm -mlwp -mno-fma 

 -mfma4 -mxop -mno-bmi -mno-tbm -mavx -msse4.2 -msse4.1 --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver1" 
```

Nach 5stunden und 50min war die Kompiliererei abgeschlossen. Man sollte nicht vergessen den Kernel neu zu bauen.

Ich muss sagen es hat sich gelohnt, ich hatte vorher CINEBENCH mit wine durch laufen lassen, damit ich vorher-nachher Werte habe. (unter den gleichen Bedingungen) Diese Methode ist zwar nicht die beste Methode aber sie reicht für meinen Zweck.

Vorher: 3.83

Nachher: 4.01

Das entspricht einer Übertaktung von 3300gHz auf 3900gHz. Wer seine CPU optimal nutzen möchte, kann ich nur empfehlen mal über  -march=native hinaus zu schauen.

----------

## slick

 *Beelzebub_ wrote:*   

> Nachher ...

 

Das poste bitte jetzt noch die Ausgabe von /proc/cpuinfo dazu damit auch jeder weiß welche CPU genau hier optimiert wurde und so mit deinen Angaben was anfangen kann.

----------

## franzf

Sorry, aber das ist absoluter Käse.

Du testest, was spezielle CFLAGS bringen anhand eines proprietären Windows-Programms, das in einem Emulator läuft?!?

Kannst du mal - rein interessehalber - ein emerge -pv wine zeigen?

Desweiteren bringt kernel neubauen gar nichts, der verwendet seine eigenen CFLAGS. Man kann zwar irgendwo einstellen, dass zum Bauen die optimierten Flags verwendet werden, würde ich aber nicht empfehlen.

Es spricht absolut gar nichts gegen march=native, und wenn man keine Ahnung hat was man da genau rumfummelt sollte man das auch tunlichst bei den empfohlenen minimalen Flags belassen!

http://en.gentoo-wiki.com/wiki/Safe_Cflags

----------

## Beelzebub_

Klar gerne, hier meine "emerge -pv wine"

```
 [ebuild   R    ] app-emulation/wine-1.5.11  USE="X alsa cups fontconfig gecko jpeg lcms ldap mono mp3 ncurses nls opengl oss perl png ssl threads truetype udisks win32 win64 xml -capi -custom-cflags -gnutls -gphoto2 -gsm (-gstreamer) -hardened -odbc -openal -opencl -osmesa -pulseaudio -samba -scanner (-selinux) -test -v4l -xcomposite -xinerama" 0 kB

```

Mir war auch klar dass das evtl. nicht optimal mit der Windows Benchmark ist. Ich denke jedoch, da beide Test absolut gleich waren, dass sie auch vergleichbar sind. Ich wollte nicht einfach schreiben das System verhält sich etwas schneller, da ich nur mein eigenes Vorher-Nachher Gefühl habe und das kein richtiger Beweis ist. Kennt jemand Linux-Benchmarks?, mir sind keine bekannt.

Bei dem Kernel kenne ich mich nicht aus, ich hatte das einfach angenommen. Bitte um Entschuldigung für den Fehler.

```
 cat /proc/cpuinfo

processor   : 0

vendor_id   : AuthenticAMD

cpu family   : 21

model      : 1

model name   : AMD FX(tm)-6100 Six-Core Processor             

stepping   : 2

microcode   : 0x6000613

cpu MHz      : 3314.198

cache size   : 2048 KB

physical id   : 0

siblings   : 6

core id      : 0

cpu cores   : 3

apicid      : 16

initial apicid   : 0

fpu      : yes

fpu_exception   : yes

cpuid level   : 13

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext perfctr_core arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold

bogomips   : 6628.39

TLB size   : 1536 4K pages

clflush size   : 64

cache_alignment   : 64

address sizes   : 48 bits physical, 48 bits virtual

power management: ts ttp tm 100mhzsteps hwpstate cpb

processor   : 1

vendor_id   : AuthenticAMD

cpu family   : 21

model      : 1

model name   : AMD FX(tm)-6100 Six-Core Processor             

stepping   : 2

microcode   : 0x6000613

cpu MHz      : 3314.198

cache size   : 2048 KB

physical id   : 0

siblings   : 6

core id      : 1

cpu cores   : 3

apicid      : 17

initial apicid   : 1

fpu      : yes

fpu_exception   : yes

cpuid level   : 13

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext perfctr_core arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold

bogomips   : 6628.39

TLB size   : 1536 4K pages

clflush size   : 64

cache_alignment   : 64

address sizes   : 48 bits physical, 48 bits virtual

power management: ts ttp tm 100mhzsteps hwpstate cpb

processor   : 2

vendor_id   : AuthenticAMD

cpu family   : 21

model      : 1

model name   : AMD FX(tm)-6100 Six-Core Processor             

stepping   : 2

microcode   : 0x6000613

cpu MHz      : 3314.198

cache size   : 2048 KB

physical id   : 0

siblings   : 6

core id      : 2

cpu cores   : 3

apicid      : 18

initial apicid   : 2

fpu      : yes

fpu_exception   : yes

cpuid level   : 13

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext perfctr_core arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold

bogomips   : 6628.39

TLB size   : 1536 4K pages

clflush size   : 64

cache_alignment   : 64

address sizes   : 48 bits physical, 48 bits virtual

power management: ts ttp tm 100mhzsteps hwpstate cpb

processor   : 3

vendor_id   : AuthenticAMD

cpu family   : 21

model      : 1

model name   : AMD FX(tm)-6100 Six-Core Processor             

stepping   : 2

microcode   : 0x6000613

cpu MHz      : 3314.198

cache size   : 2048 KB

physical id   : 0

siblings   : 6

core id      : 3

cpu cores   : 3

apicid      : 19

initial apicid   : 3

fpu      : yes

fpu_exception   : yes

cpuid level   : 13

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext perfctr_core arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold

bogomips   : 6628.39

TLB size   : 1536 4K pages

clflush size   : 64

cache_alignment   : 64

address sizes   : 48 bits physical, 48 bits virtual

power management: ts ttp tm 100mhzsteps hwpstate cpb

processor   : 4

vendor_id   : AuthenticAMD

cpu family   : 21

model      : 1

model name   : AMD FX(tm)-6100 Six-Core Processor             

stepping   : 2

microcode   : 0x6000613

cpu MHz      : 3314.198

cache size   : 2048 KB

physical id   : 0

siblings   : 6

core id      : 4

cpu cores   : 3

apicid      : 20

initial apicid   : 4

fpu      : yes

fpu_exception   : yes

cpuid level   : 13

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext perfctr_core arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold

bogomips   : 6628.39

TLB size   : 1536 4K pages

clflush size   : 64

cache_alignment   : 64

address sizes   : 48 bits physical, 48 bits virtual

power management: ts ttp tm 100mhzsteps hwpstate cpb

processor   : 5

vendor_id   : AuthenticAMD

cpu family   : 21

model      : 1

model name   : AMD FX(tm)-6100 Six-Core Processor             

stepping   : 2

microcode   : 0x6000613

cpu MHz      : 3314.198

cache size   : 2048 KB

physical id   : 0

siblings   : 6

core id      : 5

cpu cores   : 3

apicid      : 21

initial apicid   : 5

fpu      : yes

fpu_exception   : yes

cpuid level   : 13

wp      : yes

flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext perfctr_core arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold

bogomips   : 6628.39

TLB size   : 1536 4K pages

clflush size   : 64

cache_alignment   : 64

address sizes   : 48 bits physical, 48 bits virtual

power management: ts ttp tm 100mhzsteps hwpstate cpb

```

----------

## bell

 *Quote:*   

> echo "" | gcc -march=native -v -E - 2>&1 | grep cc1
> 
>  /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1 -E -quiet -v - -march=bdver1 -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mabm -mlwp -mno-fma -mfma4 -mxop -mno-bmi -mno-tbm -mavx -msse4.2 -msse4.1 --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver1 

 Ok, der GCC löst -march=native in diese vielen Parameter auf.

 *Quote:*   

> Nachher
> 
> Code:
> 
>  CFLAGS="-O2 -pipe -fomit-frame-pointer -march=native -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mabm -mlwp -mno-fma -mfma4 -mxop -mno-bmi -mno-tbm -mavx -msse4.2 -msse4.1 --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver1"
> ...

 Aber das sind doch genau die selben Parameter die sowieso bereits im "native" stecken! Es hat sich also an der Optimierung nichts verändert. Die Vorher und Nachher Einstellungen sind identisch.

----------

## Max Steel

 *Beelzebub_ wrote:*   

> Klar gerne, hier meine "emerge -pv wine"
> 
> ```
>  [ebuild   R    ] app-emulation/wine-1.5.11  USE="X alsa cups fontconfig gecko jpeg lcms ldap mono mp3 ncurses nls opengl oss perl png ssl threads truetype udisks win32 win64 xml -capi -custom-cflags -gnutls -gphoto2 -gsm (-gstreamer) -hardened -odbc -openal -opencl -osmesa -pulseaudio -samba -scanner (-selinux) -test -v4l -xcomposite -xinerama" 0 kB
> 
> ...

 

Das USE-Flag custom-cflags bewirkt in einigen PRogrammen die Verwendung eigener, per make.conf CFLAGS= und CXXFLAGS= eingestellten, CFLAGS  :Wink:  Somit ist auch wine in beiden Fällen genau gleich kompiliert.

----------

## Beelzebub_

Da liegst du leider Falsch,

oder um es Positiv zu formulieren fast richtig.

Ich habe mir vorher angeschaut, welche CFLAGS von -march=native automatisch mit aktiviert werden. Einige waren wie du vermutest hast dabei, aber viele waren auch nicht dabei.

Ich habe nicht 5h50m blind kompiliert. 

Finde den Befehl dazu gerade nicht, werde ihn später posten

----------

## Beelzebub_

 *Max Steel wrote:*   

>  *Beelzebub_ wrote:*   Klar gerne, hier meine "emerge -pv wine"
> 
> ```
>  [ebuild   R    ] app-emulation/wine-1.5.11  USE="X alsa cups fontconfig gecko jpeg lcms ldap mono mp3 ncurses nls opengl oss perl png ssl threads truetype udisks win32 win64 xml -capi -custom-cflags -gnutls -gphoto2 -gsm (-gstreamer) -hardened -odbc -openal -opencl -osmesa -pulseaudio -samba -scanner (-selinux) -test -v4l -xcomposite -xinerama" 0 kB
> 
> ...

 

Hmm, gut zu wissen.

Aber ich hoffe das ist nicht bei allen Programmen so, dann hättest du recht. Aber auch wenn wine genau gleich blieb, der Unterbau des Systems wurde verbessert. 

Ist das -custom-flags sinnvoll? Bzw wo kann ich die CFLAGS aktivierten des Pakets sehen?

----------

## Beelzebub_

 *bell wrote:*   

>  *Quote:*   echo "" | gcc -march=native -v -E - 2>&1 | grep cc1
> 
>  /usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/cc1 -E -quiet -v - -march=bdver1 -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mabm -mlwp -mno-fma -mfma4 -mxop -mno-bmi -mno-tbm -mavx -msse4.2 -msse4.1 --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver1  Ok, der GCC löst -march=native in diese vielen Parameter auf.
> 
>  *Quote:*   Nachher
> ...

 

Das ist die Frage. So wie ich das hier verstanden habe (http://en.gentoo-wiki.com/wiki/Hardware_CFLAGS) werden mir alle möglichen CFLAGS meiner nativen CPU angezeigt.

----------

## Max Steel

 *Beelzebub_ wrote:*   

> 
> 
> Hmm, gut zu wissen.
> 
> Aber ich hoffe das ist nicht bei allen Programmen so, dann hättest du recht. Aber auch wenn wine genau gleich blieb, der Unterbau des Systems wurde verbessert.

 

Stellenweiße ja. Stellenweiße gibt es auch CFLAGS welche bei einem Programm nutzen, bei anderen sich wiederum gegenteilig auswirken werden.

 *Beelzebub_ wrote:*   

> Ist das -custom-flags sinnvoll? Bzw wo kann ich die CFLAGS aktivierten des Pakets sehen?

 

Meistens wird -custom-cflags dort verwendet, wo das Compilat relativ allergisch auf die falschen Flags reagiert (also das es evtl nicht kompiliert oder zu Laufzeitfehlern führen wird (Wahrscheinlichkeit >99%).

Manchmal (Fallwahrscheinlichkeit <1%) geht es auch um Performance, falls das Compilat durch besondere Flags so in der Performance negativ beeinflusst wird damit dieses nicht oder nur ungenau arbeiten wrd (wenn dann wird sowas im Simulations oder Scientific Bereich gebraucht).

----------

## Beelzebub_

@bell vielleicht hast du recht.

Ich frage mich was das (http://en.gentoo-wiki.com/wiki/Hardware_CFLAGS) für einen Sinn macht, wenn der Effekt 0 ist. 

Außerdem frage ich mich mit welchem Befehl ich alle möglichen CFLAGS für meine CPU herausfinde.

----------

## franzf

 *Max Steel wrote:*   

> Somit ist auch wine in beiden Fällen genau gleich kompiliert.

 

Und eben genau custom-cflags war der Grund, warum ich danach gefragt hatte  :Wink:  Das wäre mMn. der letzte Strohhalm gewesen, an dem man die Performance-Fahne hätte hissen können. Oder so.

Und ja, du kannst auch unter Linux nativ benchen. Schau dir mal die phoronix-test-suite an (wobei das auch nur ein "bequemeres" Interface für als Benchmark heranziehbare Programme ist)

Und custom-cflags bitte jetzt nicht global in die make.conf nehmen! Hat schon seinen Grund, warum da "unsupported" mit in der Beschriebung steht:

```
$ quse -D custom-cflags

 global:custom-cflags: Build with user-specified CFLAGS (unsupported)

 local:custom-cflags:app-emulation/wine: Bypass strip-flags; use are your own peril
```

----------

## bell

Mit 'echo "" | gcc ....' hast Du ja bereits die empfohlenen Flags rausgefunden, die auch automatisch gesetzt werden wenn Du "-march=native" nutzt.

Wenn Du noch mehr optimieren willst, so hat Max Steel ja bereits angemerkt, dass unterschiedliche Programme unterschiedlich auf die Optimierungen reagieren. Dh. diese Zusatz-Optimierungen gehören pro Paket in die /etc/portage/package.cflags. Aber da muss man sich mit den Tiefen des GCC und mit den Tiefen der jeweiligen Anwendungen sich auskennen oder viel Zeit haben zum ausprobieren und benchmarken.

Der Beitrag Hardware_CFLAGS macht schon Sinn bei Szenarien wo mann kein "native" nutzen kann. Dies ist zB. bei Cross-Compiling und bei der Nutzung von distcc der Fall.

----------

## cryptosteve

Reagieren denn heute immer noch viele Programme eher allergisch auf allzu gutgemeinte Optimierungen?

P.S.: Ich dachte, diese funroll-loops-Geschichte hätten wir vor Jahren hinter uns gelassen.  :Wink: 

----------

## mrueg

 *cryptosteve wrote:*   

> 
> 
> P.S.: Ich dachte, diese funroll-loops-Geschichte hätten wir vor Jahren hinter uns gelassen. 

 

du meinst sicher http://funroll-loops.info/  :Wink: 

wundert mich eigentlich dass der link in dem thread noch nicht aufgetaucht ist.

----------

## cryptosteve

 *mrueg wrote:*   

>  *cryptosteve wrote:*   
> 
> P.S.: Ich dachte, diese funroll-loops-Geschichte hätten wir vor Jahren hinter uns gelassen.  
> 
> du meinst sicher http://funroll-loops.info/ 

 

Na klar!   :Laughing: 

Aber vielleicht ist's heute nicht mehr so "dramatisch" und verpufft einfach so ... was es nicht weniger sinnvoll machen würde.

----------

## Klaus Meier

 *Beelzebub_ wrote:*   

> Ich habe trotzdem mal ein paar CFLAGS geändert, man soll ja keiner Studie vertrauen, welche man nicht selbst gefälscht hat. 
> 
> Vorher 
> 
> ```
> ...

 

Ich sage dazu nur eins: Absoluter Unfug. Du hast da eine Steigerung von nicht mal 5% erziehlt. Im normalen Desktopbetrieb sind Steigerungen von 50% deutlich zu spüren, welche unter 20% merkt man absolut nicht. Warum den Kernel neu kompilieren? Der Kernel wird doch mit cflags gebaut, die nichts mit der make.conf zu tun haben. Oder hast du das Makefile vom Kernel auch modifiziert? Warum gibst du beim Kernel eine um 20% höhere Taktfrequenz an, wenn der Benchmark gerade mal um 4,5% schneller läuft?

Ansonsten, das habe ich ja geschrieben, gibt es schon einige Anwendungen, die von höheren Optimierungen profitieren. Aber warum wegen dieser Handvoll Anwendungen das ganze System damit übersetzen? Werden jetzt Dateien schneller kopiert? Startet dein System schneller? Kannst du Fenster schneller verschieben? Hast du schon irgend einen Unterschied gespürt, außer diesem einen Benchmark? Aber: Hast du wichtige Programme darauf hin überprüft, ob sie auch korrekte Ergebnisse liefern? Die Tatsache, dass sich ein überoptimiertes Programm kompilieren lässt, bedeutet noch lange nicht, dass die Ergebnisse korrekt sind.

Hochoptimierte Anwendungen sind sinnvoll fürs Numbercrunching oder so etwas. Im Desktopbetrieb sind zum größten Teil die Ladezeiten und das Linken dafür verantwortlich, wie schnell du dein System empfindest. Und da kann oftmals -Os nützlicher sein, weil die Anwendungen schneller geladen werden. Habe ich aber selber noch nie getestet.

Und ansonsten gibt es viele Effekte. Ich habe hier mal vor langer Zeit gepostet, ext4 seit um 20% schenller als ext3. Und dann festgestellt, dass es daran lag, dass ich das fs neu angelegt habe. Ein fsck -fD hatte den gleichen Effekt. Eventuell hätte ein emerge -e world mit den gleichen Flags einen ähnlichen Effekt.

Und ansonsten, liegt denn der Cinebench im Quellcode vor? Das ist doch ein Windowsprogramm. Was haben denn die Flags in der make.conf für einen Einfluss auf Cinebench? Irgend etwas ist da passiert, das glaube ich gerne, aber ob es an den Cflags liegt? Nur als Beispiel, lass den Benchmark doch 10x durchlaufen und schau dann mal, in was für einen Breite die Werte streuen. Eventuell liefen da andere Hintergrundprozesse.

Ich habe da ganz am Anfang auch ewig dran rumprobiert. Mach dir keine Sorgen, dass legt sich irgendwann mal...

----------

## Beelzebub_

Wie bell mich bereits darauf aufmerksam gemacht hat, hat sich nichts am Code durch meine Scheinoptimierung getan. Diese Optimierung war Unfug von mir.

Ich bin stets am herum experimentieren/lernen. 

"Never change a working system." Ist überhaupt nicht meine Art.  :Wink: 

----------

## schmidicom

 *franzf wrote:*   

> Desweiteren bringt kernel neubauen gar nichts, der verwendet seine eigenen CFLAGS. Man kann zwar irgendwo einstellen, dass zum Bauen die optimierten Flags verwendet werden, würde ich aber nicht empfehlen.

 

Lass mich raten, diese Einstellungen werden erst sichtbar wenn man dort in den Expertmode geht stimts?

Irgendwie glaube ich nicht das es "gesund" wäre wenn die breite Masse hier, inklusive meiner Wenigkeit, an solchen Einstellungen herumschrauben würde.   :Wink: 

----------

## Christian99

Ich hab ne ganze weile mal zen-sources verwendet, da gabs eine Option für march=native und ich glaube auf für O2. Ich hatte das aktiviert, und hatte (deswegen) nie Probleme.

----------

## franzf

 *Christian99 wrote:*   

> Ich hab ne ganze weile mal zen-sources verwendet, da gabs eine Option für march=native und ich glaube auf für O2. Ich hatte das aktiviert, und hatte (deswegen) nie Probleme.

 

Da bringst du mich auf was...

Kann sein dass ich das auch da gesehen hab (bzw. in den pf-sources) und nicht im vanilla... Bei mir hat es aber Probleme bereitet, drum hab ich das schnell wieder ausgemacht.

Hast du denn einen Performancesprung gespürt?

----------

## Klaus Meier

Also im Makefile für meinen Kernel steht -O2. Und den Prozessortyp stellt man doch auch ein. Also ich glaube nicht, dass da extrem viel zu holen ist.

----------

## bell

Ich probiere mal die gentoo-sources mit "native" zu übersetzen. Danke für den Hinweis, ich mag auch mein System optimieren.

Laut einigen Forenbeiträgen reicht es vor dem Kompilieren die variablen KCFLAGS= und KCPPFLAGS zu exportieren.

----------

## Beelzebub_

Ich habe mein System mal mit O3 übersetzt. Einen Geschwindigkeitsunterschied kann ich so nicht feststellen, da mein System eh schon sehr schnell ist. Aber ich freue mich das mein Arbeitsspeicher mehr genutzt ist. Da ich 12GB RAM habe sollte es kein Problem sein. Ich denke das -O3 von Vorteil ist, wenn man wenig Anwendungen offen hat und -Os bei vielen Sinn macht.

----------

## Christian99

 *franzf wrote:*   

>  *Christian99 wrote:*   Ich hab ne ganze weile mal zen-sources verwendet, da gabs eine Option für march=native und ich glaube auf für O2. Ich hatte das aktiviert, und hatte (deswegen) nie Probleme. 
> 
> Da bringst du mich auf was...
> 
> Kann sein dass ich das auch da gesehen hab (bzw. in den pf-sources) und nicht im vanilla... Bei mir hat es aber Probleme bereitet, drum hab ich das schnell wieder ausgemacht.
> ...

 

nun ja, sprung würd ich es nicht nennen. außerdem hab ich zu der auch noch den brainfuckscheduler verwendet, weswegen ich nicht sagen kann was von was kam, aber ein bisschen war es schneller hätte ich gedacht.

Aber ohne genaue messungen, nur persönlicher eindruck.

 *Beelzebub_ wrote:*   

> Aber ich freue mich das mein Arbeitsspeicher mehr genutzt ist.

 

ähm, diese aussage ist ein bisschen komisch. wenn deine Programme mehr speicher brauchen, brauchen sie auch mehr Zeit um geladen zu werden. das würd ich jetzt nicht als optimierung bezeichnen.

----------

## bell

So, mein Kernel ist jetzt "native". 

Als Benchmark habe ich 

```
time seq 100000
```

genommen (mir ist nicht besseres Eingefallen).

vorher:

```
real   0m1.274s

user   0m0.085s

sys   0m0.180s
```

nachher

```
real   0m1.261s

user   0m0.057s

sys   0m0.117s
```

"system" und "user" sind also besser geworden. "real" ist das selbe. Wie kann man diese Zahlen deuten?

----------

## Klaus Meier

Das besagt, dass dieser "Benchmark" von der Ausgabegeschwindigkeit deines Terminals bestimmt wird. Und egal was du machst, dies ist der limitierende Faktor.

----------

## Treborius

 *bell wrote:*   

> So, mein Kernel ist jetzt "native". 
> 
> Als Benchmark habe ich 
> 
> ```
> ...

 

grob übersetzt heisst das :

das program braucht zur ausführung immernoch genausoviel zeit (real)

aber es macht in der zeit weniger (sys + user) 

seq ist dafür also völlig ungeeignet, komprimier den linux kernel, oder compilier ihn, das dürfe aussagekräftiger sein

----------

## Beelzebub_

 *Christian99 wrote:*   

> 
> 
>  *Beelzebub_ wrote:*   Aber ich freue mich das mein Arbeitsspeicher mehr genutzt ist. 
> 
> ähm, diese aussage ist ein bisschen komisch. wenn deine Programme mehr speicher brauchen, brauchen sie auch mehr Zeit um geladen zu werden. das würd ich jetzt nicht als optimierung bezeichnen.

 

(Die Zeit von der SSD in den RAM ist nicht so gravierend.

Wenn sie geladen sind, arbeiten sie schneller. =)

Das ist die Optimierung.

----------

## Christian99

 *Beelzebub_ wrote:*   

> 
> 
> Wenn sie geladen sind, arbeiten sie schneller. =)
> 
> 

 

wie kommst du da drauf? weil sie mehr platz im speicher brauchen?

----------

## Beelzebub_

Weil der Code optimiert ist?

----------

## mrueg

Lasst mich kurz raten, bei all euren "Benchmarks" habt ihr noch ein DE nebenbei laufen? Glückwunsch, damit ist das Ding höchstens für die eigene Psyche brauchbar. 

Wenn ihr unbedingt auf Optimierung aus seid, schaut euch lieber http://clang.llvm.org/ an, kompiliert damit rum und produziert nebenbei ein paar sinnvolle Bugreports als irgendwelche kruden CFLAG Experimente.

----------

## Klaus Meier

Es artet hier langsam in einen peinlichen Kindergarten aus. Es werden "Benchmarks" gemacht, wo man nur noch mit dem Kopf schütteln kann. Ein Windowsprogramm unter wine? Textausgabe in der Konsole? Es werden die Programme aufgebläht, damit der Speicher ausgelastet wird, weil ja die SSD so unglaublich schnell ist? Meine Güte, der langsamste RAM ist immer noch um den Faktor 1000 schneller als die schnellste SSD.

Bei aktuellen Desktopsystemen sind die Ladezeiten bei 99% der Anwendungen der limitierende Faktor. Als nächstes kommen die Linkzeiten. Deshalb bringt ja eine SSD mehr als hundert neue Cflags. Und das bremst man dann wieder aus, indem man die Anwendungen absichtlich aufbläht? lto wird dann der nächste Schritt sein, aber das ist noch nicht so weit. Dann gibt es im portage so etwas wie app-benchmark.

Und dann macht euch mal Gedanken über eure Messgenauigkeit. 4,5% Steigerung werden als großer Erfolg gefeiert und ich sage mal, die Messgenauigkeit ist nicht mal 10%. Wisst ihr, was Messgenauigkeit ist? Zu jedem Messwert gehört eine Angabe seiner Genauigkeit. Ich musste in meinem Studium mal so etwas angeben. Also, z.B, 10,5 plus/minus 0,2. Sollte ich da 10,5 plus/minus 2 geschrieben haben, hätte man es mir um die Ohren gehauen bekommen. Denn bei einer Fehlerbreite von 20% ist die 0,5 eine nicht vorhandene Genauigkeit. Es hätte also 10 plus/minus 2 heißen müssen. Ihr arbeiten auf einem Mulituser/Multitaskingsystem, wo viele Anwendungen im Hintergrund laufen. Ist es garantiert, dass da immer die gleichen liefen? Und ansonsten, wenn ich z.B. meinen Kernel übersetze, das ist beim ersten Mal immer am langsamsten. Warum? Weil da alles geladen werden muss. Und es beim nächsten Mal im Filecache ist.

Das ist inzwischen wie bei PC-Blöd. 100 000 Tips für ein schnelleres Windows. Glaubt ihr, sowohl bei Microsoft als auch bei Gentoo wird ein System ausgeliefert, was man absichtlich so langsam macht, dass man es mit drei Klicks merkbar schneller bekommt? In der c't werden ja öfters mal Tuningtools für Windows getestet. Ergebnis: Die besten haben gar nichts gemacht, weil sie nicht mal Administratorrechte hatten und deshalb nichts verändern konnten. Jedes Programm, was irgendetwas verändert hat, hat das System verlangsamt.

----------

## Beelzebub_

 *Klaus Meier wrote:*   

> Es artet hier langsam in einen peinlichen Kindergarten aus. Es werden "Benchmarks" gemacht, wo man nur noch mit dem Kopf schütteln kann. Ein Windowsprogramm unter wine? Textausgabe in der Konsole? Es werden die Programme aufgebläht, damit der Speicher ausgelastet wird, weil ja die SSD so unglaublich schnell ist? Meine Güte, der langsamste RAM ist immer noch um den Faktor 1000 schneller als die schnellste SSD.
> 
> 

 

Ich habe im betrieb fast keinen Zugriff auf meine SSD, weil ich beim Systemstart alle wichtigen/oft genutzten Programme  in meinen 1000x schnelleren RAM laden lasse.

//Edit: Aber ich denke ein fatalerer Trichter ist der CPU cache.  Weshalb Os eigentlich auch für moderne CPUS gut seien müsste.

----------

## mrueg

 *Beelzebub_ wrote:*   

> 
> 
> //Edit: Aber ich denke ein fatalerer Trichter ist der CPU cache.  Weshalb Os eigentlich auch für moderne CPUS gut seien müsste.

 

Wenn du eingebettete Systeme zu Systemen mit moderner CPU zählst, hast du vllt. Recht. Aber ich vermute dein Desktop mit der SSD zählt nicht wirklich dazu.

Du kannst entweder Laufzeit oder Fläche (Speicherplatz) optimieren und -Os tut letzteres. 

Es aktiviert nämlich alle Flags die mit -O2 auch aktiviert werden, ohne die, die die Größe des Kompilats erhöhen.

siehe auch: http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Ergo: -Os ist im Normalfall sogar langsamer* als -O2.

Übrigens zu -O2 vs. -O3 hier ein etwas älterer (noch auf gcc-3 bezogener) Artikel:

http://freecode.com/articles/gcc-myths-and-facts

----------

## Gentoo-kid

Man sollte sich genau ueberlegen, was man mit dem Rechner anstellt:

Welche Programme man zb oft in den Speicher laed und wieder beendet, 

was die Programme genau machen, ob und wie sie rechnen.

Welche Programme man zb ueber Nacht rechnen laesst, waehrend der Rechner sonst nichts tut 

und wie er die Rechneungen macht, wieviel Speicher er braucht zb, wie oft welche Schleifen durchlaufen werden.

Nur dann kann man abschaetzen, ob ein "optimierter" Code was bringt und wie man ihn optimieren muss.

Soweit ich abschaetzen kann, bringt das Ganze ueberhaupt erst was auf Rechnern, 

die fuer einen ganz speziellen  Anwendungsbereich gedacht sind. 

Und dann sollte man die Flags fuer jede binary individuell anpassen.

Global definierte flags moegen bei einer Anwendung Vorteile bringen, bei der Anderen evtl Nachteile.

----------

